通俗易懂解释什么是“中台”

随着互联网公司崛起，“中台”这个词也进入了人们的视线。BAT 等公司纷纷推出了自己的中台系统。那么，什么是中台系统？它是如何诞生的？它长什么模样？我们为什么需要它？一串串的问题不禁浮现在我们的脑海，今天我们就带着这些问题，一起走进中台。

一.没有中台的时代

在传统IT企业，项目的物理结构是什么样的呢？无论项目内部如何复杂，都可分为“前台”和“后台”这两部分。

什么是前台？

首先，这里所说的“前台”和“前端”并不是一回事。所谓前台即包括各种和用户直接交互的界面，比如web页面，手机app；也包括服务端各种实时响应用户请求的业务逻辑，比如商品查询、订单系统等等。

什么是后台？

后台并不直接面向用户，而是面向运营人员的配置管理系统，比如商品管理、物流管理、结算管理。后台为前台提供了一些简单的配置。

前台、后台、用户之间的关系，可以用下图简单表示：

在传统的前台-后台架构中，各个项目相对独立，许多项目都在重复发明同样的轮子，即让项目本身越来越臃肿，也让开发效率越来越低。

这种时候，为提高开发效率，我们有必要整合出一个中间组织，为所有的项目提供一些公共资源。而这个中间组织，就是人们所说的“中台”。

二.什么是中台？

1.中台诞生

任何一个软件系统都是通过帮助客户解决问题来实现价值的。针对不同的需求会建立不同的软件项目。

这些软件项目包含客户端的应用和后台管理配置的应用。久而久之就形成了固定的“前台”和“后台”系统，而且大家都在乐此不疲地开发着类似的业务系统。

但是，时间一长大家就发现了，这些系统中有一些部分大同小异，在做第二个项目的时候并不用将所有的功能重写，可以把之前项目中那些共有的模块拿出来，稍作修改就可以在新项目中应用了。这就是中台的雏形。

2.中台的领跑者

SuperCell是一家芬兰的手机游戏公司，这个名字或许有些陌生，但是说起下面几款游戏，大家一定会很熟悉：

部落冲突

海岛奇兵

皇室战争

SuperCell公司就像是一个高产的游戏孵化器，在几年内开发出了10款以上的游戏，但是大部分用于试错的游戏都在研发过程中被腰斩了，最终呈献给用户的几款游戏都是经典中的经典。

是什么让SuperCell公司能够如此高效地试错和迭代呢？他们依靠的是强大的平台资源，支撑起各个游戏开发的小团队。

他们开发出的游戏看上去风格迥异，却存在许多共同之处。在业务上，共通的东西包括支付系统、用户系统等等，在技术上，共同的东西包括游戏引擎，内部开发工具等等。而这些共通的资源，都可以由一个强大的“中台”来提供：

中台的架构思想改变的不只是项目结构，也影响了研发团队的组织形式。SuperCell公司把这种高效的组织形式称为“部落”。

紧随其后，国内互联网公司也纷纷开始了各自的中台战略。

阿里巴巴提出了“大中台，小前台”的战略：

图中，阿里巴巴许多产品线的共通业务经过下沉，形成了中台的各种业务中心，而Aliware则是阿里巴巴的技术中间件平台，为各大业务线提供技术支持。

华为提出了“平台炮火支撑精兵作战”的战略：

华为把作战小分队比喻为前台项目团队，把中台比喻成战地指挥部。在这个比喻当中，中台的作用就是提供资源支持：要数据给数据、要技术给技术。

3.转动的齿轮

抽象和解耦是软件开发铁律，同样也适用于中台系统。中台系统就是将“后台”系统中那些针对技术，业务，组织的通用“模块/服务”从原来固定的项目中抽离出来，并且使之能够成为一个自治的服务提供给更多的“前台”使用。

中台就是“前台”和“后台”之间联动的齿轮，也是：

调节器：前台业务变化快，后台系统相对比较稳定，中台就是他们中间的速度调节器；
加速器：新业务上马，接入中台即刻享受服务，不用零开始；
稳定器：前台业务多如牛毛，后台数据排山倒海，而中台提供各式各样的接口对接两者使用户享受稳定可靠的服务。

“中台系统”犹如齿轮，带动“前，后台系统”飞速转动。

4.中台的分类

中台是一种能力的抽象，这种能力可以是业务能力，技术能力，数据能力甚至是组织能力。我们可以从不同的维度对其进行分类。

中台分为如下几类：

业务中台；
技术中台；
数据中台；
组织中台。

（1）业务中台

业务是根本，特别是用户的核心业务。对于中台来说需要针对业务进行颗粒度划分。例如：客户服务，结算中心，订单中心。

如果业务发生变化需要对上述服务进行拆解，例如：将结算中心拆解成支付服务和核销服务。

这样的分类和拆解是为了更好的支持前台，给前台业务提供更多的可能性，从而为用户组合出更多的使用场景。

这类平台的提供者一般在某一个行业深耕多年，积累大量的行业知识。

业务中台：根据业务对服务进行划分。

（2）技术中台

作为技术人员接触过最多的就是技术中台，通常我们会将服务进行拆解通过微服务的方式重新组织。

每个微服务都是自我治理的，通过服务注册，服务网关，服务跟踪的方式让他们形成一个整体。

技术中台的划分通常分为两个维度，第一个是基础服务，这些服务针对整个系统来说相对通用，如：日志服务，安全服务等等。

第二个就是业务服务，这些服务都针对每个业务模块做划分，通常这些服务会根据业务的变化或者增量进行更新或者横向扩展。

这类平台的提供者，一般都是科技型企业，涉及过多个行业，对基础组件和模块的应用得心应手，往往他们设计出来的中台架构性能和可靠性方面比较优秀。

技术中台：利用微服务，DevOps 给前台提供支撑。

（3）数据中台

数据的获取通常需要经过数据采集，数据清洗/过滤，数据存储，数据归档几个步骤，最后才能通过数据服务的形式展现给用户。

特别是针对客户端来说，同时通过数据中台提供的服务来获取数据的。数据中台会根据不同的业务场景，生成不同的数据服务，满足客户的需要。

提供类似平台的企业进入 IT 信息化的时间比较早，积累了一大批数据，通过对数据的整合和分析可以助力业务发展。

数据中台：让前端不用关心数据处理过程，只专注于“数据服务”。

（4）组织中台

中台是需要人来实现的，如何组织好这些人就显得尤为重要了。如果要谈谈组织中台，那么就要先说说下面几种组织结构。

职能型：每个部门各司其职，虽然都是一个老板管，但是部门之间的界限明确。

每次有了项目就从各个部门抽调人员，当项目完成以后人员都回到各自的部门当中。

如果再有新的项目就再次抽调。这种方式沟通成本高，责权不清，出现问题以后容易踢皮球，对用户需求的反应相对较慢。

职能型：根据职能对组织进行划分。

矩阵型：随着互联网的兴起，矩阵型的组织结构也悄然兴起。把人员从原来的部门中完全剥离出来成立专门的项目，并且指定项目经理。

人员汇报的线路也从原来的部门经理换成了项目经理。而项目经理又对 CTO 直接负责，这样的结构相对简单，实用性较强，避开了职能型组织结构的一些缺点。

矩阵型：从职能部门中抽取合适的人形成独立的组织。

产品型：随着产品意识的不断提升，人们不再拘泥于之前的矩阵型组织结构了，于是加入了产品和产品经理，更重要的是把客户也纳入到组织当中。

让客户参与产品决策，验收测试，增加用户的参与感，做到产品为客户所用。用户自己设计，测试出来的产品他想说不好都难。

产品型：在职能型的基础上，让组织围绕产品和用户工作。

随着组织中台的不断发展，我们的组织结构也慢慢从职能型向矩阵型，产品型进行过渡。

5.中台的生命周期

任何事物都有自身的运转规律，中台系统也不例外。首先我们需要满足使用者在某种场景中的需求，通过对需求的转化我们知道需要通过哪些功能或者系统来实现。

这些功能或者系统是否已经在中台系统中存在？如果存在是否需要进行优化或者拆分，如果不存在是否做成可以有通用性的模块？

在定义了以上几点以后，再进行设计，编码调试，集成测试。最后，发布给客户去验证业务的可行性。

如果发现问题再回到需求的原点重新走一次上面的过程，周而复始，直到满足客户的需求为止。

“需求”、“实施”、“验证”不断循环，直到满足用户的需求。

三.中台的作用

大家既然对中台有了一定的了解，那我们再从两个维度来看看中台的作用。虽然上面已经介绍了很多关乎作用的例子，但是我们还是希望从两个维度来归纳总结一下。

1、业务方面的作用

1）快速切入市场

在中台出现之前，我们进入每个行业是比较困难的。在了解业务的基础上需要搭建基础的业务模块。

现在不需要了，有了中台策略的加持即使对一些行业不太了解也能够从容应对。

在 BAT 中已经有染指汽车制造，航空航天等专业性很强的行业了，靠的就是中台能力的输出。

2）专业人员融入系统

有了中台系统，那么就离不开行业中的专业人员。行业中的专业人员，协助中台系统打磨各个业务模块，通过 PASS 平台打造行业自身的应用。让业务和技术更好的融合，产生化学作用。

3）定义平台规则

现在阿里的钉钉就把用户，服务提供商，经销商都拉到了一个平台上了。通过阿里平台的能力，将钉钉打造成企业服务的中台，让多方从中受益。

业务方面：通过满足市场需求，提高专业化程度，打造平台战略，逐步升级。

2、技术方面的作用

1）服务重用

不要重复造轮子是我们始终面对的问题，中台的初衷就是抽离通用的部分，让更多人能够享受他们。

2）服务进化

技术会跟随业务的进化而进化，每一次进化都是一次技术的沉淀。以前这些技术进化是不可见的，现在新的项目也可以通过中台系统享受这些技术的进化。

3）快速响应

由于中台系统针对服务进行颗粒化处理，让每个服务都有独立性，可以针对业务的需求对服务进行横向扩展，从而提高服务的响应时间。

4）数据积累

长年累月的数据积累，特别是对业务数据的积累，能够帮助我们带来商业价值。

5）提高效率

不用从无到有去搭建整个项目架构，也大大缩短了给用户的交付时间，高效的组织结构也促进了交付质量，提高了用户的满意度。

技术方面：服务重用、服务进化、快速响应、数据积累、提高效率相辅相成。

四.中台对于个体来说意味着什么？

点，线，面

如果说淘宝网整个就看成一个大中台来说，它提供了各式各样的服务，接口，数据，为商家和消费者创造交易的环境。那么我们把淘宝网可以看成一个“面”。

那么对于商家来说，他需要利用一些营销工具，聘请一些模特拍照，利用一些物流信息为自己送货。商家可以看成一条“线”。

那些提供营销工具，拍照服务，物流服务的供应商就可以看成“点”。

对于我们而言，可能无法成为“面”，但是可以通过“面”的支持去做“线”和“点”。

再把眼界扩大一点，到微信小程序，支付宝小程序，钉钉应用，都是有发挥空间的。

供应商、商家、平台，构成“点”、“线”、“面”的有机整体。

五.中台模式的困扰

中台相比于传统模式虽有优势，但实践和理论的隔阂必然存在。中台该做不该做什么，如何与业务方良好协同，如何评估KPI都成了难题。

我们可以根据中台对业务方的参与度，绘制成下面的一张图。

轴的最左边：仅提供工具库和少量答疑维护，不对业务效果负责。绝大多数开源项目，各种数据库，都可以归于这种极端。
轴的最右边：all-in参与业务方的大部分流程，从运营业务，到数据模型，事无巨细。我们戏称其为“高级外包”。

我们形象地称其为左倾和右倾问题。

越往左走，工具抽象和通用能力强，赋能业务多，雨露均沾，研发人员能专注于技术本身。但越往左越好么？不一定。越左就无法深入业务场景，无法接受业务滋养，很可能故步自封，甚至为了技术而技术，变得学究派，而使过于独立的中台变成了纯后台，更重要的是，如何评估业务产出？

在最右面则是另一种极端，其优点非常明显：此时中台完全融入业务，有完整的业务sense，非常理解并能快速应对需求，与业务方打成一片，戏称为“高级外包”。但是，该模式的人力一般只能覆盖单一业务，很难对外辐射。由于精力所限，技术人员过分关注业务，中台的技术深度就会相对较差。

我们要同时警惕这两种极端，但从整体来看，最容易被忽视的反而是右倾。右倾构建了看似美好的中台合作模式，亲密无间的服务，但是人们很容易忽略其问题：由于过分具象和强耦合，中台能力难以沉淀在通用的工具和理论上，当出现其他相关业务时，原有产品并不能支持，应对变化的能力小，一旦业务方向变化就可能前功尽弃。

此时由于中台容量有限，过重的服务模式导致只能覆盖有限的业务。中台不得不评估前台项目的重要程度，甚至拒绝为低优先级的前台提供支持，挑肥拣瘦。那么前台可能会为自己的业绩考虑去自行组团队完成项目，进而导致中台与前台隔阂。相反的，若事无巨细地参与到业务方，侵入性就会很强，人的问题会成为最大的问题：它可能会架空业务方人员，引起猜疑，甚至可能被并入业务方，导致中台骨干流失。

参考链接1：https://www.toutiao.com/a6738524780011454984/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1&timestamp=1569068545&app=news_article&utm_source=weixin&utm_medium=toutiao_android&req_id=201909212022240100260770892C46402B&group_id=6738524780011454984

参考链接2：https://www.toutiao.com/a6737580615262011908/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1&timestamp=1568860343&app=news_article&utm_source=weixin&utm_medium=toutiao_android&req_id=201909191032230100260760850A74DC27&group_id=6737580615262011908

参考链接3：https://www.cnblogs.com/buptzym/p/8763490.html