阿里IT架构转型的实践

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

本书主要讲了三个问题。

为什么要实施中台战略？

2015年底，阿里巴巴集团对外宣布全面启动阿里巴巴集团2018中台战略，构建符合DT时代的更具创新性、灵活性的“大中台，小前台”组织机制和业务机制。

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

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

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

• 原来的烟囱式建设会带来重复开发；
• 烟囱式系统之间的集成和协作成本高；
• 烟囱式系统不利于业务沉淀和数据的协作，这在DT时代尤为重要；
• 从业务角度，中台是为了给前台赋能，更灵活的响应业务。

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

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

阿里如何实现IT架构转型，以支撑中台战略？

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

为什么是分布式服务架构？

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

服务怎么拆？

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

• 高内聚，低耦合
• 数据完整性
• 业务可运营性
• 建设渐进性

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

数据怎么拆？

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

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

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

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

业务怎么拆？

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

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

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

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

中台的定位发生了哪些变化？

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

• 服务稳定是前提-40%
• 业务创新-25%
• 服务接入量-20%
• 前端满意度-15%

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

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

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

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

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