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

前面，我们从单体架构开始，讲到了微服务，今天我们就接着讲最新的中台架构。

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

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

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

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

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

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

这个营销思路很棒，老板希望能马上验证，前台好改，但后台调整起来需要好几个月；

后台系统技术旧，性能差，接口不开放，前台对接起来很麻烦，而且一有促销活动，后台立马就挂。

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

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

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

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

中台的定位

讲中台前，先举一个比较熟悉的 Windows 系统的例子：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

中台的适用性

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

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

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

如下图左边部分所示：

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

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

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

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

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

一方面，这和公司业务线的数量有关，业务线越多，意味着重复建设的成本会更大，当我们开始上第 3 条业务线时，就应该要考虑转到“山”字形了。

另一方面，也和各个业务线的相似度有关，相似度越高，意味着业务线之间有更多类似的逻辑，更适合“山”字形。比如，出行平台的各个出行方式相似度很高，适合“山”字形；但同一个公司的出行业务和互联网金融业务，差异比较大，就可以考虑“川”字形，而没必要把它们强行扭在一起。

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

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

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

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

如何落地一个中台架构？

通过课程之前的分享，应该对微服务架构比较熟悉了，也提到了中台架构紧跟着微服务架构，那么中台和微服务架构到底有什么区别和联系呢？

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

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

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

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

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

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

对于大的互联网企业来说，系统已经是类似于“山”字型的结构，进化到中台，更多的是各个基础服务点上的强化和面上的整合。

对于传统企业来说，系统基本上是“川”字型的结构，大量独立的商业套件组成遗留系统，落地中台是一个革命性的动作。

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

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

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

渠道 & 应用

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

应用平台

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

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

业务中台

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

后台

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

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

总结

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

对于互联网企业来说，有大量微服务做基础，往中台转是改良，目的是更好地衔接前台和后台，实现业务的快速创新；

对于传统企业来说，内部有大量的遗留系统，落地中台是革命，目的是盘活老系统，全面实现企业的数字化转型。

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

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