如何选择共享服务中心的框架
上一篇提到，阿里巴巴以共享服务体系来作为其“中台”战略的核心支撑，那么应该选择什么样的框架构建这个共享服务体系？
我们先来简单回顾一下淘宝平台“服务化”历程。发展到2007年，淘宝成为了一个由超过500人的技术团队共同维护的WAR包（几百兆字节），大小功能模块超过200个，飞速发展的业务（当时的淘宝基本上几个月业务就会翻倍）与传统的应用架构碰撞带来了下面几大问题：
1）团队间协同成本高，业务响应越来越慢。超过200个功能模块的包，必然分项目进行开发以及维护，这样每次系统功能升级后新版本上线会出现各种冲突以及不一致的情况，需要耗费大量的成本来沟通协作。
2）错误难隔离，应用复杂程度已超出人的认知负载。200多个功能模块中核心模块如用户、商品、交易等比较稳定，一些前端页面交互、广告展示等非核心模块则可能每天都有新的发布。错综负责的模块杂糅在一起导致每一次的发布都蕴藏着巨大的风险，淘宝历史上发生过几起因为非核心功能设计不合理而导致整个业务受到影响的事件，整个平台给人一种“牵一发而动全身”的感觉。
3）拓展成本高。当系统出现业务瓶颈时，由于所有的功能模块都打包在一起，无法单独对负载较高的功能模块进行拓展，只能将整个完整的应用拓展而带来额外配置的消耗。
以上问题驱使淘宝团队于07年开始进行架构的改造，最终选择了“去中心化”服务框架（共享服务体系）来搭建整个中台，关于为什么没有选择当时盛行的“中心化”服务架构（ESB模式下的SOA架构）除了在系列一中提到几点外，还有下面两点考虑：
第一，由于服务调用方式不同，ESB模式下的SOA架构所需的网络带宽要求非常高，对于具有一定量级用户的应用来说，采用ESB方式将会导致在网络设备上的超大额投入；
第二：企业服务总线承载了越来越多的服务路由压力，这是必然会采取集群部署的方式进行负载均衡以提供可用性，却因此也埋下了巨大的隐患，当业务访问峰值时，假设每个总线的负载达到80%，日常运行中不会产生问题，但是如果一台服务器出现了故障将会施压给其他即将满载的服务器，这就要求所有的服务器状态都非常“健壮”，否则在业务高峰时就会被各个击破从而导致企业服务总线全军覆没，给整个平台带来灾难性的后果。
阿里巴巴集团目前的分布式服务框架HSF（Hign Speed Framework，也有人戏称“好舒服”）支撑着2000多个应用的运行，以服务化的方式构建整个应用体系的同时也保证了在高并发的情况下，服务依然保持高稳定、高效交互以及强大的拓展能力。
共享服务中心的建设原则
按照ESB模式下的SOA模式，很多人认为服务中心是一个固化的概念，每个服务中心提供某项服务后便一劳永逸，实际上大部分企业的SOA都是作为一个项目，项目结束后服务中心基本也就固化了，当有新的需求产生时，服务中心如果不能满足，就不得不产生新的“烟囱”。实际上服务中心应该是一个充满生命力的个体，是一个承载业务逻辑、沉淀业务数据、产生业务价值的平台，随着公司的业务不断发展进化。
下面介绍在阿里巴巴中台架构建设的实践中总结出来的一些原则：
1.高内聚、低耦合原则——高内聚是指同一个服务中心内的服务模块应该相关性、依赖性很高，而服务中心之间应该隔离性较大，尽可能追求低耦合。
2.数据完整性原则——与上一条原则一脉相承，让业务相关的数据统一起来，尽可能让数据模型统一，为以后的大数据建设做好基础。
3.可运营性——这里的可运营性包含2层含义，一是指能快速满足上层业务的需求，同时利用业务不断滋养平台，二是指共享服务中心这个平台的可运营性，数据模型统一之后可以较低成本的引入大数据技术，让数据来源、数据分析、数据业务价值自然行程闭环，所以通过服务中心引入大数据来产生业务价值也是服务中心建设原则之一。
4.渐进性原则——该原则是从降低风险和实施难度的角度出发，有些人可能会觉得服务中心是基础建设，所以从一开始设计了太多的原则从而导致项目周期延长，数据过于分散也会产生数据库性能以及分布式事务的问题，其实服务化架构就是一种敏捷实践，我们推荐小步快跑而不是推倒重来，通过真实的业务需求锻炼出高价值高可靠的共享服务。
共享服务最基本的目的就是要把普通的服务能力升级为组件化服务并对服务本身加以管理，我们可以依次按照下面来实践共享服务平台的搭建：
第一、找到合适的服务化对象。这个对象要能够涵盖各种各样的业务流程、业务数据又要便于封装。为了保持对现有系统的兼容性，目前阿里巴巴集团的共享服务中心的功能支持粒度都是API，但是并不意味着只能把API作为服务对象，也还可以有其他粒度的服务。
第二、建设对象服务化的基础设施。有了服务话对象之后，需要制定制定相关的服务组件规范以及对应的服务治理平台与工具，以便对服务进行封装。一个完整的服务应该包括的基本功能有服务的描述元数据、服务注册与发现机制、服务访问控制与安全策略、应用服务portal、服务依赖与运维管理、服务SLA协议、服务消费者的管理与支持工具、服务化辅助工具支持、服务调用分析与报表、服务成本核算与服务能力变现、文档与开发工具支持。
第三、服务化实施。阿里巴巴中台把推进服务化实施过程化分为三个阶段：API as Service, Product as Service, Solution as Service。API as Service 解决了存量API的服务化问题，Product as Service是基于API初级服务的深加工，服务更面向场景，更专业化。这两个阶段实现了阿里巴巴从基础能力到业务能力的共享开放，Solution as Service的目标是让各种业务场景和解决方案在共享服务平台上达到最大程度的复用，让业务的拓展是基于服务的方式而不是基于代码的方式。
当然业务中台是前端应用所需服务的提供者，中台的需求需要前端应用来提供，两者需要在对接过程中相辅相成，共同发展。在阿里巴巴业务中台过去的几年发展中出现了多种与前端应用协作的模式：建立业务中台对前端核心业务的紧密沟通机制，及时、准确地了解核心业务需求；建立分歧升级机制；岗位轮转推动真正换位思考；业务持续沉淀及业务共建等。
内容摘录于《企业IT架构转型之道》
作者：钟华（古谦）
阿里巴巴中间件首席架构师，15年中间件领域行业经验。对传统企业IT建设和互联网架构都有较为深入的理解，有着扎实的理论基础和丰富的实战经验，多次作为总架构师协助大型传统企业打造业务中台项目，为企业实现“互联网+”转型提供了科学的发展方向和强有力的技术支持，项目涉及政府、制造业、金融、交通、媒体等多个领域。
本章主要介绍了共享服务体系建设的原则，接下来将分篇介绍共享服务体系搭建的过程、技术选择、组织架构以及金融行业的应用实践等。敬请期待！
来源：阿里金融云
原文链接
