第一篇 中台之前

软件复杂度

软件技术发展的使命之一就是控制复杂度(Complexity)。从高级语言的产生，到结构化编程，再到面向对象编程、组件化编程等等。软件复杂度偏包括两个要点: 

- 难以理解 (难以维护和扩展) 

- 无法预测行为 

软件技术发展的使命之一就是控制复杂度(Complexity)。从高级语言的产生，到结构化编程，再到面向对象编程，以分解的方式进行的设计。主要特点是:

- 分离职责(Seperation of Concerns)

- 关注接口(定义交互)

架构

架构是设计蓝图，是对结构和组件的描述，可以让大家快速理解整个体系，指导一系列的细节设计。

架构的本质，是利用分、合、打散、重组等技术手段，对系统进行有序化重构，以达到减少系统"熵"的过程。

常见的一些架构维度

·业务架构，描述我们要做一些什么样的事情，对应的业务流程和模式是怎样的。

·应用架构，描述我们提供哪些功能以及如何去实现这些功能，可拆解为产品架构和技术架构。

·技术架构，描述我们的技术实现方案，例如微服务间的关系，中间件的使用，组件的设计等。

·数据架构，描述我们的数据逻辑模型、物理模型等。

架构演进路线

（一）单体应用

1、所有的功能集成在一个项目工程中。

2、所有的功能打一个 war 包部署到服务器。

3、应用与数据库分开部署。

4、通过部署应用集群和数据库集群来提高系统的性能

优点：

1、项目架构简单，前期开发成本低，周期短，小型项目的首选。

缺点：

1、全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。

2、系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

3、技术栈受限。

（二）SOA 架构

1、基于 SOA 的架构思想将重复公用的功能抽取为组件，以服务的方式给各各系统提供服务。

2、各各项目（系统）与服务之间采用 webservice、rpc 等方式进行通信。

3、ESB 企业服务总线作为项目与服务之间通信的桥梁

优点：

1、将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。

2、可以针对不同服务的特点制定集群及优化方案。

3、采用 ESB 减少系统中的接口耦合。

缺点：

1、系统与服务的界限模糊，不利于开发及维护。

2、虽然使用了 ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。

3、抽取的服务的粒度过大，系统与服务之间耦合性高。

（三）微服务架构

特点：

1、将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务。

2、微服务遵循单一原则。

3、微服务之间采用 RESTful 等轻量协议传输。

实现方式

1、分库分表

2、统一的服务接口

3、所有的微服务都是独立的 Java 进程跑在独立的虚拟机上

优点：

1、服务拆分粒度更细，有利于资源重复利用，提高开发效率。

2、可以更加精准的制定每个服务的优化方案，提高系统可维护性。

3、微服务架构采用去中心化思想，服务之间采用 RESTful 等轻量协议通信，相比 ESB 更轻量。

4、适用于互联网时代，产品迭代周期更短。

缺点：

1、微服务过多，服务治理成本高，不利于系统维护。

2、分布式系统开发的技术成本高（容错、分布式事务等），对团队挑战大

第二篇 中台的诞生

- 2009 年阿里巴巴成立共享事业部，开始建共享服务平台，当时不叫业务中台;

2012 年开始建数据平台，当时也不叫数据中台，数据平台在系统架构上处于底层；

-2015 年 4 月 1 日 阿里基于共享服务理念和阿里云计算平台为某大型国企打造的物装电商平台上线，大数据能力通过阿里云数据平台透出，对外提供数据服务；

-2015 年中 马云带阿里巴巴集团高管拜访了位于芬兰赫尔辛基的移动游戏公司 supersell，这家公司号称世界上最成功的的移动游戏公司；

-2015 年 12 月 7 日年 阿里集团宣布全面启动集团中台战略，构建符合 DT 时代的更具创新性、灵活性的“大中台、小前台”组织机制和业务机制；

-2018 年开始，腾讯、美团、京东、百度、字节跳动陆续跟进，发布各自的中台产品，中台逐渐进入大众视野。

阿里的共享事业部

阿里开始发展时，刚开始只有淘宝，后来意识到 B2C 模式的业务也会是电商领域重要的组成部门，所以出现了天猫，随着天猫的不断发展，逐渐独立成一个部门，但是这两套都包含商品、交易、评价、支付、物流等功能。

所以共享事业部门应运而生，希望能够把两套系统中公用的部门沉淀到共享事业部。

共享业务事业部的产生和发展确实与大多数人的期望有着很大的偏差；组织架构上共享业务事业部和淘宝天猫平级, 但从对业务的理解和业务贡献的体现来说, 淘宝和天猫相对共享事业部拥有这更多的话语权。

随着阿里电商入口不断的增加，特别是 2010 年聚划算的出现，阿里要求淘宝、天猫和 1688 必须通过共享业务对接聚划算，从而把共享业务事业部拉到和其他部门一个相对平衡的位置。

阿里双中台架构

阿里中台主要体现为由业务中台和数字中台构成的双中台，并肩扛起了所有前台业务。业务中台将后台资源进行抽象包装整合，转化为前台友好的可重用共享的核心能力，实现了后端业务资源到前台易用能力的转化。前端业务部门可以像搭积木一样调用平台上的产品技术模块，从而快速搭建新业务场景。

数据中台从后台及业务中台将数据导入，完成海量数据的存储、计算、产品化包装过程，构成企业的核心数据能力， 为前台基干数据的定制化创新和业务中台基干数据反馈的持续演进提供了强大支撑。

阿里中台建设阶段

阶段一：分布式，中间件基座

全栈分布式

√分布式调用∶HSF/Dubbo/MQ

√ 分布式 DB∶TDDL/AliSQL

√服务注册与调度∶ CongServer/Diamond

阶段二：平台化---内部是简单服务，对于业务侧就是快速上线

业务能力∶

√ 持续优化的领域模型

√ 简单复用

√ 业务热启动

技术平台∶

√ 服务高可用、稳定性治理

√ 全链路监控、分析、处理

√ 服务节点容量评估

√ 灰度变更自动化

阶段三：中台化---提升组织协同效率、研发效率

业务能力∶

√ 统一业务能力认识

√ 能力地图（可视化）

√需求结构化（规范、量化）

技术平台∶

√ 业务能力 OneID

√ 业务能力 SDK

√ 业务能力测试验证

第三篇 中台是什么？

阿里巴巴对中台的定义

阿里巴巴中间件团队，给中台架构做过一个定义∶

"中台架构，是将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新， 实现以数字化资产的形态构建企业核心差异化竞争力。"

业界对中台的定义

中台就是：“企业级的能力复用平台“

“企业级”划定了中台的范围，区分开了单系统的服务化与微服务。

“能力”指定了中台的主要承载对象，能力的抽象解释了各种各样中台的存在。

“复用”定义了中台的核心价值，过去的平台化对于易复用性并没有给予足够关注。中台的兴起，使得人们的目光更多的从平台内部，转换到平台对于前台业务的支撑上。

“平台”说明了中台的主要形式，区别于应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，对于前台业务更好的支。

第四篇 中台的价值

解决前后台脱节的问题

前台：企业前方市场的管理平台，是企业的终端用户直接使用或交互的系统。

比如像微信、QQ、淘宝这样的 APP；

-面向用户，侧重于提供服务界面和客户交互

-要求快

后台：企业内部支撑的管理平台，是企业管理核心能力的系统。比如像企

业 ERP 管理平台、企业财务管理平台等系统。

-面向企业内部的，侧重于企业内部流程支撑和数据支撑

-要求稳

中台：前台和后台之间的变速轮与缓冲，支持前台快速变化，隔离对后台的

依赖。

-持续迭代：提取、抽象、积累、演化

解决部门墙的问题

企业发展到一定程度，组织架构和层级必然不断膨胀扩张。各大事业部下各大部门，就像一个小型组织一样，各占山头，势必会出现屁股决定脑袋的现象。大企业内部各处都是墙——部门墙、业务墙、数据墙。

一些原本可以快速提供的用户服务，却需要多重对接，无法快速拿出产品方案，耗费很大的成本和极长的时间。一个原本可以共用的服务，被不同部门重复建设。

第五篇 如何理解中台？

可以将中台与现代战争的形式类比，前面是精兵小队突进（类比为前台业务发展）;其后是炮火支援与充足，灵活，统一的后勤保障和指令和协调（类比为中台）; 后方军工厂源源不断生产和供应战备物资（类比为后台）。

除此之外，还应该有∶ 与战备物资的生产相关的设备及标准，生产过程控制，生产及战斗人员培养（类比为技术及开发平台）。

中台和平台的关系？

1. 平台是一个功能完善可独立服务且支持二次开发的组建，它集合了多种功能模块；

2. 中台是跟前台和后台一起来说的，是面向业务的；平台是为了支撑各种组件，如百度做的阿波罗和 DuerOS，就是平台；

3. 中台和平台的坐标轴不一样，所以可能会出现交叉，比如：客户平台， 可能是前、中、后台都会调用，如图：

什么是技术中台？

1. 技术中台整合和包装了云基础设施，以及在其上建设的各种技术中间件，比如微服务、分布式缓存、消息队列、搜索引擎、分布式数据库等，并在此基础上建设和封装了简单易用的能力接口；

2. 开发运维一体化(DevOps)：完成“为飞行中的飞机更换发动机”一样高难度而频繁发生任务。

什么是数据中台？

1. 数据平台是长期以来阿里巴巴对内部大数据团队的叫法，数据中台是阿里面向 2B 客户提出的理念。

2. 数据中台：多种类、多来源、海量数据数据进行存储和处理，通过数据分析洞察商业规律，挖掘潜在信息，从而实现大数据价值，达到赋能于商业和创造价值的目的。

3. 数据中台是面向业务的，它不依赖于你现在数据中台的建设方法，不依赖于你现在有什么数据。

从技术视角，中台就是微服务

微服务提供可复用的功能接口，使得前端可以通过 API 调用和自动化编排(配置器)来实现持续交付和系统集成，从而构建一个快速响应前端的技术平台，微服务特点：

-分布式服务组成的系统

-按照业务而不是技术来划分组织

-做有生命的产品而不是项目

-智能化服务端点与傻瓜式服务编排

-自动化运维

-系统容错

-服务快速演化

微服务是 SOA 框架的演进，和中台的理念一致，某种意义上当我们说中台的时候就是在说微服务，尤其是在技术层面。

如何判断一个企业需不需要上中台?

企业要不要上中台，不能盲目跟风。别人家上了我也要上，你不清楚别人的战略布局、核心竞争力、战术打法，盲目去学，你不死谁死?

道理都懂，那么有没有一种方法来判断一个企业需不需要上中台?我们参照"美国国家标准技术研究院"的技术战略选择分析流程图，来给企业来做个诊断， 如图 ：

图中列出了 5 个条件判断;

1）是否大型复杂生态系统。如果企业的业态不是大型复杂生态型企业，也许企业信息化系统、ERP 就可以解决企业 IT 治理的问题。何为复杂生态型企业? 国内如∶ BATJ、海尔、华为、小米等跨行业的大型集团公司，都属于这类型企业。

2）是否业务具备不确定性。即市场环境变化快，如互联网行业，以及产业互联网相关行业，都属于这类型行业。

3）是否存在低水平重复建设。先决条件是企业体量够大，不管是白建技术团队还是跟外部第三方公司合作，是否存在重复建设，如整个企业光 CRM 就有 5 套，还不是一家公司的产品，就属于重复建设。

4）是否存在数据互联互通问题。即由于事业部制的组织架构，形成了部门墙，数据和系统也是烟囱式的，阿里的业务中台、数据中台解决的就是这样的问题。

5）是否信息技术制约企业发展。尽管企业的 IT 建设一直在持续，但是在当今产业互联网时代、人工智能时代，企业的发展已经受到严重阳碍，也许你该引入中台架构进行变革了。以上 5 个条件，任意满足 3 个及以上，我们就认为这个企业适合做中台战略升级。

第六篇 如何建设中台？

实施难易度分析

首先，我们来看，技术中台、数据中台、业务中台、组织中台，在整个中台建设实施过程中的难易度，如图 4-3 所示∶

业务中台建设路径

借鉴阿里对外部企业输出的中建设路径∶

1. 决心变革。企业内达成战略共识，一把手牵头，做总体规划、分步实施，找准切入点，解决具体业务问题。

2. 成功试点。通过分析调研，明确业务目标和范围，完成技术平台引入、中台建设方法论宣导，进行试点，梳理标杆，积累经验。

3. 持续融合。总结出适合企业自身的理念和规范，优化组织、提升中台效率。

企业中台升级的 4 个方面

阿里建议企业实施中台战略的 4 个升级∶

1、战略升级。通过中台建设，落地企业数字化战略。

2、组织升级。组织架构需要与中台架构相匹配，根据企业实际情况优化组织效率。

3、流程升级。将企业现有流程进行梳理，优化及固化企业流程，提升企业运作效率。

4、技术升级。通过互联网技术，对企业基础技术设施进行升级，降本增效。

企业中台建设有哪些坑

第一，组织架构不匹配中台架构。观察阿里 HR 组织中台，从结构来看，跟阿里的业务中台架构很像，这就是组织架构与业务架构要相匹配。

第二，需求治理缺失，大量浪费资源。建立以价值为导向的需求治理机制，以价值为导向的需求治理机制，其目的是把有限的开发资源，投入到更有价值的项目上，该机制分成几个部分。

建立需求管理闭环。以价值为导向的需求治理机制， 是在需求提报环节，提出该需求的价值预估，即这个需求将给业务带来什么样的价值，这些价值要能命量化、能甸追踪。比如，一个结算系统需求，价值是; 提升客户对账效率 20%， 上线后会来验证效果，看看是否达到预期。

第三，中台部渐渐脱离一线业务，成为鸡肋中台。

中台化的难度是∶ 技术<数据<业务<组织。因为越往后，越需要业务团队的介入，越要有业务认知才能做好中台。而中台团队，天然就是离业务远的。

各公司跟中台团队的协作，都存在很大的低效问题，一线的前台业务团队，要反复与中台沟通，才能讲清楚业务需求的背景，在大公司，跨部门协作都会徒增成本。另外对干中台业务团队来说，长期离业务很远，没有成长性，在判断需求时也不准确，很难获得前台业务团队的信任。

久而久之，就变成了中台团队纯支撑、被动接需求的状态，成为"鸡肋中台"。更大的问题在于，中台团队的价值就是整合需求、抽象能力的，在对用户和业务不够了解的前提下，做起来就会特别吃力。如果是多个前台业务的需求有了冲突，中台团队未必能做好协调，多方要反复沟通扯皮。

第四，一把手不重视中台建设。导致的问题是，未把中台建设上升到战略高度，资源投入不足，也没有决心进行组织架构变革，导致中台建设不能持之以恒。

第五，幻想着中台战略一步到位。没有中长期投入的准备，想着怎么短平快的进行建设，或者把中台战略当成向公司要资源的新理由。

第六，认为中台包治百病。这类企业把业务增长慢、企业运作效率低、组织架构臃肿、缺乏创新等问题，都想用一套方法来一次性解决掉，结果问题依然存在。中台建设，首先要定义问题，越聚焦越能够产生好的效果。

总之，企业是否要上中台，要根据企业的具体情况做分析，可根据上文"中台战略选择分析流程图"进行判断，不要盲目跟风，认为别人家上了中台，自己也要上。中台是一剂良药，对症下药能治顽疾，用药不当，会送了你的命。

总结

中台战略改变的是企业的业务形态以及业务的交付形态(从项目到产品)，那么很显然的，要不要建中台、中台的构建原则以及基本交付形态，应当是一个业务决策而并非一个技术决策；

• 没有银弹，不够痛就不要建中台

• 不是所有项目，都是中台项目

• 选择成熟的技术平台，更关注稳定性和未来

• 中台是一把手工程，全员共识是关键

• 阿里中台之所以成功，倚靠的不仅是技术，更是组织变革

• 中台本身不能解决所有问题

• 中台是一次变革，避免急功近利。

End