依然写在前面的读后感：
- 全书读下来给人一种种「阿里服务中台化实践概要」的感觉，如果是讲「道」吧（看主标题是这样），高度不够；如果要讲「术」呢，深度又有所欠缺；
- 还是要吐槽一下本书中涉及的技术部分：技术部分虽然不是重点，但是给我的感觉就是内容没有好好组织，没有从「问题-思路-方案」的脉络去阐述，痛点一两句话说了，然后扔一张架构图，也没有做方案的对比；
- 可能是我自己做了好几年的服务化工作，所以读完这本书后，个人觉得内容新意不足，纸质书定价 79 元，略贵。
- 本书优点：书中服务化体系、方法论的的抽象值得一读的，在服务化方面有实践经验的同学估计有更深的体会。
引子
阿里巴巴集团中台战略引发的思考
今天企业IT系统建设的模式是：当业务部门提出业务需求，信息中心部门进行系统集成商的招投标（如自身有开发团队的企业则无需此流程），再进入到需求收集、需求分析、开发、测试、上线的项目周期中，某种程度上每个新系统的上线都预示着一座新的烟囱矗立而成，这种完全基于业务需求建设系统的方式已经成为过去20多年企业建设IT系统的标准流程，导致IT系统建设早的企业内部系统烟囱林立。这正是今天很多企业面临互联网转型难的根节所在。
“烟囱式”系统建设带来的弊端：
- 重复功能建设和维护带来的重复投资；
- 打通“烟囱式”系统间交互的集成和协作成本高昂；
- 不利于业务的沉淀和持续发展。
构建业务中台的基础——共享服务体系
当SOA在企业客户中落地时，几乎无一例外的是通过搭建企业的ESB（企业服务总线），使各个系统以服务封装或服务调用的方式实现了不同系统间的业务交互。总体来说，我们发现在过去10年，企业实施的SOA项目，本质上仅仅是采用服务的形态，以技术的视角选择了一个科学的架构实现了系统的互联，这只是利用了企业服务总线构建了一个企业内部的服务路由枢纽和渠道，受到项目制建设模式的影响，对于企业中业务服务的持续发展和沉淀没有任何帮助，根本没有真正发挥出SOA理念最核心的价值：松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新。
好的创新一定是基于企业的现状因地制宜，而这决定了在很大程度上企业的创新会来自于企业内部，而且提出创新的人一定是对行业有过人的认识和理解，才有可能提出创新的想法。
科学证明，人数是7个人的团队协同效率是最高的。当团队进行作战时，最短时间内达成意见的统一和行动步调的一致，是团队强大战斗力充分展现的必要条件。
共享服务体系搭建
分布式服务框架的选择
2007年，淘宝已经拥有超过500人的技术团队规模，整个淘宝网站是一个几百兆字节的WAR包，大小功能模块超过200个。
HSF框架中采用如今流行的网络通信框架Netty加上Hession数据序列化协议实现HSF服务间的交互，主要考虑点是在大并发量时，服务交互性能达到最佳。阿里巴巴当时在对多种通信协议和数据序列化组件等测试中，Netty+Hession的组合在互联网高并发量的场景下，特别是在TPS上达到10w以上时，性能和效率远比REST或者Web Service高。
“微服务” 和 SOA 的区别：
- 分布式服务组成的系统。 意味着各个系统都将会是有多个分布式的服务组成，而不是传统SOA架构中基于“中心化”企业服务总线（ESB）的方式构建服务架构，更多是采用系统提供服务的方式实现系统间的打通和交互；
- 按照业务而不是技术来划分组织以及做有生命的产品而不是项目。 传统SOA实施的方式是以项目的方式实施，而不是以做产品的方式让服务在业务发展过程中快速演化；
- 智能化服务端点与傻瓜式服务编排。 更加强调了能力向服务端的迁移，而不是像传统ESB的方式，将整体服务架构中的所有核心能力都运行在ESB上；
- 自动化运维和系统容错。 这两点则是在微服务架构建设后，对于整体服务的运维管控和平台高可用性和稳定性方面提出了更高的要求。
微服务中服务边界的划分一定是从业务的维度，以什么样的服务颗粒度定义服务？以什么样数据模型支撑服务能力的线性扩展？如何保持设计出的服务具有很好的业务前瞻性？在高效满足现有业务需求的前提下，还能保持整个服务能力的通用性，为接下来其他业务的服务接入提供业务的扩展能力？这些问题都是微服务架构在落地过程中，实施团队都将面临的问题。
共享服务中心建设原则
在阿里巴巴集团的中台战略中，共享服务中心是中台架构的基石，如何构建稳定可靠、最高效地支撑上层业务快速创新的共享服务能力是中台战略成功落地的关键。一般来说，服务能力包括两个层次，一个层次是底层PaaS的能力，PaaS层解决大型架构在分布式、可靠性、可用性、容错、监控以及运维层面上的通用需求；第二个层次是业务能力，业务服务能力提供云化的核心业务支撑能力，这层能力建设的好与坏，直接决定了是否能真正支持上层业务达到敏捷、稳定、高效。
服务中心提供的服务能力不拘泥于形式，从大类来看，可以分成以下三类：
- 依赖于接口的服务： 这类服务是上层应用提供编程接口，接口可以是RPC，也可以是基于Web API的，从整体上来看，这里尽量统一会带来整体结构的简化；
- 依赖于工具的服务： 这类服务有两类，一类用于提供定制的配置服务，比如淘宝商品中心要设置前台类目体系，交易中心要配置业务的交易流程；另二类是运营管理类的工具，比如商品巡检服务；
- 依赖于数据的服务： 这里的服务主要是指对大数据的分析能力，实时交易型的数据能力一定要通过接口服务对外暴露。
共享服务中心的架构目的是：
- 通过业务拆分来降低系统的复杂性；
- 通过服务共享来提供可重用性；
- 通过服务化来达到业务支持的敏捷性；
- 通过统一的数据架构来消除数据交互的屏障。
实际项目中总结的一些基本原则：
- 高内聚、低耦合原则：高内聚是从服务中心的业务界域来说的，在一个服务中心内的业务应该是相关性很高、依赖性很高的；而服务中心之间应该是业务隔离性比较大的，这里的业务隔离性是从应用场景来说的；
- 数据完整性原则：不光只是业务逻辑的关键数据，还要考虑到业务的相关性数据；不光是实时在线数据，还要考虑到离线计算的数据；
- 业务可运营性原则：能否用大数据能力提升运营水平是服务中心原则之一；
- 渐进性的建设原则：服务化架构本来就是一种敏捷的实践，我们是推荐小步快跑的方式逐步推进，不是轰轰烈烈地推翻重来。
数据拆分实现数据库能力线性扩展
在2008年，阿里巴巴内部开始了分布式数据库的研发工作，相关的平台和工具陆续登上了淘宝技术发展史的历史舞台。
时间真是早啊，所以说，业务场景带来了技术的革新。
扩展数据库读写能力：
- 首先实施的是数据库的读写分离。缺点：主数据库的数据写入能力依然没法扩展，单表的数据量也是有限制的；
- 其次是采用水平分区的方式对数据进行拆分。
数据分库分表设计的最佳实践：
- 数据尽可能平均拆分：不管是采用何种分库分表框架或平台，其核心的思路都是将原本保存在单表中太大的数据进行拆分，将这些数据分散保存到多个数据库的多个表中，避免因为单表数据太大给数据的访问带来读写性能的问题。数据如何拆分并没有所谓的金科玉律，更多的是需要结合业务数据的结构和业务场景来决定；
- 尽量减少事务边界：即一条SQL语句同时被推送到后端所有数据库中运行，事务边界的数量越大，会给系统带来以下弊端：
- 系统的锁冲突概率越高：有多个类似的SQL请求并行执行时，则出现数据锁造成的资源访问互斥的概率会大大增加；
- 系统越难以扩展：整个数据库的能力是无法通过增加后端数据库实例来扩展；
- 整体性能越低
- 异构索引表尽量降低全表扫描频率：采用异步机制将原表内的每一次创建或更新，都换另一个维度保存一份完整的数据表或索引表。一种是从数据库层采用数据复制的方式实现；另一种是在应用层实现，在这一层实现异构索引数据的创建，会带来分布式事务的问题；
- 将多条件频繁查询引入搜索引擎平台：采用数据异构索引的方式在实战中基本能解决和避免90%以上的跨join或全表扫描的情况，是在分布式数据场景下，提升数据库服务性能和处理吞吐能力的最有效技术手段；但在某些场景下，比如商品的搜索，应采用专业的搜索引擎平台来行使这样的职能；
- 简单就是美：如果在“尽量减小事务边界”与“数据尽可能平均拆分”两个原则间发生了冲突，那么请选择“数据尽可能平均拆分”作为优先考虑原则，因为事务边界的问题相对来说更好解决，无论是做全表扫描或做异构索引复制都是可以解决的。而写入或单机容量如果出现不均衡，那么处理起来难度就比较大。
异步化与缓存原则
阿里巴巴内部使用消息中间件的方式实现了业务异步化，异步化后的业务处理流程提高了服务的并发处理，从而大大减少整个业务请求处理所花的时间。
事务与柔性事务
采用最终一致性，一定会产生柔性状态。柔性事务如何解决分布式事务问题：
- 引入日志和补偿机制
- 可靠消息传递
- 实现无锁
- 避免事务进入回滚
- 辅助业务变化明细表
- 乐观锁
阿里巴巴内部分布式事务解决方案:
- 支付宝XTS框架
- 消息分布式事务
- TXC事务服务
消息分布式事务
基于MQ提供的事务消息功能实现分别对两个不同数据库进行事务处理。
通过消息进行事务异步的方式，保证了前后两个数据库事务同时执行成功或失败，保持了事务的一致性，同时因为避免了传统两阶段提交事务方式对数据长时间的资源锁定，所以数据库整体的吞吐率和性能大大超过传统的分布式事务方式。对比柔性事务解决分布式事务的思路，消息服务在其中扮演了事务日志的职能，对全局事务有一个统一的记录和调度能力；事务的参与者通过对消息订阅关系建立了事务间的关联。
在采用消息服务实现分布式事务的场景如果出现异常时，一般会采用正向补偿的方式，即不会像传统事务方式出现异常时依次进行回滚，会通过消息的不断重试或人工干预的方式让该事务链路继续朝前执行，而避免出现事务回滚。
缺点：
- 原本通过数据库的事务特性实现的事务执行检查和回滚都需要靠开发人员来实现，这对于开发人员提供了额外更高的要求；
- 如果一个事务上下文中超过两个事务操作后，因为事务的回滚逻辑变得非常复杂而不可控，所以在这样的场景下只能进行正向的事务补偿，在某些业务场景下会给带给客户不同的体验。
使用场景：淘宝的订单交易、异构索引数据等类似跨库数据更新的场景。
支付宝XTS框架
支付宝的XTS分布式事务框架是基于BASE的思想实现的一套类似两阶段提交的分布式事务方案，用来保障在分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求，XTS可同时支持正向和反向补偿。
评：这一部分的内容很差，感觉像是把设计文档复制过来的。
阿里巴巴 AliWare TXC事务服务
TXC同样也是基于两阶段提交的理论实现的分布式事务框架，TXC的功能：
- 满足之前分布式事务平台所提供的对于事务服务高可用和事务最终一致性的基本业务要求；
- 标准模式下无需开发人员自行进行事务回滚或补偿的代码，平台支持自动按事务中事务操作的顺序依次回滚和补偿；
- 易用性是TXC的主要目标，在保证事务完整性的前提下，标准模式可不修改应用的代码，同时也提供之前平台中所提供的事务重试以及自定义事务模式。
TXC服务器负责整体的事务协调和管理，由部署在TXC客户端上的资源管理器组件实现各客户端与TXC服务器的事务注册、状态更新、提交等操作
TXC相比于传统的两阶段提交方式，最大的区别在于XA在准备阶段是没有提交本地事务的，而TXC则是立即执行并可见，在隔离性级别上实现的是读未提交（read uncommitted），所以避免了在分布式事务中对于数据的长时间锁占用。如果业务场景不允许数据的脏读，TXC平台也支持select for update以及提供@hint的功能临时提升事务的隔离级别。
从本质来说，TXC是将原来传统事务场景下由数据库提供的锁机制提升到了TXC服务端进行了实现，这样相比于数据库锁的实现成本更加轻量，加上TXC本身服务能力的扩展能力，最终在同样实现事务隔离性的前提下，大大提升了整体的数据库处理吞吐率。
TXC 如何实现事务自动回滚？
- 用户在向 TXC 服务器发起事务请求后，进入到数据库的操作时，会对该分支事务在 TXC 服务器上进行注册。当资源管理器捕捉到 SQL 的请求后，会对 SQL 语句进行 SQL 解析，如果是执行Insert/Delete/Update的 SQL 操作，则会针对该 SQL 语句构造出对应的SQL查询语句，将当前 SQL 请求要修改的数据先从数据库中获取，以 Undo 日志的方式保存起来，用于将来回滚；
- 进行实际的 SQL 语句的执行，在 SQL 执行完毕以后，会再次通过查询方式获取到修改后的数据，并保存为Redo日志，用于业务回滚前脏数据的校验；
- 当 SQL 的执行和 Undo/Redo 日志作为一个本地事务提交给数据库的同时，也会更新分支事务状态。当整个事务成功提交后，则会删除 Undo/Redo 日志。
TXC 的性能
两个查询+一个update+一个insert，数据库qps峰值为23000。采用TXC实现分布式事务后，整体的QPS峰值接近20000，吞吐率仅下降13%左右。
在100并发测试下，测试平台运行10个小时，完成了接近1亿次分布式事务，全部成功，没有业务异常
关于柔性事务的总结
- 应用程序一定要做幂等实现，特别是对数据库进行数据修改操作时。
- 远程模块之间用异步消息来驱动，异步消息还可以起到检查点的作用。
缓存技术？
这里就简单讲了下大促时一些缓存使用技术，譬如前度页面的缓存、大库存商品库存信息缓存化等。讲的非常浅。
打造数字化运营能力
鹰眼：分布式服务调用链跟踪平台。
TraceID：会出现在该请求中所有服务调用、数据库、缓存、消息服务访问时生成的所有日志中；
RCPID：通过顺序编号的方式表示服务间的顺序关系，采用如1.1、1.2.1的多级编号方式标识日志埋点顺序和服务调用间的嵌套关系；
埋点：将实现服务调用、各种资源的访问所需要生成服务链路日志，以及TraceID传递等功能的代码（称为埋点）植入到了服务框架层和各资源的访问驱动层，也就是在中间件层面上统一实现了鹰眼的上下文创建以及日志埋点功能，让调用上下文在中间件的网络请求中传递，同时将调用上下文信息保存在了本地ThreadLocal中，从而实现了鹰眼平台所需的调用上下文和日志信息对于应用开发人员完全透明
通过对采样率的使用，在遇到大量请求时只记录其中一部分数据，而不是像平时那样做全量的数据记录。在较低采样率和较低传输负载下，可能会导致错过重要事件，而想用较高的采样率就需要能接受一定的性能损耗。所以在实际的使用中，结合服务调用的频率和业务的访问量，调整适合的日志采样率，找到事件捕捉和性能损耗的平衡点，也是此类跟踪平台需要考虑的问题。
打造平台稳定性能力
限流和降级
阿里巴巴是通过在Nginx上实现的扩展组件TMD（Taobao Missile Defense，淘宝导弹防御系统）实现了接入层限流的主要工作，TMD系统可通过域名类限流、cookie限流、黑名单以及一些安全策略等很好地实现了在接入层的限流措施。
Sentinel平台主要涵盖了授权、限流、降级、调用统计监控四大功能模块。Sentinel提供了多个默认切入点，比如服务调用时，数据库、缓存等资源访问时，覆盖了大部分应用场景，保证对应用的低侵入性；同时也支持硬编码或者自定义AOP的方式来支持特定的使用需求。
…需要通过Sentinel实现限流功能的应用中都嵌入了Sentinel客户端，通过Sentinel客户端中提供对服务调用和各资源访问缺省实现的切入点，使得应用方完全不需要对要实现限流的服务或资源进行单独的AOP配置和实现…
评：这是 SDK 接入还是节点 agent？
流量调度
单机、局部服务能力出现问题，带来的影响远比我们预估得要严重，原因是：
- 分布式服务环境调用链路局部问题会被放大到整个链路；
- 单点、局部问题会被放大成面。
阿里巴巴中间件团队实现了针对分布式服务系统的流量调度平台，用于屏蔽所有机器的软硬件差异，根据机器的实时服务能力来分配机器的实时流量。
- 对实时服务能力好的机器多分配流量；
- 对实时服务能力差的机器减少流量分配；
- 对实时服务能力不可用的机器迁移流量。让因为软件或者硬件带来的单点、局部问题发生时，不会影响整体业务的稳定运行。
流量调度的核心是通过秒级获取服务器系统运行指标以及业务指标，通过流量调度平台设置的决策算法以及规则，当发现满足规则条件的指标状态发生时，对线上环境的服务器进行下线等操作，以屏蔽这些单点或局部出现故障的应用实例对整体平台产生扩展式的影响。
收集到系统指标、业务指标信息这些实时指标值后，一旦判断为故障现象，则执行对线上流量调度的执行。譬如，当发现某些服务提供者出现服务响应慢或系统资源负载飙高时，实时降低对该服务器的服务路由权重（甚至直接降为0），最终达到通过自动化的流量调度来隔离故障。
举例：流量调度通过迁移个别这种发布负载飙高机器的流量，等到机器的负载降低到正常范围内后，再自动恢复机器流量。
业务开关
动态开关，类似于美团点评的 MCC 组件。
容量压测和评估
应用系统容量压测和评估的自动化平台通过对生产环境上的流量模型引流到压测服务器上，获取到服务实例单机最大处理能力，结合不同型号服务器处理能力以及生产环境的水位监控信息，对服务集群所需部署的服务器数量进行容量评估及预测。这种方法优点在于：实用，准确，高效。
美团点评内部也有类似的压测平台，思路基本一致，但是上文提到的平台仅能测试单机的服务处理能力（通过权重实现）。
全链路压测平台
全链路压测平台通过应用系统改造使线上环境可以同时处理正常流量和测试流量，以支持线上不影响正常用户访问的集群读写压测，获得最真实的线上实际承载能力数据。
*…阿里巴巴在2013年双11准备过程中开始了称为全链路压测的工作，经过3年的发展，已经沉淀成为一个业界领先的全链路自动压测平台。该平台在过去一段时间内很少对外宣传，称得上是过去几年阿里巴巴集团针对天猫双11自主研发出的一项黑科技…
看到这里我蛮激动的，然后看到翻过去看了一页….就没有了，敷衍啊~
业务一致性平台
实时业务审计平台（Business Check Platform，BCP）统一解决平台服务化后越来越凸显的业务一致性问题，解放业务人员那颗悬着的心。BCP平台并不仅限于交易类业务，也适合其他对业务稳定性要求比较高的领域。
BCP平台通过事件模式，把业务数据变化触发的消息（如精卫、MQ等平台消息）转换为相应业务类型的事件，放入到事件执行队列进行规则检查，BCP提供了通用的事件监听框架，实现了与MQ（消息服务）对于数据库的对接，是对于数据变更的日志信息接入到了BCP平台中。
对于平台或应用进行服务化后，很难保证所有的应用设计人员都能对每个服务的能力和逻辑准确认识，而且不同业务链路是由不同的人来设计实现的，业务不一致会是此类平台迟早会面临的问题。BCP平台让整个平台稳定性的能力从技术维度延伸到了业务维度，完善了平台稳定性的覆盖广度，是平台稳定性体系化的一个非常重要的拼图。
这个功能挺好的，赞同「BCP平台让整个平台稳定性的能力从技术维度延伸到了业务维度」。
共享服务中心对内和对外的协作共享
服务化建设野蛮发展带来的问题
服务化建设野蛮发展带来的问题:
- 服务的数量和业务覆盖范围越来越大；
- 应用和业务架构越分越细，服务越来越专业化，跨领域理解的成本越来越高；
- 服务安全控制层缺乏；
- 开发体验很不友好，产品在接入流程，开发使用手册建设非常之差；
- 整体服务体系缺乏一个统一的服务治理层。
共享服务平台（Shared Platform as Service，SPAS）的目标是对阿里巴巴集团的服务更好地进行治理和共享，其实也可以看做服务能力在线化、数据化的过程。
离线的时候，服务能力没有数据化，都沉淀在小二的脑子里或者各种Wiki上；服务在线后，服务和服务的结构化信息都在服务平台上，从而缩短了开发者与服务提供者之间的路径。
- 离线模式下的路径是：服务消费者（业务开发者）→各种渠道（电话、旺旺、小二）→服务提供方→服务；
- 共享服务平台建设之后的流程：服务消费者（业务开发者）→共享服务平台→服务→服务提供者。
共享服务平台的建设思路
- 服务 是一个名词，通常我们说的服务是指服务端暴露出来的一种服务接口，与服务消费者相对应，其代表了服务端一个具体的能力。在SOA架构中的服务被当成一个组件对象，组件就包括服务接口和附加在这个接口上的组件规范：服务策略、限制、描述等，我们把这种服务称为组件化服务。
- 服务化 是一个动词，它更像是一个商业策略，核心是从产品能力转化直接服务客户的能力。
从产品和技术手段上如何实践共享服务这个目标？践行共享服务最基本的目标就是把普通的服务能力升级为组件化服务并提供良好的服务治理支持。
以下是依次实现服务共享的条件：
- 要找到一个合适的服务化对象；
- 建设对象服务化的基础设施；
- 服务化实施阶段；
- 增强服务和基础设施实现服务的精细治理。
服务化实施的三个阶段：
- API as Service：这个阶段就是让API具有服务组件的能力；
- Product as Service：在共享服务平台上利用API服务来开发和部署组合服务。这类组装的服务更面向业务场景，更专业化。对开发者来说，使用会非常友好，对提供者来说，对这类服务的管理可以支持到非常细腻，提升管理服务的效率；服务组装旨在真正实现服务粒度的敏捷，让服务开发和部署的流程可以非常简单和快速，服务提供者利用服务平台的服务辅助开发工具实现在服务端或者客户端封装的服务。
- Solution as Service：通过共享服务平台的方式沉淀出解决方案。
总结来说，共享服务平台是各方参与共建，把离线的服务能力数据在线的过程，在这个过程中，共享服务平台只是提供服务共享的基础设施和服务治理的规范与工具。把离线的服务能力在线化，建设一个丰富的服务市场，这需要业务方共同参与密切协作。
业务中台与前端应用协作
业务中台与前端应用协作的模式：
- 业务中台对前端核心业务的紧密沟通机制；
- 建立分歧升级机制；
- 岗位轮转推动真正换位思考；
- 业务持续沉淀及共建模式；
业务中台绩效考核
业务中台比较有特点的绩效考核机制:
- 服务稳定是重中之重；
- 业务创新推动业务发展；
- 服务接入量是衡量服务价值的重要考核；
- 客户满意度促动服务的提升。