对中台的探索与思考-技术圈

前言

今天要分享的主题是：对中台的探索与思考。

中台概念如今已经不是什么新的名词了，相信大家对中台都有所耳闻，目前各大企业已经先后开始建设自己的中台。

那中台到底是什么？为什么大家要建设中台？怎样去建设中台？

希望通过本次分享，能让大家有所收获。

本次分享主要分为三个部分：

概念篇：介绍中台的发展历史，中台的分类，让大家对中台概念有一个了解。

案例篇：分享一些中台建设的案例，让大家对各种类型的中台有更清晰的认识。

思考篇：聊一聊我对中台建设的一些思考。

概念篇

中台的发展历史

2008年阿里战略调整创建天猫，因为天猫与淘宝相比有他自身的特性，所以当时淘宝和天猫各自为战，没有共用一套系统架构，也就是现在所说的烟囱式系统架构，这种架构造成大量重复工作与资源浪费，那怎么解决呢？阿里共享事业部就诞生了，负责将前台公共部分进行平台化改造，为中台战略埋下了种子。

2015年，马云访问Supercell,这是一家开发游戏的公司，他发现这家公司虽然开发了很多款游戏，却只有不到200名员工，每款游戏也就5-7人，快速开发产品公测，如果产品不成功就快速放弃。

实现这种快速试错机制的前提是开发速度要快，Supercell就是使用了中台机制，开发新产品就像搭积木一样可以快速实现。

于是，阿里CEO张勇在2015年提出启动中台战略。国内中台概念的诞生。

2018开始中台概念全面爆发，腾讯、京东等大厂都开始建设自己的中台。

到现在，互联网行业进入下半场，中台战略也随之进入了下半场，各企业纷纷开始建立自己的中台。

这里我要解释一下，什么是互联网行业的下半场。

先说互联网行业的上半场，上半场是面向C端的消费互联网，目前已经逐渐饱和，因为用互联网的人就这么多，用户增长红利已经不见了，企业为了更好的发展，就开始进入下半场，由面向C端的消费互联网转为面向B端的产业互联网。

面向B端客户就会面临个性化需求严重的情况，所以大家都想建立中台复用中台能力，来更好的支持B端客户的快速迭代。

什么是中台

那现在我们来看一下中台是什么。

说中台之前，我们先来看一下没有中台的组织架构是什么样的。

没有中台的时候，一般分为前台和后台。

前台：直接向用户交付的产品、开发产品的人

后台：可以理解成提供基础技术的支撑，比如erp、cms、基础技术平台（中间件、大数据）

那引入中台后的组织架构是什么样的呢？

前台：从中台获取可复用能力快速形成面向用户的产品

中台：企业级能力复用平台

后台：为中台提供建设中台的原料，比如：基础中间件、devops等等

这里其实我们已经给中台下了定义，那就是：企业级能力复用平台

企业级：说明了中台的使用范围是面向整个企业的

能力：抽象解释了中台是各种能力的集合体

复用：说明了中台的内容一定是公共的，能复用的。

平台：平台是建设中台的基座，建设中台之前一般都是先建设平台

说到这，正好可以引出一个话题，中台与平台有什么区别。

我们来看一下平台的概念。

平台，是开放出去的一些通用功能，你可以直接来用这个平台提供的一些功能，他主要是站在自己的角度来构建和开放一些通用化的能力，而不是有目的为了抽取前端通用和公共的可复用能力来设计的

可以看出平台重技术，轻业务。平台对比与中台更偏向底层。

中台的类型

关于中台的类型，主流的分类就是业务和数据双中台架构了。

业务中台顾名思义，指的是把企业内能够复用的业务能力抽取出来，集成到中台建设中

数据中台，主要就是采集数据，让各个业务间共享数据。

数据中台和业务中台主要是为前台赋能的。

那什么是技术中台呢？

技术中台可以认为是更加底层的技术基座，与业务关联可能不大，技术中台有点类似于平台的概念。

技术中台是建设中台的第一步，前台业务团队接入技术中台，阻力比较小.

案例篇

京东移动技术中台

京东移动技术中台主要建设了三个部分：标准化、工具化、组件化。

提供了下图中整体DevOps体系能力：

标准化：指的是整体开发、测试、发布这些工作流程的标准化

工具化：指的是为了实现标准化流程，自研适合自己企业的工具

组件化：指的是通用能力形成公共组件，供企业内所有前端产品共用

京东移动中台的组件化程度如下图：

可以看到，京东是组件贡献大户，其他业务借用公共组件就可以很快生成新的产品给用户使用，就拿极速版来讲，它的组件借用率高达71，贡献率只为3，也就说明它基本上就是通过组件堆积出来的，基本不需要自己开发什么。

某电商业务中台

下图展示了一个常见的电商业务中台架构图。

前台可以类比与淘宝、天猫、闲鱼等各种电商的业务线，直接面向用户。

中台为前台提供一套商品、订单、库存等通用的电商业务流程。

后台为中台提供基础的支撑，比如用户、仓储、物流等等。

这里我单独对订单中台做一个展开，建设电商中台一般要开发独立的流程编排引擎，对不同的业务流程进行编排满足于不同的业务，比如实体商品的买卖和虚拟商品的买卖肯定流程是不一样的。再细节就不展开说明了。

总结起来，业务中台建设目标呢就是通用业务的集中化和可编排化。

某数据中台

在数据中台中，首先要实现数据资产化，三大体系保证了数据资产化顺利进行：

（1）One Model：简单的理解就是数据模型的统一，我们不用重新建模，只要调用数据中台中已有的模型即可，一个模型可以被多个业务部门共享。

（2）One ID：打通了用户账号，可以在多终端识别同一用户。

（3）One Service：统一的数据服务中间件，实现对外的数据服务。

提到数据中台我们第一个想到的就是大数据部门，下图是某公司大数据部门的发展战略：

图中还少了一个数据湖的阶段，数据湖与大数据仓库主要的区别就是存储数据的方式不同，数据仓库存储的都是经过结构化转换后的数据，数据湖则不同，存储大量结构化与非结构化的原始数据，包含音视频二进制等等。能更好的为人工智能，机器学习提供数据支持。

思考篇

什么样的企业适合建设中台

中台的优点我们通过之前的内容已经大体上清楚了，但不合理的建设中台其实也有着它的缺点：

拖慢业务：中台体系反应迟缓，在各种商业竞争上频繁败北。这似乎与前面提到的第一个中台期望背道而驰。
遏制创新：中台化的企业普遍丧失业务创新能力，无法跟上竞争对手的步伐。
人才流失：中台化之后的企业，优秀人才会大量流失。
伤害客户：中台化之后的企业，会逐渐减少对用户体验的关注。当用户不再是企业的关注点，最终整个企业也将在竞争中丧失优势。

那所有企业都适合建设中台吗？不是这样的，如果企业的业务线没有能够通用的内容，那通用的业务抽离不出来，就无法建立业务中台，如果强行建立的话反而会适得其反。

另外企业发展的初期，也不适合建立中台，这个时候快速实现功能抢占市场才是当前企业的使命。建设中台并不能帮助企业快速抢占市场，架构设计原则之一就是演进式架构，合适的时间要采用合适的策略。

那什么样的企业适合建设中台呢，最合适建设中台的企业最好有多条业务线，它们的体量相似，QPS 都不高，业务线间相似度高，多条业务线的变更频次基本稳定。

如何建设中台

建设前必须想清楚的四个问题

1）中台建设的愿景是什么？

“遇事不决看愿景”，建设中台之前一定要确定唯一的正确的目标，这也是架构设计的准则之一。

2）中台的用户和客户是谁？

用户和客户是一个群体么，除了用户和客户还有哪些干系方。对于中台来讲，他的干系方还不止是用户和客户这两方，因为其所处的特殊位置，干系方往往纷繁复杂。在保持自己方向的前提下，找到各方利益的结合点，是一件非常困难且有必要的事情。否则，在建设过程中就会受到各方的阻力，产生摩擦，导致中台很难推进落地。

但反过来讲，中台也不应该只是极力去满足各方的诉求，中台团队毕竟不是业务的外包团队。中台需要有自己的思想和规划，要能做到听得进别人的话，但是还要明确自己的目标，走自己的路。而自己的目标，就是来源于上面提到的中台建设愿景，而中台的愿景也往往来源于企业的战略需要。

3）中台的钱由谁出？

市面上的中台建设，如果从投资结构来讲，基本上可以分为两种类型，即“众筹模式”和“投融资模式”

众筹模式就是用户预付款，就是从业务前台集资，有钱的捧个钱场没钱的碰个人场，能出预算的出预算，能出人的出人，来组建中台团队，然后再反过来服务于前台业务团队。

投融资模式，顾名思义，就是一个产品的建设前期先由投资方出资，按照产品的建设目标经过一段时间的建设期，相对成熟之后，再逐渐地让用户使用，最终通过对于用户的服务，让用户满意，实现收入并收回企业投资且盈利的模式。目前大部分的创业公司都是采用类似的模式。

4）中台的目标怎么验证？

建设中台一定要有量化结果，让领导能看得出建设中台的效果。

中台建设的实例路径：

DDD、微服务与中台的关系

首先中台我们已经知道是什么了，那么建立中台的后端技术架构一般就是使用的微服务架构，

DDD领域驱动设计方法可以帮助我们定义领域模型，限界上下文，聚合等，在中台建设中可以指导我们更好的为业务划分边界，也能指导我们更合理的拆分微服务。

关于DDD的一些概念说起来又是很长的话题了，本文就不详细说明了。

前端是如何适应中台化的

单体前端的困境

传统企业在完成中台转型后，虽然后台的业务完成了微服务架构的升级，但前端仍然是单体模式，随着时间推移和业务发展，前端会变得越来越臃肿，越来越难维护。很多企业都想把所有的业务能力都尽量集中到一个 APP 中。试想如果仍然沿用单体前端的设计模式。前端项目团队将面对多个中台微服务团队，这就需要相当高的沟通成本和技术要求。

从单体前端到微前端

为了解决单体前端的问题，我们可以借鉴微服务的设计思想，引入微前端概念。让每个微前端可以单独部署维护，常见的微前端类型如下：