《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》是一本由钟华著作，机械工业出版社出版的平装图书，本书定价：79，页数：357，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。

《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》读后感(一)：abcde

1.针对这类场景问题，最常用的是采用“异构索引表”的方式解决，即采用异步机制将原表内的每一次创建或更新，都换另一个维度保存一份完整的数据表或索引表。本质上这是互联网公司很多时候都采用的一个解决思路：“拿空间换时间”。也就是应用在创建或更新一条按照订单ID为分库分表键的订单数据时，也会再保存一份按照买家ID为分库分表键的订单索引数据，其结果就是同一买家的所有订单索引表都保存在同一数据库中，这就是给订单创建了异构索引表。

2.建议采用仅仅做异构索引表，而不是数据全复制，同时采用两次SQL请求的方式解决出现全表扫描的问题。

3.如果在“尽量减小事务边界”与“数据尽可能平均拆分”两个原则间发生了冲突，那么请选择“数据尽可能平均拆分”作为优先考虑原则，因为事务边界的问题相对来说更好解决。

《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》读后感(二)：阿里（国际）中台服务共享体系研究

注：来源本书和知乎。

一、战略指导

全球化战略是阿里未来20年最核心的三大战略之一

马云曾这样描述阿里的全球化目标：希望为全世界解决1亿就业机会，服务20亿消费者，为1000万家中小企业创造盈利。要让全世界的中小企业能够做到全球买、全球卖、全球付、全球运和全球游。

围绕上述目标，阿里打造出了一个完善的跨境电商生态体系。目前阿里的全球化业务，除了速卖通和Lazada外，还有天猫国际，以及阿里国际站等。阿里众多国际业务将迎来深度融合，以打通海外端、供应链、商品库和技术体系，通过协同出海去推动“货通全球”的实现。

二、背景

源自芬兰游戏公司 Supercell 的启发

2015年年中，马云带领阿里巴巴集团高管拜访了芬兰移动游戏公司Supercell——《部落战争》《海岛奇兵》《卡通农场》等多款知名游戏的创作者。Supercell的模式给了集团高管们很大的感想：在Supercell内部以小团队（cell）形式作战，小团队最多不超过7人，小团队对整个项目周期负责，从项目策划到研发再到向市场推广，如果产品没有受到市场欢迎则迅速放弃产品，从中吸取经验后再进行新的尝试。这样的快速试错、不断创新的模式使得Supercell成为了一家年税前15亿美元的游戏公司。

透析Supercell的模式，它的成功离不开其自身在多年游戏研发中积累的“中台”能力，这个能力使得几个人的小团队在几周时间就能研发出一款新游戏，通过对游戏开发过程中公共的素材、算法等资源进行沉淀，充分鼓励员工进行试错、创新，降低试错成本，提升创新效率，使得团队能以最快的速度找到受市场欢迎的产品，为奠定其游戏行业地位打下了坚实的基础。

2009年阿里巴巴开始构建的共享服务体系应该算得上是微服务实践的先驱，经过7年多的实践探索和演变，绝对称得上是“微服务”架构在大型互联网公司中的最佳实践。

三、作用

1、降低试错成本，提升企业创新效率

2、为团队培养出既懂技术，也懂业务的复合型人才。

“中台”是强调资源整合、能力沉淀的平台体系，为“前台”的业务开展提供底层的技术、数据等资源和能力的支持，用张勇的话来说就是“中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑”。

之前有知友提到阿里巴巴内部存在的各自为政、重复造轮、缺乏沉淀的问题，其实这是所有互联网公司的共同问题，而在目前业务瓶颈日益显现的背景下这些问题就显得更加不容回避了。而这些问题背后的根源其实就在于没有形成一个规划协同、共建共享的中后台，而是任由前台条线各行其是、南辕北辙。此次阿里组织架构中“中台”的设置就是为了提炼各个业务条线的共性需求，并将这些打造成组件化的资源/能力包（对组件化感兴趣的可以自行了解“Component Business Model”的知识），然后以接口的形式提供给前台个业务部门使用，这样就可以最大限度地避免“重复造轮子”的问题，也让每一个新的前台业务创新能够真正意义上“站在阿里巴巴这个巨人的肩膀上”，而不用每次开辟一个新业务都像新建一家创业公司那么艰难，甚或更为艰难。

总而言之，阿里巴巴这次以及之前的数次组织架构调整，其实背后反映了小公司长成大公司的过程中所必须经历的规范化与正规化历程。而这，也是其它的互联网公司迟早都需要经历的---这似乎也意味着中国互联网的发展将进入到“新常态”了。

四、过程

依次按照下面来实践共享服务平台的搭建：

第一、找到合适的服务化对象。这个对象要能够涵盖各种各样的业务流程、业务数据又要便于封装。为了保持对现有系统的兼容性，目前阿里巴巴集团的共享服务中心的功能支持粒度都是API，但是并不意味着只能把API作为服务对象，也还可以有其他粒度的服务。

第二、建设对象服务化的基础设施。有了服务话对象之后，需要制定制定相关的服务组件规范以及对应的服务治理平台与工具，以便对服务进行封装。一个完整的服务应该包括的基本功能有服务的描述元数据、服务注册与发现机制、服务访问控制与安全策略、应用服务portal、服务依赖与运维管理、服务SLA协议、服务消费者的管理与支持工具、服务化辅助工具支持、服务调用分析与报表、服务成本核算与服务能力变现、文档与开发工具支持。

第三、服务化实施。阿里巴巴中台把推进服务化实施过程化分为三个阶段：API as Service, Product as Service, Solution as Service。API as Service 解决了存量API的服务化问题，Product as Service是基于API初级服务的深加工，服务更面向场景，更专业化。这两个阶段实现了阿里巴巴从基础能力到业务能力的共享开放，Solution as Service的目标是让各种业务场景和解决方案在共享服务平台上达到最大程度的复用，让业务的拓展是基于服务的方式而不是基于代码的方式。

当然业务中台是前端应用所需服务的提供者，中台的需求需要前端应用来提供，两者需要在对接过程中相辅相成，共同发展。在阿里巴巴业务中台过去的几年发展中出现了多种与前端应用协作的模式：建立业务中台对前端核心业务的紧密沟通机制，及时、准确地了解核心业务需求；建立分歧升级机制；岗位轮转推动真正换位思考；业务持续沉淀及业务共建等。

五、成果和案例

案例：聚划算，十几个员工，1个半月上线，其他同类型的团购平台建设所投入的研发资源可能是阿里投入资源的几十倍。14个月后发展为600人团队。商品一旦进入聚划算平台，销售额会在短时间内至少增长25倍。

以阿里巴巴集团1688（B2B电商平台）、淘宝、聚划算、闲鱼为例，每个平台都有各自的订单创建流程，各流程所包含的服务数量和流程因为业务场景的不同而有所不同，但不管是哪种模式下的订单创建无一不会牵涉会员信息的验证、商品库存的修改、订单的创建、支付记录的生成，而这些流程都可以由对应的服务中心提供，这意味着不管前端业务形态如何变化，共享服务中心都能很好的支持业务需求并将对应的交易信息以及数据回流到对应的服务中心。

目前阿里巴巴集团已经将20多个核心业务中通用的、公共的业务以服务的方式沉淀到了共享服务平台，整个集团的核心业务能力均建立在这样一套共享服务体系之上，集团2000多个应用在核心业务层通过共享服务中心实现了统一和畅通，从而也最大程度地避免了打通不同系统间业务交互带来的集成和协作成本。

六、未来-项目

为发挥大数据能力奠定基础

近年来大数据重要性日益凸显，然而大部分企业在实施大数据项目时候都会碰到两大比较突出的问题：数据在企业内部广泛分布，格式以及标准都不统一；缺少能真正利用大数据平台发挥业务价值的人才。

解决以上两个问题的方法与建设共享服务体系的思路一致，共享服务体系通过服务中心将业务和数据做了很好的融合，在同一个服务中心内部对数据做了很好的规整以及沉淀，为以后实施大数据项目时对完整的、高质量的数据需求打下基础。

《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》读后感(三)：阿里IT架构转型的实践

这本《企业IT架构转型之道》，副标题是“阿里巴巴中台战略思想与架构实战”。作者钟华，是阿里中间件团队的核心成员，首席架构师。

本书主要讲了三个问题。

为了实施这个战略，阿里共享业务事业部诞生，并主导了这一波阿里IT架构的演变。

阿里实施中台战略，其中的一个重要契机是阿里的管理层在2015年参观了一家叫SuperCell的公司，没错就是开发了《部落冲突》，然后2016年被腾讯以86亿美元收购了80%以上股份的不到200人的公司。为什么他们可以开发出风靡全球的游戏，是因为他们积累了非常科学的研发方法和体系，能够不断尝试，快速的从失败中学习。这种能力给了阿里很大的震撼，学习回来后半年，阿里的中台战略应运而生。

而作者从IT架构演变的角度来诠释了为什么要实施中台战略。

我从中还解读出这么几个信息，一是，IT架构的转型一定是为了配合组织机制和业务机制的发展，这也符合康威定理；二是，IT架构转型一定是举全公司之力，并不是IT部门一家能搞定的；三是，中台战略，是解决大企业有效的进行协作创新的有效手段。

“中台”其实并不是阿里发明的，在IT领域具备中台属性的架构早已诞生。从最开始的企业服务总线（ESB）到PASS（平台即服务）到SOA服务框架，到微服务，无一不具备支撑中台战略思想的潜质。

最终阿里选择的是分布式的SOA服务架构，来建设中台的服务中心。跟大部分传统企业一样，也涉及到去IOE的问题。IOE的架构，作为OLTP（在线事务处理）领域，其实非常成熟，但是为了利于扩展，实现系统的渐进式建设，必须要打破IOE的架构，同时还要保留原来的数据以及事务的一致性。这里涉及到几个重要的问题。

阿里的业务规模和复杂度决定了只能采取分布式的服务架构。如果你的企业规模不大，业务数据不是特别服务，采用集中式的ESB也无所谓。

这跟企业大了，必须划分部门是一个道理。有四条原则：

总之，就是责任划分的比较清楚，每个中心（部门）规模相当。面向中台的服务中心，就是要把共享服务划分好，比如客户中心，订单中心等等。但，同时又不能拆分的过细，比如会员数据如果跟客户中心高度相关，按照数据完整性的原则，就不应单独拆分出来。

数据库就像图书管理员，但你的藏书规模不大的时候，一个管理员就能应付过来了；但是如果你管理的书籍和资料非常大的时候，管理员就成了瓶颈，这个时候，就需要增加人手。

当有多名管理员的时候，你可能会让张三负责小说，李四负责社科，王五负责自然科学。这是基于业务划分的原则。

但是，马上发现张三忙的要死，李四闲的要死，为了避免这种情况，就需要采用随机的方法划分数据。

过了一段时间又发现有一些热门的书籍，比如小说，借阅的人非常多，因此你会多买几套，找专人管理起来，提高效率。对数据而言，小说就相当于热数据，因此就复制一份放到内存里面，以提高访问效率。

在IOE时代，写应用的一项重要工作是保障事务的一致性，这需要数据库加锁来保障。在服务中心化之后，一次交易就涉及跨中心了，如果还靠数据库来保障事务一致性，明显不现实。所以，就需要用很多软件的办法来解决事务一致性的问题。

一是把大事务拆小，分阶段异步完成。在这种思路下需要在业务层面来协调分阶段提交的关系。有的事务部涉及主流程，比如下发通知信息等，就直接剥离；有些小事务可以用反向的业务来考虑，而不是事务回滚，比如退货以后，进行退款，而不是取消之前的交易。同时要可以增加交易校验机制和增加资源预占以及两阶段提交。

二是引入柔性事务的概念，即交易最终的状态保持一致，在这个过程中，容忍一定程度上的不一致，换来高可用性。比如数据库锁比较豪资源，那么采取软件方式实现无锁，可以有效提升资源效率，但需要牺牲一定的交易过程中的用户体验。同时还可引入日志和补偿机制，从更底层来保障事务一致（对业务逻辑依赖没那么强）。

另外有些分布式系统的新问题，需要考虑的，比如机器和机器之间的通信，消息可能会丢（单机不存在这种情况），所以要考虑采用可靠消息传递机制，远程模块之间一定要用异步消息来驱动。

从阿里给业务中台的绩效考核，就可以看出中台在这一波变革中承担的角色：

更复杂的架构必然带来运维的问题，阿里开发了基于海量日志可视化分析的鹰眼系统，可以对服务以及服务调用链进行全方位的监测，同时日志中反映出来的业务数据可以跨业务领域跟踪故障，实现业务级的监控。

监测出故障或隐患后，就要围绕平台的稳定性开展业务限流、流量调度、服务降级、全链路压测等工作。

考核业务创新，说明了中台需要跟前台紧密合作，要通过业务滋养服务，实现业务的持续沉淀，抽象后可以扩大应用的场景。

服务的接入量以及前台的满意度，基本体现了中台的量化价值，服务调用的次数越多，前端越满意，反映了内部市场部的机制，完全可以通过内部结算来体现中台的价值。

从阿里的实践来看，中台让传统的IT从单纯的技术，向业务迈进一大步，唯有不断通过业务滋养系统，IT架构才能持续演进；而前台也更贴近技术，能够借助中台能力快速响应市场，而把精力可以放在不断提升客户体验上。而最终的结果，也证明了这一点，阿里的中台和前台实现了定期轮岗，这在传统的企业是很难想象的。