9.2　共享服务平台的建设思路

共享服务平台的建设思路借鉴了SOA和API管理的思想，结合阿里巴巴的现状，从应用服务治理的角度入手来解决这些问题。

首先明确一下服务和服务化这两个概念：

·服务是一个名词，通常我们说的服务是指服务端暴露出来的一种服务接口，与服务消费者相对应，其代表了服务端一个具体的能力。在SOA架构中的服务被当成一个组件对象，组件就包括服务接口和附加在这个接口上的组件规范：服务策略、限制、描述等，我们把这种服务称为组件化服务。

·服务化是一个动词，它更像是一个商业策略，核心是从产品能力转化直接服务客户的能力。这首先是一个理念的转变，产品能力是从产品出发，以产品为核心，就像我们从产品出发来抽象API；服务化是以面向客户的服务为核心，就像我们根据用户的需求来提供最适配用户需求的设计方案，是按需服务（Service On Demand）的体验。服务化的思路就是把产品和服务的中心转移到用户身上，以方便用户使用、降低使用成本为目标。如果服务的用户是开发，我们就要从开发的需求出发；如果服务的用户是运营，我们就要从运营的需求出发。

关于服务化，想再扯得远一点，用一点经济学的思维来看技术。我们常常听到服务业，说服务业是第三产业。经济学上也可以看到一个现象，经济发达程度越高，第三产业所占的比重就越高。这是不是可以对应到产品的服务所带来的整个价值比重其实超过产品本身的比重？再直白一点，其实是这么一个逻辑：如果只有产品，用户会花费极大的成本去调研、分析、学习，最后使用、维护这个产品，如果你用产品服务化的方式来提供这种产品的能力，对用户来说，看起来购买服务价格高了，但是总体成本却降低了，这也是市场配置资源的结果。所以发展的必然结果就是产品服务化，专业分工更细，云计算的商业本质其实也是这样，通过市场配置资源。

从产品和技术手段上如何实践共享服务这个目标？践行共享服务最基本的目标就是把普通的服务能力升级为组件化服务并提供良好的服务治理支持。有了这个作为基础，就可以考虑在这之上给用户提供更好的服务。以下是依次实现服务共享的条件：

第一，要找到一个合适的服务化对象。服务本来就是个抽象概念，我们去做服务化，到底基于哪个承载对象来做服务化？这个对象既要能够涵盖各种各样的业务流程、数据服务能力，又要便于实现对对象的服务化组件封装。

第二条，建设对象服务化的基础设施。有了服务化对象，就要解决应用服务治理的目标，就要制定并实现服务组件规范和服务治理工具与平台。有了这些规范和工具，就可以把在第一步选定的服务化对象封装成服务组件，完成治理。

第三条，服务化实施阶段。用服务化基础设施把服务化对象变成服务组件，到了这一步，让业务方共同参与进来推动业务服务化，享受服务化带来的应用服务治理的红利。

第四条，增强服务和基础设施实现服务的精细治理。通过产品和工具的支持，为用户提供更好理解、更易用、更优质的服务，最终达到按需服务的层次，这是我们的终极目标。

下面就介绍阿里巴巴共享服务平台是怎么构建而成的。

1.确定服务化的对象是API

这应该是一个比较自然的答案，但是为什么就是Interface层级而不是method或者一些method的集合又？或者一些Interface的集合？在当初也有过讨论，但是最后我们还是确定基于Interface，这个结论和阿里现有的体系结构有莫大关系。淘宝的业务系统架构基于淘宝的中间件平台，现在中间件的产品功能支持粒度都是API，为了保持对现有系统的兼容性，所以我们也选择以Interface为服务粒度，把API作为服务化的基本对象。这里是把API作为初始对象粒度，而不是只能把API作为服务，这一点很重要，它意味我们还可以有其他粒度的服务，但这是将来的事，现在要解决淘宝已有的数以万计的API服务。

2.建立共享服务的基础设施，实现API的服务封装

把现有的API加工成服务组件，打个通俗的比喻就是，我们要对阿里巴巴的业务服务能力做一次结构化包装，这个包装让服务能力具有规范的描述，可以与服务治理工具进行交互。具有服务治理的能力，这时候API就成了治理良好的组件服务。

根据对淘宝业务需求的分析，共享服务基础设施包括以下几个方面的基本功能（参见图9-2）：

图9-2　共享服务平台功能架构

·服务的描述元数据

·服务注册与发现机制

·服务的访问控制与安全策略

·应用服务Portal

·服务依赖与运维管理

·服务SLA协议

·服务消费者的管理与支持工具

·服务化辅助工具支持

·服务调用分析与报表

·服务成本核算与服务能力变现

·文档与开发工具支持

图9-2中，共享服务的基础设施就是提供服务元数据规范与工具，帮助API完成从普通服务到组件化服务的蜕变。

从共享服务落地的角度来讲，必须要用平台的方式使服务天然具有以上的能力，而不是像之前那样去创建一个服务的Wiki，或者实现一个服务的安全调用。我们需要这样一个以组件服务为管理对象的通用平台，以后在服务层面的共性需求都可以在这个平台上来实现，这是共享服务平台的价值所在。

3.服务化实施阶段

推进共享服务就是要把阿里巴巴电商体系内原生的API服务变成共享服务平台上的组件化服务，这是一个渐进的过程，需要业务方的参与。我们把服务化实施划分为API as Service、Product as Service、Solution as Service三个阶段，参见图9-3。

图9-3　服务建设的三个阶段

这三个阶段也可以看成服务化的初、中、高三个阶段：

1）API as Service

这个阶段就是让API具有服务组件的能力。API只是一个接口，这个接口可能是HSF的一个服务接口，也可能是消息中间件的消息收发接口，或者是配置服务器的配置项的访问接口。要让依赖这些接口暴露的业务服务成为服务组件，需要在这些基础中间件接口层实现API元数据的支持。让这些通过HSF、消息中间件这些中间件产品暴露的服务能力具有完整的服务组件特征，并具有与服务治理工具的交互能力，这就是API as Service的含义。

所以第一步中API as Service的具体任务就是要把HSF、分布式数据库、消息服务、配置服务、缓存等这些中间件能力API服务化，如图9-4所示。当我们完成HSF的服务化的时候，所有通过HSF暴露的API服务就支持了API as Service，当我们完成消息服务的服务化时候，所有依赖消息服务器的消息服务的业务应用就完成了消息服务的API as Service，以此类推。通过对基础服务API接口服务化，业务层依赖这些基础件暴露的HSF服务、消息服务、配置项服务都自然成为组件化的服务，获得了服务治理的能力。

图9-4　对技术平台的能力API化

API成为服务是最基本的要求，API有通过API元数据的自描述，API自描述元数据能够与服务治理工具交互，那么服务就具备了以下几个特点：

·服务还是通过原来的接口暴露，API元数据对API没有侵入性。

·服务具有共享服务平台上的所有服务治理的能力。

·所有服务都具有相同的使用体验，降低横向学习成本。

完成了API as Service这一步之后，业务方的服务就可以接入服务化平台，并使用共享服务平台来管理自己的服务。这里暴露的服务是最初级的服务，因为现在服务的粒度是API，这些API不是面向服务设计的结果，可能是经过长时间的演变妥协的结果。所以在优雅性、易用性、安全性上肯定还有需要改进，这就是下一个阶段Product as Service。

2）Product as Service

API as Service解决存量API的服务化问题，把淘宝现有的大量业务API升级成了服务化平台的组件服务，让它们成了受控的服务对象。Product as Service基于API初级服务的深加工，把API形态的服务利用共享服务平台“封装服务”来暴露让开发者尖叫的服务，参见图9-5。

图9-5　对API进行服务的封装

初始的API设计会顾及产品的设计、业务兼容、平台化发展等各个因素，所以API会显得很复杂。这层服务虽然对服务治理非常有意义，但是对帮助开发者快速理解服务的意义不是特别大，而共享服务平台的服务封装工具可以针对服务进行精加工。

用户可以在共享服务平台上利用API服务来开发和部署组合服务。这类组装的服务更面向业务场景，更专业化。对开发者来说，使用会非常友好，对提供者来说，对这类服务的管理可以支持到非常细腻，提升管理服务的效率。

服务组装旨在真正实现服务粒度的敏捷，让服务开发和部署的流程可以非常简单和快速，服务提供者利用服务平台的服务辅助开发工具实现在服务端或者客户端封装的服务。共享服务平台对这种二次封装的服务提供工具层面的开发、测试、部署和上线支持，从而大大提升对业务快速响应能力，其流程如图9-6所示。

图9-6　服务组装流程

经过这个阶段，服务提供者提供的服务就不仅是一堆API的列表，还会包括从业务需求出发梳理出来的一些场景化的服务接口。而且利用共享服务平台提供的服务组装机制，可以在线完成服务简单的组装，从而快速提供特定业务需求的短期服务。

3）Solution as Service

上一个阶段完成后，阿里巴巴从基础计算能力到业务能力在共享服务平台的服务市场上都可以找到、发现，这是阿里十几年来软件产品能力最集中的展示。当然，我们的目的不是为了展示，是要让这种能力更好地服务于业务，服务于卖家、买家及整个电子商务体系，让淘宝上的各种业务场景和解决方案在共享服务平台上达到最大程度的复用。比如我们在大陆的三淘市场，可以通过共享服务平台的方式沉淀出针对海外淘宝的解决方案，以后淘宝业务的扩展是基于服务的扩展而不是基于代码的方式进行扩展，这是Soluting as Service的目标。