什么是中台

中台发展史

无共享架构-大烟囱架构

共享架构模式

IaaS架构

PaaS架构

SaaS架构

中台架构

中台定义

中台就是“企业级的能力复用平台”-Thoughtworks 首席咨询师王健

中台是将系统的通用化能力进行打包整合，通过接口的形式赋能到外部系统，从而达到快速支持业务发展的目的-百度百科

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

理解中台概念

业务中台

业务相关：业务中台是企业内部业务相关的能力共享，IaaS、PaaS、SaaS都不是中台

跨业务：业务中台肯定是跨业务的，单个业务不需要中台这个概念

相似业务：相似的业务才可以构建在同一个中台上，差异太大的业务，中台没有意义

业务中台，是将企业内多个相似业务的通用业务能力沉淀到平台，以减少重复建设，提升业务开发效率的一种架构模式

数据中台

所有业务：数据中台应该是支持所有业务的

数据打通：业务间的数据需要打通。例如通过“统一用户ID”来关联同一用户在多个业务上的数据

数据复用（最难的部分）：不同业务间的数据可以复用，提升整体的运营效率。例如，美团可能根据你看电影的数据来向你推荐外卖的商品

数据中台，是将企业所有业务的数据沉淀到同一平台，支持业务间数据打通以及数据复用，提升企业运营效率的一种架构模式

中台的价值

业务中台

相似业务的能力共享，避免大量重复开发，提升开发效率

1. 业务相似度越高，业务中台价值越大，建议相似度达到60%以上的多个业务共建中台
2. 评估业务相似度，需要依赖业务专家，而不是一个单纯的技术工作
3. 强行将相似度低的业务塞进一个中台，不但不会提升开发效率，还会大大降低效率

数据中台

数据打通和复用，避免数据孤岛，提升运营效率

1. 使用数据中台的业务越多，数据中台价值越大
2. 数据中台的价值体现在：统一数据平台、跨业务的数据打通、跨业务的数据复用（挖掘）
3. 跨业务的数据复用：理想很丰满、现实很骨感，受限于业务熟悉度和组织结构的相关约束

中台带来的问题

小业务抱中台大腿，中台抱大业务大腿

现象

1. 业务A：爸爸级别的业务，中台KPI关键
2. 业务C：保3.5争3.75的重要抓手
3. 业务X：有P11大佬站台的业务，汇报重点
4. 其他：爱理不理，没事做就支持一下的业务

应对方法

目前没有看到很好的应对方法，中台建设最后就是一个组织结构问题（康威定律）

中台与业务的边界难以明确

现象

1. 没有任何明确的规则，都是靠人肉讨论
2. 在已有业务基础上比较容易提炼，创新业务几乎无法判断
3. 创新业务对中台KPI没有帮助，大部分情况下都会被拒掉，由业务自己实现
4. 中台适合做“组合式创新”，没法做“颠覆式创新”

应对方法

业务上和组织上目前没有很好的解决方法

中台的全流程效率并不高

现象

1. 每个业务功能都要讨论边界
2. 每个业务功能都要考虑对所有业务的影响

应对方法

业务上没有什么解决方法

中台系统落地技巧

微服务搭建业务中台

微服务不一定是中台，中台一定是微服务

用Pipeline封装不同业务流程

用SPI封装不同业务

SPI 全称 Service Provider Interface，是 Java 提供的一套用来被第三方实现或者扩展的接口，它可以用来启用框架扩展和替换组件

SPI 的作用就是为这些被扩展的 API 寻找服务实现

Pipeline和SPI方案对比

	Pipeline	SPI	对比
开发模式	中台团队负责框架和实际的业务代码实现	中台团队负责框架，业务团队负责业务代码实现	SPI看起来好一些
开发难度（非常重要）	中台团队全部搞定，开发难度低	业务团队需要熟悉中台团队的设计和原理，并且需要明确边界，开发难度高	Pipeline好一些
部署方式	统一部署	业务代码更新只需要发布jar包	SPI更好一些
业务隔离	Pipeline做业务隔离，代码级别隔离	微内核+插件做业务隔离，插件级别隔离	SPI好一些