防止断更 请务必加首发微信：171 6143665
关闭
讲堂
部落
算法训练营
前端进阶训练营
企业服务
极客商城
客户端下载
兑换中心
渠道合作
推荐作者
06 | 可扩展架构案例（三）：你真的需要一个中台吗？
2020-03-04 王庆友
架构实战案例解析
进入课程
讲述：王庆友
时长17:40大小16.19M
你好，我是王庆友。前面的课程，我们从单体架构开始，讲到了微服务，今天我们就接着讲最新的中台架构。
关于中台，最近比较火，你可能也听到过不少关于它的讨论，但中台究竟是什么？它能解决什么问题？相信你不一定非常清楚。今天，我就为你解决这些困惑。
讲中台之前，我们先来理解下前台和后台，这样，你才能更清楚中台的定位。
前台比较好理解，指的是面向 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，再到现在的产业互联网，已经进入了深水区，很多传统企业都面临着数字化转型的挑战。架构上往中台转型，落好中台，真正发挥中台的价值，这将是一个长期的过程，也是企业业务复杂化的必然结果。
通过今天的分享，相信你对中台有了更深入的理解，对是否要往中台转型，你也能够做出更好的判断了。
最后，给你留一道思考题：现在中台很热，我们经常听到很多中台名词，它们分别是什么定位呢？
欢迎你在留言区与大家分享你的答案，如果你在学习和实践的过程中，有什么问题或者思考，也欢迎给我留言，我们一起讨论。感谢阅读，我们下期再见。
© 加微信：642945106 发送“赠送”领取赠送精品课程 发数字“2”获取众筹列表。
上一篇
05 | 可扩展架构案例（二）：App服务端架构是如何升级的？
下一篇
07 | 可复用架构：如何实现高层次的复用？
写留言
171614 3665 拼课微信(16)
默然 置顶2020-03-04王老师，您好！我所在的公司是传统行业，目前想从传统企业转型到数字化企业，目前后台基础平台架构也未成型，一切从0造1的现状，研发团队根据业务分成了多个业务线，想做业务数据双中台，具体实施步骤，您有什么好的建议吗？期待老师的回复，谢谢展开作者回复: 具体情况不清楚，只能从大的方面来说，之前传统企业落地一些系统，只是初步做到核心部门的信息化，系统之间的信息是割裂的。全面数字化要求全局一盘棋，还要涵盖直接面向用户的场景。建议的做法是，首先梳理下企业有哪些核心的业务能力，比尔商品，订单，促销，库存等，然后考虑怎么基于现有的各个系统显式地构建这些能力，然后把这些能力输出给消费端，并通过这些核心能力实现后台系统的打通，形成有机整体。
1
2020-03-04先抢个沙发，1.这两年中台的概念比较火，但是也不能忙目跟风，2.是中台思想有点像设计模式里面的适配器模式，做了一个中间层，把前台与后台耦合开展开 3
2020-03-04https://www.processon.com/view/link/5e51378ce4b0c037b5f9d1e3 学习整理更新 2
2020-03-04不得不说，之前一直把前后台也理解成了前后端。。。展开 2
2020-03-05最常听到的名词是“大中台，小前台”，大中台是一个稳定的，可共享，可复用的的能力中心；小前台是为了适应变化，求快。展开 1
2020-03-05老师，后台和中台之间的适配器，主要一个核心功能就是从后台同步数据给中台，之所以这样做是因为传统后台的内部系统如erp等主要给内部员工操作界面使用，从设计初衷看不适合开放api给外部直接调用，所以中台就通过适配器把后台的数据同步过来，有了后台的数据，中台就可以完整且自由对前台提供高性能、高并发的服务了，不知道我理解的正确不？请老师指教☺展开作者回复: 差不多，同步是双向的，中台也要往后台同步数据，比如中台把订单推送给收银系统。
1 1
2020-03-04老师您好，想问下业务中台下的技术平台(中间件平台)和所谓的技术中台有什么区别作者回复: 同一个意思，我们讲中台是企业级能力复用，业务的复用已经包含技术的复用，没必要单独提技术中台。
1
2020-03-04解决企业遇到的问题，总的来说就是加中间层，一层不行，就多层<没有加中间层解决不了的问题😄> 1
2020-03-04隔壁王健老师一语中的，中台是企业级能力复用平台展开 1
2020-03-09业务没有共性（比如教育行业的搜题业务、直播业务、作业检查业务、同步学习业务等，无论从业务还是流程上都没有共性），但期望通过技术复用提高研发效率、节省成本（引入第三方技术的成本），这种情况适合做中台吗？展开作者回复: 技术平台该做的要做，统一使用中间件，总结使用的坑，落地统一的监控等等。但这个到不了中台的层面，不包含业务的中台提法，我个人觉得有点勉强。
2020-03-07老师你好，请教下流程编排一般是怎么实现，有现成的框架吗？作者回复: 一般不建议在框架或中间件里做流程编排，否则业务逻辑不透明，就像以前的esb一样。现在都是直接建一个流程服务来实现。
2020-03-0720200307 传统 互联网 企业级能力复用平台展开
2020-03-07关于各业务系统提供价值输出到适配层，个人的体会是输出价值的质量取决于各业务系统的配合程度。
此外，业务系统自己往往也不清楚输出的价值是如何被使用，去理解如何被使用的意愿也不高，可能存在少输出和乱输出，还是需要高层统筹规划各业务系统。展开- 2020-03-07老师您好，我想问个关于异构系统间适配层落地的问题。假设有三个业务系统，分别使用java、python和c++实现，那适配层由谁来提供？如果由专职人员负责，那意味着这批人要对各个系统的实现和业务都有很深的理解才能落地准确，对人员要求高，感觉风险较大。如果由各个业务系统提供，必然增加工作量，往往出于利益考虑，阻力较大。老师有没有落地的经验和教训分享下？展开
作者回复: 由每个系统自己提供http服务，让业务系统转变观念，不是别人要对接你，而是你要把业务价值输出去。
2020-03-05应用平台层怎么横向拆分？按照什么纬度拆分？一个电商一般要拆分多少个类型应用？比如会有购物车应用，商品详情应用？订单详情应用？展开作者回复: 应用平台是对应各个前端的服务端集合，还包括一些不属于共享服务的简单业务服务，这部分就按照具体前端的业务来，就象你这里说的购物车服务，商品详情页应用。
应用直接负责提供给前端api接口。
2020-03-04老师您好，在提到传统企业改造为中台架构时，后台提到适配器插件，我的理解是每个后台的IT基础服务，提供对外访问的服务API，从而对外开放服务的能力，不知道理解是否正确？作者回复: 适配器是单独的一层，负责打通后台和中台，具体一般还是中台负责提供，比如后台把数据定时导出到单独的数据库甚至文件，然后一个单独的适配器应用去读取，放到中台也是一种落地方式。如果后台直接有接口，适配器直接访问那是最好
