什么是”服务“？

作者简介

Gavin，程序员、软件架构师、企业架构师，关注智能制造。

本文是专栏《智能制造系统架构》中的文章，其它文章请参阅入坑智能制造系统架构。

服务是一个IT领域里说烂了的词，天天挂在嘴边的概念，不同人却能讲出不同的说法。结果就是侃侃而谈了半天，发现是鸡同鸭讲。

背景

现在聊IT，服务这个词出现的频率越来越高。上世纪九十年代末SOA（面向服务架构）兴起，业务组件服务化成为企业架构讨论的热点。2006年云计算提出后，又引出了XaaS (Everything As A Service)模式。比如IaaS（Infrastructure As A Service, 基础设施即服务），PaaS（Platform As A Service，平台即服务）或SaaS（Software As A Service，软件即服务），及所谓Anything As A Service。然后是基于PaaS平台的概念又催生了范围更广，影响更大的平台概念。比如工业互联网，2013年通用电气提出工业互联网概念来应对德国提出的“工业4.0"，并推出了Predix平台来与西门子的Mindsphere平台分庭抗礼。这两个平台的发展几经沉浮，但不论哪个平台架构图中的最中间位置永远都是一片醒目的PaaS。现如今，工业互联网概念在中国又热炒起来，高度和外延越来越大，但核心模式没有变化。
Facebook成功后，开放平台战略在国内外兴起。一时间百度、阿里、腾讯、新浪众多互联网公司都推出了Open API平台，平台战略和生态思维催生了诸如百度系、阿里系、腾讯系的各类大小应用。2015年底，阿里巴巴集团提出所谓“大中台，小前台”战略，通过将核心业务中公共的、通用的业务以服务的方式沉淀到共享服务中心打破原有的“烟囱式”的系统建设模式。同时，Thought Works也提出了“数字化平台战略”。
最后提一下近几年大火的“微服务”，从2005年PeterRodgers提出微服务概念开始，发展至今，这个与SOA有点傻傻分不清楚的架构模式让人似乎一夜间觉得服务化和分布式才是王道，单体应用成为了众多架构师宣传微服务架构时必然批判挞伐的对象。特别是借助云计算与容器技术发展，云原生架构（Cloud Native Architecture）已成潮流，其核心依然是微服务架构。
如此，你会发现不讲服务你还真不太好意思说你在搞IT，那么这些服务都是一回事吗？如果不是一回事，各自都要表达什么样的含义？

营销学中的服务，满足用户需求的活动

先说营销学中的服务。对企业而言，产品是企业获得利润的基本途径。根据菲利普·科特勒的一个著名的营销学术观点，产品是市场上任何可以让人注意、获取、使用、或能够满足某种消费需求和欲望的东西。所以，产品可以是实体产品（例如，麦片、汽车）、服务（例如航空公司、银行）、人（例如演员、体育运动员）、组织（艺术团体、非营利性组织）、地名（城市、旅游景点）、思想（政治、社会原因）。
因此，服务可以认为是企业产品的一个类别。服务是具有无形特征却可给人带来某种利益或满足感的可供有偿转让的一种或一系列活动。比如房产中介，咨询，教育都可以称为服务。即使制造商、分销商和零售商也开始提供增值服务或更好的顾客服务，以此与竞争对手进行差异化。许多纯服务型公司现在都在使用互联网与顾客进行接触，从头到尾完完全全在线上操作。梁宁在她的课程里讲过腾讯关于产品和服务的理解，我将其理解为服务就是满足用户的最终需求。以打孔机生产企业为例，其用户的需求是什么？是要拥有一个打孔机吗？不是。用户的需求是家里的墙上要有一个孔。所以，以产品为核心，企业关注的是如何打造一款好的打孔机；而如果以服务为核心，企业关注的是如何帮用户得到想要的那个孔。这种思维方式的转变会影响企业的战略。比如汽车制造企业，核心目标不再只是造好一台车，而是优化用户的出行体验；ERP厂商核心目标也不是做好一款软件，而是提高客户企业资源管理效率，降低管理成本，准时把恰当的物料放到恰当的位置。
但是在IT领域，因为软件本身就是无形的，所以营销学概念上的服务和产品本身功能上或架构上的服务就很容易混淆。所以厂商可能一会儿将自己的产品叫成服务，一会儿将自己提供的二、三线运维叫做服务，一会儿将产品中的功能叫做服务，一会儿将可对外开放的API叫做服务。结果在企业架构的全景图里混杂了一堆本不是一码事的东西。

X As A Service, 随用随取，按需付费

另一个“服务”经常出现的地方就是云平台，云平台上的资源都是通过服务的形式卖给客户的。那么云平台中的服务是营销学概念里的服务吗？不是。这就要说一下XaaS。
XaaS（Everything As A Service），也称为Flexible consumption models (FCMs)。它描述的是一种消费模式，在这种消费模式下，你只为你实际使用的付费。
举个例子，IaaS (Infrastructure As A Service)将基础设施分成计算资源、存储资源和网络资源三个类别以随用随取的方式提供机房中服务器、存储和网络交换机、路由器等同的能力。传统模式下，实施软件系统需要先搭建软硬件环境，其资源配置是需要考虑未来数年的业务需求的，并且需要预支硬件使用生命周期内全部的一次性部署成本。打个比方，预估支撑一个系统未来5年运行需要一台20万的服务器，不会因为你只使用一年就可以只花4万，或者前期资源消耗不大可能只需1万，购买这台服务器就只能花费20万。但IaaS就提供了这种灵活性，当前需要多少核的CPU，多少G内存就购买多大的配置，使用了多久的资源就支付相应的费用，都以当前实际所需所用为基础。
PaaS (Platform As A Service) 也是如此，将系统开发的基础工具、组件以服务的方式交付给用户。典型的PaaS云平台核心功能都是提供封装好的，弹性的运行时环境。通过容器技术将诸如JRE，Web Container等打包起来封装成轻量级彼此隔离的运行环境，然后再通过诸如K8S等工具实现多容器的编排和集群管理。除此之外，再配套一些常用的基础组件也封装成服务提供给用户，有了这些基础服务的加持也就形成了各类各具特色的PaaS平台。比如Cloud Foundary可以提供MySql, Redis ,Jenkins等应用开发所必须的基础服务，是比较通用的用于应用开发的PaaS平台；而Predix、Mindsphere可以在Cloud Foundary基础上提供面向特定工业领域的数据采集、数据分析基础服务，所以可以称其为工业PaaS平台。总之，在这样的PaaS平台上，你都是按需购买资源，按实际使用付款。
而这种模式最典型的场景就是云计算，因为云计算通过虚拟化技术将用户实际使用的资源与物理资源隔离开来从而实现了资源的弹性分配。所以，云平台上买的各种资源都可以实现按需消费，用多少，买多少；用多久，花多钱。
所以，在XaaS模式中的服务，指的是这种按需消费模式下可弹性交付的资源。

中台中的服务，能力共享

那么另外一个火热到有点烂大街的概念”中台“，它上面的又是什么服务？
为什么会有中台，可以在《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》中看一下阿里的心路历程。核心思想是过去的企业应用架构是一堆桶（指彼此独立的应用系统，打个比方，非专业术语），这些桶里包含重复的功能，也包含隔离的数据。随着企业架构的规模越来越大，桶也就越来越多，于是就遇到了一个比较尴尬的问题。当我为了某些新的业务需求新建桶的时候，我就不得不继续重新建设一些重复的功能。同时，当我需要使用一些留存在其他桶中的现有数据的时候，又需要花费心思考虑去寻找数据、集成数据，开发和维护成本都很高。所以干脆，从企业架构层面将这些桶中共性的数据、功能提取出来，建立一个共享层，这个共享层就是所谓中台。按照中台中包含能力的内容划分，又可以划分成业务中台、数据中台和技术中台。而中台中的这些公用的功能或者数据，我们称为共享服务。
而中台或者共享服务的建立更深一层的好处是增强了企业的快速响应客户能力。现在企业越来越意识到“以客户为中心”的重要性，都要求前台系统能够快速响应并满足客户需求变化。但同时，企业后台众多大型系统由于本身架构等历史遗留问题以及自身功能特点又难以满足这种敏捷快速变更的要求。中台则可以在中间缓冲掉这种不同层面的系统变更节拍的不一致，在保证后台业务稳定的同时在前台快速响应用户需求变化。
但因为共享服务的目的是为了共享，所以它需要有重用的价值，而且要易于重用。所以在中台中，只有需要被不同系统、不同应用重复使用的能力或者数据才有价值做成共享服务。否则即使做出来也没有人用，劳民伤财。并且共享服务应该按照统一的标准、统一的设计原则实现。这样消费这些服务的应用就可以以比较小的成本使用这些共享服务，比如REST API。
开放平台中的API服务从形式上与中台的服务类似，都是开放一些REST API给应用调用，以提供可复用的基础能力。但对象和目的不同。中台服务的对象主要是内部应用，目的是提高企业资源的使用效率和快速响应客户的能力。而开放平台服务的对象主要是外部应用，目的是通过第三方合作伙伴扩展企业能力，打造生态系统。所以形式上类似，但目的不同。

面向服务架构，解耦

还有一类经常提到的服务在架构模式中出现，最典型的是SOA（Service Oriented Architecture）和微服务。这两种架构模式关系紧密又有所不同，讲起来又是一篇文章。相同点是两种架构模式都采用服务的方式封装功能单元以实现解耦。其中的服务就是一个软件程序，通过发布的技术接口（又叫服务契约）来共享功能。
但两者又存在很大不同。SOA侧重解决的是企业范围内应用架构中应用集成的问题。它将应用系统的功能装成良好的接口然后通过企业服务总线关联起来。接口是采用中立的方式进行定义的，企业服务总线本身也功能强大，可以支持适配和编排多种协议的服务接口。通过SOA的方式，软件系统可以将功能单元以服务的形式发布到企业总线同时还可以消费总线中的其它服务。
微服务侧重于实现应用范围内功能模块的独立开发部署，从而实现应用功能模块的功能、数据和技术解耦。因此，微服务架构中的服务拆分的粒度更细，目的是提高系统功能模块的可伸缩性和可维护性。相比SOA，微服务采用更加轻量级的通信协议，也更加适合敏捷开发和容器化集群的持续交付环境，因此现在微服务的热度远大于SOA。
但微服务就一定比SOA优秀吗？或者微服务就一定远胜单体应用架构吗？我们是否都应该把架构重构为微服务呢？
其实不然， SOA 和微服务是两种不同理念的架构模式，并不存在孰优孰劣，实现的目的和应用场景也不相同。即使是和单体应用相比，微服务架构也并非完全可以替代，也是各有各的适用场景，不能一概而论。

结论

由上可知，虽然都叫做服务，但在不同的上下文场景下关注点是不同的，概念也不同。
另外，这些服务解决问题域的层级和角度也不同。比如营销学中的服务解决企业营销策略和经营模式的问题；XAAS模式解决的是消费模式的问题；中台解决的是企业级能力复用的问题；SOA解决的企业级应用集成的问题；而微服务解决的是应用架构解耦的问题。
但是在现实问题中，企业架构师们面临的却是难以清晰界定的混合场景。比如要增强能力复用，你会考虑构建中台服务，但构建这些服务的时候可能还需要考虑与传统后台应用的集成问题，同时为了提高共享服务的性能和可伸缩性，可能还会考虑微服务架构。于是，在一件事情里，服务就可能代表不同的含义了，概念也就不那么清晰了，一些让人困惑的争论也就开始产生了。
所以，解决问题的前提是明确问题，而明确问题的关键的理清问题对象。这种情况下，我的建议是先分解问题，剥离关注点，明确概念，然后再逐级处理，如此才能避免后续工作中的混乱。