大家好，我是易安！今天我分享下如何落地中台架构。
前台和后台
讲中台之前，我们先来理解下前台和后台，这样，你才能更清楚中台的定位。
前台 比较好理解，指的是 面向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，再到现在的产业互联网，已经进入了深水区，很多传统企业都面临着数字化转型的挑战。架构上往中台转型，落好中台，真正发挥中台的价值，这将是一个长期的过程，也是企业业务复杂化的必然结果。
本文由 mdnice 多平台发布