阿里巴巴中台战略思想与架构实战笔记

序言之前[本书之外]：行癫认为阿里自身的‘中台化’仍在探索中，‘只完成了30%’。[注：2019年初一位阿里高管]

序言一

随着业务的发展，阿⾥巴巴系统规模进⼀步变⼤之后，需要解决更多、更复杂的问题，⽐如在全球进⾏分布式的部署、99.999%以上的⾼可⽤、容灾等，这对系统的架构与设计提出了更多的挑战。
阿⾥巴巴集团CTO张建锋（⾏癫）
2017年4⽉于杭州

序言二

阿⾥巴巴电商系统的架构经历了烟囱式架构到分布式架构再到共享式
架构的转变。
在早期往往⼀个新业务的上线除了数据可以被重复使⽤之外，服务却不能被重复使⽤。其实服务的重⽤将⽐数据重⽤带来更多好处，数据只是原始⽣产资料，服务则包含逻辑，是⼯⼚的加⼯⻋间，如果加⼯过程也⼀样可以复制，将带来⽣产效率的⼤幅度提升。
阿⾥巴巴集团中间件技术部研究员蒋江伟（⼩邪）
2017年3⽉于杭州

第一部分 引子

第1章 阿⾥巴巴集团中台战略引发的思考

2015年底，阿⾥巴巴集团对外宣布全⾯启动阿⾥巴巴集团2018年中台战略，构建符合DT时代的更具创新性、灵活性的“大中台、小前台”组织机制和业务机制，即作为前台的⼀线业务会更敏捷、更快速适应瞬息万变的市场，而中台将集合整个集团的运营数据能⼒、产品技术能⼒，对各前台业务形成强力支撑。

阿⾥巴巴为什么会在这样⼀个时间点做出如此重⼤的决定呢？
这还要从⼀次商务拜访说起。在2015年年中，⻢云带领阿⾥巴巴集团的⾼管，拜访了位于芬兰的移动游戏公司Supercell，这家号称是世界上最成功的移动游戏公司，以《部落战争》《海岛奇兵》《卡通农场》等游戏知名。Supercell是⼀家典型的以⼩团队模式进⾏游戏开发的公司，⼀般来说两个员⼯，或者5个员⼯，最多不超过7个员⼯组成独⽴的开发团队，称之为Cell（细胞），这也是公司名字Supercell（超级细胞）的由来。团队⾃⼰决定做什么样的产品，然后最快的时间推出产品的公测版，看看游戏是否受⽤户欢迎。如果⽤户不欢迎，迅速放弃这个产品，再进⾏新的尝试，期间⼏乎没有管理⾓⾊的介⼊。使⽤这样的模式使得Supercell公司成为了年税前利润15亿美元的游戏公司，2015年App畅销排⾏榜上Top 10的游戏中，Supercell公司开发的游戏占据了榜单的⼤半江⼭。2016年6⽉，中国腾讯公司以86亿美元收购了员⼯数不超过200⼈的Supercell公司84.3%的股权，每⼀名员⼯⼈均贡献的估值超过3.54亿⼈⺠币。

为什么其他游戏公司不具备Supercell这样的能⼒呢，我觉得很多⼈忽略了Supercell所构建的“中台”能⼒，Supercell公司在多年的游戏研发中积累了⾮常科学的研发⽅法和体系，使得今天公司可以⽀持⼏个⼈的⼩团队在⼏周时间就能研发出⼀款新游戏，并进⾏公测。

1.1 阿⾥巴巴共享业务事业部的发展史

淘宝->天猫->共享业务事业部->聚划算[集团要求三⼤电商平台如果要与聚划算平台进⾏业务对接，必须通过共享业务事业部]

1.2 企业信息中心发展的症结

“烟囱式”系统建设模式

阿里巴巴集团1688、淘宝、天猫三套电商体系的架构完全独⽴，各⾃应⽤独⽴开发和运维。最终促成了三座“烟囱”分别矗⽴⽀撑着当时阿⾥巴巴集团最为核⼼的电商业务。

我想导致这种建设模式的因素有很多，个⼈认为其中主要原因是开发团队考虑到电商模式的不同，所以需要独⽴建设；或者是新的业务团队认为在之前的电商平台基础上改造成⽀持新模式的电商平台会有太多的技术和业务的历史包袱，还不如重新构建。

其实对于“烟囱式”系统建设带来的弊端在⼗年前就已经有⼈提出，以这样的⽅式建设系统对企业的“伤害”有三⼤弊端：
1）重复功能建设和维护带来的重复投资。
2）打通“烟囱式”系统间交互的集成和协作成本⾼昂。
3）不利于业务的沉淀和持续发展。

采⽤“烟囱式”⽅式建设的系统体系，企业中⼀个业务领域的数据和业务往往就被打散在不同的系统中，采⽤系统打通的⽅式解决了眼前相关业务间的交互问题，但这样的⽅式治标不治本。随着业务的发展，这样的⽅式最终⽆法满⾜业务快速响应和业务模式创新的需求。这也就是过去很多年中，在很多企业经常上演的⼀幕：⼀个系统上线运⾏5〜8年后，企业的信息中⼼会向企业更⾼领导⼈提出随着业务的快速发展，现有系统不管是技术架构还是业务模型都不能满⾜现在业务发展的需求，需要整体系统升级，⽽这样的升级往往意味着对原有系统推倒重建。且不论这样推倒式重建对于现有业务带来影响的⼤⼩，多少基础功能的重复建设和资源投⼊，更重要的是对于之前多年业务的沉淀能保留多少，这对于企业来说可能是最⼤的资产流失。

这个问题本质上是由于系统所提供的服务能⼒没有随着企业业务的发展做到与时俱进。系统业务需求响应的能⼒和企业本⾝业务发展对系统建设的要求不成⽐例。如果说过去，业务需求的增⻓态势还算⽐较平滑，没有体现出系统的响应能⼒有多⼤差距，那么在今天，互联⽹时代业务需求的增⻓越来越迅猛，原有系统对业务响应的能⼒就显得更加捉襟⻅肘。到了⼀个时间点，量变产⽣质变，就会出现企业核⼼业务系统运⾏多年后被推倒重来的现象。

业务支持⼀直是企业信息中心的组织职能

⽽造成IT信息中⼼不懂业务的根本原因⼜是什么呢？很多⼤型企业的IT信息化部门已经存在了超过20多年，⼀成不变的就是项⽬制的系统建设模式，这样建设项⽬的模式除了带来前⾯所提到的“烟囱式”建设的⼀系列弊端，同时使得IT信息化部门⼀直处于“业务⽀持”的职能位置，即只是为了满⾜业务部门需求⽽进⾏IT系统建设的实施和运维部门。这样模式下造成我们今天看到的很多企业IT信息化部门的员⼯⼤多数的⼯作内容就是进⾏项⽬管理，负责开发商招投标、开发商与业务团队间的协作沟通、紧盯项⽬进度。当⼀个项⽬顺利上线验收后，这些员⼯开始投⼊到下⼀个项⽬的⼯作中。这样的⼯作确实也⾮常锻炼⼈的组织、协调能⼒，但这样能⼒的提升与⼯作时间的⻓短并不是呈线性增⻓的，更多的时候，我们看到能⼒较强的员⼯能体现⾃⼰价值的地⽅在于负责的项⽬更⼤，甚⾄同时负责多个项⽬，⽽这在我看来终归是增加了项⽬经验，并不能在某⼀专业领域得到知识和经验的沉淀，我相信随着时间的流逝，越来越多的⼈会慢慢失去最初的⼯作积极性和创造性。这样的最终结果是IT信息中⼼的员⼯很少有能在⼀个业务领域做⾜够的深⼊了解和业务沉淀，更多的是对业务知其然，⽽不知其所以然，也谈不上成为业务领域专家，更不可能对业务发展有创新想法和独到⻅解。

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

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

2.1 回归SOA的本质——服务重用

SOA是⽬前业界被验证的真正赋予企业业务快速响应和创新的科学架构，包括如今⽐较⽕的微服务概念在我看来也只是SOA⽅法经过演变后的另⼀种呈现⽅式⽽已。
今天的阿⾥巴巴已经将集团20多个核⼼业务中公共的、通⽤的业务以服务的⽅式沉淀到了共享业务事业部，共享业务事业部在中台战略中扮演着⾄关重要的作⽤，整个集团的核⼼业务能⼒均建⽴在这样⼀套共享服务体系之上，使得我们在今天的业务⽀持中，真正发挥出了SOA架构的核⼼价值——服务重⽤。

2.2 服务需要不断的业务滋养

服务能⼒的沉淀和体现的业务价值是完全成正⽐的，所以打造企业的业务服务能⼒绝不是靠单个SOA项⽬就能⼀蹴⽽就的，⽽是⼀个⻓期、持续的过程，企业应该避免再⾛⼊“项⽬制”实施SOA项⽬的误区，这样的项⽬实施完成充其量只是SOA建设的开始，企业需要多⼀些耐⼼，在接下来的业务发展过程中逐步打造这些服务，这就要求新的业务必须接⼊这些已经产⽣的服务，为这些服务能够变得更加专业和稳定带来急需的需求养分，⽽不能因为这些“刚出⽣”的服务功能简单、服务消费体验糟糕、服务不稳定等原因⽽放弃使⽤这些服务。

2.3 共享服务体系是培育业务创新的⼟壤

好的创新⼀定是基于企业的现状因地制宜，⽽这决定了在很⼤程度上企业的创新会来⾃于企业内部，⽽且提出创新的⼈⼀定是对⾏业有过⼈的认识和理解，才有可能提出创新的想法。

2.4 赋予业务快速创新和试错能力

企业要想在互联⽹时代相⽐同⾏业的竞争对⼿们真正产⽣差异化的竞争⼒，我觉得业务试错是⼀个⾮常重要的能⼒，只有先⼈⼀步，唯快不破，才能帮助企业抢占商业先机的制⾼点。互联⽹时代的竞争只有第⼀，没有第⼆，这也是我认为互联⽹公司的IT架构能⼒跟传统企业间最⼤的差别！
业务创新如同创业⼀样，⼀旦成功，给企业带来的回报可能是超出预期的，但也意味着有失败的⻛险。在要申请⼤量资源⽽且项⽬还有失败的可能性的情况下，有业务创新想法的⼈在考虑到失败带来的影响时，⼀定会权衡其中的利弊，⼤多数⼈会选择退缩，只有少部分有魄⼒的⼈顶着巨⼤的压⼒⾛上了业务创新之道。
便于⼤家理解中台，我引述⼀段关于美军作战阵型演变的描述。美军在⼆战时，以军为单位作战；到了越战时，以营为单位作战；到了中东战争时，以7⼈或者11⼈的极⼩班排去作战，它是今天全世界范围内最灵活的军事组织，也是核⼼竞争⼒和打击能⼒最强的组织。美军之所以能灵活作战，敢放这么⼩的团队到前⾯，是因为有⾮常强的导弹指挥系统，有⾮常强⼤的中后台能⼒，能⽀持这样的⼩团队快速做判断，并且引领整个进攻完成。美军这样的战⽃阵型与阿⾥巴巴如今的“⼤中台、⼩前台”战略完全⼀致，与华为公司提的头狼团队也有异曲同⼯之妙。
小的前台团队具备以下特征：

• ·团队协同效率最⾼。
• ·对战机（商机）的把握更加敏锐。
• 调整⽅向更加快捷。
• ⼀旦发现正确⽬标，全⼒投⼊扩⼤战果。

2.5 为真正发挥⼤数据威⼒做好储备

⼤数据接下来会是展现企业核⼼竞争⼒并挖掘新商业模式，从⽽改变世界的强⼤技术推动器。
但从结果来看项⽬带来的成效并没有达到企业实施⼤数据项⽬的预期，其中有以下两个问题尤为凸显：

• 数据分布⼴、格式不统⼀、不标准。
• 缺少能基于数据有业务建模能⼒的专家。

对于那些计划实施⼤数据项⽬的企业，如果还没有想清楚如何通过⼤数据平台的建设给企业带来真正的业务价值，可以先从共享服务体系的打造⼊⼿，对企业⾃⾝的业务在阵型上做⼀次优化和调整，为将来⼤数据平台真正威⼒的展现准备好⾼质量、统⼀的业务数据，培养出兼具技术功底和精通业务的复合型⼈才。

2.6 改变组织阵型会带来组织效能的提升

如今⼤多企业的信息中⼼部门的职能还停留在“业务⽀持”的程度，是为企业的业务部门提供IT系统⽀持的组织。这也造成了这些企业的信息中⼼部门的员⼯，更多的是承担甲⽅项⽬经理的职能，很多事情本质上都是偏事务性的⼯作，也就是这样的⼯作并不会随着⼯作时间的⻓短⽽让⼈的能⼒得到持续性提升。这种以项⽬为导向的⽅式，使得信息中⼼的员⼯往往⼀个项⽬上线后，就会投⼊到下⼀个项⽬的⼯作中，对员⼯在业务或专业能⼒上很难得到持续的积累和沉淀，结果就是员⼯的积极性和创造⼒在逐渐被消磨，整个信息中⼼部门的⽣产⼒和创新氛围也会受到⾮常⼤的影响。

如果企业打造了共享服务体系，⼀⽅⾯会彻底改变现在“烟囱式”系统建设的模式，新的项⽬都会基于共享服务体系建设，在项⽬的建设周期和资源投⼊上会相⽐之前带来很⼤的效率提升，⾃然信息中⼼的员⼯也⽆需再投⼊那么多的精⼒负责项⽬管理的事务，接下来对整个共享服务体系中的这些服务中⼼进⾏持续“运营”的职能势必会落在企业信息中⼼这个部门，此时我们就可以将信息中⼼部门的员⼯按照服务中⼼的⽅式进⾏⼈员组织的重新编排，让员⼯在各⾃擅⻓和感兴趣的业务领域中持续发展，员⼯的业务理解和专业技能随着对应服务中⼼所提供业务能⼒的逐渐完善⽽同步提升，这样对于员⼯的⼯作积极性和创新意识的提升将会创造⼀个很好的氛围。

针对每⼀个建设的服务中⼼，从组织架构的形态上也发⽣了对应的调整，会有不同⾓⾊的⼈员（架构师、开发⼈员、UED⼯程师等）组建成了⼀个新的组织，每⼀个这样的组织都针对某⼀服务中⼼提供持续的服务能⼒开发及运维，更准确说是基于这⼀服务中⼼的业务能⼒进⾏“运营”。

在这样的⼀个组织中，最为核⼼的⾓⾊就是业务架构师，在阿⾥巴巴共享服务各服务中⼼的业务负责⼈⼀般为此⾓⾊，业务架构师的能⼒模型正是那种典型的即懂技术，也对负责的业务领域有相当理解的。这些架构师⼀般是从技术开发出⾝，在多年业务领域的需求浸染中，不断形成了对该业务全⾯的知识体系以及⾃⾝的理解，对该业务在集团内的职能定位、市场发展趋势都有⼀定的全局认识，能从业务的视⾓带领团队朝着服务中⼼的核⼼能⼒打造、专业、成熟的⽅向前进。

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

在接下来的这⼏章中，我会将阿⾥巴巴在逐步打造共享服务体系历程中，在技术框架选择、平台能⼒、技术实现等⽅⾯的实践做⼀个全⾯的分享，供有想法打造企业⾃⾝共享服务体系的读者提供⼀些借鉴和思路。

第3章 分布式服务框架的选择

3.1 淘宝平台“服务化”历程

2007年，淘宝已经拥有超过500⼈的技术团队规模，整个淘宝⽹站是⼀个⼏百兆字节的WAR包，⼤⼩功能模块超过200个，在当时淘宝业务计划处于每隔⼏个⽉就翻倍的⾼速发展期，这样的应⽤架构给淘宝技术团队带来了⾮常⼤的压⼒。⼏百⼈维护⼀个WAR包的模式，带来了以下⼏个主要问题：

• 项⽬团队间协同成本⾼，业务响应越来越慢。代码合并的过程中，会出现各种jar包冲突、代码不⼀致的情况，这就需要在不同团队间进⾏各种确认和协调的⼯作。
• 应⽤复杂度已超出⼈的认知负载。
• 错误难于隔离。⼀些⾮核⼼功能的设计不合理、代码质量差引起整个淘宝平台的业务受到全⾯影响
• 数据库连接能⼒很难扩展。
• 应⽤扩展成本⾼。

淘宝从2007年开始整个技术体系架构坚持⾛⾃主可控、创新变⾰之路。解决以上问题的根本就在于业务的拆分，⽽当时业界已经盛⾏的SOA理念和⽅法则是有效解决以上问题的不⼆选择。在14个⽉的时间内将原来单⼀应⽤的模式改造成为基于SOA理念的分布式服务架构。在应⽤部署形态上，由之前⼀个⼏百兆字节⼤⼩的WAR包部署模式改造成为上百个WAR包独⽴部署的服务化架构。

随着淘宝平台服务化改造⼯作的完成，之前因为应⽤没有拆分的问题都得到了很好的解决：

• 降低不同模块开发团队间的协同成本，业务响应更迅捷。
• ⼤⼤降低系统间的耦合度以及整体复杂度，各个开发团队可专注于各⾃的业务模块。
• 避免了个别模块的错误给整体带来的影响。
• 业务拆分后解放了对单数据库集群连接数的能⼒依赖。
• 做到针对性的业务能⼒扩容，减少不必要的资源浪费。

3.2 “中心化”与“去中心化”服务框架的对比

当时SOA的理念已经在业界⾮常⻛⾏，其中以传统软件⼚商提出的以ESB（企业服务总线）实现SOA的⽅案为主流，这也是为什么⼏乎所有传统企业的客户都认为ESB是SOA理念的最佳实践，甚⾄是唯⼀的实现。这是⼀种“中⼼化”服务框架。

回顾⼀下SOA的主要特性：

• ⾯向服务的分布式计算。
• 服务间松散耦合。
• ⽀持服务的组装。
• 服务注册和⾃动发现。
• 以服务契约⽅式定义服务交互⽅式。

3.3 阿里巴巴分布式服务框架HSF

阿⾥巴巴集团内部使⽤的分布式服务框架HSF（High SpeedFramework，也有⼈戏称“好舒服”），早期还有⼀个对应的开源项⽬Dubbo，因为某些原因，在2012年年底，阿⾥巴巴停⽌了对此开源项⽬的更新。

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

• 服务提供者
• 服务调⽤者
• 地址服务器[是由Nginx（是⼀个⾼性能的HTTP和反向代理服务器）提供该服务能⼒]
• 配置服务器
• Diamond服务器[Diamond服务器是⼀个通⽤的统⼀配置管理服务（类似Zookeeper），给应⽤提供统⼀的配置设置和推送服务，使⽤场景⾮常⼴泛]

阿⾥巴巴的分布式服务框架核⼼是以服务化的⽅式构建整个应⽤体系的同时，保证在⾼并发的情况下，服务具备⾼效交互、⾼可⽤性和扩展能⼒。接下来具体介绍HSF框架如何给服务提供以上能⼒。

• HSF框架采⽤Netty+Hession数据序列化协议实现服务交互。
  Hessian是HSF框架中默认使⽤的数据序列化协议，在数据量较⼩时性能表现出众，Hessian的优点是精简、⾼效，同时可以跨语⾔使⽤，⽬前⽀持Java、C++、.Net、Python、Ruby等语⾔。另外Hessian可以充分利⽤Web容器的成熟功能，在处理⼤量⽤户访问时很有优势，在资源分配、线程排队、异常处理等⽅⾯都可以由Web容器保证。HSF框架同时也⽀持切换使⽤Java序列化，Hession相⽐JDK标准的序列化⽅式（即基于Serializable接⼝的标准序列化），在典型场景中，其序列化时间开销可能缩短20倍。虽然Hessian不是最快的序列化协议，但它对于复杂业务对象的序列化正确率、准确性相较于最稳定的Java序列化并不逊⾊太多；业界还有⼀些⽐Hessian更快的序列化协议，但它们相对于Hessian在复杂场景下的处理能⼒还是会差⼀些；所以Hessian是在性能和稳定性同时考虑下最优的序列化协议。
• HSF框架的容错机制
• HSF框架的线性扩展⽀持
  当服务⾯对较⼤的服务调⽤压⼒或将要⾯临如双11⼤促、秒杀等活动前，已有的服务提供者各服务器⽔位（CPU、内存、IO等）处于⽐较⾼的情况或现有服务能⼒满⾜不了业务访问量的要求时，则需要通过增加服务节点数量的⽅式提升该服务的服务处理能⼒。
  此时，只需要通过增加该服务的服务提供者实例，基于HSF框架的运⾏机制，新增加的服务提供者实例⼀旦应⽤启动完成后，可在⼏秒内（主要完成服务注册发布、更新后服务列表推送到服务调⽤者端）开始进⾏服务请求的处理，从⽽达到分担其他服务器实例压⼒的作⽤，实现服务能⼒整体⽔位恢复到正常的状态。

3.4 关于微服务

对于微服务每个⼈都有⾃⼰不同的理解，我个⼈⽐较赞同MartinFowler对于微服务架构的典型特征的描述：

• 分布式服务组成的系统。
• 按照业务⽽不是技术来划分组织。
• 做有⽣命的产品⽽不是项⽬。
• 智能化服务端点与傻⽠式服务编排。
• ⾃动化运维。
• 系统容错。
• 服务快速演化。

回到Docker这个问题，正因为有了“微服务”中所谓“微”服务的说法，那如何对这些微服务进⾏快速的部署、发布，更⾼效的利⽤服务计算资源，就给了容器技术爱好者借题发挥的空间，开始宣传Docker是实现微服务的解决⽅案的说法。
从技术⾓度，Docker完全有能⼒⽽且适合微服务体系中给服务提供实际的运⾏容器以及进⾏部署运维的平台，但Docker本⾝提供的核⼼能⼒还只是在计算资源层⾯，对于微服务架构所需的应⽤服务层⾯还存在着不⼩的空缺，构建企业微服务架构的建设过程中⼀定会遇到本书中阿⾥巴巴构建共享服务体系过程中所遇到的以下⼀系列问题，⽽这些远不是单单的Docker平台能解决的问题：

• 微服务化的应⽤架构如何进⾏有效的服务管控。在分布式服务体系下，服务链路跟踪、链路分析、实时业务指标的监控等问题，也都是实现微服务架构时⼀定会⾯临的问题，扩⼤到更⼤范围就是整体服务平台的管控能⼒。
• 分布式事务难题。
• ⾃动化运维和平台稳定性。
• 微服务的服务设计。
• 原有组织架构是否满⾜微服务架构持续发展的需要。

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

⼀般来说，服务能⼒包括两个层次，⼀个层次是底层PaaS的能⼒，PaaS层解决⼤型架构在分布式、可靠性、可⽤性、容错、监控以及运维层⾯上的通⽤需求；第⼆个层次是业务能⼒，业务服务能⼒提供云化的核⼼业务⽀撑能⼒，这层能⼒建设的好与坏，直接决定了是否能真正⽀持上层业务达到敏捷、稳定、⾼效。

4.1 淘宝的共享服务中心概貌

淘宝的共享服务中⼼包括多个服务中⼼。最初有四⼤服务中⼼：⽤户中⼼（UIC）、商品中⼼（IC）、交易中⼼（TC）、店铺中⼼（SC）。随着业务的不断发展，越来越多的服务能⼒沉淀到了共享服务中⼼，⽐如后期的物流中⼼、营销中⼼、数据服务中⼼等。
以下是对四大服务中心的介绍：

1.⽤户中心

⽤户中⼼是淘宝进⾏业务服务化历程中所构建的第⼀个服务中⼼，它统⼀了淘宝原来的各个业务线分散的⽤户体系，统⼀了⽤户数据、存储和服务接⼝。

2.商品中心

淘宝的商品中⼼建设⾮常有代表意义，淘宝是平台型的电商，商品管理其实是最复杂的业务场景之⼀。原因有以下⼏个。

• 商品数据量⼤
• 卖家众多
• 商品数据是电商导购的入口，对数据质量有很⾼的要求，⽽且这些数据商品搜索的数据源
• 类⽬运营小二要根据商品的分析数据来优化商品的前端类⽬结构

建⽴淘宝的商品中⼼从⼀开始就注定了是⼀条不平凡之路。商品库的数据库管理难度最⼤，商品中⼼需要对上层提供的服务能⼒包括以下⼏个⽅⾯：

商品描述能力。商品描述能⼒主要包括三⽅⾯，⼀是商品的描述数据模型，具体就是类⽬属性体系、SPU、SKU等，这⽤于为整个商品建⽴⼀个统⼀的、灵活的、易于使⽤的商品数据模型；⼆是商品的存储模型，就是商品数据在数据库中的存储结构；三是对外提供的服务接⼝，上层业务通过服务接⼝操作商品数据。这⼀部分的能⼒屏蔽了商品内部的实现细节，简化了上层业务操作商品数据。
商品发布能力。对上层业务来说，商品发布能⼒其实是⼀个个性化需求⽐较⼤的能⼒，⽐如B端商家需要通过Open API直接对接现在企业的商品进销存系统；C端⼩商家直接使⽤浏览器能进⾏发布；C端⼤商家可能更喜欢使⽤C/S客户端的⽅式发布；⽆线端⽤户可能更喜欢轻量级的发布，⽤APP或者⼿机扫码就能发布。所以发布能⼒在商品中⼼是提供通⽤的发布服务接⼝和标准的发布⼯具，业务层⾃⼰会根据业务需求提供满⾜业务需求的发布⼯具。从这个场景⼤家可以感受到服务与业务的边界，“服务中⼼⼀定是实现通⽤的能⼒，个性化尽量在业务层实现”。
商品管理能力。管理⼀个超过10多亿数量的商品库绝对是⼀个⾮常有难度的事，淘宝的商品是个百科全书，号称“只有你想不到，没有你找不到”，这个商品库的组织管理⽐世界上最⼤的图书馆管理难度还要⼤。
商品巡检的能力。商品都是有⽣命周期的，⽤户发布的商品如果太⻓时间没有管理，⽤户本⾝也⻓时间没有登录，那这种⾮活跃卖家可能本⾝就不再经营店铺了。要能识别这种商品，从活跃商品库中剔除，否则不但浪费⼤量的计算和存储资源，还给买家带来极其糟糕的⽤户体验。有些卖家为了利⽤淘宝商品的搜索引擎排序规则，会为商品加上⼀些热门的搜索词，这些词严重⼲扰搜索的准确率，要能发现这类违规的描述；有些卖家描述商品使⽤⽐较随意的⽂字，与淘宝的商品描述体系中其他⽤户的认知不⼀致，系统要能发现并纠正⽤户的这种随意⾏为。
商品数据数据分析的能⼒。运营⼩⼆要进⾏⽇常运营、营销活动、类⽬调整，都需要数据的⽀持，商品中⼼能⾃动聚合推荐的类⽬数据并提供调整的决策⽀持。在淘宝这种平台型的电商体系下，针对商品的⼤数据能⼒是必须要求的。
商品评价的能⼒。成功交易的订单，淘宝引⼊了商品评价体系可以评论商品和卖家，评价中⼼的职责就是要识别正常的评价，剔除恶意的差评与好评，从⽽建⽴更公平的商品评价体系。

3.交易中心

交易中⼼是电商的交易业务领域的服务中⼼，包含交易相关的服务信息，⽐如购物⻋、交易流程、订单管理、⽀持、结算、营销等。初期，淘宝的交易中⼼聚合了很多相关的业务服务，后来随着业务的发展，交易中⼼有了相应的调整，⽐如后来拆分出来了营销中⼼。服务中⼼都是这样动态发展进化的过程，⽐如由于天猫业务的发展，对库存有了更⾼的要求，所以后来从商品中⼼独⽴出来了库存中⼼。

4.店铺中心

店铺中⼼承担了卖家店铺管理、店铺装修、店铺⽣命周期管理、店铺⽇常管理等业务，在店铺体系下，发展了淘宝最具活⼒的第三⽅店铺装修市场，这是平台化的最好实践。

4.2 什么是服务中心

我们从下⾯⼏个⾓度澄清⼀下服务中⼼的概念。
1.服务中⼼⼀定是不断发展的
2.服务中⼼中的服务形态多样性
3.一个服务中心可以进一步划分

4.3 服务中⼼的划分原则

高内聚、低耦合原则

数据完整性原则

业务可运营性原则

渐进性的建设原则

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

本章详细介绍淘宝如何基于数据库分库分表的⽅式，利⽤分布式数据库平台解决数据库瓶颈问题，包括在进⾏数据库改造的过程中如何进⾏数据分库分表设计的最佳实践。

5.1 数据库瓶颈阻碍业务的持续发展

在淘宝平台向共享服务体系改造的过程中，通过各个服务中⼼拥有各⾃独⽴数据库的⽅式，即采⽤数据垂直分区的⽅式对业务数据进⾏分区，确实在很⼤程度上缓解了当时数据库连接数资源捉襟⻅肘和数据库因为表多、数据多造成的性能等问题。

⾸先实施的是数据库的读写分离（如图5-1所⽰）。读写分离基本原理是让主数据库处理事务性增、改、删（INSERT、UPDATE、DELETE）操作，⽽从数据库专门负责处理查询（SELECT）操作，在数据库的后台会把事务性操作导致的主数据库中的数据变更同步到集群中的从数据库。

基于数据库分区的思路，当出现单个表的数据量很⼤的情况，则需要采⽤⽔平分区的⽅式对数据进⾏拆分，即将同⼀个表中的不同数据拆分到不同的数据库中。
以⽤户中⼼的应⽤为例，淘宝平台的⽤户量已接近6亿，对⽤户数据按照⽤户ID进⾏hash取模的⽅式实现⽤户数据平均分布在8个（对6亿数据进⾏拆分的数据库数量会远⼤于8个，在此只为⽰意）数据库中，确保了单个数据库中保存的数据量在单机数据库能提供良好读写性能的范围之内。
单单对数据进⾏拆分的操作本⾝不复杂，但在很多实际的业务场景中，不可避免会出现跨库的表join、事务操作，以及数据的统计、排序等情况，⽽且数据进⾏了拆分后，对于数据库的运维管控也提出了更⾼的要求。为了更好地在数据库层⾯⽀持好淘宝的业务，在2008年，阿⾥巴巴内部开始了分布式数据库的研发⼯作，相关的平台和⼯具陆续登上了淘宝技术发展史的历史舞台。

5.2 数据库分库分表的实践

1.阿⾥巴巴分布式数据层平台发展和演变

业务数据从原来的单库单表模式变成了数据被拆分到多个数据库，甚⾄多个表中，如果在数据访问层做⼀下功能的封装和管控，所有分库分表的逻辑和数据的跨库操作都交给应⽤的开发⼈员来实现，则对开发⼈员的要求变得相对⾼⼀点，稍有不慎，可能会对平台的业务包括数据带来较⼤的影响。

在2006年阿⾥巴巴B2B团队以开源⽅式研发了Cobar这⼀关系型数据的分布式处理系统。但随着阿⾥巴巴业务场景越来越复杂，Cobar平台功能上的约束对满⾜某些业务场景显得⼒不从⼼，例如：

• 不⽀持跨库情况下的连接、分⻚、排序、⼦查询操作。
• SET语句执⾏会被忽略，处理事务和字符集设置除外。
• 分库情况下，insert语句必须包含拆分字段列名。
• 分库情况下，update语句不能更新拆分字段的值。
• 不⽀持SAVEPOINT操作。
• 使⽤JDBC时，不⽀持rewriteBatchedStatements=true参数设置（默认为false）。
• 使⽤JDBC时，不⽀持useServerPrepStmts=true参数设置（默认为false）。
• 使⽤JDBC时，BLOB、BINARY、VARBINARY字段不能使⽤setBlob（）或setBinaryStream（）⽅法设置参数。

2008年阿⾥巴巴内部基于淘宝业务发展的需要，在Cobar的基础上重新研发了分布式数据层框架TDDL（Taobao Distributed Data Layer，外号：头都⼤了），针对分库分表场景，提供了对各种业务场景的⽀持更加完善，开发⼈员体验更加友好，管控能⼒⼤幅提升。

从架构⾓度，TDDL沿袭了Cobar之前在应⽤和后端数据库之间的定位，通过增加对SQL的解析实现了更为精准的路由控制，以及对跨库join、统计等计算的⽀持，弥补了之前Cobar在功能上的约束和限制，成为⼀个完整⽀持SQL语法兼容的平台。

TDDL相⽐之前的Cobar在功能上提升了⼀个新的层级，对于Cobar不⽀持的跨库数据聚合、⼦查询、group by、order by等特性都有了很好的⽀持，从⽽成为在分库分表技术业界被很多技术同仁认可的⼀套分布式数据层框架，总结来说，TDDL提供了以下优点：

• 数据库主备和动态切换。
• 带权重的读写分离。
• 单线程读重试。
• 集中式数据源信息管理和动态变更。
• ⽀持MySQL和Oracle数据库。
• 基于JDBC规范，很容易扩展⽀持实现JDBC规范的数据源。
• ⽆Server、client-jar形式存在，应⽤直连数据库。
• 读写次数，并发度流程控制，动态变更。
• 可分析的⽇志打印，⽇志流控，动态变更。

随着阿⾥巴巴集团业务的多元化，特别是对于除电商领域以外业务的不断扩展和并购，TDDL这种⽆Server的模式对于故障的定位和对运⾏环境的要求（必须是阿⾥巴巴内部服务环境），⽀持这些新兴业务有了不少困难，所以在2014年，阿⾥巴巴已经研发出新⼀代分布式数据库产品DRDS（Distributed Relational Database Service）。

2.数据尽可能平均拆分

在分库分表场景下，最重要的⼀个原则就是被拆分的数据尽可能的平均拆分到后端的数据库中，如果拆分得不均匀，还会产⽣数据访问热点，同样存在热点数据因为增⻓过快⽽⼜⾯临数据单表数据过⼤的问题。

3.尽量减少事务边界

所谓的事务边界即是指单个SQL语句在后端数据库上同时执⾏的数量。比如⼀条SQL语句同时被推送到后端所有数据库中运⾏。事务边界的数量越⼤，会给系统带来以下弊端：

• 系统的锁冲突概率越⾼。
• 系统越难以扩展。
• ·整体性能越低。

如果是⾼并发情况下同时请求的话，为了数据库整体的扩展能⼒，则要考虑下⾯描述的异构索引⼿段来避免这样的情况发⽣。对于在内存中要进⾏⼤数据量聚合操作和计算的SQL请求，如果这类SQL的不是⼤量并发或频繁调⽤的话，平台本⾝的性能影响也不会太⼤，如果这类SQL请求有并发或频繁访问的要求，则要考虑采⽤其他的平台来满⾜这⼀类场景的要求，⽐如Hadoop这类做⼤数据量离线分析的产品，如果应⽤对请求的实时性要求⽐较⾼，则可采⽤如内存数据库或HBase这类平台。

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

该部分太难啦。。放弃笔记。后期整理异构索引相关

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

采⽤数据异构索引的⽅式在实战中基本能解决和避免90%以上的跨join或全表扫描的情况，是在分布式数据场景下，提升数据库服务性能和处理吞吐能⼒的最有效技术⼿段。

阿⾥巴巴有⾃⾝的主搜索平台，该平台承载了淘宝、天猫、⼀淘、1688、神⻢搜索等搜索业务，其核⼼功能跟业界开源⼯具，如Iucene、Solr、ElasticSearch等搜索引擎类似，但在数据同步（从数据库到搜索引擎）、索引创建算法、查询执⾏计划、排序算法等⽅⾯针对商品搜索这样的场景做了相应的调整和功能增强。

6.简单就是美

如果在“尽量减⼩事务边界”与“数据尽可能平均拆分”两个原则间发⽣了冲突，那么请选择“数据尽可能平均拆分”作为优先考虑原则，因为事务边界的问题相对来说更好解决，⽆论是做全表扫描或做异构索引复制都是可以解决的。⽽写⼊或单机容量如果出现不均衡，那么处理起来难度就⽐较⼤。

尽管复杂的切分规则或数据的异构索引能够给系统的性能和扩展性带来显著的收益，但其后⾯所带来的系统运维复杂度上升也是不能忽视的⼀个结果。

如果为每⼀个存在跨join或全表扫描的场景都采⽤数据异构索引的⽅式，整个数据库出现⼤量数据冗余，数据⼀致性的保障也会带来挑战，同时数据库间的业务逻辑关系也变得⾮常复杂，给数据库运维带来困难和⻛险，从⽽对数据库运维⼈员的要求和依赖会⾮常⾼，所以从系统⻛险的⾓度考虑，以82法则，在实际中，我们仅针对那些在80%情况下访问的那20%的场景进⾏如数据异构索引这样的处理，达到这类场景的性能最优化，⽽对其他80%偶尔出现跨库join、全表扫描的场景，采⽤最为简单直接的⽅式往往是就最有效的⽅式。

第6章 异步化与缓存原则

6.1 业务流程异步化

阿⾥巴巴内部使⽤消息中间件的⽅式实现了业务异步化，提⾼了服务的并发处理，从⽽⼤⼤减少整个业务请求处理所花的时间。

6.2 数据库事务异步化

数据库事务的异步化，通俗来说，就是将⼤事务拆分成⼩事务，降低数据库的资源被⻓时间事务锁占⽤⽽造成的数据库瓶颈，就能⼤⼤提升平台的处理吞吐量和事务操作的响应时间。
⼀定要考虑到程序异常时对业务的回滚或重试机制，保障整个还款过程结果的最终⼀致。通过以上对还款事务异步化的处理，在不影响业务体验的前提下，整个平台对于还款的处理能⼒相⽐之前提升了20倍以上，因为⼤⼤减少了数据库记录的锁冲突，系统在还款⾼峰时期时⽤户体验基本跟平时没有太⼤的差异。

6.3 事务与柔性事务

传统数据库的事务确实⾮常好地保证了业务的⼀致性，但在互联⽹场景下，就暴露出数据库性能和处理能⼒上的瓶颈。所以在分布式领域，基于CAP理论和在其基础上延伸出的BASE理论，有⼈提出了“柔性事务”的概念。

在结合具体实例对柔性事务进⾏介绍前，有必要对CAP和BASE理论做⼀个简单的介绍，这样才能让⼤家更加清晰地理解互联⽹场景下解决事务问题的思路和理论出发点。

1.CAP理论

2000年7⽉，加州⼤学伯克利分校的Eric Brewer教授在分布式计算原则研讨会议上提出CAP猜想。直到2002年，由⿇省理⼯学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP理论，从⽽让CAP理论正式成为分布式计算领域的公认定理。

CAP理论：⼀个分布式系统最多只能同时满⾜⼀致性（Consistency）、可⽤性（Availability）和分区容错性（Partitiontolerance）这三项中的两项。

“⼀致性”指更新操作成功并返回客户端完成后，所有节点在同⼀时间的数据完全⼀致。⼀致性指在⼀个系统中不论数据存放在何处，作为⼀个整体应是完整和⼀致的。在分布式系统中，数据通常不会只有⼀份，⽤户对数据进⾏⼀定的修改操作（增/删/改）之后，为了保证数据的⼀致性，那么应该对所有数据进⾏相同的操作并且这些操作应该是同时成功或者同时失败的。

“可用性”指⽤户在访问数据时可以得到及时的响应。可⽤性是关于⼀个系统能够持续不间断使⽤的问题，严格的定义是⾼性能可⽤性。这意味着⼀个系统从设计到实施都应该能够提供可持续的操作（如读写操作），⽆论是操作冲突，还是软硬件部分因为升级⽽导致失效。
同时可⽤性的要求包含时效性，对于⼤多数应⽤⽽⾔，超过⼀定响应时间的服务是没有价值的或者价值量低的。例如，阿⾥巴巴和Google这样的公司很细⼩的响应延迟都会对公司的盈利造成损失。

“分区容错性”指分布式系统在遇到某节点或⽹络分区故障的时候，仍然能够对外提供满⾜⼀致性和可⽤性的服务。Gilbert和Lynch是这样定义分区容忍性的：除了整个⽹络的故障外，其他的故障（集）都不能导致整个系统⽆法正确响应。

CAP之间的取舍
根据前⾯的介绍，CAP理论的核⼼是：⼀个分布式系统不可能同时很好地满⾜⼀致性、可⽤性和分区容错性这三个需求，最多只能同时较好地满⾜两个。
CAP定理并不意味着所有系统的设计都必须抛弃三个要素之中的⼀个。CAP三者可以在⼀定程度上衡量，并不是⾮⿊即⽩的，例如可⽤性从0%到100%有不同等级。显然我们有⼏种组合选择问题。

1）放弃分区容忍性。为了避免分区问题发⽣，⼀种做法是将所有与事务相关的东⻄都放到⼀台机器上。
2）放弃可⽤性。相对于放弃分区容忍性来说，其反⾯就是放弃可⽤性。
3）放弃⼀致性。

2.BASE理论

eBay的架构师Dan Pritchett源于对⼤规模分布式系统的实践总结，在ACM上发表⽂章提出了BASE理论。BASE理论是对CAP理论的延伸，核⼼思想是即使⽆法做到强⼀致性（Strong Consistency，CAP的⼀致性就是强⼀致性），但应⽤可以采⽤适合的⽅式达到最终⼀致性（EventualConsitency）。

BASE是指基本可⽤（Basically Available）、柔性状态（Soft State）、最终⼀致性（Eventual Consistency）。

• “基本可⽤”是指分布式系统在出现故障的时候，允许损失部分可⽤性，即保证核⼼可⽤。电商⼤促时，为了应对访问量激增，部分⽤户可能会被引导到降级⻚⾯，服务层也可能只提供降级服务。这就是损失部分可⽤性的体现。
• “柔性状态”是指允许系统存在中间状态，⽽该中间状态不会影响系统整体可⽤性。分布式存储中⼀般⼀份数据⾄少会有三个副本，允许不同节点间副本同步的延时就是柔性状态的体现。MySQL Replication的异步复制也是⼀种柔性状态体现。
• “最终⼀致性”是指系统中的所有数据副本经过⼀定时间后，最终能够达到⼀致的状态。弱⼀致性和强⼀致性相反，最终⼀致性是弱⼀致性的⼀种特殊情况。

ACID和BASE的区别与联系
ACID和BASE代表了两种截然相反的设计哲学。ACID是传统数据库常⽤的设计理念，追求强⼀致性模型；BASE⽀持的是⼤型分布式系统，提出通过牺牲强⼀致性获得⾼可⽤性。

ACID（英⽂中是酸）和BASE（英⽂中有碱性的意思）在化学的世界中两者（酸和碱）是完全对⽴的，具有独特⽽相反的性质。

互联⽹应⽤的最核⼼需求是⾼可⽤（也就是BASE的BA）。

对于如何实现⾼可⽤，我们认为：
⾼可⽤ = 系统构建在多机 = 分布式系统
⾼性能 = 分布式系统的副产品
今天⼤家都知道淘宝去IOE的故事，但当年去Oracle排名第⼀位的需求不是性能，⽽是因为Oracle是系统单点。⼀旦Oracle不可⽤，整个系统100%不可⽤，⽽Oracle每年总是会出1次故障。既然为了⾼可⽤采⽤了分布式系统，那么分布式系统特性决定了柔性事务的第⼆个特性：最终⼀致。

分布式系统内通信和单机内通信最⼤的区别是：单机系统总线不会丢消息，⽽⽹络会。
消息不可靠带来的副作⽤是：数据或者状态在多机之间同步的成本很⾼。

⼤家都知道Paxos协议。在多机间通信不存在伪造或篡改的前提下，可以经由Paxos协议达成⼀致性。成本是发给Paxos系统的信息（数据）需要⾄少同步发送到⼀半以上多数（Quorum）的机器确认后，才能认为是成功。这样⼤幅增加了信息更新的延迟，因此分布式系统的⾸选不是这种强同步⽽是最终⼀致。

⽽采⽤最终⼀致，⼀定会产⽣柔性状态。

3.传统分布式事务

到数据在按照业务领域（⽤户中⼼、交易中⼼）的不同被拆分到不同的数据库后，在某些业务场景（⽐如订单创建）下，就必然会出现同⼀个事务上下⽂中，需要协调多个资源（数据库）以保证业务的事务⼀致性，对于这样的场景，业界早就有基于两阶段提交⽅式实现的分布式事务，两阶段提交协议包含了两个阶段：第⼀阶段（也称准备阶段）和第⼆阶段（也称提交阶段）。如图：

当commit请求从客户端向事务管理器发出，事务管理器开始两阶段提交过程。在第⼀阶段，所有的资源被轮询到，问它们是否准备好了提交作业。每个参与者可能回答“就绪”（READY）、“只读”（READ_ONLY）或“未准备好”（NOT_READY）。如果有任意⼀个参与者在第⼀阶段响应“未准备好”（NOT_READY），则整个事务回滚。如果所有参与者都回答“就绪”（READY），那这些资源就在第⼆阶段提交。回答“只读”（READ_ONLY）的资源，则在协议的第⼆阶段处理中被排除掉。

两阶段提交协议要求分布式事务参与者实现⼀个特别的“准备”操作，⽆论在资源管理器（如数据库）还是在业务服务中实现该操作都存在效率与复杂性的挑战。因此，两阶段提交协议有⼀个重要的优化，称为“最末参与者优化”（Last Participant Optimization，LPO），允许两阶段提交协议中有⼀个参与者不实现“准备”操作（称为单阶段参与者）。最末参与者优化的原理如下图所示：

从上图可见，LPO中单阶段参与者不需要实现准备操作，只需要提供标准的提交操作即可。分布式事务协调者必须等其余两阶段参与者都准备好之后，再请求单阶段参与者提交，单阶段参与者的提交结果决定整个分布式事务的结果。本质上，LPO是将最后⼀个参与者的准备操作与提交/放弃操作合并成⼀个提交操作。

X/Open组织为基于两阶段协议的分布式事务处理系统提出了标准的系统参考模型（X/Open事务模型）以及不同组件间与事务协调相关的接⼝，使不同⼚商的产品能够互操作。X/Open事务模型如下图所示：

从图中可以看出，X/Open模型定义了两个标准接⼝：TX接⼝⽤于应⽤程序向事务管理器发起事务、提交事务和回滚事务（即确定事务的边界和结果）；XA接⼝形成了事务管理器和资源管理器之间的通信桥梁，⽤于事务管理器将资源管理器（如数据库、消息队列等）加⼊事务、并控制两阶段提交。

事务管理器⼀般由专门的中间件提供，或者在应⽤服务器中作为⼀个重要的组件提供。资源管理器如数据库、消息队列等产品⼀般也会提供对XA接⼝的⽀持，通过使⽤符合X/Open标准的分布式事务处理，能够简化分布式事务类应⽤的开发。

两阶段提交协议的关键在于“预备”操作。分布式事务协调者在第⼀阶段通过对所有的分布式事务参与者请求“预备”操作，达成关于分布式事务⼀致性的共识。分布式事务参与者在预备阶段必须完成所有的约束检查，并且确保后续提交或放弃时所需要的数据已持久化。在第⼆队段，分布式事务协调者根据之前达到的提交或放弃的共识，请求所有的分布式事务参与者完成相应的操作。很显然，在提交事务的过程中需要在多个资源节点之间进⾏协调，⽽各节点对锁资源的释放必须等到事务最终提交时，这样，⽐起⼀阶段提交，两阶段提交在执⾏同样的事务时会消耗更多时间：

• 单机锁=时间消耗（微秒级）
• 跨多机的锁=时间消耗（毫秒级）=1000倍单机时间消耗

事务执⾏时间的延⻓意味着锁资源发⽣冲突的概率增加，当事务的并发量达到⼀定数量的时候，就会出现⼤量事务积压甚⾄出现死锁，系统性能和处理吞吐率就会严重下滑，也就是系统处理的吞吐率与资源上的时间消耗成反⽐（参考阿姆达尔定理）。这就是为什么今天在互联⽹应⽤场景中鲜有⼈会选择这样传统的分布式事务⽅式，⽽选择柔性事务处理业务事务的主要原因。

4.柔性事务如何解决分布式事务问题

引入日志和补偿机制

类似传统数据库，柔性事务的原⼦性主要由⽇志保证。事务⽇志记录事务的开始、结束状态，可能还包括事务参与者信息。参与者节点也需要根据重做或回滚需求记录REDO/UNDO⽇志。当事务重试、回滚时，可以根据这些⽇志最终将数据恢复到⼀致状态。

为避免单点，事务⽇志是记录在分布式节点上的，数据REDO/UNDO⽇志⼀般记录在业务数据库上，可以保证⽇志与业务操作同时成功/失败。通常柔性事务能通过⽇志记录找回事务的当前执⾏状态，并根据状态决定是重试异常步骤（正向补偿），还是回滚前序步骤（反向补偿）。

在互联⽹业界采⽤⽇志⽅式实现柔性事务的⽐例⾮常⼤，但因为这部分的技术实现并没有如XA这样的技术标准和规范，看到很多互联⽹应⽤对这部分的实现⾮常的粗糙，只是简单的采⽤数据库进⾏了分布式事务过程中的状态记录，对于事务中异常处理和补偿回滚⽀持是明显不够的，并不能完全意义上的满⾜业务的最终⼀致性，⽽且⼀旦出现问题，所投⼊的⼈⼒维护成本也⾮常⾼昂。

可靠消息传递

在分布式环境下，由于“⽹络通信危险期”（⻅下⾯阅读框中内容）的存在，节点间的消息传递会有“成功”、“失败”、“不知道成功还是失败”三种状态。

由于⽹络通信故障随时可能发⽣，任何发出请求后等待回应的程序都会有失去联系的危险。这种危险发⽣在发出请求之后，服务器返回应答之前，如果在这个期间⽹络通信发⽣故障，发出请求⼀⽅⽆法收到回应，于是⽆法判断服务器是否已经成功地处理请求，因为收不到回应可能是请求没有成功地发送到服务器，也可能是服务器处理完成后的回应⽆法传回请求⽅。这段时间称为⽹络通信的危险期（In-doubt Time）。很显然，⽹络通信的危险期是分布式系统除单点可靠性之外需要考虑的另⼀个问题。

根据“不知道成功还是失败”状态的处理，消息投递只有两种模式：1）消息仅投递⼀次，但是可能会没有收到；2）消息⾄少投递⼀次，但可能会投递多次。在业务⼀致性的⾼优先级下，第⼀种投递⽅式肯定是⽆法接受的，因此只能选择第⼆种投递⽅式。

由于消息可能会重复投递，这就要求消息处理程序必须实现幂等（幂等=同⼀操作反复执⾏多次结果不变）。每种业务场景不同，实现幂等的⽅法也会有所不同，最简单的幂等实现方式是根据业务流水号写日志，阿⾥内部⼀般把这种日志叫做排重表。

实现无锁

造成数据库性能和吞吐率瓶颈往往是因为强事务带来的资源锁。如何很好地解决数据库锁问题是实现⾼性能的关键所在。所以选择放弃锁是⼀个解决问题的思路，但是放弃锁并不意味着放弃隔离性，如果隔离性没有保障，则必然带来⼤量的数据脏读、幻读等问题，最终导致业务不可控地不⼀致。

实现事务隔离的⽅法有很多，在实际的业务场景中可灵活选择以下⼏种典型的实现⽅式。

避免事务进入回滚
如果事务在出现异常时，可以不回滚也能满⾜业务的要求，也就是要求业务不管出现任何情况，只能继续朝事务处理流程的顺向继续处理，这样中间状态即使对外可⻅，由于事务不会回滚，也不会导致脏读。

辅助业务变化明细表
⽐如对资⾦或商品库存进⾏增减处理时，可采⽤记录这些增减变化的明细表的⽅式，避免所有事务均对同⼀数据表进⾏更新操作，造成数据访问热点，同时使得不同事务中处理的数据互不⼲扰，实现对资⾦或库存信息处理的隔离。⽐如在⽤户进⾏订单创建操作时，需要对商品的库存进⾏减扣，如果是在秒杀和⼤促场景下，⼤量订单都是对同⼀商品进⾏下单操作，如果所有订单创建事务中都是修改商品表中商品数据的库存的信息，则必然会出现该条商品记录访问热点，⽽且很容易出现锁抢占的情况，避免锁的⽅式就是在订单创建事务中只是在“库存预减明细表”中添加⼀条对应商品的库存预减记录（如下图），⽽⽆需对原商品数据表进⾏库存修改的操作，⼀旦⽤户成功付款，则真正地将商品数据表中的库存减除。在付款之前当应⽤要获取该商品的库存信息时，则是通过以下公式获得：
商品当前库存数量=商品表中的库存数量-预减明细表中该商品对应明细表中库存数量之和

乐观锁
数据库的悲观锁对数据访问具有极强的排他性，也是产⽣数据库处理瓶颈的重要原因，采⽤乐观锁则在⼀定程度上解决了这个问题。乐观锁⼤多是基于数据版本（Version）记录机制实现。

从以上示例可以看出乐观锁机制避免了⻓事务中的数据库加锁开销。大大提升了⼤并发量下的系统整体性能表现。需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备⼀定的局限性，如在上例中，由于乐观锁机制是在应⽤中实现的，如果有另⼀个应⽤也对商品数据进⾏更新操作时则不⼀定会遵循乐观锁机制，因此可能会造成脏数据被更新到数据库中。这也就是为什么在构建共享服务体系时，对于数据的操作都会要求统⼀到该数据库对应的服务中⼼层，⽽不允许其他应⽤再对该数据库进⾏单独访问和操作。

5.柔性事务在阿⾥巴巴内部的几种实现

基于以上柔性事务实现分布式事务的思路以及从多年对互联⽹业务场景特性的深度剖析，从阿⾥巴巴内部共发展和演变出三套成熟的分布式事务解决⽅案，下⾯分别介绍。

消息分布式事务

未完待续

⽀付宝XTS框架

未完待续

6.阿⾥巴巴AliWare TXC事务服务

未完待续

7.关于柔性事务的总结

今天在我们⾯对的众多业务平台建设时，发现其中绝⼤部分场景下，我们都不需要⽤两阶段提交这样低效的⽅式来解决分布式事务问题。上⾯描述的⼏个最终⼀致性⽅案，都很好地在保证业务⼀致性的前提下，展现出极⾼的系统吞吐能⼒。为了充分发挥柔性事务框架性能的优势并实现业务的最终⼀致，需要采纳以下配合⽅案：

• 应⽤程序⼀定要做幂等实现，特别是对数据库进⾏数据修改操作时。
• 远程模块之间⽤异步消息来驱动，异步消息还可以起到检查点的作用。

两阶段提交的⽅案可以保证最强的ACID要求，开发者因此不需要仔细考虑⾃⼰的应⽤到底可以接受什么级别的ACID；同时，两阶段提交的⽅案开发简单，开发者只需要指定事务的边界即可。⽽最终⼀致性⽅案往往意味着更⾼的事务处理性能及处理吞吐率，但有些实现⽅案需要开发⼈员更全⾯地了解前端业务以实现事务的正向补偿或反向回滚，也会付出有损事务隔离性的代价。所以⼀定要在业务上精确分析⾃⼰的ACID需求，寻找性
能与ACID的折中点，采取最合适的⽅案。

6.4 大促秒杀活动催生缓存技术的高度使用

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

从淘宝缓存产品的研发和使⽤场景的历程来看，早期通过缓存实现应⽤分布式session，以避免应⽤实例间会话的复制，后来发展为将缓存⽤于业务去重判断、交易快照、图⽚索引等场景，最后替换数据库在业务交易处理中的职能，缓存平台在业务场景中扮演了越来越重要的⾓⾊。⽬前在整个阿⾥巴巴集团部署了近千台缓存服务器，保存了百亿级别的数据，满⾜业务对数据库90%以上的请求。

所谓的⼤促、秒杀场景，其关键词有“低廉价格”、“⼤幅推⼴”、“瞬时售空”，只有满⾜这三个关键词的场景才能称为⼤促、秒杀的场景。

下⾯重点阐述如何利⽤缓存技术实现商品数据的⾼性能读取，以满⾜秒杀活动中对于商品数据访问的同时不会出现商品超卖等严重的业务问题。

1.小库存商品秒杀典型架构

⽐如库存为10个，秒杀价格为1元的⼿机则是典型的⼩库存商品秒杀活动。在这种类型的秒杀活动中，因为商品会在极短的瞬间库存会降到0，所以只要处理好商品的库存的扣减，不要出现商品超卖的情况就能平稳地度过这次秒杀活动，如下图为此类秒杀活动的典型架构⽰意图。

⾸先⼀定要让负责秒杀场景的商品中⼼应⽤实例（图中“秒杀IC”）与满⾜普通商品正常访问的商品中⼼应⽤实例（图中IC）隔离部署，通过服务分组⽅式，保持两个运⾏环境的隔离，避免因为秒杀产⽣的过⼤访问流量造成整个商品中⼼的服务实例均受影响，产⽣太⼤范围的影响。

如图中“本地缓存”所⽰，可通过给⽹⻚资源设置Expires和LastModified返回头信息进⾏有效控制，从⽽尽可能减少对后端服务端的访问次数。

当⽤户进⼊到付款界⾯（图中Buy）进⾏成功付款操作后，则对商品数据库进⾏实际的商品库存修改，当商品的库存被修改后，会同时修改缓存中对应商品的库存信息，接下来⽤户在商品详情⻚和下单⻚⾯看到的就是更新后的库存信息。

商品定时上架

对于在秒杀开始前，商品界⾯上的定时器的实现，为了减少服务端的访问压⼒，定时器倒计时控制并不是每次通过服务端获取的，⽽是⻚⾯在每刷新访问⼀次才会访问⼀次服务器，当⻚⾯没有进⾏刷新操作时，界⾯上的时间倒计时则是在客户的浏览器端⾃⾏计算的。

懂前端Web开发的读者⻢上就会想到，这⾥可以通过JavaScript代码的⽅式修改定时器时间使商品界⾯上提前显⽰出商品下单的操作按钮，或是通过跳过定时器控制的⽅式直接访问商品的下单链接URL，达到在秒杀活动前就提前对秒杀商品的下单。为了杜绝这种现象的发⽣，解决的⽅法则是在服务端在接收到⽤户提交商品下单的请求后，⼀定要检查⼀下当前服务器的时间是否晚于秒杀活动的开始时间，否则就要拒绝该商品下单请求。

商品库存的乐观锁实现

避免商品出现超卖问题，核⼼技术是利⽤数据库的事务锁机制，即不允许同⼀商品的库存记录在同⼀时间被不同的两个数据库事务修改。

⽤户在进⾏商品下单操作中，会进⾏⼀系列的业务逻辑判断和操作，对于商品库存信息这⼀访问热点数据，如果采⽤数据库的悲观锁（⽐如select语句带forupdate）模式，则会给订单处理带来很⼤的性能阻塞，所以会采⽤乐观锁的⽅式实现商品库存的操作。实现的⽅式也⽐较简单，也就是在最后执⾏库存扣减操作时，将事务开始前获取的库存数量带⼊到SQL语句中与⽬前数据库记录中的库存数量进⾏判断，如果数量相等，则该条更新库存的语句成功执⾏；如果不相等，则表⽰该商品的库存信息在当前事务执⾏过程中已经被其他事务修改，则会放弃该条update的执⾏，可以采⽤重试的机制重新执⾏该事务，避免商品超卖的发⽣，具体的SQL语句⽰意如下：

update auction_auctions set quantity=#inQuantity# where auction_id=#itemId# and quantity=#dbQuantity#

其中#dbQuantity#为事务中在update语句执⾏前，通过select语句获取到的商品库存数量。

商品库存控制业务流

商品的库存在该类秒杀场景下，详细的库存控制业务流如下图所示。

图中描述了在小库存商品秒杀场景下，⽤户在通过商品详情页查看商品时，获取的商品基本信息以及库存均是从缓存Tair中获取，如步骤1.1。
当⽤户查看到当前商品还有可卖库存时，进⼊到Buy商品下单界⾯，此时商品的相关信息依然还是从缓存获取，如步骤2.1。
⽤户在进⾏下单操作后，此时就通过数据库本机事务操作的⽅式，通过商品中⼼的服务（IC）获取到当前商品真实的库存信息（步骤3.1）。
当此时获取的库存⼤于0时，则进⾏库存的扣减操作（步骤3.2）。
在通过步骤3.3更新了商品数据库中的库存信息后，同时也会更新缓存中该商品的库
存信息（步骤3.4）。
则前⽅⽤户再访问该商品信息时，看到的就是已经更新后的库存信息。

在小库存商品的秒杀场景中，缓存平台提供了对商品相关信息的缓存服务，使得⽤户只有在最终的下单环节才需要对数据库进⾏访问操作，大大降低了数据库的访问频率，而且因为商品的库存少，秒杀活动转瞬间就结束了，所以采⽤这样的架构基本就能满⾜该类⼤促秒杀场景业务的要求。

2.大库存商品大促架构

为了解决这⼀类⼤促场景的需求，则就要进⼀步发挥缓存产品的威⼒，将之前仅仅作为商品信息浏览的缓存的作⽤，提升到为库存操作提供事务⽀持的⾓⾊。如下图：

在秒杀活动开始前，直接将该商品的初始库存信息通过商品中⼼（图中的IC）加载到缓存服务器Tair上（步骤0.1）。

跟⼩库存商品秒杀场景相同，当⽤户访问商品详情⻚时，是从Tair缓存服务器上获取商品的库存信息（步骤1.1），在库存⼤于0的情况下，⽤户进⼊到下单界⾯（Buy），并点击“确认购买”按钮进⾏下单操作时（步骤3），后端处理的逻辑就跟⼩库存商品秒杀有了较⼤的区别。

在⽤户进⾏了下单操作后，程序⾸先会为该订单创建⼀个订单详单记录，只不过在库存成功扣减前，该订单的状态是⽤户不可⻅的。保存该订单的信息⾮常重要的作⽤是当缓存服务出现故障不可⽤时，可通过商品数据库中初始缓存的信息和数据库中订单详单信息能还原出订单处理的最新状态，⽽不⾄于出现因为缓存的故障造成业务数据的丢失。

在数据库中成功创建订单详单后，会发送⼀个库存修改的请求到消息服务器。因为⼀般的缓存平台还不⽀持MVCC或数据锁的功能，此时利⽤消息服务可让库存修改的请求线性处理，这⾥可利⽤上⽂提到的事务消息的⽅式，保证在订单详单创建成功后，发送消息到消息服务器，当消息的订阅程序从消息服务器获取到消息后，则对缓存中的库存数据进⾏更新处理。因为缓存数据更新时间在纳秒级，所以整体的库存处理性能相⽐传统数据库⽅式差别⾄少在百倍。当缓存中的库存数据成功更新后，则将之前创建的订单详情状态修改为成功下单状态，整个订单创建过程结束。

在这个⽅案中，实际上是将订单交易创建环节中对于原本商品数据库的库存信息操作替换为在缓存服务器中运⾏，充分展现了缓存服务相⽐于传统数据库在性能上的巨⼤优势。⽽且随着缓存技术的逐步完善和发展，业界各缓存平台的⾼可⽤性已经越来越⾼，从趋势来看，缓存技术将会在互联⽹应⽤场景中将扮演越来越重要的⾓⾊。

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

分布式服务体系建设后，整个淘宝平台变成了⼀个复杂⽆⽐的服务交互链路⽹，如何对每天发⽣的⼏千亿次服务调⽤出现报错时快速定位问题，如何实时监控到服务的运⾏状态是否正常，如何给运营团队关注的业务指标提供实时呈现以供他们进⾏实时的精准营销，这⼀系列的问题都是应⽤基于分布式服务体系建设后所⾯对的问题和诉求，这⼀章将系统介绍阿⾥巴巴采⽤分布式⽇志引擎解决各类技术和业务问题，为今天阿⾥巴巴的数字化运营能⼒逐步奠定了坚实的平台和数据基础。

7.1 业务服务化带来的问题

整个服务化后的淘宝平台各个服务间的服务调⽤关系变得纷繁复杂。对这样复杂的服务调⽤关系以及每天海量的服务调⽤，⽽且所有的服务都是以“点对点”的⽅式进⾏交互，就⾃然会导致出现问题时很难定位。

正是因为服务开发⼈员和业务架构师对于分布式服务调⽤跟踪⽅⾯的需要，阿⾥巴巴中间件团队历时两年多的时间打造了针对分布式服务调⽤链跟踪平台——“鹰眼”。

在业界，跟淘宝的鹰眼类似的平台有不少，如Twitter的Zipkin，这⼀类平台的实现都起源于Google Dapper论⽂（http://research.google.com/pubs/pub36356.html），感兴趣的读者可以查看该论⽂对此类分布式服务跟踪平台的原理实现有⼀个更详细的了解。

如果我们把整个淘宝的分布式服务架构⽐喻为遍布全国的⾼速公路⽹络，每⼀次的页面请求都可以认为是⼀辆汽⻋在这个⾼速公路⽹络中穿行，把⾼速上的每⼀个收费站⽐喻为处理请求的服务。那么我们希望查看⼀辆汽⻋在⾼速上的⾏⾛轨迹的话，如何实现？最简单的⽅法就是在这辆⻋每次经过收费站的时候记录下⻋辆通过的时间和相关信息，并将这些信息统⼀发送到服务器端保存起来，如下图：

当我们希望查看鲁A123BC这辆⻋的⾏驶轨迹时，只需从⽇志⽂件中查找出该⻋辆的⽇志信息，就能清晰地还原出该⻋辆的⾏驶路线和过路费等信息，如下图：

上⾯⾼速路⽹络和汽⻋的⽰例直观地展现了鹰眼平台的核⼼实现思路，就是通过⼀套分布式⽇志平台实现对服务调⽤链路的跟踪。

7.2 鹰眼平台的架构

基于以上的设计思路和理念，淘宝构建的鹰眼架构（2013年架构）如下图：

⾸先在每个应⽤集群的运⾏环境中，每当应⽤中进⾏了远程服务调⽤、缓存、数据库访问等操作时，都会⽣成相关的访问⽇志并保存到应⽤所在的服务器上。

因为这些本地⽇志信息仅仅是⼀次业务请求处理中的部分⽇志信息，必须要将这些⽇志信息汇聚到⼀个地⽅才能进⾏全局的统计和查看，所以在每个运⾏应⽤所在的服务器上均有⼀个代理程序，专门负责实时地将⽣成的⽇志⽂件（增量）发送到鹰眼的处理集群上。

鹰眼平台是阿⾥巴巴中间件团队⾃主研发的JStorm流式计算引擎，对应⽤集群接收到的⽇志进⾏内容的解析拆分，按照不同业务场景的需求将拆分后的数据保存到不同的存储系统中。对于需要对⽇志信息进⾏实时业务统计的需求，会将⽇志信息保存到HBase中，对接收到的⽇志信息进⾏实时的汇总计算，最后给鹰眼服务器提供实时业务统计数据，⽐如某⼀服务实时的QPS值、交易⾦额的实时变化等场景。如果对于⽇志信息要进⾏批量的统计和分析，⽐如7.5节将会提到的链路分析功能，则会利⽤Hadoop分布式⽂件系统（HDFS）提供这类业务场景下对⽇志数据的计算和分析。

7.3 埋点和输出日志

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

未完待续

7.4 海量日志分布式处理平台

未完待续

7.5 日志收集控制

未完待续

7.6 典型业务场景

未完待续

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

在过去10多年的时间⾥，阿⾥巴巴投⼊了集团⼤量的精英⼈才⽤于提升淘宝、天猫平台服务的稳定性，正是有了多年来上万名阿⾥技术⼈员的持续创新和技术沉淀，在⼀系列秒杀⼤促，特别是天猫双11这样称为现象级的电商⼤促活动中，打造出了今天⼤家所看到的可轻松应对天猫双11的平台稳定性体系。

在整个稳定性体系中，所包含的范围⾮常⼴泛，从机房的布线、⽹络通信、硬件部署、应⽤架构、数据容灾等⽅⾯都与之相关。从共享服务中台的⾓度，则更多的是从应⽤架构设计和中间件平台的维度对平台的稳定性实现更精细化的管控和保障。本章就是从这个⾓度介绍阿⾥巴巴中间件团队多年来为了提升淘宝和天猫平台的稳定性所作出的⼀系列技术创新和成果，包括限流和降级、流量调度、业务开关、容量压测和评估、全链路压测平台、业务⼀致性平台等。

8.1 限流和降级

限流的作⽤相当于电路上的保险丝，当过载的时候掐掉⼀些流量，让系统有能⼒集中资源以较快的速度处理平台处理能⼒范围内的业务请求。比如，仅让1000万⽤户中的100万⽤户进⼊后端的处理流程中，将其余900万⽤户的请求通过队列排队或直接阻挡在平台处理单元之外的⽅式，保障平台能在处理能⼒范围内对100万的⽤户请求进⾏处理。

平台要具备限流的能⼒，⾸先需要对服务部署的能⼒有⼀个准确的评估，知道服务实例的部署量到底最⼤能满⾜多少业务请求的处理要求。这就需要采⽤压⼒测试的⽅式对系统进⾏压测，但传统的压⼒测试⽅法都是采⽤模拟的数据，从实践的⾓度来看，这些压测的数据与在实际⽣产环境中所表现的指标还是有⽐较⼤的偏差，也就是说，采⽤模拟数据进⾏压⼒测试的⽅式并不能准确测量出平台的能⼒峰值。阿⾥巴巴中间件团队针对这个问题，开发了线上压测⼯具，能更⽅便和准确地对服务的容量进⾏评估，即获取到该服务所能提供的最⼤处理能⼒。在随后8.4节“容量压测与评估规划”中对这部分内容有⼀个更详细的介绍。

在掌握服务的容量后，接下来就是要针对服务资源的使⽤情况进⾏监控，通过资源监控的指标与之前所获取的服务处理上限进⾏⽐较，如果超过服务处理上限则启动限流。通过CPU、内存、磁盘IO等资源的使⽤情况来判断系统⽬前的负载往往是不准确的，因为很多情况下系统本⾝的处理能⼒处于什么样的⽔位跟这些操作系统资源的使⽤情况没有⼀个清晰地对应关系，所以在实际中，都会通过服务的QPS作为限流的关键判断指标。

对于平台限流的实现，先从⼀个典型服务化应⽤架构的⾓度来看。⽤户的请求⾸先会通过前端接⼊层（⼀般采⽤Nginx）分发到后端的应⽤集群上，应⽤集群中主要负责⽤户的前端交互以及基于业务需求对后端服务集群中的服务进⾏服务调⽤。为了避免⼤促秒杀场景时，远超过系统处理负载上限的访问请求，同时也能很好的兼顾安全问题，通过⼀些安全策略防⽌对平台的恶意攻击，所以最优的限流拦截点在前端接⼊层⾯（如下图所示），因为让访问洪流进⼊到系统的下层，对于系统的冲击以及限流的难度都会加⼤。

阿⾥巴巴是通过在Nginx上实现的扩展组件TMD（Taobao MissileDefense，淘宝导弹防御系统）实现了接⼊层限流的主要⼯作，TMD系统可通过域名类限流、cookie限流、⿊名单以及⼀些安全策略等很好地实现了在接⼊层的限流措施。

TMD系统包含了淘宝技术团队开发的开源模块nginx-http-sysguard，主要⽤于当访问负载和内存达到⼀定的阀值之时，会执⾏相应的动作，⽐如直接返回503，504或者其他URL请求返回代码，⼀直等到内存或者负载回到阀值的范围内，站点恢复可⽤。对于nginx-http-sysguard模块的具体使⽤，在淘宝开放的Tengine平台上有⾮常详细的介绍，读者可⾃⾏到该站点（http://tengine.taobao.org/document_cn/http_sysguard_cn.html）上学习。

8.2 流量调度

背景

今天阿⾥巴巴的淘宝平台都运⾏在云平台上，在云平台中不可忽略的⼀个问题是为了最⼤程度地增加机器的利⽤率，会采⽤超配的⽅式，即⼀台物理机上创建的虚拟机CPU核数的总和会超过物理机实际的CPU核数。超配本⾝并不是⼀件坏事，淘宝平台包含了上千个⼤⼩应⽤，⼤部分都是⻓尾应⽤，即使在双⼗⼀零点，有些应⽤的流量也是⾮常低的。这些应⽤所在的服务器计算能⼒其实是有剩余的。合理的超配，可以提升机器的资源利⽤率。但同样是核⼼的应⽤在虚拟机资源分配上并没有避免超配的现象，这就造成在业务繁忙时，这些部署在超配服务器上的应⽤就会出现资源争抢，这样很可能导致个别或局部的应⽤出现服务响应慢甚⾄挂起，给整个业务链路带来更⼤的影响。

这些因为单机或者局部问题⽽导致的故障，在阿⾥巴巴淘宝的线上环境中是普遍存在的，尤其是当我们应⽤机器数达到⼏百到⼏千台的时候，⾮常容易出现个别或者局部的机器服务状态恶化甚⾄服务不可⽤的情况。

除了机器超配之外，还有其他各种原因也会造成这些单点或局部应⽤出现故障：

• 超卖问题带来的资源争抢问题。
• 部分应⽤、部分机器启动的时候，容易出现个别机器负载飙⾼，导致这部分机器响应时间变⻓。
• JVM假死、VM假死等问题。
• 受宿主机影响，负载飙⾼问题。
• JVM垃圾回收影响请求响应时间的问题。
• ⽹络抖动导致RT抖动。

为什么上述单机、局部问题会带来这么⼤的影响？原因如下：

• 分布式服务环境调⽤链路局部问题会被放⼤到整个链路。
• 单点、局部问题会被放⼤成⾯。

⾯对这种影响整体服务体系稳定性的隐患，阿⾥巴巴中间件团队实现了针对分布式服务系统的流量调度平台，⽤于屏蔽所有机器的软硬件差异，根据机器的实时服务能⼒来分配机器的实时流量。对实时服务能⼒好的机器多分配流量；对实时服务能⼒差的机器减少流量分配；对实时服务能⼒不可⽤的机器迁移流量。让因为软件或者硬件带来的单点、局部问题发⽣时，不会影响整体业务的稳定运⾏。

实现原理

流量调度的核⼼是通过秒级获取服务器系统运⾏指标以及业务指标，通过流量调度平台设置的决策算法以及规则，当发现满⾜规则条件的指标状态发⽣时，对线上环境的服务器进⾏下线等操作，以屏蔽这些单点或局部出现故障的应⽤实例对整体平台产⽣扩展式的影响。流量调度架构如下图：

通过服务器上暴露的指标信息接⼝（图中Restful API），流量调度的服务器定时（⽬前的收集频率⼤概是5s⼀次，每次指标集合⼤⼩1KB，对应⽤的性能没有任何影响）调⽤指标信息接⼝，⽬前采集的信息包括：

• 系统指标信息：CPU、Load等。
• 业务指标信息：HTTP响应时间、HSF服务调⽤响应时间、HTTP QPS、HSF QPS、Tomcat线程池使⽤信息、HSF线程池使⽤信息。

在收集到这些实时指标值后，⼀旦判断为故障现象，则执⾏对线上流
量调度的执⾏。

⽬前淘宝平台后端流量基本都是HSF服务。此时，HSF服务框架中的ConfigServer就充当了“引路⼈”的⾓⾊。正如前⽂所描述的，服务的提供者和服务调⽤者在⾃⾝应⽤启动时会将服务的发布和订阅信息上传到ConfigServer中，因⽽，在进⾏流量调度时，只要ConfigServer推送给服务消费者的服务提供者列表带上服务调⽤的权重信息，服务消费者在选择服务提供者进⾏服务调⽤的时候，就能按照权重信息选择每次调⽤的服务提供者，从⽽就能控制所有服务提供者被服务请求的流量⼤⼩。这样当发现某些服务提供者出现服务响应慢或系统资源负载飙⾼时，实时降低对该服务器的服务路由权重（甚⾄直接降为0），最终达到通过⾃动化的流量调度来隔离故障。

调度效果

⽬前流量调度平台已经完成了覆盖天猫、淘宝、⽆线、⼿淘、聚划算、航旅等事业部超过300多个应⽤的接⼊，实现了对交易核⼼链路应⽤的全部覆盖，每天平均⾃动处理上百台问题机器。限流降级平台重点解决应⽤在整体上的可⽤性，流量调度平台很好地弥补了应⽤局部可⽤性带来的问题和隐患，为淘宝平台整体平台的稳定运⾏保驾护航。

8.3 业务开关

未完待续

8.4 容量压测及评估规划

要知道⼀个平台的处理能⼒是否能⽀撑⼤促活动的访问量，最常⽤的⽅式是对平台进⾏性能测试，验证当前平台的处理能⼒是否能满⾜预估的系统处理峰值，通过对服务器容量的调整最终达到峰值处理能⼒的要求。

传统的互联⽹应⽤系统的性能测试，不论是常规性能测试，还是系统容量评估，其做法基本是，先通过需求分析得出压测的业务场景及不同场景在压测中的⽐例关系，或凭借开发、测试⼈员的经验对线上某⼀时刻的业务进⾏分析，得出经验性的测试模型，再通过性能测试⼯具在测试环境模拟压测，最后分析测试结果、判断系统的最⼤负载能⼒。

如何对平台的处理能⼒有⼀个更加清晰的了解，以及更科学合理地利⽤好服务器资源，阿⾥巴巴技术团队经过了多年的研究、实施、验证，摸索出⼀套⾯向分布式应⽤架构下应⽤系统容量压测和评估的⾃动化平台。

应⽤系统容量预测的实现原理包括：容量压测，容量分析预测两部分。

容量压测是通过将线上真实的流量引流到压测⽬标机器上，并不会对本系统及下游系统带来额外的流量，也不需要准备测试数据、压测系统。实现将⽣产环境对服务进⾏压测实际上利⽤了HSF服务框架对于服务路由权重的⽀持，通过对服务路由权重的逐步增加，达到对路由到某服务单机的服务请求逐步增加的⽬的，运维⼈员只需在控制台（如图8-11所⽰）上设置好HSF服务实例的服务、服务路由的权重增⻓⽅式、被压测的单机的关键指标（CPU利⽤率、系统整体负载、QPS、响应时间等）达到的阀值⽔位后即⾃动停⽌压测，以免对⽣产环境产⽣⼤的影响。⼀旦系统停⽌压测后，就能在平台上查看到该服务实例在系统资源达到阀值时，单机服务实例所能提供的最⼤的QPS处理值。

通过容量压测获取到的单机QPS能⼒后，既能发现⼀些应⽤性能的问题，也能对性能优化后的应⽤再通过容量压测的⽅式进⾏验证。

8.5 全链路压测平台

全链路压测是阿⾥全系统每个环节都参加的双11实战演习，主要对零点峰值流量进⾏评估，以及对⽹站承压能⼒进⾏测试，是双11前为系统查缺补漏的重要⼀环。全链路压测平台通过应⽤系统改造使线上环境可以同时处理正常流量和测试流量，以⽀持线上不影响正常⽤户访问的集群读写压测，获得最真实的线上实际承载能⼒数据。要实现全链路压测，涉及的产品很多，包括⽹络、应⽤、中间件、数据库、安全、数据等都需要改造，涉及的应⽤范围很⼴，涵盖核⼼交易链路的上百个应⽤。所以全链路压测平台的诞⽣涉及了⼤量⼈⼒资源的投⼊和配合，⽬前成为集团⼤促备战最重要的武器。下⾯介绍这个平台。

1.基础数据抽取

全链路压测的⽬的在于模拟双11，模拟的真实性尤为重要。基础数据（买卖、卖家、商品等）的构造是真实性保障的重要⼀环，为了模拟尽可能真实，全链路压测以线上数据为数据源，进⾏采样、过滤和脱敏，作为全链路压测的基础数据，数据量与线上数据保持同⼀个数量级，在数据库的sequence id上进⾏区间隔离。

2.链路与模型构造

全链路压测的链路代表要压测的业务范围，同⼀条链路需要构造海量的参数集合，代表不同⽤户的不同⾏为。链路范围、链路的访问量级、链路的参数集合、基础数据的特性⼀起构造了压测的业务模型。链路与模型的构造对压测结果的影响同样⾄关重要。

3.链路验证

在全链路压测平台的诞⽣阶段，链路验证耗费了压测项⽬组⼤量的时间和精⼒，电商业务具备复杂的业务特性，有上百条链路，每⼀条链路都需要确保能够让全链路压测引擎跑通，好在这是个⼀次性的⼯作，跑通以后出问题的概率不⼤，全链路压测平台也将链路验证功能集成到平台当中，能够⾃动化完成对压测链路的验证。

4.业务改造

全链路压测有不少地⽅需要在业务系统针对压测流量进⾏相应改造。⽐如压测链路的重复执⾏：全链路压测通常会进⾏好⼏个⼩时，这⼀特性要求链路能够被重复执⾏。实际情况当中，我们有不少链路并⾮是幂等的，需要针对存在这⼀特性的链路做专门的压测流量改造。再⽐如下游写流量的拦截、防⽌污染BI报表和线上推荐算法等场景都需要在业务系统进⾏相应改造。类似这样的改造点，在全链路压测早期时代⾮常多。

5.数据平台

数据平台是全链路压测的数据基地。由数据的准备、链路的构造、模型的构造等⼀系列重要模块构成，随着全链路压测的不断演进，数据平台沉淀了⼀系列⾃动化和智能化的基础设施，⼤幅提升全链路压测数据准备的效率和模型精确性。

6.流量平台

流量平台是全链路压测的CPU，主要由两⼤部件构成：

• 全链路压测操控中⼼，进⾏压测的配置和操控、数据的监控以及对压测引擎集群的管控。
• 压测引擎，由控制台统⼀管控，部署在外⽹CDN集群，进⾏登录、session同步，发送各种协议的压测请求、状态统计。

7.影子表

数据的隔离是全链路压测诞⽣阶段的⼀⼤难题。全链路压测的链路有读有写，并且在线上进⾏，为了不污染到线上的正常数据，全链路压测在同⼀个数据库的实例上对数据库表建同样结构的影⼦表来进⾏数据的隔离。

8.中间件改造

全链路压测的流量通过在链路上带上特定的压测参数进⾏区分，如果缺乏相应中间件的⽀持，在调⽤到下游系统的时候，压测标志就丢失了。因此需要所有中间件的协议都⽀持对压测流量的识别，使得压测标识能够随着调⽤传递下去，使得下游的应⽤、基础中间件和存储都能够识别压测流量。

9.安全机制

全链路压测的安全机制分两层：第⼀层是安全的监控和保护，建⽴⾮法流量的监控机制，正常⽤户访问不了测试数据，测试账户也访问不了正常数据，防⽌数据错乱；并且设置压测引擎集群的⽩名单，防⽌恶意访问；第⼆层是对压测流量的安全过滤，针对压测流量放松安全策略，使得压测流量不被判别为攻击流量。

随着后期全链路压测平台在⾃动化以及能⼒开放⽅⾯的改善，已经很好地实现了⼤促⾃动化备战，沉淀了⼀套⾃动化、系统化的基础设施和流程，能提升整体备战效率，⼤⼤缩减了⼤促准备环节的⼈⼒、时间和机器成本。⼤促⾃动化备战串联了备战环节的离线节点，从全链路压测链路模型的⾃动计算、全链路数据准备和流量发送的⽆缝衔接、应⽤容量的弹性伸缩、⾃动化的预案执⾏和验证等多个维度，使得整个⼤促备战更加⾼效和精准，将阿⾥巴巴在⼤促稳定性保障能⼒提升到⼀个崭新的⾼度。

8.6 业务一致性平台

在淘宝平台进⼊服务化时代后，偶尔还是会遇到远程服务调⽤失败，数据库保存失败，MQ消息发送失败这样的情况，从⽽导致丢失数据或者各服务中⼼数据不⼀致。

要解决这个问题，就需要在实现业务处理的过程中，实时检测到业务不⼀致的问题，在消费者发现该问题之前系统就应该发出了报警，并且已转交相关技术⼈员处理。

在这样的背景下，实时业务审计平台（Business Check Platform，BCP）应运⽽⽣，这个平台采⽤规范与标准化业务规则的⽅式，统⼀解决平台服务化后越来越凸显的业务⼀致性问题。

平台的⽬标是在每个上线的业务都能形成⼀对⼀的监控与检测，并形成⼀个规范的业务上线、订正流程。BCP平台实现了以下4个主要⽬标：

• ⾼实时性地发现业务脏数据或错误逻辑实现，第⼀时间发现并及时通知技术保障⼈员，⽽不是等客户反馈。
• ⽅便地接⼊各种业务规则，通过脚本规则编写的⽅式，让各应⽤快速接⼊业务审计平台。
• 整合订正⼯具，形成规范的赃数据订正流程。
• 业务上线的实时监控，新上线业务可以很⽅便地进⾏校验。

为了更⾼效率地让应⽤快速接⼊业务审计平台，同时减少对应⽤带来的代码侵⼊以及性能的影响，BCP平台通过事件模式，把业务数据变化触发的消息（如精卫、MQ等平台消息）转换为相应业务类型的事件，放⼊到事件执⾏队列进⾏规则检查，BCP提供了通⽤的事件监听框架，实现了与MQ（消息服务）对于数据库的对接，是对于数据变更的⽇志信息接⼊到了BCP平台中，如下图：

未完待续

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

9.1 服务化建设野蛮发展带来的问题

未完待续

9.2 共享服务平台的建设思路

未完待续

9.3 共享服务平台与业务方协作

未完待续

9.4 业务中台与前端应⽤协作

未完待续

9.5 业务中台绩效考核

未完待续

9.6 能⼒开放是构建⽣态的基础

未完待续

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

第10章 大型央企互联网转型

10.1 项目背景

10.2 项目实施

10.3 客户收益

10.4 笔者感想

10.5 项目后记

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

11.1 项目背景

11.2 供应链的改造

11.3 基于SCRM的全渠道整合营销

11.4 小结