企业IT架构转型之道：阿里巴巴中台战略思想与架构实战

钟华

序言一

• 互联网技术架构的实践与发展史。
• 在数据库层面，阿里巴巴很早就启动了去IOE的项目，本质上是想解决大规模数据的线性可扩展问题，包括存储与访问两个方面。

序言二

• 系统的建设要从生产型模型升级到运营型模型，从版本模型升级到迭代模型。运营型模型最大的优势是所有的积累都被沉淀，而生产型模型会因为10%的差异而重新建设100%的系统。

前言

• 共享服务理念和企业级互联网架构
• 阿里巴巴的共享服务理念以及企业级互联网架构建设的思路，给这些企业带来了不少新的思路
• 我一直以来都信奉再好的技术和框架如果不给企业带来业务价值，就没有太大意义

第一部分 引子

• 阿里巴巴共享业务事业部从建立、摸索及系列演变，到最终成为阿里巴巴业务中台战略中核心组成部分的过程。
• 构建符合DT时代的更具创新性、灵活性的“大中台、小前台”组织机制和业务机制，即作为前台的一线业务会更敏捷、更快速适应瞬息万变的市场，而中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑。

第2章 构建业务中台的基础——共享服务体系

• SOA理念最核心的价值：松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新。
• 最重要的是让信息中心部门从之前在企业中“业务支持”的组织职能，转变为基于企业核心业务和数据进行运营的团队，这个团队会更快、更好地支持业务发展的同时，逐渐掌握企业最核心的业务和数据，逐步培养出企业最稀缺的“既精通业务，又熟悉技术”的复合型人才。在接下来整个社会进入开放共享的时代，企业最大的价值将会是基于这些核心业务和数据进行对外开放的运营，到那个时候，这个部门将成为企业最为宝贵的资产。

第二部分 共享服务体系搭建

• SOA的主要特性： ❑面向服务的分布式计算。 ❑服务间松散耦合。 ❑支持服务的组装。 ❑服务注册和自动发现。 ❑以服务契约方式定义服务交互方式。
• 微服务架构的典型特征的描述： ❑分布式服务组成的系统。 ❑按照业务而不是技术来划分组织。 ❑做有生命的产品而不是项目。 ❑智能化服务端点与傻瓜式服务编排。 ❑自动化运维。 ❑系统容错。 ❑服务快速演化。

第4章 共享服务中心建设原则

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

第5章 数据拆分实现数据库能力线性扩展

• 首先实施的是数据库的读写分离
• 如果最后发送到分布式数据层的SQL语句中没有分库键，则通过对“库名+表名+主键值”哈希后对线程数取模，这样就能让同一条记录的数据同步事件处理都会在同一线程中顺序执行，保证了该记录多次变更的顺序性，但是不保证不同记录间的顺序。如果SQL语句中有分库键，则通过“库名+分库键值”哈希后对线程数取模，效果是保证不同逻辑表针对相同分库逻辑的记录变化顺序。
• 友好的用户自服务接入体验
• 精卫平台是整个电商业务实现数据实时同步复制的统一平台
• 所以提供一个用户体验友好，自带常用功能的平台，能针对大部分的业务需求可以让应用方在界面上通过配置的方式就能实现，大大降低接入开发成本。
• 不需要在各个前端应用层的代码中去实现，只需统一通过精卫平台实现。有了这样专业的平台来实现数据同步的效率、服务高可用性、任务管控、统计等，能提供更好的服务。
• 采用数据异构索引的方式在实战中基本能解决和避免90%以上的跨join或全表扫描的情况，是在分布式数据场景下，提升数据库服务性能和处理吞吐能力的最有效技术手段。
• 以82法则，在实际中，我们仅针对那些在80%情况下访问的那20%的场景进行如数据异构索引这样的处理，达到这类场景的性能最优化，而对其他80%偶尔出现跨库join、全表扫描的场景，采用最为简单直接的方式往往是就最有效的方式。
• 在实际中，我们仅针对那些在80%情况下访问的那20%的场景进行如数据异构索引这样的处理，达到这类场景的性能最优化，而对其他80%偶尔出现跨库join、全表扫描的场景，采用最为简单直接的方式往往是就最有效的方式。

第6章 异步化与缓存原则

• 异步化与缓存两个技术都与系统的性能有很大的关系
• 对于原来应用中利用数据库事务特性解决的事务性问题在新的技术体系下给应用开发带来了新的挑战。
• 其实稍微有点设计经验的技术人员都会想到以异步化方式将交易创建过程中，对于有严格先后调用关系的服务保持顺序执行，对于能够同步执行的所有服务均采用异步化方式处理。
• 解决平台性能问题的核心就是数据库事务的异步化。通俗来说，就是将大事务拆分成小事务，降低数据库的资源被长时间事务锁占用而造成的数据库瓶颈，就能大大提升平台的处理吞吐量和事务操作的响应时间。
• CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
• 两阶段提交协议有一个重要的优化，称为“最末参与者优化”（Last Participant Optimization, LPO），允许两阶段提交协议中有一个参与者不实现“准备”操作（称为单阶段参与者）。
• 由于消息可能会重复投递，这就要求消息处理程序必须实现幂等（幂等=同一操作反复执行多次结果不变）
• 图6-15 XTS分布式事务架构
• [插图]图6-19 TXC架构示意图
• TXC Server扮演了事务协调者的角色，负责对整个事务上下文的日志的记录以及在事务处理过程中全局的协调和控制
• ❑应用程序一定要做幂等实现，特别是对数据库进行数据修改操作时。❑远程模块之间用异步消息来驱动，异步消息还可以起到检查点的作用。
• 所谓的大促、秒杀场景，其关键词有“低廉价格”、“大幅推广”、“瞬时售空”，只有满足这三个关键词的场景才能称为大促、秒杀的场景。
• 也就是在最后执行库存扣减操作时，将事务开始前获取的库存数量带入到SQL语句中与目前数据库记录中的库存数量进行判断，如果数量相等，则该条更新库存的语句成功执行；如果不相等，则表示该商品的库存信息在当前事务执行过程中已经被其他事务修改，则会放弃该条update的执行，可以采用重试的机制重新执行该事务，避免商品超卖的发生

第7章 打造数字化运营能力

• 分布式日志引擎解决各类技术和业务问题
• 整个服务化后的淘宝平台各个服务间的服务调用关系变得纷繁复杂（如图7-1所示）。对这样复杂的服务调用关系以及每天海量的服务调用，而且所有的服务都是以“点对点”的方式进行交互，就自然会导致出现问题时很难定
• 阿里巴巴中间件团队历时两年多的时间打造了针对分布式服务调用链跟踪平台——“鹰眼”。
• 将实现服务调用、各种资源的访问所需要生成服务链路日志，以及TraceID传递等功能的代码（称为埋点）植入到了服务框架层和各资源的访问驱动层，也就是在中间件层面上统一实现了鹰眼的上下文创建以及日志埋点功能，让调用上下文在中间件的网络请求中传递，同时将调用上下文信息保存在了本地ThreadLocal中，从而实现了鹰眼平台所需的调用上下文和日志信息对于应用开发人员完全透明。
• 在较低采样率和较低传输负载下，可能会导致错过重要事件，而想用较高的采样率就需要能接受一定的性能损耗。所以在实际的使用中，结合服务调用的频率和业务的访问量，调整适合的日志采样率，找到事件捕捉和性能损耗的平衡点，也是此类跟踪平台需要考虑的问题。
• 当服务运行指标出现异常时，该应用的运维人员接收到报警信息的时间是在秒级，真正做到比用户更早一步感知到系统异常，并快速修复。
• 鹰眼平台中的服务调用链跟踪的功能真是针对这个问题的杀手锏。通过对服务调用时的埋点信息的收集，以及TraceID和RCPID的串联作用，给运维人员在Web界面上清晰还原出每一次业务请求所产生的服务链调用情况。
• 调用链跟踪除了对于系统出现问题时，起到快速定位问题的作用，也对应用的性能优化带来帮助。
• 通过调用链跟踪中对于一次请求中服务的调用关系，特别是服务调用的并行度以及一次请求所消耗的时间分布，对于定位应用的性能瓶颈点和优化有较大的帮助。
• 服务调用的并行度实际指的是在业务不受影响的前提下，进行服务的异步调用，使得多个原本依次调用的服务能并行执行，从而大大减少了整个的业务处理响应时间
• 在今天很多的企业中，单单实现了应用服务化工作，但对于随之而来所需的服务管控能力考虑并不多，使得很多的应用和平台都运行在一个不可管控的状态，对于这一类的平台，从专业角度来说这些平台是一个不可用的状态，完全不能支撑起企业业务的进一步发展，同时也存在很大的运维隐患。
• 服务调用链跟踪的功能着重于对业务链路数据的实时监控，服务调用链分析则是对服务调用数据按照不同维度进行离线的统计和分析，两者相辅相成，很好地解决了服务开发人员和业务架构师针对应用服务化后服务管控的诉求，是阿里巴巴服务管控体系最为重要的两个核心功能。
• 通过全息排查平台，将鹰眼平台从对跨系统调用追踪升级为跨业务领域追踪，走出了从运维平台向运营平台转型的重要一步。

第8章 打造平台稳定性能力

• 在出现机房断电或通信电缆故障的情况下，如何保障平台持续稳定运行？
• 包括限流和降级、流量调度、业务开关、容量压测和评估、全链路压测平台、业务一致性平台等。
• 平台要具备限流的能力，首先需要对服务部署的能力有一个准确的评估，知道服务实例的部署量到底最大能满足多少业务请求的处理要求
• 所以在实际中，都会通过服务的QPS作为限流的关键判断指标。
• 重写before方法，那么在调用指定的接口或者方法前会计算当前线程数或QPS，如果当前的线程数大于所设置的最大线程数阈值，则返回访问限流的异常信息
• 因为此方案在实际应用中所暴露出的问题，所以有了限流平台Sentinel的出现。Sentinel平台正如它英文的意思“哨兵”一样，为整个服务化体系的稳定运行行使着警戒任务，是对资源调用的控制平台，主要涵盖了授权、限流、降级、调用统计监控四大功能模块：
• 在云平台中不可忽略的一个问题是为了最大程度地增加机器的利用率，会采用超配的方式，即一台物理机上创建的虚拟机CPU核数的总和会超过物理机实际的CPU核数。
• 原因是在分布式环境中，软件、硬件、网络等因素导致机器的实时服务能力是有差异的。大家可能会认为只要每台服务器的CPU和内存配置一样，这些机器的服务能力都是一样的，但实际在生产环境中，所有机器的实时服务能力都是有差异的。可能因为一次网络抖动导致这台机器实时服务能力下降，也可能因为CPU超配导致资源争抢，从而最终导致实时服务能力下降。
• 流量调度的核心是通过秒级获取服务器系统运行指标以及业务指标，通过流量调度平台设置的决策算法以及规则，当发现满足规则条件的指标状态发生时，对线上环境的服务器进行下线等操作，以屏蔽这些单点或局部出现故障的应用实例对整体平台产生扩展式的影响。
• 限流降级平台重点解决应用在整体上的可用性，流量调度平台很好地弥补了应用局部可用性带来的问题和隐患，为淘宝平台整体平台的稳定运行保驾护航。
• 所以集团开发出了一套统一标准和规范的业务开关管理Switch平台。
• 这种做法的缺陷是测试场景简单，线下环境（即测试环境）中测试出的结果与线上环境（生产环境）并没有对比关系，测试场景是否能较准确的体现出真实场景很大程度上取决于测试人员的经验和水平。
• 这种做法的缺陷是测试场景简单，线下环境（即测试环境）中测试出的结果与线上环境（生产环境）并没有对比关系，测试场景是否能较准确的体现出真实场景很大程度上取决于测试人员的经验和水平。
• 该自动化平台通过对生产环境上的流量模型引流到压测服务器上，获取到服务实例单机最大处理能力，结合不同型号服务器处理能力以及生产环境的水位监控信息，对服务集群所需部署的服务器数量进行容量评估及预测。
• 容量压测是通过将线上真实的流量引流到压测目标机器上，并不会对本系统及下游系统带来额外的流量，也不需要准备测试数据、压测系统。
• 容量规划平台（如图8-12所示）还能利用服务的单机QPS数据，结合对各种服务器机型处理能力的差异化分析，对到底需要部署多少线上服务器资源才能满足大促活动有更准确的预测。
• 已经沉淀成为一个业界领先的全链路自动压测平台
• 全链路压测平台通过应用系统改造使线上环境可以同时处理正常流量和测试流量，以支持线上不影响正常用户访问的集群读写压测，获得最真实的线上实际承载能力数据。
• 在这样的背景下，实时业务审计平台（Business Check Platform, BCP）应运而生，这个平台采用规范与标准化业务规则的方式，统一解决平台服务化后越来越凸显的业务一致性问题，解放业务人员那颗悬着的心。
• BCP平台让整个平台稳定性的能力从技术维度延伸到了业务维度，完善了平台稳定性的覆盖广度，是平台稳定性体系化的一个非常重要的拼图。

第9章 共享服务中心对内和对外的协作共享

• 共享服务中心对内和对外的协作共享
• 阿里巴巴共享服务平台（Shared Platform as Service, SPAS）
• 从基础的中间件服务：分布式数据库、分布式缓存、分布式配置、分布式文件系统、分布式日志、分布式远程调用框架，到电商领域的商品、库存、交易、支付、搜索、商品类目、商品结构化数据等等，甚至比较小众的图像识别、图像搜索
• 2．应用和业务架构越分越细，服务越来越专业化，跨领域理解的成本越来越高
• 从商业本质上来看，云计算其实是让IT产业进行更专业的分工，用专业化、规模化来提高效率，降低总体成本。
• 这和传统商业软件有巨大的反差，商业软件发版有严格的市场策略和规划，他们要用市场来收回成本赚取利润；而互联网模式使用新特性来吸引用户，只要用户在，赚钱永远不是问题。
• 如果只有产品，用户会花费极大的成本去调研、分析、学习，最后使用、维护这个产品，如果你用产品服务化的方式来提供这种产品的能力，对用户来说，看起来购买服务价格高了，但是总体成本却降低了，这也是市场配置资源的结果。所以发展的必然结果就是产品服务化，专业分工更细，云计算的商业本质其实也是这样，通过市场配置资源。
• 以后淘宝业务的扩展是基于服务的扩展而不是基于代码的方式进行扩展，这是Soluting as Service的目标。
• 一定要引入分歧升级以及最终仲裁的机制，不能将问题永远停留在无休止的讨论甚至争吵中。
• 这与前面所讲述的淘宝开放平台最本质的区别是，整个体系中所有的参与者都是被动的使用者，而淘宝商家IT服务商是主动参与者，他们持续地往整个体系中注入自己的智慧和创新的源泉。就是说，所有的参与者都是主动加入到这个体系中，同时不断贡献自己的价值，只有这样才有可能打造出企业所希望的生态效果。

第三部分 阿里巴巴能力输出与案例

• 从2014年开始，阿里巴巴中间件团队就开始着手将原本支撑阿里巴巴集团内部业务的一系列平台进行整合和产品化，以阿里云标准云服务产品的方式将这样原本阿里巴巴集团内部才能享有的互联网技术架构输出给阿里巴巴集团外部的客户，让更多的企业和个人能享受到过去十几年互联网高速发展所带来的技术红利。
• 第一个案例就是阿里巴巴协助国内大型央企在90天构建出一个B2B电商平台，整体平台构建基于阿里巴巴的共享服务理念以及阿里云飞天Aliware一系列产品
• 中心思想是要积极支持云计算与物联网、移动互联网等融合发展，催生基于云计算的在线智能制造、研发设计、教育医疗、等新业态。
• 本章介绍了该央企实施的第一个“互联网+”转型项目——工业品电商平台，在此电商平台项目后，基于电商平台项目过程中打造的业务和技术架构，该央企又进行了一系列业务创新
• 核心是采用云计算设计理念，对服务器、存储等物理设备进行池化，便于对资源的灵活调配，满足不同应用及应用在不同时间段对计算和存储等资源的需求
• 阿里巴巴团队给客户介绍了基于共享业务平台构建的“厚平台+瘦前端”的架构，以多个共享服务中心为基础，可以更好、更快地进行业务的构建和业务变更的响应。
• 业务需求还没有完全明确，项目实施团队没有任何互联网平台实施经验、只有两个半月开发时间，要构建一个如1688的B2B电商平台，而且还要完成跟企业内部原有的招投标、ERP等系统进行集成对接，这个难度几乎让所有人都认为这是一个不可能完成的任务
• 整个项目团队完全采用互联网节奏：每天从早上8:30到晚上9:30，周六上班。
• 在电商平台的建设阶段，系统的共享服务层分为以下几个共享服务中心： 1）会员中心 2）商品中心 3）交易中心 4）搜索中心 5）评价中心 6）内容管理中心
• 你们是一批朝气蓬勃、有战斗力、能打胜仗的团队，你们的付出在开辟着企业一个崭新的未来，实践着国家提出的“服务增值和经济转型”的承诺
• 基于共享服务的理念打造的“厚平台+瘦前端”体系架构同样对传统企业客户的互联网转型有着举足轻重的作用，也让我们将这样的理念和技术架构赋能给更多的企业有了十足的信心。
• 尤其是电商领域，平台上线只是一个重要的开始，但这个平台能否发展壮大甚至是否能生存下去更多取决于平台的后期运营，是否真正做到以客户为中心。
• 共享服务的框架将会是整个集团信息化建设的统一基础框架，只有这样才能彻底解决原来“烟囱式”项目建设的方式带来的数据难打通、业务交互成本高、功能重复建设、业务得不到沉淀的问题，而且能真正做到业务的可持续发展和沉淀，为将来企业在互联网转型过程中所需的业务快速响应、业务的创新或试错打下坚实的服务中台。
• 这次信息中心组织结构的改变表明了信息中心在企业中的组织职能从长久以来的业务支持走向了基于企业核心业务和数据进行服务运营之道

第11章 时尚行业品牌公司互联网转型

• 其一是基于快速响应的供应链协同，其二是基于SCRM的全渠道营销
• 通过分布式应用与分布式数据库解决系统容量与扩展性问题。 ❑通过服务中心的方式，来匹配业务快速变化的需求。 ❑通过阿里技术团队输出技术，解决技术能力获得问题
• 基于中台架构、服务中心的理念，通过分布式应用系统，快速建设POS、SCRM等系统，并通过持续地沉淀业务，并支持新业务的IT快速实现
• 这家品牌公司的零售云平台包括零售后台、门店POS、SCRM、智能供应链（分销自动补货部分）、消费者互动平台，目前系统承载着4000多家门店，为数百万的会员提供互动营销服务。
• 基于互联网技术分布式关系型数据库、企业级分布式应用、企业级消息中间件等
• 自动补货好处之一是快，这种快体现在补货效率上。门店售卖结束后，晚上可以通过系统自动为门店计算需要补多少货品，仓库可以凌晨4点前就接受到指令，仓库可以在8～9点前结束拣货并开始发运，近一些的门店甚至可以当天就收到货。自动补货另外的好处是减少了商品管理人员的日常重复计算工作，可以把更多的时间用于和门店沟通，为门店优化货品结构，帮助门店设计促销方案等。
• 2）在重构POS的时候，建立了库存中心（不光有POS的数据，总仓、分仓的数据也在库存中心）、商品中心、订单中心，复用这些共享服务中心，快速开发了拉式补货系统与O2O（全渠道）订单平台。从软件开发到上线大约经历了2个月的时间。
• 传统的CRM（管理客户型CRM）更多的是分析消费者的历史消费数据，通过若干模型（最常见的是RFM模型），为消费者打上若干标签（分组），然后根据标签推送营销内容。
• 在互联网特别是移动互联网时代，CRM（客户关系管理）最大的一个变化就是加上了S，进化为社会化关系型客户管理，我们可以和消费者互动了。
• 基于SCRM进行全渠道整合营销，我们可以将品牌传播与市场营销移动化、互动化、游戏化，以消费容易接受的方式来增加趣味性与粘性，引导PK来促进分享传播（社交属性）
• 最后注意一点，消费者于企业而言不单单是“流量”，更是一个个鲜活的个体，有情感的诉求，虽然企业是靠通过满足消费者需求而获取利润，但在进行一系列的SCRM营销活动时，必须时刻关注消费者的感受，注重消费者的体验，否则掉粉很厉害的。