大家好,我是易安!今天我分享下如何落地中台架构。
前台和后台
讲中台之前,我们先来理解下前台和后台,这样,你才能更清楚中台的定位。
![alt](https://i-blog.csdnimg.cn/blog_migrate/d893db5ae1dd133cec1941db39389fff.png)
前台 比较好理解,指的是 面向C端的应用,比如像微信、淘宝这样的应用。不过,你要注意,前台不仅仅是指前端,它还包含和前端配套的服务端。
后台 指的是 企业内部系统,比如ERP、CRM、仓库管理系统等等,主要是面向企业内部人员使用。对于传统企业来说,之前只有线下场景,通过内部的后台就能完成所有业务流程;而对于互联网企业,或者逐步开展线上业务的传统企业来说,同时需要前台和后台,一起协作,完成业务的闭环。
但问题是,前台和后台的特性是不一样的。 前台对外,我们知道,消费者的需求快速多变,所以前台需要能快速响应,做到低成本试错;而 后台对内,企业内部的业务流程不能经常变,所以后台需要稳定,不能随意调整,一旦改动,影响面广,成本很高。
简单地说,前台要快,后台要稳,因此在业务扩展时,我们经常会遇到以下两类挑战:
-
这个营销思路很棒,老板希望能马上验证,前台好改,但后台调整起来需要好几个月; -
后台系统技术旧,性能差,接口不开放,前台对接起来很麻烦,而且一有促销活动,后台立马就挂。
第一类挑战,在互联网企业比较普遍,前台经常玩各种花样,要求快;第二类挑战,在传统企业很典型,大量的后台都是早期采购的商业套件,新的线上应用很难直接对接内部老系统。
你可以发现,前台和后台是企业IT系统的一体两面,它们需要紧密协作,共同服务于企业的业务战略。但两者对业务稳定性的要求不一样,在技术上也普遍存在脱节现象。
所以,如何实现前后台的平滑对接,这是一个巨大的挑战,中台架构因此而生。
操作系统案例
讲中台前,我先举一个你比较熟悉的Windows系统的例子:
![alt](https://i-blog.csdnimg.cn/blog_migrate/ac727319fad21735cc7ab64cc9599710.png)
在Windows系统里,最上面是各种桌面应用,比如Office套件等,这些是用户能够直接看到的部分;最底下是各种硬件设备,比如磁盘、内存、CPU等;中间是操作系统,它处于软硬件之间。
我们知道,理论上,桌面应用可以直接操作底层硬件,完成所需要的功能。比如,我们用低级的汇编语言去开发应用,就可以通过端口来直接操作硬件。但很显然,这种开发方式的效率很低,代码的可读性和可维护性也很差。
但是,如果我们在中间加上一层操作系统,通过操作系统向下管理硬件,屏蔽各种硬件的差异和复杂性,向上提供简洁的API接口,我们就可以使用各种高级语言,通过调用API,很方便地操作硬件了。
在这个里面,操作系统在底层硬件和上层应用之间,起到了很好的衔接作用。
我们就对照Windows操作系统的例子,来看下传统企业的IT系统。比如说麦当劳,它经过多年的信息化建设,购买了大量的商业套件,如总部使用的ERP、门店使用的收银系统等等,这些系统都属于后台的范畴,面向企业内部管理,针对的是传统的线下业务。
现在,随着麦当劳的业务发展,要往新零售转型,比如说,他们要提供线上小程序点餐服务,为消费者创造更好的用户体验。
但是,这个小程序点餐服务不是孤立的,它离不开内部系统的支撑。比如,小程序展示的菜品来自于后台ERP;小程序下的订单,会进入门店的收银系统和厨房作业系统。
那么问题来了, 这些C端应用,与内部后台系统要如何打通呢?
理论上,C端的应用也是可以直接调用后台老系统来实现打通的,比如在麦当劳的例子中,小程序服务端可以直接调用ERP获取菜品信息,提供给小程序前端进行展示。但这个和Windows系统里的桌面应用直接控制硬件设备类似,这里前后台的直接对接是非常低效的。
我们知道,小程序服务于C端,ERP服务于B端,ERP建设在前,小程序建设在后。ERP系统在实施的时候,完全没有考虑小程序点餐场景,两者在业务流程、数据模型、技术栈、性能要求等方面,差异都很大,导致直接的对接非常困难。
而且,如果有新的C端场景进来,又要从头到尾对接一遍,重新吃一遍苦。这是一种硬着陆的方式,如果新业务上线采取这种方式,那至少需要好几个月时间,根本无法满足业务快速创新的要求。
这时,如果有个中间层来负责C端应用与内部后台系统的平滑衔接,帮助新的C端应用软着陆,这样就会非常高效。这里我对比了操作系统和新零售中台,如下图所示:
![alt](https://i-blog.csdnimg.cn/blog_migrate/df3a23aff84c296e3cf1c935afb712c7.png)
以麦当劳为例,如果我们对内部老系统进行包装,对外提供标准的API,这样就能把旧的IT基础设施,转换成面向互联网的业务平台。然后,新的C端应用可以快速基于这个业务平台来构建,而不用关心底层老系统的实现细节。 这个中间层就是中台。
你可以看到,中台相当于企业的商业操作系统,通过对后台的包装,为前台提供全方位的支持。这里,需要注意的是,中台不仅仅是前后台之间简单的适配器,中台本身也会落业务数据,有完整的业务规则,就像Windows操作系统一样,它在适配硬件的基础上,进一步提供内存管理、进程调度等功能,为上层应用提供体系化的支持。
对于互联网企业来说,前后台虽然是同时建设的,它们在功能上能够衔接起来,但前台求快,后台求稳。所以在这里,中台可以先承接前台的业务和数据,和前台构成C端业务的小闭环,支持业务的快速创新,等业务模式验证后,中台和后台再进一步彻底打通,构成业务的大闭环。
现在你已经了解了中台的定位,可能会想, 企业处于什么样的发展阶段,需要落地中台呢?
接下来,我就结合一个出行平台的发展过程,来说明中台的适用性,让你能够在合适的时机选择落地中台。
为什么需要中台
一个出行平台,当公司发展从0到1的阶段时,往往只有一条业务线,比如说出租车业务,我们直接根据它的需求落地系统即可。随着公司发展到从1到n的阶段时,业务线会逐渐增加,比如增加了快车、顺风车等业务。
这时,从系统落地的角度,我们有两种做法。
第一种是独立地建设新业务线,这样,各个业务线并列,系统整体上是一个“川”字型的结构。
如下图左边部分所示:
![alt](https://i-blog.csdnimg.cn/blog_migrate/72620ab8d6c29cbadbe38dece7371bbd.png)
但是,如果各个业务线的业务逻辑非常类似,子系统之间会有大量的代码复制,这就会导致重复建设以及多头维护的问题。显然,这是非常低效的,本来我们想能尽快上线新的业务线,但结果是欲速而不达。
第二种做法是,把各业务线中相同的核心逻辑抽取出来,通过抽象设计,实现通用化,共同服务于所有业务线的需求,系统结构整体上是一个“山”字型。
“山”字型的上面三竖,代表各个业务线定制的应用;最底下一横,代表通用层,它把各个业务线有机粘合在一起,实现了业务逻辑和业务规则的统一,如上图中的右边所示。
这样,我们就能一处建设,多处复用,一处修改,多处变化,从而实现最大程度的复用。
那我们什么时候,需要从“川”字型转为“山”字形呢?
-
一方面,这和公司业务线的 数量 有关,业务线越多,意味着重复建设的成本会更大,当我们开始上第3条业务线时,就应该要考虑转到“山”字形了。 -
另一方面,也和各个业务线的 相似度 有关,相似度越高,意味着业务线之间有更多类似的逻辑,更适合“山”字形。比如,出行平台的各个出行方式相似度很高,适合“山”字形;但同一个公司的出行业务和互联网金融业务,差异比较大,就可以考虑“川”字形,而没必要把它们强行扭在一起。
所以说,中台实现了通用基础业务的平台化。从 变化速度 来看,企业基础的业务是相对固定的,而具体上层业务场景是相对多变的;从 数量 来看,基础业务数量是有限的,而具体业务场景是无限的。因此,有了完善的中台,我们就可以通过有限而比较固定的基础业务,来满足无限而快速变化的上层业务场景了。
此外,从 业务角度 来看,中台收敛了业务场景,统一了业务规则;从 系统角度 看,中台相当于操作系统,对外提供标准接口,屏蔽了底层系统的复杂性;从 数据角度 看,中台收敛了数据,比如使用同一套订单数据模型,让所有渠道的订单使用相同的订单模型,所有订单数据落到同一个订单库。
那么用一句话总结就是, 中台通过实现基础业务的平台化,实现了企业级业务能力的快速复用。
好,接下来,我们就一起深入中台,具体了解下中台架构设计的细节。
中台架构如何落地?
中台架构紧跟着微服务架构,那么中台和微服务架构到底有什么区别和联系呢?
简单地说,我认为 中台是微服务的升级。
在微服务架构下,我们搭建的是一个个离散的服务,如商品服务、订单服务等等。而在中台里,这些微服务升级为了商品中心、订单中心,每个中心更强调体系化,包括更好的业务通用能力,更好的系统运营能力(如监控、稳定性、性能的强化),更好的业务运营能力(比如商品中心自带配套的商品管理后台)。
每个服务中心都围绕核心业务,自成体系,成为一个微内核,这些微内核形成一个有机整体,共同构成了基础业务平台,也就是中台。 松散的微服务->共享服务体系->中台,这是微服务架构向中台架构的演进过程。
现在大家谈论比较多的是业务中台,那我们就来具体看下一个典型的业务中台的结构。它一般包含三层,从上到下分别是 通用聚合服务层、 通用基础业务平台 和 通用中间件平台。
![alt](https://i-blog.csdnimg.cn/blog_migrate/c4b42a5dec3353e5e33e0a8765b8b75d.png)
对于中台来说,基础业务能力由通用基础业务平台来实现;另外,通用聚合服务对基础业务进行组合,进一步提升了业务能力的易用性;而通用中间件平台,通过技术手段保证了业务中台的稳定性,三者一起实现了企业整体业务能力的复用。
![alt](https://i-blog.csdnimg.cn/blog_migrate/591ea03bf0f9de19917977052bbb32e8.png)
那么关于具体如何落地中台,互联网企业和传统企业的侧重点则有所不同。
-
对于大的 互联网企业 来说,系统已经是类似于“山”字型的结构,进化到中台,更多的是各个基础服务点上的强化和面上的整合。 -
对于 传统企业 来说,系统基本上是“川”字型的结构,大量独立的商业套件组成遗留系统,落地中台是一个革命性的动作。
所以接下来,我就主要分析下传统企业如何落地中台,这样更能体现出中台的价值和落地的挑战。
首先,如下图所示,我们看下典型的传统企业中台架构设计是什么样的。
你可以看到,整个中台架构从上到下分为四个层次:
渠道&应用
渠道&应用层,这是整个系统的 对外部分,包括了各个应用的前端,如App、小程序、公众号等等,这些是需要定制的部分。同时,在对外部分,我们还会提供Open API,供上下游企业调用。
应用平台
应用平台是各个具体应用的 母体,它包含了各个应用的服务端,比如小程序服务端、App服务端等等,这些服务端会针对具体场景,做流程编排和信息的聚合。
服务端和前端之间还有一个 网关,网关实现前后端隔离,具体负责外部访问的安全验证和监控,以及内外部请求的路由和消息格式转换。
业务中台
业务中台是中台架构的 核心,它包括一系列的通用基础服务,以及它上面的通用聚合服务和下面的技术平台。
后台
后台包括两部分,第一部分是 适配插件,用于连接商户内部系统和中台基础服务,比如,在中台的商品服务和后台ERP之间同步商品数据,在中台的会员服务和后台CRM之间同步会员信息。一般针对每个内部系统,都有一个适配插件,它起到了类似硬件驱动程序的作用,这个一般是定制化的。第二部分是 企业内部系统,这个是企业的IT基础设施,业务最终会在这里落地。
OK,通过以上的介绍,你可以清晰地看到, 中台代表了企业核心的业务能力,它自成体系,能够为C端的互联网场景提供通用的能力,并通过各种插件和后台打通。这样,经过中台的通用化和后台的插件适配后,我们最终就把企业的后台老系统,包装成一个面向互联网的平台,可以快速地给C端赋能。
总结
中台是从企业的业务战略高度,来考虑企业IT系统的建设,它的目标是实现企业整体业务能力的复用。从落地的角度看:
-
对于互联网企业来说,有大量微服务做基础,往中台转是改良,目的是更好地衔接前台和后台,实现业务的快速创新; -
对于传统企业来说,内部有大量的遗留系统,落地中台是革命,目的是盘活老系统,全面实现企业的数字化转型。
互联网发展到现在,从最初的电商,到O2O,再到现在的产业互联网,已经进入了深水区,很多传统企业都面临着数字化转型的挑战。架构上往中台转型,落好中台,真正发挥中台的价值,这将是一个长期的过程,也是企业业务复杂化的必然结果。
本文由 mdnice 多平台发布