大中台的黄粱一梦和复用性设计的繁荣盛世

K8s已经成为一线大厂分布式平台的标配技术。你是不是还在惆怅怎么掌握它？来这里，大型互联网公司一线工程师亲授，不来虚的，直接上手实战，3天时间带你搭建K8s平台，快速学会K8s，点击下方...

Docker_

1131人浏览 · 2020-08-06 07:45:00

Docker_ · 2020-08-06 07:45:00 发布

K8s已经成为一线大厂分布式平台的标配技术。你是不是还在惆怅怎么掌握它？来这里，大型互联网公司一线工程师亲授，不来虚的，直接上手实战，3天时间带你搭建K8s平台，快速学会K8s，点击下方图片可了解培训详情。

自从阿里巴巴现任CEO逍遥子在2015年提出“大中台，小前台”战略以来，关于“什么是中台”，可谓是一石激起千层浪，大量文章在描述什么是中台。而不懂的人看完后依旧是云里雾里，我们经常听到一些词：“业务中台”，“技术中台”，“系统中台”等，我相信很多同学都会懵逼。本文为作者眼中对中台的理解，中台可广义可狭义，理解到其本质含义更为重要。不同于其他由非技术人员编写的中台释义，本文会严格考虑系统实现的可操作性，时刻带着这种落地感来诠释中台。也希望通过此文指引更多的企业走向正确的中台之路，而不要被那些花里胡哨的概念误导，最后落到舍本逐末、烂尾收场的尴尬境地。

中台的本质理解

大中台小前台战略的由来

最广为流传的故事应当是2015年年中马云参观SuperCell后感慨这家公司单个员工的创造价值为何如此之大——这家创造了年税前利润15亿美元的公司，却只有不到200名员工[1]。SuperCell这家公司可能大家可能没听说过，但它出品的游戏比如《部落冲突》、《卡通农场》、《海岛奇兵》、《皇室战争》和《荒野乱斗》等相信大家多少有所耳闻。这家公司的组织结构也是另类的，传统公司中越是上层，权利也越大，需求、产品定义都是由上至下的，如下图所示：

而在SuperCell，CEO权力很小，CEO自称是“世界上权利最小的 CEO“，其实这正是一种睿智，自己反而轻松了，类似老子提出的“无为之治”，老祖宗的很多道理真的是放之天下皆可。先看下SuperCell的组织结构：

他们的工作模式是这样的：谁都可以发起新的游戏创意，然后给组织几个人去实施，做出来看看，行不行，火了就进一步推广，风靡一把；火不起来，玩家不活跃，那这个创意立即终止，再来一个新的继续搞。

这个想法其实他们不是第一个，很多公司都内部竞争，都有多产品实施。它们的牛逼之处还是在于上线一个游戏竟然只要若干人的小组就可以完成，笔者了解到的大公司中很多互相竞争的项目团队各自都是百人规模，还频繁在招人。

SuperCell的快速业务试错模式固然是值得学习的，但支撑这些快速变化的却是背后的那套游戏构建系统。相信很多人，尤其是男生，都会偶尔有个想法：“要是能开发出这样那样玩法的游戏就好了”。现在若是有一个平台，你只需要配置各种事件对应的反馈、游戏的一些设定、建筑的风格等，再配备几个美工，对游戏中的物体进行按需美化，这些操作之后，平台就会给你生成一款全新的符合你设计的游戏，这是多么高效、轻松、低成本的一件事。

相信只要熟悉这套系统，谁都可以在极短的时间内，完成一个新游戏的创建。事实证明，SuperCell的这套新游戏研发系统已经炉火纯青了，《皇室战争》和《海岛奇兵》这两个游戏，如果您都玩过，你会发现它们的游戏画风极为相似，本人曾一度以为它们是一款游戏，只是做了APP升级。

就是这么一个逻辑，对前去参观的马老师一行人来说，犹如醍醐灌顶，豁然开朗。做管理做企业的领导们在看到“新”的高效的模式的时候，总是会想着我们公司是不是也可以这么搞？网上流言中台是马老师提出的无从考证，本人所知的情况是逍遥子内发的邮件最先提到了这个概念。根据广泛的理解，前台一般对应着一个具体的商业模式以及配套的用户应用（App、小程序等），对应阿里的中台架构图（后面会提到），前台就是一个个BU业务线。注意，这张图里压根就没有后台。

还有一种推理帝们的说法是，后台对应了面向内部人员的运营配置、前台对应了面向用户的客户端，所以中台就是衔接它两的。笔者想提醒下，这是压根不是技术人员提出来的，当年张建锋接到马老师的中台作业，也纳闷了半天，百思不得其解。高层管理们不会这么理性的技术化的看待前中后台的关系，个人猜测他们的逻辑是，用户看得到的这些叫前台，这之后看不见的所有的支撑平台叫后台，由于考虑到需要直接支撑前台，所以搞了一个前无古人，后无来者的叫法——中台，连专业代码二十年的阿里各大技术元老们都涨了见识。

笔者看来，在管理层眼中的中台和后台（这里的后台跟技术理解的后台管理系统也不是同一件事）并无差异，只是强调这跟之前看不见的后台是有差异的，他们希望中台这部分能打造成为一个公共后台，而不是竖烟囱式的后台。

说了这么多，总结下本文通用的中台定义：前台的支撑系统，基础设施层之上的通用业务层，具体由通用的业务领域能力和与其对应的后台系统共同组成。画成图的话大概是这样：

其中前台特有领域和中台领域之间的比例是按前台业务差异性不同而变化的，有些场景下，中台领域可以做的非常厚，厚到前台就剩一个前端应用（APP、小程序、PC站等）；有些场景下，中台可能只能做有限的抽象。笔者的另外一个观点是——中台是一个相对的概念，除了整个集团能谈中台，在各个前台领域中，前台研发团队仍然可以做自己的“小中台”，用于服务自身商业模式下的多变的一类业务产品。这种关系是多级的。本质都是在做复用设计。

“新”打了引号，是想表明，这种软件通用性的设计其实很早就有了。

超级细胞公司的“中台”本质

个人非常欣赏埃隆·马斯克经常提及的“第一性原理[2]”，从本质来思考，SuperCell公司并不是一开始就有一个“大中台、小前台”的战略在指引自己，而是任何一家游戏公司，要想做得好，不完全是追求短期利益，都会走向这条路。事实上，超级细胞自身从来没有公开提出什么“中台”的概念。只从游戏工厂这种产品模式来说，SuperCell也不是第一家这样做的公司，所有玩过暴雪的WarCraft（魔兽争霸）的同学都知道，它不仅仅是一款即时战略游戏，它还是一个游戏制造器，通过创建一个新的地图，配置剧情，任何人都可以很快的上手并创建一个自己的玩法。游久网就是这么一个专门提供不同魔兽争霸地图的网站。虽然看不到超级细胞的游戏创造后台系统，我们可以看看魔兽争霸的游戏编辑器是啥样的：

通过任务系统和事件系统，我们还可以定制出各种剧情。为了展示下魔兽地图编辑器（WE）有多变态，以下几幅游戏截图，都是来自于自定义的地图。

单说游戏工厂这种产品或游戏创作模式，暴雪的游戏团队绝对是全球顶尖的。在超级细胞的官网介绍中也曾提到，他们的很多员工都是魔兽世界的铁粉。然而人们关注的往往是成功的对象，暴雪最近几年在手游领域除了炉石传说这种卡牌类的，几乎没出啥游戏。PC游戏做的再好，知名度也很难与全民参与度更高的手游相比。与这些先驱游戏公司类似的，超级细胞的“中台”系统本质也是一个游戏工厂，是游戏行业里的一种高复用性、高度可自定义、高度开放式设计的软件系统。当然了，这个工厂生产的东西可能只是一套虚拟的游戏逻辑，具体的用户端APP还是需要依靠研发团队进一步加工和研发的。

个人猜想，马老师一行人回去之后，对标超级细胞一想，这么大一个公司，每天有那么多想法和创意，每个创意、产品都搞一个五脏俱全的团队去实施那得浪费多少人力成本？要是有一个强大的系统，可以让各种想法和创意快速试错，推向市场、反馈、迭代，行就推广，不行就终止，那该多高效。所以才有了后来的“大中台、小前台”战略，为的是给业务打造快速试错的平台，他们理解的中台实质就是一个业务产品工厂，可以通过“配置大于研发的约定”快速构建业务前台，这对应了超级细胞的各种游戏。

中台本质总结

为了更好的阐述和帮助读者理解下文笔者的意图，先总结下对中台的一些理解：

中台的意图：让业务更好的进行创新、试错，同时大大降低新业务研发成本。
中台的理论基础：前台只是一层皮（这层皮也不仅仅是前端，还可以包括后面的前台领域系统），基础设施只是一套没血肉的骨架，位于中间的看不见的血肉才是软件系统的核心，如果这些血肉每次都要重建，那么将严重阻碍新业务创新、试错的速度。
中台的方法论：和平台方法论并无差异——抽象通用能力+开放设计，这两者比例多大，不好说，这里也不想耍流氓那样用个二八定律去糊弄大家，相信不同的业务场景这个比例多少会有些不同。
中台的本质：四个字——系统复用。复用也分层次，也有复用程度之分，通过抽象出各种配置来支撑定制化这件事的本质也是复用——复用配置系统。
中台的实施原则：专注领域复用能力建设、配置大于研发。这个点看似很简单，但是极具艺术性，配置如何做到化繁为简很关键，如果发现配置复杂度比研发还大，那就瞎了。

阿里“大中台、小前台”战略的成与败

阿里中台建设之路

2016 ATF阿里技术论坛于4月15日在清华大学举办，主旨是阐述阿里对世界创新做出的贡献。会上阿里业务平台事业部&淘宝基础平台技术部负责人玄难阐释了淘宝经历13年的发展中，业务平台从零到有，同时又逐步演进为业务中台[3]。下面是个人梳理的可能与阿里中台战略提出有关的一个时间线：

2003年淘宝事业部成立，推进以淘宝为中心的电商系统。

2008年，从淘宝事业部中抽出了一拨人，成立了天猫（最初期也叫淘宝商城）。天猫瞬间变火，业务话语权飙升，于是晋升成了天猫事业部，与淘宝事业部并驾齐驱。但是由于主要的技术团队都还是淘宝的，所以你懂的，很多公司毛病之一——屁股意识太强，所以天猫的需求优先级总是比不过淘宝自身的。天猫业务团队自然就不爽了。另外，到这个时候，天猫和淘宝的大部分业务系统都是各自建设的，但都是由淘系研发团队负责。

2009年，共享业务事业部应运而生。领导层发现上述的问题后，决定成立一个与淘宝事业部、天猫事业部平级的事业部，用来处理他们的公共业务。这么看起来似乎很棒，但却带来了另一个问题，共享业务事业部自身没有前台业务，自然话语权比较小，所以逐渐演变成一个两头受气、吃力不讨好的角色。纵使研发天天加班，也填满不了铺天盖地的需求。

2010年，基于共享业务搭建的聚划算前台取得了喜人的成绩，从此说话腰杆子都直了。当时集团就要求1688、淘宝、天猫要想上聚划算，必须通过共享业务事业部。目前，阿里集团超过25个业务单元（如淘宝、天猫、聚划算、去啊等）都是基于这个共享业务事业部上构建的。整体架构如下图所示：

2015年年底，集团“大中台，小前台”战略正式启用，逍遥子张勇在邮件里写道：“构建符合DT时代的更创新灵活的‘大中台、小前台’组织机制和业务机制：作为前台的一线业务会更敏捷，更快速适应瞬息万变的市场；中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑”。尝到了共享业务事业部的甜头后，加上前往超级细胞获得的灵感，集团大胆的走出了激进的一步——构建集团中台，纳入更多的BU。此时的整个中台的大致结构如下：

其中玄难负责业务中台事业群，致力于构建和推行整个集团的业务中台。

2019年，玄难离职创业，方向为电商中台。坊间一个比较靠谱的说法是：2015年阿里制订了一个15~18的三年中台战略，但到19年还没有任何建树，所以中台大将玄难不得不引咎辞职。

2019年阿里组织架构又进行了调整[4]，如下图所示，中台的影子已悄然不见，取而代之的是出现了很多能力型BU和基础基建，这标志着中台回归本质化——复用，既然是复用，自然是被复用的能力型BU躺在下面，面客业务性BU在上面各自发展。

至今，官方和小道消息都没有具体中台有没有做成的消息，说没有做成吧，淘系电商业务平台（也可以叫中台）确实支撑了好多BU。但是支撑归支撑，要是中台做不大，前台做不小，可能还是达不到管理层的目标。笔者猜测，由于管理层过度的理想化，导致技术实施时困难重重，毕竟复用性并不是想做多大就可以做多大的，支撑的业务模式越多，抽象出来的通用复用性就越底层。这就达不到小前台的效果，前台还是需要一定规模的研发团队，事实证明，目前阿里的各个BU仍然各自都有着大量的研发团队。

阿里中台战略败点分析

该部分没有什么参考文献，全部为个人的观点。笔者做软件设计和研发已有12年，作为一名架构师和码农，个人最怕的就是自己因为害怕走出舒适区而陷入“极端陷阱”。这是一个笔者自己发现和定义的现象：很多时候，绝大多数人会认定一个死理，难以自拔，而究其本质是一旦大脑好不容易发现了某种理解可行时，不想再接受更多的反例，不愿意再去用第一性原则慢慢推导，个人认为这也是一种不想走出舒适区的表现。陷入极端陷阱后引发的问题是，当时你以一个高层领导的身份急着去拍了一个方案，实际上还有很多细节没想明白，这样大概率的结果就是项目烂尾。以下是按个人理解总结的阿里“全局大中台、小前台”战略的两个致命问题。

注：本节仅代表个人思考，不能作为事实依据。

(1) 中台应当分门别类，因地制宜，全局中台并不适合大集团

阿里集团业务繁杂度远高于超级细胞，中台范围应当细化，不适全局中台。治理小区和治理国家固然有一些类似的点和方法论，但是问题规模变大后，很多小规模下的方法也会变得不再适用，这是一个广泛被认可的观点。超级细胞的业务范围很专一，就是手游，所以它可以很容易就做成游戏工厂。放到阿里这样的大集团，业务种类繁杂，性质大相径庭，何必强融？

像淘宝、一淘、天猫，这些其实换汤不换药，那么即便没有中台战略，架构师也知道很多业务逻辑可以复用，要说阿里架构师没有超级细胞的架构师懂？怎么可能。文献[5]中提到的第三阶段其实已经在考虑通过搭建业务平台来建设通用业务能力。而管理层想通过打造一个统一的万能中台来支撑所有集团业务前台，是未经深度思考的表现，从超级细胞小公司到阿里大集团，业务复杂度规模急剧增大，怎么能照搬模式呢。正如没有一个架构师可以在新问题上做出百分之一百与实际匹配的架构一样，也不会有一个统一的万能中台能在保证开闭原则的基础上适配所有业务。

总结来说，阿里集团业务繁杂，不能把BU当做前台来构建大中台，每个BU就是一个独立的公司，有着自己独立的业务，根本“小”不了。而为各个BU做的那些通用的东西也是具有局限性的，只能帮助上层BU节省部分研发成本。过度贪求高度复用，会陷入“强求陷进”——把不该抽象的东西硬是抽象到了一起，结果就是系统的复杂度并没有降低，而是从多个地方搬到了一个地方。因此，管理层想要的“全集团大中台、小前台”，是一种理想主义，注定难以实现。

(2) 全局中台带来的新问题——依赖单点和热点

按上文的理解，中台战略的实际意义更大的是在于提醒所有BU，要尽量的增强能力复用，为BU业务创新营造一个高效低成本的环境。而如果我们把一家大集团的所有主要业务系统都放到一个事业部去管理，就会产生一个新的问题——单点甚至是热点现象。每个BU甚至业务线都各自有KPI，如果某个BU发现中台无法支撑自己的场景（因为总会有没考虑的情况），那么势必要求中台团队做支撑，需求一多，还得排队，这和BU寻求自身的生存和发展势必是矛盾的。所以，复用能力涉及的业务范围越大，单点问题就越是严重，单点变热点的概率也就越大。即便中台事业部做的再大，哪怕为每个BU都搞一个小团队去支持，由于所背的KPI和汇报关系并不在所支撑的BU，实践起来总是会存在信息断层。

合理的复用是不会产生热点的，因为正确的抽象聚焦是的领域内的业务，设计思路会无差别的对待所有用户，要么一个用户都没法用，要么所有用户都可以用（无故障的情况下）。就好比数据库一样，任何一款数据库都不会关注数据的业务属性，电商的数据能存，金融的数据必然也能存。引入数据库就是一种数据存取能力复用——数据库属于基础设施，复用性是必要的。

阿里中台战略的成功之处

时至今日，中台的理念已经深入所有互联网人的心，阿里集团各个BU也在打着自己的中台算盘。全局大中台虽未建成，单各个事业部都开始在研发中试着使用中台思维去思考自己的研发体系。中台的理念一定是没错的，只是要因地制宜，切忌一刀切。早期，大家只会思考基础设施的复用性，产品如各种中间件等，现在大家开始关心另外一个问题了——这个业务能不能做成一个通用能力；又或者，会先问问其他同学——集团是不是有这样的业务能力可以复用过来？这就是一种良性的影响。

中台，未必要大。前台，未必就小。能避免低水平重复性劳动的研发体系，就是可以被称为优秀的研发模式。

企业如何建设适合自己的中台

中台建设的通用步骤

(1) 定义需要快速变化、试错的前台业务（业务线、产品线）

如果您都无法清晰的定义自己的业务线，那么可以先内部脑暴一下。先基于现有的业务线讨论，再继续讨论未来可能发展的业务线。

(2) 领域分析和模块划分

架构师在充分了解了每个业务线后，梳理出每个业务线所需要的业务领域块。这对架构师的要求很高，纯粹的业务架构师可能无法胜任，但是可以参与讨论，因为业务架构师可能对研发细节欠缺考虑，从而做出形而上无法落地的复用设计。

(3) 识别业务线共性并归类

架构师进行前台业务线归类。通过上文的讨论我们知道中台的本质是复用性设计，那么业务线分类就是把可以大程度进行复用业务逻辑的业务线放到一起。这部分需要资深架构师参与，毕竟这很大程度上是一个经验活。有些不该放到一类的业务线应当分开，比如金融业务和电商业务大相径庭，硬是搞一个团队同时维护两套系统，甚至揉在一个系统里，结果是不会太好的。

(4) 画出领域模块（能力）对齐图

由2、3步骤可以画出一个各业务线所需的领域能力图。把名字相同(或者类似)的领域能力对齐，如下图所示大致的内容为：

先申明下，该图只是提供一种参考，着重去说明复用设计的通用步骤，不具备实际的参考意义，各企业应当结合自身的具体现状具体分析。图中每一列相同的颜色代表它们可以做成一套系统，给各个前台复用。从图中我们可以看出以下关键信息：

一般来说相同业务类别相同的他们的领域划分也比较类似，但也存在反例，比如本地生活中的外卖和到店O2O，可能在商品、营销上有着很大的差异。

用户中心一般不带有具体的业务信息，这部分是可以做成全局统一的，也方便统计用户画像。当然了，各个业务线除了对接这个统一的用户中心外，还是要各自记录一些跟自身业务相关的用户信息，比如金融用户的征信信息等，这种信息可能还需要由另外的系统来承载——比如征信中心。

同样的商家结算，一般都是B2B之间的资金往来，业务不同仅仅影响的是交易凭证的描述不同，其他的结算方式等完全可以复用。

商品中心，看起来各个业务都有商品中心，但是各个业务线的商品结构可能存在差异，比如金融和传统电商的商品中心，其实现逻辑应当是不一样的。当然，硬要把金融产品标上价格，打上SKU去传统电商前台去卖，也是可以的，只是这种方式带来的问题需要事先想好怎么克服，例如，谁来配置这些SKU，谁来进行商品售后等等。

一般涉及货物差异性的业务，都会用到评价中心，这是对商户货物品质的一种用户反馈。而在金融行业的贷款业务看来一般不会对不同的资金提供方去做评价，不排除其他业务会有，比如基金业务等。

而有些领域是业务特有的，比如电商经常需要用到竞价中心，它负责对手商品价格的抓取和匹配等。

(5) 严格遵循开闭原则，从底至上的去实施

针对我们上文找出的存在复用可能性的领域（每一列里颜色相同的领域块），架构师需要识别出其边界和专注解决的问题，最后安排不同的产研团队去实施。各个领域块的研发团队在实施时应当尽可能的抽象公共业务逻辑，并且将无法通用的环节做成开放式的。只要按照这个思想创建的系统，即便没有配置后台，上层业务系统对接也是极其轻松的。这里推荐另一篇笔者的文章《浅谈微服务体系中的分层设计和领域划分》，它讲述的就是一种搭建通用大后端的系统架构，按照柔性的定义，这也是中台——它可以支撑新业务应用快速研发。在完成了通用能力的搭建后，我们还可以为每个通用能力去构建配置后台，这样可以更快的给前台应用研发提速，配置优于研发带来的好处就是不需要走研发流程就可以完成一定的定制逻辑。

需要注意，图中的每个域不代表只有一个服务，服务数量可以是多个。

从底而上是要求我们优先实现那些被广泛依赖和公用的通用领域能力，然后再去实现被依赖较少的那些通用领域能力，最后基于这些能力可能还会继续抽象出一些更具有具体业务含义的领域能力。比如资源库存中心搭建好之后，还可以基于它去搭建商品库存中心。这样不仅可以实现效能最优化，也可以避免由于上层抽象不合理带来的重构成本。想象一下，如果我们先竖烟囱，再去抽象他们的公共部分，是不是会带来巨大的重构成本和重构风险。

万能工厂要不得

“一个强大的集中的流程定制配置后台”是不是企业中台必须要有的部分？个人理解不是必须的，因为互联网业务复杂度规模很大，涉及各种细节，花大代价去整合一个这样的流程配置中台对中小型公司来说是不可取的。前两年阿里内部很火的NBF、TMF框架[6]，可以快速的通过配置和少量研发帮助阿里集团内的其他BU搭建业务项目，说的神乎其神，除了一两个用来打广告的案例之外，真实用的BU并不多，文献[7]对应的知乎回答中也有表达类似看法的。为什么？笔者的答案是“极端陷阱”，只要路子够极端，必定会遇到新的问题，在这一点上，苍天饶过谁？

本以为只要把“开闭原则”用到极致，提供通用配置之外，允许需求方编写很多插件接口实现定制化业务，就可以解决任何问题，其实不然。由于要保证灵活和个性化，配置会呈爆炸式增长，多到理解它学习它使用它的成本也到了一个不小的量级，这时候大部分研发会想——还不如我写代码了。而且一旦遇到某些功能不满足业务需要，业务也不想迁就，那么还得依赖这样一个框架去发起新的迭代，这是业务方不想看到的。代码是一种逻辑语言，本质上和配置一样，只是为了保证代码的正确性，需要经过合理的研发环节，比如研发、自测、测试、灰度、上线验证等，这才是让我们抵触研发的根本原因，而一旦配置复杂了，笔者认为一样一套配置实例仍然需要经过一定的验证流程才能上线，而为这样的一套大型配置系统去编写在线测试机制，又是一大坨工作量。

所以笔者建议，中台的建设应当围绕单一职责的领域能力去构建，单一能力又可以提供一些简单配置来实现定制化使用（就像一款款的中间件那样），比如我们只需要申请好支付账号和密钥，就可以在系统里集成支付宝了。在这些可以复用的系统能力至上，我们再去定制化构建自己的前台业务系统。如果前台产品明确的话，我们甚至可以搭建自己的产品工厂，专门生产某一商业模式下的产品。

这些产品也代表了小前台中的更小前台，也可以反应框定范围内业务模式的不同，业务们也是可以基于这个工厂去玩不同的花样的，只是这样的工厂不能用来生产其他商业模式的产品。反过来说，本来就没啥关系，为啥要管别的商业模式呢？管的越多，工厂本身越复杂，越耽误事，折射到现实中，一般一个工厂只会生产某一种类的产品，但是产品系列可以有多个。折射到超级细胞，它的那套游戏工厂，生产游戏自然没问题，非得让它生产贷款产品，这得多无聊。

所以号称自己可以快速搭建某行业任何业务系统的“万能工厂”，多半是陷入了“极端陷阱”，最后只能是庸人自扰，舍本逐末。记得《最强大脑第七季》的某一场比赛，娄云皓对宋佳昌，单位时间内根据解开的“异形谜盘”数量来得分，娄云皓选择了低阶的盘面，而宋佳昌选择的是高阶的盘面，最后娄云皓大获全胜。这个例子告诉我们，过于追求更大复杂度的成功，很可能陷入自己跟自己过不去的尴尬境地。

笔者不否认理论上是存在一套全能的系统，仅通过配置就可以完成各类电商的业务系统定制，但也别忘了，当配置足够复杂时，也许写写代码更容易解决问题，毕竟底层通用能力有的话，已经可以极大的提高研发效率了。

中台建设本质是复用能力的建设，能力系统的建设应当聚焦某一领域，切实的去解决众多前台业务的某一类复杂性子问题，并封装出简洁的接口提供给前台业务开发使用。万能工厂的做法不可取，这种方法的本质是简单问题复杂化，分布式前台业务的集中式抽象，若是前台业务逻辑本身就相似，那么不用系统工厂也能做的很通用；若是差异很大的前台业务，用了系统工厂可能更难如期交付。

举个例子，一个稍经通用设计的商品中心，从日用百货，到飞机大炮，再到房产基金都可以卖！何必去搞一个万能电商工厂，根据所卖的货物不同而生成一套新的电商系统呢？如果担心很多定制化个性化的逻辑无处表达，那就做好基础能力建设，然后一个小团队就可以基于这些通用能力去快速构建出新的电商系统了。笔者有信心，这种方式比搞一个万能电商工厂来的更加现实和经济，以下是笔者眼中的合理中台架构：

不同的前台可以有自己的产品工厂，比如金融业务可以有自己的贷款产品工厂、电商业务可以有自己的商品中心等。在写该部分的时候，由于内容很抽象，笔者在极力寻找生活中的例子来帮助读者理解笔者的意图。关于这个部分，可以这样来比拟：如果您某天特别想吃川菜，可以选择自己买菜来做；如果你想能定时吃到按照自己口味做的菜又不想自己做，你可以开个该菜系的小饭馆，请个川菜厨师；如果你还想吃湖南菜，那么你可以尝试招聘一个又会川菜又会湖南菜的厨师（类似业务线是存在抽象复用的可能性的）；如果你心血来潮，想着自己还喜欢看书，就想着开一个超级工厂，可以生产你想要的任何东西（食物、书和其他），很可能您会落到一个舍本逐末、烂尾收场的境地。

因为本来成立这个工厂就是为了节省成本，而建设它的投入已经远大于分别去搭建按现有需求所需的小生产线了。即便万幸你的超级工厂建成了，你也会发现它的内部很可能也是一条条小生产线组成的，写书和炒菜毕竟差的太远了。这个例子告诉我们以下几点：

尽早识别出截然不同的业务线，不要企图去构建同时支撑他们的中台。
保守的做法是，优先为很容易就被识别的同类业务线去搭建复用中台。
不要激进的去框定一个万能中台的目标，落到实处，为前台老百姓们切切实实的解决一些实在的问题。
中台的设计讨论可以从上至下的去分析，但是实施路径一定要从底至上，先从最基础的通用能力开始，慢慢往上建设，不用强求高度复用性，因为很可能那是业务差异决定的。即便是有解的，高度复用性设计也是在从底至上的建设过程中逐渐形成的。

各大互联网中台实施现状

具体内容参考文献[8]。笔者看完的感受是：广观各大互联网中台建设，都是打着中台的幌子在进行复用性设计战略实施，而且他们的战略实施都有个规律，都是从稳固底部做起，从下至上。似乎只有大阿厂是锚定了一个理想化终态从上至下的大搞特搞的。从腾讯中台定义来看就知道阿厂中台大而泛了，腾讯都是建设了具体的内容中台、用户中台等，而阿厂上来就是业务中台、数据中台和技术中台。不过随着2019年组织结构调整，“大中台、小前台”战略已经无人提及了，提出中台的阿里正在像行业理解的中台前进！这就好比老师跟学生说了某个知识，结果学生理解到了精髓，而老师却曲解了知识本意。

互联网业务参差不齐、细节差异大，很难像超级细胞那样搞个超级中台工厂，业务随便来配置一下就可以生成一个新的业务前台了。不如从基础能力复用性做起，建设好通用基础业务领域能力，其他的个性化前台业务还是需要各自的研发团队负责。从本质上看，全局中台没有意义，但能想的很清楚的领域能力一定要提供出来，比如用户、物流、支付、营销、数据管理等，能减轻多少上层的负担是多少，不必逞强。另外，前台业务的研发团队是需要保留的，他们需要基于全局的通用基础能力去构建属于自己业务的“小”中台。

中台由中台能力组成，具体表现为一个个领域系统，叫不叫中台不重要，重要的是这个领域的服务能力是复用的。

总结

火极一时的阿里“大中台、小前台”战略折射出的是高层管理者在初尝复用技术的甜头后引发的一系列创造性思考，表明企业的管理者正开始思考自身研发体系的科学性和可持续性。中台的提出是粗犷研发转向精益研发的重要里程碑，就像冷兵器时代早期打仗靠堆人，后面慢慢的演化出高效用兵的兵法。

很难想象如果没有中台思想的提出，还有多少公司要陷入研发滚雪球、竖烟囱的状态并且管理层还认为就应该是这样，业务催着要交付产品，研发毫无机会去思考复用性，大家都为着短期的利益做着极端的取舍：前台业务需求第一，不管合不合理，先怼上去，烟囱先竖起来。中台战略，就像是一场革命，革掉了“唯短期利益主义”，当然我们也要避免走入另外一个极端——唯远期利益，这种情况下可能死的更快，对应了过度设计。适合企业的优秀研发架构的实现没有一条黄金定律，架构师和技术TL需要担起这个识别复用点的责任。最后引用一段超级细胞一位开发同学在受采访时说的话：

I feel like when you’re chasing short-term goals, you can end up stepping on your own toes —— Seth Allison。

翻译为：我认为当你追寻短期利益时，你最终会踩到自己的脚趾。文中寓意为超级细胞认为每一款游戏都会运营个20-30年，每次更新变更的内容都会经过充分的讨论。笔者相信，这样的团队在打造自己的游戏研发平台时，注定也会去追求了一个中长期的目标，围绕这个目标小步快跑。