深入浅出话中台

产品之魂 2019-10-17

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

本文的内容包括:

  1. 什么是中台
  2. 中台和微服务的区别
  3. 为什么要做中台
  4. 深入中台架构

1. 什么是中台

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

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

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

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

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

一些文章笼统地介绍中台是用来连接前台和后台的,这个值得商榷。如果管理后台就是后台,那没有连接的必要,因为管理后台本身就是系统的附属部分,和前台属于一体两面。至于履单后台,前台接单系统和后台履单系统设计时就是打通的,也不需要额外定义一个中台来连接两者。互联网企业的中台更多的是基础业务下沉,实现多业务场景共享,但在传统企业,后台系统清晰地存在,中台确实起到连接后台 (内部老系统) 和前台 (新的 C 端应用) 的作用,所以互联网企业的中台和传统企业的中台定位和侧重点是有差异的,这个下文会展开介绍。

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

深入浅出话中台

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

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

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

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

2. 中台和微服务的区别

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

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

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

深入浅出话中台

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

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

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

3. 为什么要做中台

软件架构从单体架构,到分布式 SOA,到微服务,到中台架构,这都是业务复杂化的结果,架构好比生产关系,业务是生产力,架构一定要随着业务发展而演化。

0 到 1 阶段,只有一条业务线,比如出租车业务,直接根据需求实现即可。从 1 到 n 阶段,业务线逐渐增加,比如快车 / 顺风车。

这时系统有两种做法,第一种是新业务线还是单独实现,多个业务线之家是相互独立的,系统结构整体上是”川”字型,如下图所示。但如果业务线类似,它们的核心逻辑(地图 / 调度 / 订单支付)也是类似的,子系统之间有大量的代码复制和多地维护,这是非常低效的。

第二种做法是把核心逻辑单独抽取出来,做好通用化,共同服务于所有业务线的需求,此时对于各个业务线系统而言,包括自身的应用层和通用层两部分,定制的东西在应用层解决,共享的东西由通用层提供,再通过编排共享逻辑完成业务流程。系统结构整体上是”山”字型,这个通用层就是山字最底下一横,把各个业务线有机粘合在一起,共享业务逻辑和统一业务规则,实现最大程度的复用。

当然搭建山字形是有难度的,什么时候转型为“山”字形? 一方面和 n 值有关,比如 n>=3 时,应该要考虑转到山字形,另一个因素和各个业务线的相似度有关,相似度高更适合”山”字形,比如电商的 C2C 和 B2C 业务;差异比较大,适合”川”字形,比如电商业务和互联网金融业务,没必要强行扭在一起。

深入浅出话中台

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

基础业务是有限的,业务场景是无限的,特别是在移动互联网和全面数字化转型的大背景下,传统企业需要开拓大量新渠道,搭建中台,可以很好地通过有限的基础业务满足无限的业务场景。

从系统角度看,中台相当于商业操作系统,提供标准接口给上层应用,对于传统企业来说,中台之下还有明确的后台,中台很好地把前端应用 (面向互联网) 和企业遗留系统 (面向内部管理) 衔接起来,屏蔽底层系统的复杂性和各种适配工作。

从数据角度看,中台收敛业务场景的同时,也收敛了数据 比如自有小程序的订单和外卖订单统一到一个订单库,使用同一套数据模型(具体用到的字段可能略有差异),这为后续的数据中台搭建打下良好基础。

4. 深入中台架构

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

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

深入浅出话中台

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

  1. 渠道 & 应用

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

  1. 应用平台

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

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

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

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

  1. 业务中台

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

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

  1. 后台

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

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

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

5. 总结

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

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

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

后续会介绍关于中台的更多内容,敬请期待:

  1. 服务化成熟度模型
  2. 企业信息系统成熟度模型
  3. 什么时候适合做中台
  4. 中台有哪些挑战
  5. 中台的落地步骤

作者介绍:

相关推荐