9.1　服务化建设野蛮发展带来的问题

随着阿里巴巴集团服务化改造的持续进行，共享服务中心的服务数量越来越多，同时集团除了电商业务之外的多元化业务（如医疗、文化、物流等业务）的蓬勃发展，原有的几乎是人工模式的服务支持模式越来越满足不了业务发展的要求，主要的问题凸显在以下五个方面。

1.服务的数量和业务覆盖范围越来越大

经过多年的发展和沉淀，阿里巴巴现在几乎拥有了互联网应用中需要的几乎所有的服务能力，而且还在逐年增加。从基础的中间件服务：分布式数据库、分布式缓存、分布式配置、分布式文件系统、分布式日志、分布式远程调用框架，到电商领域的商品、库存、交易、支付、搜索、商品类目、商品结构化数据等等，甚至比较小众的图像识别、图像搜索，你想得到的、想不到的基本上都能找得到。我们的产品、应用和能力远超出我们的想象。有一个不精确的统计数字，全阿里依赖HSF暴露的服务数量在20KB+的量级。

这就让业务方面临着一个很大的挑战，怎么样才能非常高效地找到我需要的服务，并能快速地接入和使用起来？当团队和业务规模小的时候，面对面的交流是最有效的方式，但是当到达一定的数量级的时候，通过人与人之间的互通有无肯定不可行了。

2.应用和业务架构越分越细，服务越来越专业化，跨领域理解的成本越来越高

淘宝从“五彩石”项目开始确立了淘宝业务系统分治的格局，从此就进入了业务服务专业分工的时代。随着商品、交易、支付、店铺、搜索等服务中心的建设，这些慢慢都演变成了阿里电商的基础设施。由专业团队来支撑着这些庞大复杂的系统和数据的开发和维护，给上层业务系统提供稳定可靠的服务。

从商业角度来看，这种专业化分工其实就是云计算思维。撇开技术，从商业本质上来看，云计算其实是让IT产业进行更专业的分工，用专业化、规模化来提高效率，降低总体成本。淘宝的这种模式是发展的必然结果，而且将来肯定会更专业化。在这种模式下，系统对外都是通过服务暴露能力进行的，除了用户是内部用户外，其他与公有云上的服务模式并没有本质的差异。

3.服务安全控制层缺乏

这里的安全不是简单的机密性保护的安全，而是从广义角度来说服务的安全：包括数据的机密性、服务的可用性、SLA的遵循等。

系统切分比较细之后，系统之间都通过服务来耦合。系统之间的依赖与调用成了比较关键的环节。从广义安全的角度，一要防止恶意调用行为；二要杜绝由于人为的或者系统的错误发生的错误调用行为；三要能管理服务的依赖使用关系，提供满足SLA规范协议的服务。

而之前建设的服务体系中对于安全部分的考虑是比较少的，甚至某些方面还是空白。这就在实际中会面临这样的问题：

1）应用不知道有哪些下游业务在使用我的服务，当服务要升级或者变更时候，与依赖业务方沟通要花费大量的时间。

2）服务被未授权的业务方调用。

3）随意发布服务。

4.开发体验很不友好，产品在接入流程，开发使用手册建设非常之差

当时的情况是服务中心对前端业务的支持高度依赖答疑，经验的沉淀依赖个人或者团队的管理和习惯。阿里巴巴是典型的互联网公司，非常强调快速响应、敏捷、业务驱动、试错。在这种浓厚的互联网文化基因下，产品和项目把时效性、稳定性、效率放在了第一位，而把系统的可维护性、可使用性和开发友好性都视为细枝末节。

这和传统商业软件有巨大的反差，商业软件发版有严格的市场策略和规划，他们要用市场来收回成本赚取利润；而互联网模式使用新特性来吸引用户，只要用户在，赚钱永远不是问题。两种市场的目标不同，必然导致生产和管理的过程有很大不同。但是长久来看，应用规模扩大和复杂度的增加会造成开发和维护成本急剧上升，这是软件工程学早就得出的结论。

5.整体服务体系缺乏一个统一的服务治理层

上面这些问题可以抽象为一个需求：服务治理。我们的服务分散在各种底层基础的分布式基础服务上，这些服务各自都有自己的后台管理平台去实现管理。一是缺乏对这种分布式服务层面各种服务能力的抽象模型；二是缺乏从整体角度把各种分布式服务能力管理起来的产品。

刚刚拜读了阿里巴巴集团王坚博士的《在线》新书，他对“在线”这个概念做了非常精彩的解读。其中举例到，因为乘客和司机在线了，乘客、司机不再是陌生人的偶遇，而是可以通过App互相找到，所以打车App火爆了；类似的余额宝、移动支付，都是不同场景在线的结果。因为从线下到了线上，信息更透明，缩短了交易的路径，带来了更高的效率，有了直接的交互机会，产生了更多数据，所以诞生了很多新的商业模式。

基于同样的思路，针对当时阿里巴巴集团内服务化建设的问题，集团的共享服务平台（Shared Platform as Service，SPAS）应运而生，目标是对阿里巴巴集团的服务更好地进行治理和共享，其实也可以看做服务能力在线化、数据化的过程。

离线模式下的路径是：

服务消费者（业务开发者）→各种渠道（电话、旺旺、小二）→服务提供方→服务

共享服务平台建设之后的流程：

服务消费者（业务开发者）→共享服务平台→服务→服务提供者

离线的时候，服务能力没有数据化，都沉淀在小二的脑子里或者各种Wiki上；服务在线后，服务和服务的结构化信息都在服务平台上，从而缩短了开发者与服务提供者之间的路径。让服务提供者、服务消费者直接基于服务进行交互。图9-1是共享服务平台的架构概览。

图9-1　实现服务从线下到线上的平台功能

上面描述了我们在当时服务化建设过程中遇到的一些问题以及对于问题的思考，以前，我们的系统缺乏服务组件化的抽象和对应用服务的治理，下面看看如何通过共享服务化平台进行高效的服务治理。