# 06 | 可扩展架构案例（三）：你真的需要一个中台吗？

    你好，我是王庆友。前面的课程，我们从单体架构开始，讲到了微服务，今天我们就接着讲最新的中台架构。

关于中台，最近比较火，你可能也听到过不少关于它的讨论，但中台究竟是什么？它能解决什么问题？相信你不一定非常清楚。今天，我就为你解决这些困惑。

讲中台之前，我们先来理解下前台和后台，这样，你才能更清楚中台的定位。

![](https://static001.geekbang.org/resource/image/7e/b2/7e8f2b10eba1efbe492ca6b10d080ab2.jpg)

**前台**比较好理解，指的是**面向C端的应用**，比如像微信、淘宝这样的应用。不过，你要注意，前台不仅仅是指前端，它还包含和前端配套的服务端。

**后台**指的是**企业内部系统**，比如ERP、CRM、仓库管理系统等等，主要是面向企业内部人员使用。对于传统企业来说，之前只有线下场景，通过内部的后台就能完成所有业务流程；而对于互联网企业，或者逐步开展线上业务的传统企业来说，同时需要前台和后台，一起协作，完成业务的闭环。

但问题是，前台和后台的特性是不一样的。**前台对外**，我们知道，消费者的需求快速多变，所以前台需要能快速响应，做到低成本试错；而**后台对内**，企业内部的业务流程不能经常变，所以后台需要稳定，不能随意调整，一旦改动，影响面广，成本很高。

简单地说，前台要快，后台要稳，因此在业务扩展时，我们经常会遇到以下两类挑战：

*   这个营销思路很棒，老板希望能马上验证，前台好改，但后台调整起来需要好几个月；
*   后台系统技术旧，性能差，接口不开放，前台对接起来很麻烦，而且一有促销活动，后台立马就挂。

第一类挑战，在互联网企业比较普遍，前台经常玩各种花样，要求快；第二类挑战，在传统企业很典型，大量的后台都是早期采购的商业套件，新的线上应用很难直接对接内部老系统。

你可以发现，前台和后台是企业IT系统的一体两面，它们需要紧密协作，共同服务于企业的业务战略。但两者对业务稳定性的要求不一样，在技术上也普遍存在脱节现象。

**所以，如何实现前后台的平滑对接，这是一个巨大的挑战，中台架构因此而生。**

接下来，我会结合自己在中台方面的实践，和你深入聊下中台的定位，以及具体的中台架构，让你可以轻松应对这个挑战。

## 中台的定位

讲中台前，我先举一个你比较熟悉的Windows系统的例子：  
![](https://static001.geekbang.org/resource/image/cc/ab/cc4f9f8a5807e03e84ee74c1680087ab.jpg)

在Windows系统里，最上面是各种桌面应用，比如Office套件等，这些是用户能够直接看到的部分；最底下是各种硬件设备，比如磁盘、内存、CPU等；中间是操作系统，它处于软硬件之间。

我们知道，理论上，桌面应用可以直接操作底层硬件，完成所需要的功能。比如，我们用低级的汇编语言去开发应用，就可以通过端口来直接操作硬件。但很显然，这种开发方式的效率很低，代码的可读性和可维护性也很差。

但是，如果我们在中间加上一层操作系统，通过操作系统向下管理硬件，屏蔽各种硬件的差异和复杂性，向上提供简洁的API接口，我们就可以使用各种高级语言，通过调用API，很方便地操作硬件了。

在这个里面，操作系统在底层硬件和上层应用之间，起到了很好的衔接作用。

我们就对照Windows操作系统的例子，来看下传统企业的IT系统。比如说麦当劳，它经过多年的信息化建设，购买了大量的商业套件，如总部使用的ERP、门店使用的收银系统等等，这些系统都属于后台的范畴，面向企业内部管理，针对的是传统的线下业务。

现在，随着麦当劳的业务发展，要往新零售转型，比如说，他们要提供线上小程序点餐服务，为消费者创造更好的用户体验。

但是，这个小程序点餐服务不是孤立的，它离不开内部系统的支撑。比如，小程序展示的菜品来自于后台ERP；小程序下的订单，会进入门店的收银系统和厨房作业系统。

那么问题来了，**这些C端应用，与内部后台系统要如何打通呢？**

理论上，C端的应用也是可以直接调用后台老系统来实现打通的，比如在麦当劳的例子中，小程序服务端可以直接调用ERP获取菜品信息，提供给小程序前端进行展示。但这个和Windows系统里的桌面应用直接控制硬件设备类似，这里前后台的直接对接是非常低效的。

我们知道，小程序服务于C端，ERP服务于B端，ERP建设在前，小程序建设在后。ERP系统在实施的时候，完全没有考虑小程序点餐场景，两者在业务流程、数据模型、技术栈、性能要求等方面，差异都很大，导致直接的对接非常困难。

而且，如果有新的C端场景进来，又要从头到尾对接一遍，重新吃一遍苦。这是一种硬着陆的方式，如果新业务上线采取这种方式，那至少需要好几个月时间，根本无法满足业务快速创新的要求。

这时，如果有个中间层来负责C端应用与内部后台系统的平滑衔接，帮助新的C端应用软着陆，这样就会非常高效。这里我对比了操作系统和新零售中台，如下图所示：

![](https://static001.geekbang.org/resource/image/f2/b9/f2da313161166386baa79f054c1d68b9.jpg)

以麦当劳为例，如果我们对内部老系统进行包装，对外提供标准的API，这样就能把旧的IT基础设施，转换成面向互联网的业务平台。然后，新的C端应用可以快速基于这个业务平台来构建，而不用关心底层老系统的实现细节。**这个中间层就是中台。**

你可以看到，中台相当于企业的商业操作系统，通过对后台的包装，为前台提供全方位的支持。这里，需要注意的是，中台不仅仅是前后台之间简单的适配器，中台本身也会落业务数据，有完整的业务规则，就像Windows操作系统一样，它在适配硬件的基础上，进一步提供内存管理、进程调度等功能，为上层应用提供体系化的支持。

对于互联网企业来说，前后台虽然是同时建设的，它们在功能上能够衔接起来，但前台求快，后台求稳。所以在这里，中台可以先承接前台的业务和数据，和前台构成C端业务的小闭环，支持业务的快速创新，等业务模式验证后，中台和后台再进一步彻底打通，构成业务的大闭环。

现在你已经了解了中台的定位，可能会想，**企业处于什么样的发展阶段，需要落地中台呢？**

接下来，我就结合一个出行平台的发展过程，来说明中台的适用性，让你能够在合适的时机选择落地中台。

## 中台的适用性

一个出行平台，当公司发展从0到1的阶段时，往往只有一条业务线，比如说出租车业务，我们直接根据它的需求落地系统即可。随着公司发展到从1到n的阶段时，业务线会逐渐增加，比如增加了快车、顺风车等业务。

这时，从系统落地的角度，我们有两种做法。

**第一种是独立地建设新业务线，这样，各个业务线并列，系统整体上是一个“川”字型的结构。**

如下图左边部分所示：

![](https://static001.geekbang.org/resource/image/51/45/511406013d3ae63a2a15acfaa1ba3545.jpg)

但是，如果各个业务线的业务逻辑非常类似，子系统之间会有大量的代码复制，这就会导致重复建设以及多头维护的问题。显然，这是非常低效的，本来我们想能尽快上线新的业务线，但结果是欲速而不达。

**第二种做法是，把各业务线中相同的核心逻辑抽取出来，通过抽象设计，实现通用化，共同服务于所有业务线的需求，系统结构整体上是一个“山”字型。**

“山”字型的上面三竖，代表各个业务线定制的应用；最底下一横，代表通用层，它把各个业务线有机粘合在一起，实现了业务逻辑和业务规则的统一，如上图中的右边所示。

**这样，我们就能一处建设，多处复用，一处修改，多处变化，从而实现最大程度的复用。**

那我们什么时候，需要从“川”字型转为“山”字形呢？

*   一方面，这和公司业务线的**数量**有关，业务线越多，意味着重复建设的成本会更大，当我们开始上第3条业务线时，就应该要考虑转到“山”字形了。
*   另一方面，也和各个业务线的**相似度**有关，相似度越高，意味着业务线之间有更多类似的逻辑，更适合“山”字形。比如，出行平台的各个出行方式相似度很高，适合“山”字形；但同一个公司的出行业务和互联网金融业务，差异比较大，就可以考虑“川”字形，而没必要把它们强行扭在一起。

所以说，中台实现了通用基础业务的平台化。从**变化速度**来看，企业基础的业务是相对固定的，而具体上层业务场景是相对多变的；从**数量**来看，基础业务数量是有限的，而具体业务场景是无限的。因此，有了完善的中台，我们就可以通过有限而比较固定的基础业务，来满足无限而快速变化的上层业务场景了。

此外，从**业务角度**来看，中台收敛了业务场景，统一了业务规则；从**系统角度**看，中台相当于操作系统，对外提供标准接口，屏蔽了底层系统的复杂性；从**数据角度**看，中台收敛了数据，比如使用同一套订单数据模型，让所有渠道的订单使用相同的订单模型，所有订单数据落到同一个订单库。

那么用一句话总结就是，**中台通过实现基础业务的平台化，实现了企业级业务能力的快速复用。**

好，接下来，我们就一起深入中台，具体了解下中台架构设计的细节。

## 如何落地一个中台架构？

通过[课程之前的分享](https://time.geekbang.org/column/article/205832)，你应该对微服务架构比较熟悉了，我也提到了中台架构紧跟着微服务架构，那么中台和微服务架构到底有什么区别和联系呢？

简单地说，我认为**中台是微服务的升级。**

在微服务架构下，我们搭建的是一个个离散的服务，如商品服务、订单服务等等。而在中台里，这些微服务升级为了商品中心、订单中心，每个中心更强调体系化，包括更好的业务通用能力，更好的系统运营能力（如监控、稳定性、性能的强化），更好的业务运营能力（比如商品中心自带配套的商品管理后台）。

每个服务中心都围绕核心业务，自成体系，成为一个微内核，这些微内核形成一个有机整体，共同构成了基础业务平台，也就是中台。**松散的微服务->共享服务体系->中台**，这是微服务架构向中台架构的演进过程。

现在大家谈论比较多的是业务中台，那我们就来具体看下一个典型的业务中台的结构。它一般包含三层，从上到下分别是**通用聚合服务层**、**通用基础业务平台**和**通用中间件平台**。

![](https://static001.geekbang.org/resource/image/11/87/115a36d4713c02698c215d6af6fdb187.jpg)

对于中台来说，基础业务能力由通用基础业务平台来实现；另外，通用聚合服务对基础业务进行组合，进一步提升了业务能力的易用性；而通用中间件平台，通过技术手段保证了业务中台的稳定性，三者一起实现了企业整体业务能力的复用。

那么关于具体如何落地中台，互联网企业和传统企业的侧重点则有所不同。

*   对于大的**互联网企业**来说，系统已经是类似于“山”字型的结构，进化到中台，更多的是各个基础服务点上的强化和面上的整合。
*   对于**传统企业**来说，系统基本上是“川”字型的结构，大量独立的商业套件组成遗留系统，落地中台是一个革命性的动作。

所以接下来，我就主要分析下传统企业如何落地中台，这样更能体现出中台的价值和落地的挑战。

首先，如下图所示，我们看下典型的传统企业中台架构设计是什么样的。

![](https://static001.geekbang.org/resource/image/e9/b1/e90d7eb2cc9118bf50e3d2d600245bb1.jpg)

**你可以看到，整个中台架构从上到下分为四个层次：**

### 渠道&应用

渠道&应用层，这是整个系统的**对外部分**，包括了各个应用的前端，如App、小程序、公众号等等，这些是需要定制的部分。同时，在对外部分，我们还会提供Open API，供上下游企业调用。

### 应用平台

应用平台是各个具体应用的**母体**，它包含了各个应用的服务端，比如小程序服务端、App服务端等等，这些服务端会针对具体场景，做流程编排和信息的聚合。

服务端和前端之间还有一个**网关**，网关实现前后端隔离，具体负责外部访问的安全验证和监控，以及内外部请求的路由和消息格式转换。

### 业务中台

业务中台是中台架构的**核心**，它包括一系列的通用基础服务，以及它上面的通用聚合服务和下面的技术平台，这个在前面已经详细介绍过了，我就不赘述了。

### 后台

后台包括两部分，第一部分是**适配插件**，用于连接商户内部系统和中台基础服务，比如，在中台的商品服务和后台ERP之间同步商品数据，在中台的会员服务和后台CRM之间同步会员信息。一般针对每个内部系统，都有一个适配插件，它起到了类似硬件驱动程序的作用，这个一般是定制化的。第二部分是**企业内部系统**，这个是企业的IT基础设施，业务最终会在这里落地。

OK，通过以上的介绍，你可以清晰地看到，**中台代表了企业核心的业务能力，它自成体系，能够为C端的互联网场景提供通用的能力，并通过各种插件和后台打通**。这样，经过中台的通用化和后台的插件适配后，我们最终就把企业的后台老系统，包装成一个面向互联网的平台，可以快速地给C端赋能。

## 总结

中台是从企业的业务战略高度，来考虑企业IT系统的建设，它的目标是实现企业整体业务能力的复用。从落地的角度看：

*   **对于互联网企业来说**，有大量微服务做基础，往中台转是改良，目的是更好地衔接前台和后台，实现业务的快速创新；
*   **对于传统企业来说**，内部有大量的遗留系统，落地中台是革命，目的是盘活老系统，全面实现企业的数字化转型。

互联网发展到现在，从最初的电商，到O2O，再到现在的产业互联网，已经进入了深水区，很多传统企业都面临着数字化转型的挑战。架构上往中台转型，落好中台，真正发挥中台的价值，这将是一个长期的过程，也是企业业务复杂化的必然结果。

通过今天的分享，相信你对中台有了更深入的理解，对是否要往中台转型，你也能够做出更好的判断了。

**最后，给你留一道思考题**：现在中台很热，我们经常听到很多中台名词，它们分别是什么定位呢？

欢迎你在留言区与大家分享你的答案，如果你在学习和实践的过程中，有什么问题或者思考，也欢迎给我留言，我们一起讨论。感谢阅读，我们下期再见。