阿里巴巴中台战略简介_阿里巴巴业务中台 2023

本书最重要内容是前两部分：第一是从阿里巴巴启动中台战略说起，详细阐述了共享服务理念给企业业务发展带来的业务价值。第二分享了阿里巴巴在建设共享服务体系时如何进行技术框架的选择，哪些重要的技术平台支撑起了共享服务体系。最后的案例实践笔者就感觉比较水了。

 

作者钟华说，在当今整个中国社会都处于互联网转型的浪潮中，不管是政府职能单位、业务规模庞大的央企，还是面临最激烈竞争的零售行业都处于一个重要的转折点，这个转折对企业业务模式带来了冲击，当然也给企业的信息中心部门带来了挑战：如何构建IT系统架构更好地满足互联网时代下企业业务发展的需要。

 

下面就是本人学习后的几点体会和心得，整理如下：

 

一.    阿里巴巴CTO张建锋提出：为了应对高可用、海量、复杂业务逻辑交织的挑战，阿里巴巴在技术上、组织架构上都进行了深入的探索，并进一步将此种实践提升至中台这样的概念。

 

张建锋在序言是这样说的，本书讲述了阿里巴巴的技术发展史，同时也是一部互联网技术架构的实践与发展史。阿里巴巴业务系统面临的主要挑战，高可用、海量、复杂的业务逻辑交织在一起：

1.对于电子商务、支付业务来说，要求高稳定性与可靠性。

2.对于互联网企业来说，能承载海量的访问请求与数据。

 

阿里巴巴集团为了应对这些挑战，在技术上、组织架构上都进行了广泛的实践。并进一步将此种实践提升至中台这样的概念。在很多技术方面进行了不断的探索，如数据库的水平扩展、复杂业务系统的结构化与服务化、大型系统的消息处理、关键业务系统的实时调控等。

 

二.    一个优秀的技术架构已经超出了效率本身的范畴，而是决定企业成败的关键因素。

 

阿里巴巴电商系统的架构经历了烟囱式架构到分布式架构再到共享式架构的转变，在这个过程中持续推动着大量业务的创新，天猫、聚划算、闲鱼、拍卖、玩兔、淘抢购等应用不断涌现出来，有成功也有失败，因为架构无法决定市场的成功还是失败，但是作为土壤可以不断孵化新的物种。

 

阿里巴巴从2008年开始的架构优化过程其实并没有解决该做什么的问题，但是解决了创新效率的问题。当有人告诉你做一个市场需要100人年的时候，你会犹豫，到底投还是不投；如果告诉你100人月的时候，你会毫不犹豫地投入，所以这时候一个优秀的架构已经超出了效率本身的范畴，而是决定企业成败的关键因素。

 

笔者认为创造企业value和决定企业成败的key factors非常多，站在不同领域的角度分析往往会得出迥然不同的结论。从技术人员的角度来看，一个优秀的技术架构的确能带来领先优势，但是否能构成企业成败的key factors值得论证。

 

三.   信息时代的公司架构到底应该是怎样的？马云带队拜访supercell游戏公司半年后启动阿里集团中台战略。

 

Supercell，是一家号称是世界上最成功的移动游戏公司，以《部落战争》《海岛奇兵》《卡通农场》等游戏知名。一家典型的以小团队模式进行游戏开发的公司，一般来说两个员工，或者5个员工，最多不超过7个员工组成独立的开发团队，称之为Cell（细胞），这也是公司名字Supercell（超级细胞）的由来。

 

 

团队自己决定做什么样的产品，然后最快的时间推出产品的公测版，看看游戏是否受用户欢迎。如果用户不欢迎，迅速放弃这个产品，再进行新的尝试，期间几乎没有管理角色的介入。团队研发的产品失败后，不但不会受到惩罚，甚至会举办庆祝仪式，以庆祝他们从失败中学到了东西。使用这样的模式使得Supercell公司成为了年收入达二十亿美元的游戏公司。

 

Supercell创立到现在，一直坚持优秀的团队创造伟大的游戏、保持小巧而独立团队、要做能玩很久的游戏三条信念：

·      The best teams make the best games

·      Small and independent cells

·      Games that people will play for years

 

 

Supercell的模式给参加此次拜访的阿里高管们很大的震撼，在大家反复的心得交流和讨论中，一个非常重要的问题引起了很多人的反思：信息时代的公司架构到底应该是怎样的？正是有了这次拜访才真正让阿里巴巴的领导层有了足够的决心要将组织架构进行调整，在此次拜访的半年后，集团正式启动2018年中台战略。

 

四.    阿里巴巴“厚平台、薄应用”架构形态中，共享业务事业部正是“厚平台”的真实体现，为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务服务。

 

2009年，共享业务事业部应运而生，在组织架构上单独成为一个跟淘宝、天猫同样级别的事业部，集团希望以这样的方式更好地让技术团队同时支持淘宝和天猫的业务，同时也将两套电商的业务做了梳理和沉淀，将两个平台中公共的、通用的业务功能沉淀到了共享业务事业部，避免有些功能的重复建设和维护，更合理地利用技术资源。

 

但接下来的发展却事与愿违。虽然组织架构上共享业务事业部和淘宝、天猫平级，但从对业务的理解和业务贡献的体现来说，淘宝和天猫相对共享业务事业部拥有着更多的话语权，结果就是共享业务事业部在两大业务部门的业务需求下艰难生存着。

 

 

真正带来转折的是2010年，作为阿里电商业务的团购入口——聚划算的出现。这时出现了对于共享业务事业部历史转折点的一个举措，集团要求三大电商平台如果要与聚划算平台进行业务对接，必须通过共享业务事业部！从而最终奠定了今天大家所看到的共享业务事业部成了阿里巴巴集团业务的核心业务平台。

 

 

阿里巴巴“厚平台、薄应用”架构形态，目前阿里巴巴集团前端超过25个业务单元（如淘宝、天猫、聚划算、去啊等大家熟知的业务）均不是独立地构建在阿里云的云平台之上，在后端阿里云技术平台和前端业务间有了一个“共享业务事业部”，将阿里巴巴集团前端业务中公共、通用的业务沉淀到了这个事业部，包含了用户中心、商品中心、交易中心、评价等十几个中心，而共享业务事业部正是“厚平台”的真实体现，为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务服务。

 

五.     企业IT系统建设的传统模式带来很大弊端，导致IT系统建设早的企业内部系统烟囱林立。

 

今天企业IT系统建设的传统模式是：当业务部门提出业务需求，信息中心部门进行系统集成商的招投标（如自身有开发团队的企业则无需此流程），再进入到需求收集、需求分析、开发、测试、上线的项目周期中，某种程度上每个新系统的上线都预示着一座新的烟囱矗立而成，这种完全基于业务需求建设系统的方式已经成为过去20多年企业建设IT系统的标准流程，导致IT系统建设早的企业内部系统烟囱林立。这正是今天很多企业面临互联网转型难的根节所在。

 

其实对于“烟囱式”系统建设带来的弊端在十年前就已经有人提出，以这样的方式建设系统对企业的“伤害”有三大弊端：

1）     重复功能建设和维护带来的重复投资。

2）     打通“烟囱式”系统间交互的集成和协作成本高昂。

3）     不利于业务的沉淀和持续发展。

 

 

 

采用“烟囱式”方式建设的系统体系，企业中一个业务领域的数据和业务往往就被打散在不同的系统中，采用系统打通的方式解决了眼前相关业务间的交互问题，但这样的方式治标不治本。随着业务的发展，这样的方式最终无法满足业务快速响应和业务模式创新的需求。

 

六.   共享服务架构的建设使得阿里巴巴摆脱了因为“烟囱式”系统建设方式所带来的种种发展桎梏，最终成为阿里巴巴业务中台战略的核心组成。

 

SOA理念最核心的价值：松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新。

 

SOA的主要特性：

·      面向服务的分布式计算。

·      服务间松散耦合。

·      支持服务的组装。

·      服务注册和自动发现。

·      以服务契约方式定义服务交互方式。

 

今天的阿里巴巴已经将集团20多个核心业务中公共的、通用的业务以服务的方式沉淀到了共享业务事业部，共享业务事业部在中台战略中扮演着至关重要的作用，整个集团的核心业务能力均建立在这样一套共享服务体系之上，使得我们在今天的业务支持中，真正发挥出了SOA架构的核心价值——服务重用。

 

 

上图展示了共享服务是如何支持前端业务的，以1688（B2B电商平台）、淘宝（C2C电商平台）、聚划算（团购平台）、闲鱼（二手商品交易平台）为例，每个平台都有各自的订单创建流程，各流程所包含的服务数量和流程因为业务场景的不同而有所不同，但不管是哪种模式下的订单创建无一不会牵涉会员信息的验证、商品库存的修改、订单的创建、支付记录的生成，这些相关的服务均是由各自的服务中心提供的，也就意味着不管前端业务形态如何多样，共享服务中心提供的服务都能很好地提供所包含的核心服务，让前端业务的交易信息和数据回流到对应的服务中心。

 

今天阿里巴巴整个集团有超过2000多个应用，因为各个应用在核心业务层已经通过共享服务体系实现了统一和畅通，所以今天阿里巴巴集团内部没有类似ESB的组件。

 

七.     服务不需要“业务稳定”，而需要不停的滋养。

 

SOA项目是基于一种集成项目建设的方式，就很容易造成服务提供者面对业务提出更多要求时，考核指标、工作回报都不能得到很好体现，服务提供者在主观上没有太大的积极性满足新的业务需求，再加上如果当初服务设计的功能扩展性和业务前瞻性不足，导致有心无力满足新的需求，结果是这些服务无法再进行功能扩展，成为企业“业务稳定”运行的“服务”。

 

作者强调，服务不需要“业务稳定”，而需要不停的滋养，只有在滋养中才能从最初仅提供单薄业务功能的服务逐渐成长为企业最为宝贵的IT资产，而服务所需的滋养正是来自新的业务不断进行服务的接入。

 

 

阿里巴巴共享业务事业部经过多年探索后沉淀下的5大价值定位，其中中间最为核心的三个关键字“服务”“滋养”和“稳定”已经清晰地定义了共享服务的真谛。

 

八.      业务试错是一个非常重要的能力，只有先人一步，唯快不破，才能帮助企业抢占商业先机的制高点。

 

企业要想在互联网时代相比同行业的竞争对手们真正产生差异化的竞争力，业务试错是一个非常重要的能力，只有先人一步，唯快不破，才能帮助企业抢占商业先机的制高点。互联网时代的竞争只有第一，没有第二，这也是作者认为互联网公司的IT架构能力跟传统企业间最大的差别！

 

试想一下，如果之前有一个好的业务想法，从头到尾建设所需的资源投入可能是20个人、4个月的时间，还有可能建设的系统达不到预期的市场效果，那这样一个典型的业务试错的成本是非常高昂的，任何一个企业都很难支持这样的试错方式。

 

如果企业打造了很好的业务中台，可以让3个人基于中台提供的核心服务在2周的时间内就能建设一个系统并推向市场，看看市场的反馈来决定是否加大对这个新业务的投入，任何一家企业的领导都是很乐意做这样的投入和尝试的。

 

九.   共享服务体系可以为真正发挥大数据威力做好基础。

 

在2009年共享业务事业部成立后，将阿里巴巴集团几大电商平台的用户、商品、交易等业务沉淀为了几大服务中心，随着集团对电商平台中各业务指标越来越关注，阿里巴巴开始打造自己的大数据平台，基于现有的共享业务事业部各服务中心的数据，很快就构建了早期的淘宝指数平台，可以从各个维度（用户、区域、行业等）展现出各种业务指数，为集团和商家的业务决策和营销策略提供了最有力的支持。

 

 

十.   通过共享服务体系的建设以及组织阵型的调整，势必让整个部门的生产力和业务响应效率得到极大的提升。

 

阿里巴巴集团在构建了共享服务体系之后，对于各技术团队的组织架构也做了调整。针对每一个建设的服务中心，从组织架构的形态上也发生了对应的调整，会有不同角色的人员（架构师、开发人员、UED工程师等）组建成了一个新的组织，每一个这样的组织都针对某一服务中心提供持续的服务能力开发及运维，更准确说是基于这一服务中心的业务能力进行“运营”。

 

所以在今天阿里巴巴共享服务体系中的这些服务中心，每一个服务中心都是由一个少则100多人，多则4、5百人的团队对负责的服务中心进行专业的运营。采用这样的方式，就很好地解决了之前流水线模式下，不同角色技术人员很难对于某一业务领域有持续的理解和沉淀，而采用围绕服务能力持续运营构建独立组织的形态，让整个团队对于该服务中心的能力逐步完善、专业以及稳定负责，在这个过程中，团队的成员就有了足够的时间和机会对于该服务相关的业务领域有了更深入的理解，从而为团队培养出既懂技术，也懂业务的复合型人才创建了良好的生长土壤。

 

十一.   淘宝平台“服务化”历程：基于SOA理念新一代服务化框架研发以及采用业务模块逐步迁移的方式进行应用架构的改造工作。

 

2007年，淘宝已经拥有超过500人的技术团队规模，整个淘宝网站是一个几百兆字节的WAR包，大小功能模块超过200个，在当时淘宝业务计划处于每隔几个月就翻倍的高速发展期，这样的应用架构给淘宝技术团队带来了非常大的压力。

 

解决以上问题的根本就在于业务的拆分，而当时业界已经盛行的SOA理念和方法则是有效解决以上问题的不二选择。我个人是SOA理念的坚定拥护者，因为看到了太多基于SOA建设或重构的系统给企业带来了实实在在的业务能力和竞争力的提升。所以淘宝在2007年10月开始了一系列的基于SOA理念新一代服务化框架研发以及采用业务模块逐步迁移的方式进行应用架构的改造工作。

 

首先淘宝从现有应用中选择了用户相关的功能作为试点，剥离出了用户服务中心，其主要出发点是用户的业务逻辑相对独立和简单，而且服务功能的复用率最高。经过两个多月的应用改造，用户中心于2008年年初成功上线。

 

紧接着，又相继开始了两个在阿里巴巴内部非常著名的项目：“千岛湖”项目成功将“交易中心”和“类目中心”从现有平台中进行了剥离和改造，“五彩石”项目则将剩下的“商品中心”、“店铺中心”等核心业务功能模块进行了全部的改造。最终在保障淘宝业务不间断运行和不影响业务发展的同时，在14个月的时间内将原来单一应用的模式改造成为基于SOA理念的分布式服务架构。

 

十二.  去中心化分布式服务框架：服务提供者和服务调用者之间在进行服务交互时无需通过任何服务路由中介。

 

传统ESB的服务调用方式是，每一次服务的调用者要向服务提供者进行服务交互请求时都必须通过中心的ESB来进行路由。经过服务总线路由过的服务交互，共出现4次网络会话创建和数据传输，而“去中心化”服务架构中服务交互，一次服务的调用只有两次网路会话创建和数据传输，在网络上的开销整整减少了一半。

 

 

“去中心化”分布式服务框架除了对于SOA特性的实现和满足外，相比“中心化”服务架构最重要的不同就是服务提供者和服务调用者之间在进行服务交互时无需通过任何服务路由中介，避免因为“中心点”带来平台能力难扩展问题，以及潜在的“雪崩”影响。

 

 

十三.   阿里巴巴集团内部使用的分布式服务框架HSF（High Speed Framework）。

 

HSF服务框架包含以下主要组件：

 

 

1.服务提供者。 在服务框架中真正提供服务功能实现的应用实例，为了保障服务提供的高可用性，一般均是集群部署。

 

2．服务调用者。 作为服务的消费者，大多数也是以WAR应用包的方式运行在Tomcat容器中，在阿里巴巴集团内部也有一部分是基于C/C++、PHP、Node.js等语言开发的服务调用者。

 

3.地址服务器。 在HSF服务框架中肩负着给服务提供者和服务调用者提供部署环境中所有配置服务器和Diamond服务器的服务器列表信息，是由Nginx（是一个高性能的HTTP和反向代理服务器）提供该服务能力。

 

4.配置服务器。 配置服务器主要负责记录环境内所有服务发布（服务提供者的IP地址和服务端口信息）和服务订阅（服务调用者的IP地址和服务端口信息）信息，并将服务相关信息推送到服务节点上。为了追求服务发布和订阅的推送效率，所有的服务发布和订阅信息均是保存在内存中。

 

5.Diamond服务器。 本质上，Diamond服务器是一个通用的统一配置管理服务（类似于Zookeeper），给应用提供统一的配置设置和推送服务。

 

十四.    共享服务中心的几点构建原则。

 

从淘宝共享服务中心演变的过程，我们可以看出业务架构是能反映业务变化的，服务中心作为共享架构的核心元素一定也会体现出这种变化，所以不做过于超前的设计，也不做过于理想化的架构。

 

共享服务中心的架构目的是通过业务拆分来降低系统的复杂性；通过服务共享来提供可重用性；通过服务化来达到业务支持的敏捷性；通过统一的数据架构来消除数据交互的屏障。

 

一些基本原则如下：

 

1.高内聚、低耦合原则

高内聚是从服务中心的业务界域来说的，在一个服务中心内的业务应该是相关性很高、依赖性很高的；而服务中心之间应该是业务隔离性比较大的，即追求尽可能的低耦合。注意这里的业务隔离性是从应用场景来说的。

 

2.数据完整性原则

这个原则其实和上面的“高内聚、低耦合”一脉相承，是把这个思想穿透到数据模型层面，因为服务化架构一个很重要的业务价值就是数据模型统一。

 

3.业务可运营性原则

服务中心首先是从业务出发，单纯的技术层面抽象出来的服务框架一般不作为一个可运营的服务中心。单纯的技术型的服务中心可以存在，但服务中心是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元。

 

4.渐进性的建设原则

渐进性的建设原则是从降低风险和实施难度这个角度出发，服务化架构本来就是一种敏捷的实践，推荐小步快跑的方式逐步推进，不是轰轰烈烈地推翻重来。

 

 

十五.   数据拆分实现数据库能力线性扩展

 

在淘宝平台向共享服务体系改造的过程中，通过各个服务中心拥有各自独立数据库的方式，即采用数据垂直分区的方式对业务数据进行分区，确实在很大程度上缓解了当时数据库连接数资源捉襟见肘和数据库因为表多、数据多造成的性能等问题。从当时淘宝业务突飞猛进式的发展势头来看，单一服务中心的数据访问压力也必然很快会达到单机数据库的承载上限，所以在进行服务化改造的同一时间段内，淘宝技术团队也开始了对数据库能力扩展的工作。

 

作者总结的阿里巴巴数据库分库分表的几个原则：

 

1.数据尽可能平均拆分

不管是采用何种分库分表框架或平台，其核心的思路都是将原本保存在单表中太大的数据进行拆分，将这些数据分散保存到多个数据库的多个表中，避免因为单表数据太大给数据的访问带来读写性能的问题。

 

2.尽量减少事务边界

事务边界即是指单个SQL语句在后端数据库上同时执行的数量，即一条SQL语句同时被推送到后端所有数据库中运行。事务边界的数量越大，会给系统带来弊端。

 

3.异构索引表尽量降低全表扫描频率

最常用的是采用“异构索引表”的方式解决，即采用异步机制将原表内的每一次创建或更新，都换另一个维度保存一份完整的数据表或索引表。本质上这是互联网公司很多时候都采用的一个解决思路：“拿空间换时间”。

 

 

4.将多条件频繁查询引入搜索引擎平台

采用数据异构索引的方式在实战中基本能解决和避免90%以上的跨join或全表扫描的情况，是在分布式数据场景下，提升数据库服务性能和处理吞吐能力的最有效技术手段。但在某些场景下，比如淘宝商品的搜索和高级搜索，因为商品搜索几乎是访问淘宝用户都会进行的操作，所以调用非常频繁，如果采用SQL语句的方式在商品数据库进行全表扫描的操作，则必然对数据库的整体性能和数据库连接资源带来巨大的压力。所以面对此类场景，不建议采用数据库的方式提供这样的搜索服务，而是采用专业的搜索引擎平台来行使这样的职能。

 

十六.     分布式应用架构中的重要技术：异步化与缓存

 

1.业务流程异步化

平台进行服务化后，在平台页面上发起的业务请求势必需要将后端不同的服务进行组合调用来实现业务请求的处理。以淘宝的交易订单为例，目前淘宝的订单创建流程需要调用超过200个服务，如果按照之前所有业务逻辑均是在一个JVM中顺序执行的方式，要完成超过200次的远程服务调用，就算所有服务的调用时间都控制在20ms内返回结果，整个订单创建的时间也会超过4s，这个时间长度对于今天互联网时代的客户来说已经超过了忍耐极限。

 

 

 

其实稍微有点设计经验的技术人员都会想到以异步化方式将交易创建过程中，对于有严格先后调用关系的服务保持顺序执行，对于能够同步执行的所有服务均采用异步化方式处理。

 

阿里巴巴内部使用消息中间件的方式实现了业务异步化，异步化后的业务处理流程提高了服务的并发处理，从而大大减少整个业务请求处理所花的时间。目前淘宝平台从用户点击订单创建到返回订单创建成功的页面平均时间控制在300ms左右，让用户有非常好的用户体验，同时整个平台的吞吐量也会得到几何倍数的提升。

 

 

2. 数据库事务异步化

解决平台性能问题的核心就是数据库事务的异步化。通俗来说，就是将大事务拆分成小事务，降低数据库的资源被长时间事务锁占用而造成的数据库瓶颈，就能大大提升平台的处理吞吐量和事务操作的响应时间。

 

 

 

3.缓存技术的高度使用

 

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

 

从淘宝缓存产品的研发和使用场景的历程来看，是随着业务的快速发展以及某些特定业务场景的出现而逐步演变的。早期通过缓存实现应用分布式session，以避免应用实例间会话的复制，后来发展为将缓存用于业务去重判断、交易快照、图片索引等场景，最后替换数据库在业务交易处理中的职能，缓存平台在业务场景中扮演了越来越重要的角色。

 

十七.    阿里巴巴采用分布式日志引擎解决各类技术和业务问题，为今天阿里巴巴的数字化运营能力逐步奠定了坚实的平台和数据基础。

 

分布式服务体系建设后，整个淘宝平台变成了一个复杂无比的服务交互链路网，如何对每天发生的几千亿次服务调用出现报错时快速定位问题，如何实时监控到服务的运行状态是否正常，如何给运营团队关注的业务指标提供实时呈现以供他们进行实时的精准营销，这一系列的问题都是应用基于分布式服务体系建设后所面对的问题和诉求。

 

鹰眼平台是阿里巴巴中间件团队自主研发的JStorm流式计算引擎，对应用集群接收到的日志进行内容的解析拆分，按照不同业务场景的需求将拆分后的数据保存到不同的存储系统中。对于需要对日志信息进行实时业务统计的需求，会将日志信息保存到HBase中，对接收到的日志信息进行实时的汇总计算，最后给鹰眼服务器提供实时业务统计数据，比如某一服务实时的QPS值、交易金额的实时变化等场景。

 

 

实现分布式服务跟踪系统的主要思路是通过服务调用链各服务处理节点生成相应的日志信息，通过同一请求中生成的日志具有同一个ID将不同系统或服务“孤立的”日志串在一起，重组还原出更多有价值的信息。

 

笔者感叹，以前在传统金融机构为了分析计算业务的事件、任务维度的笔均耗时，就要花费九牛二虎之力从数仓下数，而且数据准确性往往是要听天由命。某次汇报为了取数、校准前后花费了半年之久，但最后计算出的数据也是将信将疑。笔者作为业务人员，面对公司内部众多系统不同的数据表、不同的口径、不同的逻辑，想简单精确的获取运营数据真是难于上青天。

 

如果传统金融机构在顶层设计和系统架构层面能规划类似阿里一样强大的分布式计算引擎，为前台提供数据基础和支撑平台，那么数字化中台、数字化运营和Fintech才不会是空中楼阁。

 

十八.     打造共享服务中台的平台稳定性能力。

 

在整个稳定性体系中，所包含的范围非常广泛，从机房的布线、网络通信、硬件部署、应用架构、数据容灾等方面都与之相关。从共享服务中台的角度，则更多的是从应用架构设计和中间件平台的维度对平台的稳定性实现更精细化的管控和保障。

 

作者在书中介绍阿里巴巴中间件团队多年来为了提升淘宝和天猫平台的稳定性所作出的一系列技术创新和成果，包括限流和降级、流量调度、业务开关、容量压测和评估、全链路压测平台、业务一致性平台等。

 

 

总结

 

评分：★★★★☆（四星推荐）

 

评价：读完本书，对于中台思想的了解更上一层楼。作者从系统架构师的角度来看待中台战略和共享服务平台的价值，并阐述了共享服务平台的技术和框架。虽然本书存在一些逻辑和行文的问题，但总体瑕不掩瑜，值得四星推荐。最大的收获，作者对于技术中台概念的系统讲解，引起了我从产品经理的角度去思考传统金融机构的业务和产品中台价值、数字化运营价值, 中台战略的最大价值在于共享服务。

 

对于商业银行普遍应用的条线化组织架构，天然容易存在竖井林立、职责边界不清的弊端。如果能强化技术和组织架构的中台力量，并赋予对等的权力，整合整个企业的产品和技术能力，真正打造金融产品中公共的、通用的业务以共享服务的方式沉淀到中台产品部门，快速响应和服务前台业务需求，则会助力数字化时代打造商业银行的数字化运营能力。