本书在阿里巴巴启动中台战略的大背景下编写的，作者作为阿里巴巴技术架构迭代升级的亲身经历者，将架构转型的经验总结下来以飨读者。共享服务体系是中台战略的核心部分，理解了它就是理解了中台战略思想的精髓。作者从2015年马云带领阿里巴巴集团的高管拜访位于芬兰的Supercell（已被腾讯收购）开始说起，介绍的阿里巴巴启动中台战略的初衷，之后又讲述了阿里巴巴共享事业部的发展史，来讲述共享服务中心建立的心酸历程，同时也引出传统企业进行架构转型的困难之处。在作者看来，企业架构转型是时代所驱，共享经济是未来的发展，也是提升自身价值的必经之路，下面开始为大家分享读者关于为何构建共享服务体系、怎样构建共享服务体系、共享服务体系有何价值的总结。

1. 企业架构变迁

1.1 “烟囱式”

    当企业初创阶段，且规模较小，流量不是很大的时候，选择单体项目，是可以实现快速响应需求、容易维护等优点。当有新业务需要扩展时，由于单体项目不好扩展，而且业务也不成熟，往往选择独立建设，这样就形成了多个项目的“烟囱式”发展。但是“烟囱式”有很多的缺点：

1. 重复功能建设和维护带来的重复投资
2. 打通“烟囱式”系统间交互的集成协和作成本高昂
3. 不利于业务的沉淀和持续发展

1.2 分布式

    传统企业，为了将这些单体项目打通，使用各大厂商推出的ESB产品及解决方案，通过SOA项目构建企业服务总线，基于服务的方式实现了这些“烟囱”间的交互。企业只是解决了多个异构系统之间的交互，但是底层的数据还是隔离的，而且ESB总线成为了系统的交互中心。
以下是SOA的主要特性：

• 面向服务的分布式极速单
• 服务间松散耦合
• 支持服务的组装
• 服务自动注册和自动发现
• 以服务契约方式定义服务交互方式

1.3 共享服务中心

    共享服务中心是将业务中公共的、通用的业务以服务的方式沉淀到共享服务体系中，例如用户中心、商品中心、交易中心、店铺中心、支付中心等。图中是阿里巴巴的部分共享服务中心。
    服务中心的建设不是一步到位的，需要业务慢慢的去沉淀。一个服务中的模块经过沉淀，可以独立出来成为新的服务中心，例如可以从交易中心中沉淀出评价中心、营销中心。
    服务中心提供的服务也是多样的，有基于接口的服务（RPC、HTTP），基于工具的服务（例如运营工具、业务自检工具），还可以基于数据提供服务，这样可以提供运营效率

共享服务中心的作用与好处：

• 服务重用，减少成本
• 服务不需要稳定，可以不断的滋养
• 共享服务体系是培育业务创新的土壤
• 赋予业务快速创新和试错能力
• 为真正发挥大数据威力做好准备
• 改变组织阵型会带来组织效能的提升

1.4 业务中台

    业务中台是对共享服务中心的进一步完善，能够将各个服务中心进行整合提供完整的解决方案，同时业务中台将共享服务中心作为产品向前端用户展现。业务中台是前端应用所需服务的提供者，前端应用是业务中台服务的消费者。当不同前端具有相同业务功能时，可以将业务逐渐沉淀到业务中台。

2. 共享服务体系搭建

    共享服务中心是中台架构的基石，如何构建稳定可靠、最高效地支撑上层业务快速创建的共享服务能力是中台架构成功与否的关键。

2.1 共享服务中心建设原则

    一般来说，服务能力包括两个层次，一个层次是底层PaaS的能力，PaaS层解决大型架构在分布式、可靠性、可用性、容错、监控以及运维层面上的通用需求；第二个层次是业务能力，业务服务能力提供运化的核心业务支撑能力，这层能力建设的好与坏，直接决定了能否真正支持上层业务达到敏捷、稳定、高效。
    共享服务中心的架构目的是通过业务拆分来降低系统的复杂性；通过服务共享来提供可重用性；通过服务化来达到业务支持的敏捷性；通过统一的数据架构来消除数据交互的屏障。下面是建设共享服务中心的一些原则：

• 高内聚，低耦合原则
• 数据完整性原则
• 业务可运营性原则
• 渐进性的建设原则

2.2 分布式服务框架

    业界的互联网巨头公司，都有属于自己的分布式服务框架，如阿里巴巴的Dubbo，HSF，腾讯的Tars，京东的JSF，新浪的Motan，都已经是业界非常成熟的解决方案，其中开源的Dubbo和Motan受到了广大开发者的研究对象。
    纵观这些服务框架，思路上大同小异，都离不开几个模块的功能，即Provider，Consumer，Registry，Gateway，负载均衡，服务分流，监控等，下面就这些名词再作下介绍

• Provider：服务提供者，无论是业务服务，还是一个系统中公用的SAAS，都属于Provider
• Consumer：即发起调用的客户端
• Registry：服务注册中心，是分布式服务系统中的一个重要组成模块，管理Provider的Manager，在实际的运行环境中，服务注册中心Registry被动通知或Consumer主动询问，在Provider有节点宕机或新增节点时，客户端也可实时感知到，从而避免了某个Provider被无限调用或是无限闲置
• Gateway：网关也是分布式服务框架中不可或缺的部分，每种系统与框架都有自己的一套协议，当异构系统互相调用时，网关的作用即显现出来，Gateway接受各种外部HTTP请求，完成相应的权限校验，报文适配，路由转发到对应的Provider，再将Provider返回的结果传递给异构系统的Consumer，完成异构系统的互相调用
• 负载均衡，服务分流：Consumer从Registry获得具体的Provider列表后，如何选取合适的Provider，取决与一定的负载均衡算法，常见的算法有轮询法，随机法，源地址哈希，加权轮询，加权随机等

• 监控：接收来自Consumer和Provider异步上报的性能监控数据，对有风险的节点发出告警

  
  

2.3 数据拆分

    当业务快速发展时，最先出现瓶颈的往往是数据库。数据拆分步骤一般是读写分离、垂直拆分、水平拆分。

• 读写分离：项目初期，为了节约成本、开发简单，所有数据都放在一个数据库实例中，随着业务的增长，数据库读写能力会下降。一般互联网业务，读大于写，这时最先考虑的是读写分离，对读的能力进行扩展。
• 垂直拆分：此时所有系统都访问同一数据库集群，而数据库集群的数据库连接数量是有上限的，随着业务进一步发展，这就造成数据库连接数量的资源随着系统实例数量的增加而越来越捉襟见肘。这时就需要对数据库进行垂直拆分，让每个服务中心都有自己独立的数据库。
• 水平拆分：数据库单表数据量是有限制的，当单表数据量达到一定数量后数据库性能会出现显著下降的情况。因此需要基于分治的思想，将同一表中的数据拆分到不同表，甚至不同数据库中，即分库分表，以此来扩展单表的写性能。

2.4 异步与缓存

2.4.1 异步

    平台进行服务化后，对于前端的业务请求势必需要将后端不同的服务进行组合调用来实现业务请求处理。以淘宝的交易订单为例，目前淘宝的订单创建流程需要调用超过200个服务，就算每个服务需要20ms，整个订单创建过程也会超过4s，这个时间已经超出了互联网用户的忍耐极限。同时，由于处理时间长，会导致线程资源的长时间占用，影响服务器的整体系统吞吐量。使用异步处理，是解决该问题的有效方法，使互不关联的一些处理进行并行化处理，甚至将一些非核心流程使用异步消息的方式，进行异步处理。
    但是对于一些数据库写任务进行异步，就会涉及数据事务的异步化。通俗来说，就是将大事务拆分成小事务，降低数据库的资源被长时间事务锁占用而造成的数据库瓶颈，就能大大提升平台的处理吞吐量和事务操作的响应时间。
    传统事务核心是ACID（原子性、一致性、隔离性、持久性），在分布式领域，基于CAP理论和在其基础上延伸出的BASE理论，有人提出了“柔性事务”。

• CAP理论是说一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
• BASE是指基本可用（Basically Available）、柔性状态（Soft state）、最终一致性（Eventual Consistency）

柔性事务在阿里巴巴内部的几种实现：

1. 消息分布式事务
2. 支付宝XTS
3. AliWare TXC事务服务

2.4.2 缓存

    对内存的数据操作时间一般是纳秒级，而传统的数据库访问中，一次SSD盘数据访问在几十微妙，一次SATA盘数据访问在几十毫秒，显然处理时间有数量级的差异，所以通过缓存（大部分缓存产品均是基于内存的数据存取实现）让应用具备更好的处理性能和系统吞吐率早已经在应用开发领域广泛使用。

2.5 数字化运营能力

    当系统完成服务化改造后，确实能够使业务响应速度更快，也能很好的支持业务创新。但是由于服务较多，服务之间的调用关系变得纷繁复杂，当出现海量的服务调用，面对这些“点对点”的调用方式，一但系统出问题，很难定位出问题在哪。
    作为服务的开发者，一定会关心两个问题：

1. 我的服务在什么链路下被调用，调用场景和数据是否合理？
2. 目前服务调用趋势怎样？产生的瞬间峰值是多少？是否达到服务能力的最高水位？

    作为架构师，一定会关心如下问题：

1. 在当前的业务流程设计中，我依赖了哪些应用、哪些服务？
2. 整个链路的依赖路径是怎样的？哪些服务对当前业务处理来说是最为核心的？这些依赖如果出错，会有什么影响？
3. 一次业务请求处理的时间到底花在什么地方？是因为某一个服务耗时很长，还是某一个数据库的访问操作耗时醉酒，需要一个清晰直观的定位。
4. 我负责的业务链路中，过去一段时间哪些服务是出错率比较高的，哪些服务是业务链路的处理瓶颈？

    针对这些需求，企业需要搭建“分布式服务链路跟踪平台”。一般通过分布式日志平台实现对服务调用链路的跟踪，以图形化的方式给服务的开发人员、运维人员、业务架构师提供了完善的服务调用跟踪信息，为服务出错后的快速定位、服务链路的性能优化、服务链路的流程优化等提供了非常有价值的参考数据。

2.6 平台稳定性

    当企业日趋成熟时，打造平台稳定性也是必不可少的环节，提醒平台稳定性，为企业的大促、秒杀等场景的流量洪峰保驾护航。在整个稳定性体系中，所包含的范围非常广泛，从机房的布线、网络通信、硬件部署、应用架构、数据容灾等方面都与之相关。从共享服务中台的角度，则更多的是从应用架构设计和中间件平台的维度对平台的稳定性实现更精细化的管控和保障。这就涉及限流和降级、流量调度、业务开关、容量压测和评估、全链路压测平台、业务一致性平台等。

• 限流：对特定资源进行调用的保护，防止资源的过度调用
• 降级：判断依赖的资源的响应情况，当依赖的资源响应时间过长时进行自动降级，并且在指定的时间后自动恢复
• 流量调度：通过秒级获取服务器系统运行指标以及业务指标，通过流量调度平台设置的决策算法以及规则，当发现满足规则条件的指标状态发生时，对线上环境的服务器进行下线等操作，以屏蔽这些单点或局部出现故障的应用实例对整体平台产生扩展式的影响
• 业务开关：通过业务开关实现不同业务场景的切换，尤其是在秒杀场景中，一但系统出现问题，可以通过开关进行降级处理，来保证系统的稳定性
• 容量压测：通过将线上真实的流量引流到压测目标机器上，并不会对本系统及下游系统带来额外的流量，也不需要准备测试数据、压测系统。逐步增加压测服务器的权重，观察压测服务器的关键指标（CPU利用率、系统整体负载、QPS、响应时间）到达阈值水位后停止压测。这样就得到了单机服务器实例所能提供的最大的QPS处理值
• 全链路压测平台：为了进一步覆盖超大型的大促活动，全链路压测要求每个系统环节都同时参加压测，以此更好的评估网站的承压能力。这样就需要有一套自动化、系统化的基础设施和流程来实现全链路压测
• 业务一致性平台：在分布式系统中，尤其是有异步操作的过程中，面对数据库保存失败，MQ消息发送失败，从而导致数据不一致的问题，这时需要一个保证业务一致性的平台，实时审计各方数据是否一致，及时的通知技术人员进行排查和修复，同时通过自动恢复功能，进行脏数据的订正流程。