企业大中台架构演进之路—读《阿里巴巴中台战略思考与架构实战》

本书总体上分了三部分，第一部分两章讲阿里的中台演进之路，第二部分七章从技术架构的角度分享了如何构建共享服务体系，第三部分两章介绍了阿里用中台思想帮助传统企业实现业务创新。

开篇序言提到的一句话就值得仔细揣摩：系统的建设要从生产型模型升级到运营型模型，从版本模型升级到迭代模型。运营型模型最大的优势是所有的积累都能被沉淀。仅仅从这里我们就不难理解到，中台的本质就是要解决两个问题：服务重用和统一标准。

提出这个问题是因为作者有感于烟囱式建设的弊端，当前IT行业对此已经深有体会了。烟囱式建设就是仅仅考虑当前单个业务需求，按照项目制的形式建设系统，总结起来有三个弊端：

1）重复功能建设维护带来重复投资；

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

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

前两点都是成本的增加，看得见，最后一点是对业务和发展的损害，往往看不见导致积重难返。

采用项目制建设系统还有一个弊端，IT人员在项目之间轮换，导致无法在某些特定业务领域深耕，常常对业务知其然而不知其所以然。所以在业务面前，IT部门很难有话语权，创造的价值自然有限，更遑论用技术驱动业务创新了。

要解决这些问题，基于共享服务体系建立的服务中心就应运而生。从各个前端业务中将共性和基础的功能及数据剥离出来，形成一个个按业务划分的共享服务中心。每个服务中心有自己的一套功能和数据库，供前端应用调用。服务中心将业务功能和数据做到了统一，前端系统也就没有实现系统间互通的诉求了。

这些由服务中心组成的共享服务体系，就是业务中台的核心和基础，或者说共享服务体系基本等同于业务中台。建立了业务中台，数据中台也就有了雏形，再结合数据挖掘模型、融合模型、数据服务、数据开发等，就是真正的数据中台。围绕业务中台，衍生出来的一系列服务化的中间件、服务管理调度平台、基础组件等，就形成了所谓的技术中台和基础中台。

建立企业的业务中台，除了能解决传统架构的问题外，更重要的是能为业务创新带来契机。

一般来说，企业被周边的价值链绑定，都不大可能进行颠覆式创新，大多时候需要的只是渐进式创新，这类创新一定来源于企业内部，而非外部专家，大部分企业能做的创新也大多在本行业。构建业务中台后，共享服务中心要服务各个业务，更有机会从很多的点扩展到线和面，很多在点上感知不到的问题，可以在线面上被感知到，创新的概率会大增。

另一方面，要从标准的系统中获得差异化竞争力是很难的事情，业务中台提供的各类共享服务中心，可以支撑各类新的业务探索，赋予企业快速创新和业务试错的能力。

所有的业务都从中台过，各个共享服务中心会沉淀下高质量的业务数据，同时在这一体系下能够培养精通业务的专家，两相结合为后续的大数据挖掘做好准备。

军事中的中台模型

从书中看，阿里的业务中台是从共享业务事业部的业务演变而来，更多时候是业务的高速发展在驱动。构建业务中台，在技术层面涉及到三个方面：

首先是建设原则，共享服务中心的能力包含两个层次，下层是各类中间件服务，有点类似iPaaS的能力，属于技术和基础中台。上层是业务服务能力，这里又包含了三种：依赖于接口的服务、依赖于工具的服务、依赖于数据的服务。对服务能力的定义要求共享服务中心建设遵循四条原则，这些原则在今天看来是已经不言而喻的了：

高内聚低耦合原则

数据完整性原则

业务可运营性原则（业务本身的活力、业务内部孕育出的创新想法）

渐进的建设原则

其次是分布式服务架构的搭建，这里又涉及到分布式框架的选择、数据库拆分和线性扩展的实现、异步化和缓存的使用等一系列高可用高性能的实践。阿里为此还专门自主研发了一系列的中间件和基础技术。

最后是分布式架构带来的运营问题如何解决，其实就是现在微服务架构带来的无法定位异常、单服务节点日志难以全面等。所以阿里为此打造了一系列运营平台来提升数字化运营能力和稳定性，如流量调度平台、业务开关平台、容量压测与平台（将真实的流量引流到目标机器上）、全链路压测平台、业务一致性平台等。

由于服务化前期的野蛮建设也带来了一些问题：

服务数量和业务涵盖范围越来越大；

应用和服务架构越分越细，服务越来越专业化，跨领域理解成本越来越高；

服务安全控制层缺乏。

所以，建立一套共享服务平台（SPAS）迫在眉睫，共享服务平台的理念就是服务产品化，和今天的微服务治理如出一辙：

SPAS：服务注册与发现

不得不说，阿里巴巴在技术前瞻性上做得非常好。阿里中台战略这本书值得我们企业软件服务领域的产品和技术人细细品读。