一文看懂中台架构
架构大道
分享
微信分享二维码
微信“扫一扫”,打开网页后点击屏幕右上角分享按钮

作者:王庆友

来源:架构大道

最近中台很火,已经代替微服务成为架构首选,涌现出各种各样的中台名词,业务中台、数据中台、技术中台、算法中台等,让人眼花缭乱,稍微大点的互联网公司都号称在做中台。本人从去年开始,在做类似的事情,这里结合自己的实践,谈谈对中台的理解,希望能够帮助大家更清晰地了解中台,一家之言,仅供参考。

什么是中台

既然讲中台,必然还有前台和后台。前台很好理解,指的是面向C端的应用,包括前端(如App/小程序)和对应的服务端。至于后台,很多人把它等同于管理后台,比如商品管理后台,负责商品定义/上下架等,提供给内部运营人员使用,这可能不够准确。

简单来说,对于一个交易系统,前台对应用户能看到的部分,如商品浏览和下单,属于接单的部分;后台对应履单部分,如仓库拣货/配送/财务结算/采购补货等,属于实际干活的,由企业内部人员负责,处于一个交易处理流程的后端。

在传统企业,没有在线的前台,基本是线下手工接单,内部信息管理系统基本都属于履单范畴,例如ERP、CRM、采购系统、仓库管理系统,财务系统等,这些系统属于一般意义上的后台概念。

在互联网企业,因为系统一般是自己开发,管理后台既包含面向前台销售的功能,如商品上下架和促销管理,也包含面向履单部分,比如配送、采购、财务结算,所以互联网企业的管理后台并不简单等同于履单后台。

接单和履单之间还有一系列事情要做,包括生成订单时的优惠计算/创建实际的订单/支付/库存扣减等, 这部分功能属于交易逻辑的核心。在简单场景下,前台应用包含这部分功能,在复杂的场景下,就有必要把这部分独立出来,构成独立的中台,为前台减负。

一些文章笼统地介绍中台是用来连接前台和后台的,这个值得商榷。如果管理后台就是后台,那没有连接的必要,因为管理后台本身就是系统的附属部分,和前台属于一体两面。至于履单后台,前台接单系统和后台履单系统设计时就是打通的,也不需要额外定义一个中台来连接两者。

互联网企业的中台更多的是基础业务下沉,实现多业务场景共享,但在传统企业,后台系统清晰地存在,中台确实起到连接后台 (内部老系统)和前台 (新的C端应用)的作用,所以互联网企业的中台和传统企业的中台定位和侧重点是有差异的,这个下文会展开介绍。

为了更好理解中台,这里举个形象的例子:


最上面是各种具体的桌面应用,比如office套件,最底下是各种硬件设备,磁盘/内存/CPU等。

桌面应用能不能直接操纵底层硬件设备完成功能?理论上是可以的,比如在应用里嵌入汇编语言直接操作硬件,但显然开发效率低,可维护性很差。如果中间加一层操作系统进行转换,向下管理硬件,向上提供简洁的API,应用开发就非常方便,这里操作系统类似中台的定位。

对于大型传统零售企业(上图右边部分),企业经过多年信息化建设,购买了大量的商业套装软件,形成内部IT基础设施,现在要往新零售转型,理论上C端的应用可以直接调用老系统的API(如SAP产品提供一定的开放能力)来实现功能打通。但和桌面应用直接控制电脑硬件设备类似,这两者直接对接是低效的,两者的服务对象(2C和2B)/数据模型/技术栈/实时性要求差异很大,而且新的应用进来,又要从头到尾对接一遍,新业务上线,至少需要大半年的时间。

这时如果有个中间层负责桥接和转换,就非常方便。C端应用可以快速基于这个中间层构建,不用关心底层遗留系统的实现细节。这个中间层就是中台,起到类似操作系统的作用,把旧的基础设施转换成面向互联网的基础平台,而且这个平台非常通用,新业务可以快速对接,短时间搞定上线。传统企业在做全面数字化转型时,这样的一个中台必不可少。

中台和微服务的区别

中台源于大型互联网企业,这些系统一般是分布式的微服务架构,那么中台和微服务架构有什么区别呢?

简单地说,我认为中台是微服务的升级,原来只是一个个离散的服务,只负责提供接口功能,如商品服务/订单服务/权限服务,在中台里,升级为商品中心/订单中心,每个中心更强调体系,包括更好的边界划分和业务抽象,更好地监控和系统运营能力(稳定性/故障定位),更好的业务运营能力(比如商品中心自带商品管理后台,支持基础商品定义)。每个服务中心围绕核心业务,自成体系,成为一个微内核,这些微内核既相互独立,又形成一个整体,共同构成基础业务平台,也即中台。松散的微服务->共享服务体系->中台,这是微服务架构和中台的区别和联系。

现在大家谈的最多的是业务中台,我认为一个典型的业务中台包含3层:


对于中台来说,完善的基础业务功能由通用基础业务平台实现;通用聚合服务进一步提升易用性; 通用中间件平台保证系统的稳定性。

除了业务中台,提的比较多的是数据中台,数据中台也是整合数据能力,可以高效地给业务赋能,比如智能推荐,千人千面,精准营销等。

补充说明下,这里通用中间件平台和技术中台一个概念,我觉得没有必要单独叫技术中台,不带业务的中台是没有灵魂的,不能叫中台。同理内容中台的说法是合适的,但算法中台就不合适,大家可以用这个原则区分各种中台的真伪。

为什么要做中台

软件架构从单体架构,到分布式SOA,到微服务,到中台架构,这都是业务复杂化的结果,架构好比生产关系,业务是生产力,架构一定要随着业务发展而演化。0到1阶段,只有一条业务线,比如出租车业务,直接根据需求实现即可。从1到n阶段,业务线逐渐增加,比如快车/顺风车。这时系统有两种做法,第一种是新业务线还是单独实现,多个业务线之家是相互独立的,系统结构整体上是”川”字型。但如果业务线类似,它们的核心逻辑(地图/调度/订单支付)也是类似的,子系统之间有大量的代码复制和多地维护,这是非常低效的。第二种做法是把核心逻辑单独抽取出来,做好通用化,共同服务于所有业务线的需求,此时对于各个业务线系统而言,包括自身的应用层和通用层两部分,定制的东西在应用层解决,共享的东西由通用层提供,再通过编排共享逻辑完成业务流程。系统结构整体上是”山”字型,这个通用层就是山字最底下一横,把各个业务线有机粘合在一起,共享业务逻辑和统一业务规则,实现最大程度的复用。当然搭建山字形是有难度的,什么时候转型为“山”字形?一方面和n值有关,比如n>=3时,应该要考虑转到山字形,另一个因素和各个业务线的相似度有关,相似度高更适合”山”字形,比如电商的C2C和B2C业务;差异比较大,适合”川”字形,比如电商业务和互联网金融业务,没必要强行扭在一起。


从业务角度看,中台代表通用的基础业务,一个企业基础的业务能力和业务规则是相对稳固和清晰的,各个业务线可以认为具体业务场景,如小程序下单/三方外卖等相对复杂和多变,但可以通过组装各个基础业务,快速满足业务场景需求。对于新的业务来说,基础的东西已经差不多有了,只需要少量针对场景的定制开发。总的来说,中台收敛了业务场景,统一了业务规则,比如各个渠道的订单都归到中台的订单服务,遵循类似的订单状态流转和履单过程。

基础业务是有限的,业务场景是无限的,特别是在移动互联网和全面数字化转型的大背景下,传统企业需要开拓大量新渠道,搭建中台,可以很好地通过有限的基础业务满足无限的业务场景。从系统角度看,中台相当于商业操作系统,提供标准接口给上层应用,对于传统企业来说,中台之下还有明确的后台,中台很好地把前端应用(面向互联网)和企业遗留系统(面向内部管理)衔接起来,屏蔽底层系统的复杂性和各种适配工作。从数据角度看,中台收敛业务场景的同时,也收敛了数据比如自有小程序的订单和外卖订单统一到一个订单库,使用同一套数据模型(具体用到的字段可能略有差异),这为后续的数据中台搭建打下良好基础。

深入中台架构

大一点的互联网企业,系统已经是类中台的“山”字型架构,更多的是局部强化和整合。对于传统企业来说,系统基本是”川”字型,大量相互独立的商业套件组成遗留系统。如何基于这些系统搭建中台挑战很大,所以这里更多剖析传统企业的中台架构。

下图是比较典型的传统企业中台架构:

整个架构从上到下分4层:

1) 渠道&应用

这是整个系统对外部分,包括各个应用的前端,如APP/小程序/公众号, 这些是需要定制部分。同时提供Open API,对外部企业输出业务能力。

2) 应用平台

应用平台是各个实际应用的母体,首先包含各个应用的服务端,比如小程序服务端/APP服务端,这些服务端针对具体场景,做流程编排和信息的聚合。

还有各个比较独立的应用模块,如搜索/推荐/评论/拼团,这些模块不强调各个业务线之间共享,只是作为独立模块从服务端剥离出来,方便维护。

还有一些相对简单服务,不属于基础共享业务范畴,比如和具体某个业务相关的配置数据,也通过服务的方式封装。

网关实现前后端隔离,包括外部访问的安全验证和监控,以及内部路由和消息格式转换。

3) 业务中台

由一系列的通用基础服务构成,这些基础服务边界清晰,相互独立,没有调用关系。有些业务场景需要跨服务的数据,比如下单,需要同时涉及商品服务/库存服务/订单服务,一般在基础服务之上有一层聚合服务,通过组合这些基础服务,形成更大粒度的功能接口,供应用平台调用。

中台最底下是技术中间件,包括消息推送,短信邮件,数据访问等,稳定性主要由这部分保证。

4) 后台

包括两部分,适配插件用于连接商户内部系统和中台基础服务,比如在中台商品服务和后台ERP之间同步商品和库存数据,在会员服务和CRM之间同步会员信息。一般针对每个内部系统有一个适配插件,适配插件起到类似硬件驱动程序的作用,这个定制化程度比较高。

商户内部系统就不展开,各个企业的情况不同。

架构图最右边是三方API对接,典型的如微信/支付宝的对接,美团/饿了吗三方外卖对接,天猫/京东的电商平台对接。这个对接前端/应用平台/中台都会涉及。

总结

架构向中台转型是业务复杂化发展的必然结果,中台提供了多方面的价值,不管互联网企业还是传统企业,中台的大方向都是没错的。

对于互联网企业,有基础,往中台转型是改良,需要注意的是,根据当前的业务发展阶段,平衡投入和产生比,适时启动中台改造。

对于传统企业,内部IT基础设施和面向互联网的应用差异很大,往中台转是革命性动作。如何落地中台战略既需要顶层思考,又需要结合实际,做各种平衡和妥协。做的不好,效果适得其反,所谓不做中台等死,做中台马上死,从这个意义上说,是否上中台,有点类似十几年前上大型ERP,需要务实的评估,拒绝形式主义。

分享
微信分享二维码
微信“扫一扫”,打开网页后点击屏幕右上角分享按钮
微信分享二维码
关注“珊瑚圈”公众号,获得更多企业创新经验分享

COPYRIGHT © 2018 珊瑚圈,关注企业微创新

沪ICP备18047879号-1