深入浅出话中台

这两年中台很火，已经代替微服务成为架构首选，涌现出各种各样的中台名词，业务中台、数据中台、技术中台、算法中台等，让人眼花缭乱，稍微大点的互联网公司都号称在做中台。本人从去年开始，做过类似的事情，这里结合自己的实践，谈谈对中台的理解，希望能够帮助大家更清晰地了解中台，一家之言，仅供参考。

本文的内容包括：

1. 什么是中台
2. 中台和微服务的区别
3. 为什么要做中台
4. 深入中台架构

1. 什么是中台

既然讲中台，必然还有前台和后台。前台很好理解，指的是面向 C 端的应用，包括前端 (如 App/ 小程序) 和对应的服务端。至于后台，很多人把它等同于管理后台，比如商品管理后台，负责商品定义 / 上下架等，提供给内部运营人员使用，这可能不够准确。

简单来说，对于一个交易系统，前台对应用户能看到的部分，如商品浏览和下单，属于接单的部分；后台对应履单部分，如仓库拣货 / 配送 / 财务结算 / 采购补货等，属于实际干活的，由企业内部人员负责，处于一个交易处理流程的后端。

在传统企业，没有在线的前台，基本是线下手工接单，内部信息管理系统基本都属于履单范畴，例如 ERP、CRM、采购系统、仓库管理系统，财务系统等，这些系统属于一般意义上的后台概念。

在互联网企业，因为系统一般是自己开发，管理后台既包含面向前台销售的功能，如商品上下架和促销管理，也包含面向履单部分，比如配送、采购、财务结算，所以互联网企业的管理后台并不简单等同于履单后台。

接单和履单之间还有一系列事情要做，包括生成订单时的优惠计算 / 创建实际的订单 / 支付 / 库存扣减等, 这部分功能属于交易逻辑的核心。在简单场景下，前台应用包含这部分功能，在复杂的场景下，就有必要把这部分独立出来，构成独立的中台，为前台减负。

一些文章笼统地介绍中台是用来连接前台和后台的，这个值得商榷。如果管理后台就是后台，那没有连接的必要，因为管理后台本身就是系统的附属部分，和前台属于一体两面。至于履单后台，前台接单系统和后台履单系统设计时就是打通的，也不需要额外定义一个中台来连接两者。互联网企业的中台更多的是基础业务下沉，实现多业务场景共享，但在传统企业，后台系统清晰地存在，中台确实起到连接后台 (内部老系统) 和前台 (新的 C 端应用) 的作用，所以互联网企业的中台和传统企业的中台定位和侧重点是有差异的，这个下文会展开介绍。

为了更好地理解中台，这里举个形象的例子：

最上面是各种具体的桌面应用，比如 office 套件，最底下是各种硬件设备，磁盘 / 内存 /CPU 等。

桌面应用能不能直接操纵底层硬件设备完成功能？理论上是可以的，比如在应用里嵌入汇编语言直接操作硬件，但显然开发效率低，可维护性很差。如果中间加一层操作系统进行转换，向下管理硬件，向上提供简洁的 API，应用开发就非常方便，这里操作系统类似中台的定位。

对于大型传统零售企业 (上图右边部分)，企业经过多年信息化建设，购买了大量的商业套装软件，形成内部 IT 基础设施，现在要往新零售转型，理论上 C 端的应用可以直接调用老系统的 API(如 SAP 产品提供一定的开放能力) 来实现功能打通。但和桌面应用直接控制电脑硬件设备类似，这两者直接对接是低效的，两者的服务对象 (2C 和 2B)/ 数据模型 / 技术栈 / 实时性要求差异很大，而且新的应用进来，又要从头到尾对接一遍，新业务上线，至少需要大半年的时间。

这时如果有个中间层负责桥接和转换，就非常方便。C 端应用可以快速基于这个中间层构建，不用关心底层遗留系统的实现细节。这个中间层就是中台，起到类似操作系统的作用，把旧的基础设施转换成面向互联网的基础平台，而且这个平台非常通用，新业务可以快速对接，短时间搞定上线。传统企业在做全面数字化转型时，这样的一个中台必不可少。

2. 中台和微服务的区别

中台源于大型互联网企业，这些系统一般是分布式的微服务架构，那么中台和微服务架构有什么区别呢？

简单地说，我认为中台是微服务的升级，原来只是一个个离散的服务，只负责提供接口功能，如商品服务 / 订单服务 / 权限服务，在中台里，升级为商品中心 / 订单中心，每个中心更强调体系，包括更好的边界划分和业务抽象，更好地监控和系统运营能力 (稳定性 / 故障定位)，更好的业务运营能力 (比如商品中心自带商品管理后台，支持基础商品定义)。每个服务中心围绕核心业务，自成体系，成为一个微内核，这些微内核既相互独立，又形成一个整体，共同构成基础业务平台，也即中台。松散的微服务 -> 共享服务体系 -> 中台，这是微服务架构和中台的区别和联系。

现在大家谈的最多的是业务中台，我认为一个典型的业务中台包含 3 层：

对于中台来说，完善的基础业务功能由通用基础业务平台实现；通用聚合服务进一步提升易用性 ; 通用中间件平台保证系统的稳定性。

除了业务中台，提的比较多的是数据中台，数据中台也是整合数据能力，可以高效地给业务赋能，比如智能推荐，千人千面，精准营销等。

补充说明下，这里通用中间件平台和技术中台一个概念，我觉得没有必要单独叫技术中台，不带业务的中台是没有灵魂的，不能叫中台。同理内容中台的说法是合适的，但算法中台就不合适，大家可以用这个原则区分各种中台的真伪。

3. 为什么要做中台

软件架构从单体架构，到分布式 SOA，到微服务，到中台架构，这都是业务复杂化的结果，架构好比生产关系，业务是生产力，架构一定要随着业务发展而演化。

0 到 1 阶段，只有一条业务线，比如出租车业务，直接根据需求实现即可。从 1 到 n 阶段，业务线逐渐增加，比如快车 / 顺风车。

这时系统有两种做法，第一种是新业务线还是单独实现，多个业务线之家是相互独立的，系统结构整体上是”川”字型，如下图所示。但如果业务线类似，它们的核心逻辑（地图 / 调度 / 订单支付）也是类似的，子系统之间有大量的代码复制和多地维护，这是非常低效的。

第二种做法是把核心逻辑单独抽取出来，做好通用化，共同服务于所有业务线的需求，此时对于各个业务线系统而言，包括自身的应用层和通用层两部分，定制的东西在应用层解决，共享的东西由通用层提供，再通过编排共享逻辑完成业务流程。系统结构整体上是”山”字型，这个通用层就是山字最底下一横，把各个业务线有机粘合在一起，共享业务逻辑和统一业务规则，实现最大程度的复用。

当然搭建山字形是有难度的，什么时候转型为“山”字形？ 一方面和 n 值有关，比如 n>=3 时，应该要考虑转到山字形，另一个因素和各个业务线的相似度有关，相似度高更适合”山”字形，比如电商的 C2C 和 B2C 业务；差异比较大，适合”川”字形，比如电商业务和互联网金融业务，没必要强行扭在一起。

从业务角度看，中台代表通用的基础业务，一个企业基础的业务能力和业务规则是相对稳固和清晰的，各个业务线可以认为具体业务场景，如小程序下单 / 三方外卖等相对复杂和多变，但可以通过组装各个基础业务，快速满足业务场景需求。对于新的业务来说，基础的东西已经差不多有了，只需要少量针对场景的定制开发。总的来说，中台收敛了业务场景，统一了业务规则，比如各个渠道的订单都归到中台的订单服务，遵循类似的订单状态流转和履单过程。

基础业务是有限的，业务场景是无限的，特别是在移动互联网和全面数字化转型的大背景下，传统企业需要开拓大量新渠道，搭建中台，可以很好地通过有限的基础业务满足无限的业务场景。

从系统角度看，中台相当于商业操作系统，提供标准接口给上层应用，对于传统企业来说，中台之下还有明确的后台，中台很好地把前端应用 (面向互联网) 和企业遗留系统 (面向内部管理) 衔接起来，屏蔽底层系统的复杂性和各种适配工作。

从数据角度看，中台收敛业务场景的同时，也收敛了数据 比如自有小程序的订单和外卖订单统一到一个订单库，使用同一套数据模型（具体用到的字段可能略有差异），这为后续的数据中台搭建打下良好基础。

4. 深入中台架构

大一点的互联网企业，系统已经是类中台的“山”字型架构，更多的是局部强化和整合。对于传统企业来说，系统基本是”川”字型，大量相互独立的商业套件组成遗留系统。如何基于这些系统搭建中台挑战很大，所以这里更多剖析传统企业的中台架构。

下图是比较典型的传统企业中台架构：

整个架构从上到下分 4 层：

1. 渠道 & 应用

这是整个系统对外部分，包括各个应用的前端，如 APP/ 小程序 / 公众号, 这些是需要定制部分。同时提供 Open API，对外部企业输出业务能力。

1. 应用平台

应用平台是各个实际应用的母体，首先包含各个应用的服务端，比如小程序服务端 /APP 服务端，这些服务端针对具体场景，做流程编排和信息的聚合。

还有各个比较独立的应用模块，如搜索 / 推荐 / 评论 / 拼团，这些模块不强调各个业务线之间共享，只是作为独立模块从服务端剥离出来，方便维护。

还有一些相对简单服务，不属于基础共享业务范畴，比如和具体某个业务相关的配置数据，也通过服务的方式封装。

网关实现前后端隔离，包括外部访问的安全验证和监控，以及内部路由和消息格式转换。

1. 业务中台

由一系列的通用基础服务构成，这些基础服务边界清晰，相互独立，没有调用关系。有些业务场景需要跨服务的数据，比如下单，需要同时涉及商品服务 / 库存服务 / 订单服务，一般在基础服务之上有一层聚合服务，通过组合这些基础服务，形成更大粒度的功能接口，供应用平台调用。

中台最底下是技术中间件，包括消息推送，短信邮件，数据访问等，稳定性主要由这部分保证。

1. 后台

包括两部分，适配插件用于连接商户内部系统和中台基础服务，比如在中台商品服务和后台 ERP 之间同步商品和库存数据，在会员服务和 CRM 之间同步会员信息。一般针对每个内部系统有一个适配插件，适配插件起到类似硬件驱动程序的作用，这个定制化程度比较高。

商户内部系统就不展开，各个企业的情况不同。

架构图最右边是三方 API 对接，典型的如微信 / 支付宝的对接，美团 / 饿了吗三方外卖对接，天猫 / 京东的电商平台对接。这个对接前端 / 应用平台 / 中台都会涉及。

5. 总结

架构向中台转型是业务复杂化发展的必然结果，中台提供了多方面的价值，不管互联网企业还是传统企业，中台的大方向都是没错的。

对于互联网企业，有基础，往中台靠是改良，需要注意的是，根据当前的业务发展阶段，平衡投入和产生比，适时启动中台改造。

对于传统企业，内部 IT 基础设施和面向互联网的应用差异很大，往中台转是革命性动作。如何落地中台战略既需要顶层思考，又需要结合实际，做各种平衡和妥协。做的不好，效果适得其反，所谓不做中台等死，做中台马上死，从这个意义上说，是否上中台，有点类似十几年前上大型 ERP，需要务实的评估，拒绝形式主义。

后续会介绍关于中台的更多内容，敬请期待：

1. 服务化成熟度模型
2. 企业信息系统成熟度模型
3. 什么时候适合做中台
4. 中台有哪些挑战
5. 中台的落地步骤

作者介绍：