架构设计-如何做电商业务中台

参考：

https://developer.aliyun.com/article/30340

https://hao123.blog.csdn.net/article/details/107874567

阿里研究员玄难：如何做电商业务中台

简介： 2016 ATF阿里技术论坛于4月15日在清华大学举办，主旨是阐述阿里对世界创新做出的贡献。会上阿里业务平台事业部&淘宝基础平台技术部负责人玄难阐释了淘宝经历13年的发展中，业务平台从零到有，同时又逐步演进为业务中台。

  2016 ATF阿里技术论坛于4月15日在清华大学举办，主旨是阐述阿里对世界创新做出的贡献。会上阿里业务平台事业部&淘宝基础平台技术部负责人玄难阐释了淘宝经历13年的发展中，业务平台从零到有，同时又逐步演进为业务中台。而中台的概念是阿里巴巴在2015年12月提出，并且按照“大中台、小前台”理念进行组织升级，旨在建设“敏捷的前端+强大的中台”，降低整个集团的创新成本，适应新时期的发展。

  下面是玄难演讲内容

 

玄难：大家好，我叫玄难。接下来主要讲一下淘宝13年发展中，每个阶段的业务状况、技术挑战和技术体系的应对策略。

 

 

在复杂的电商生态中，我们有4亿多的消费者，这是我们最大的资产。我们要服务好这几亿消费者，只是阿里巴巴是不可能的，现在有1700多万商家，在全国有200多万快递人员。有上万家软件服务商为我们的商家提供企业支撑软件。随着电商生态的发展，有更多的生态角色不断出现，例如大家都知道的网红。这些是外部生态。内部也从淘宝，一步步的发展壮大，现在有几十个事业部，相关的技术人员有一万多人。支撑了7000多个应用，上千种现存的业务，每天几百个业务需求，500多个独立的变更。面对这样一个复杂的体系，我们如何应对它呢？这就是我重点要讲的业务平台的发展历史。

 

 

在电商技术体系里面，我们会看到中间有一层非常关键的业务平台。淘宝网、天猫、聚划算，以及1688等耳闻目详的零售市场，都是基于业务平台建立的。很多业务也是通过业务平台进行串联的。在业务平台中包括了会员、商品、交易、营销、资金结算、店铺、评价等等电商的基础平台。4亿多会员、10多亿的商品，双11一天900多亿的成交都是在业务平台中进行管理完成的。业务平台是整个电商业务生态的基础。这是非常复杂的业务抽象和业务逻辑控制层。这一层的能力，直接决定了业务发展的速度和业务创新的成本。

 

 

电商系统的发展经历了四个阶段。第一个就是淘宝生长期，单一业务系统阶段。第二个是淘宝集市+淘宝商城时期，分布式业务系统阶段。第三个是三淘(淘宝、天猫、一淘)时期、业务平台化阶段。第四个就是目前的垂直化事业部、业务中台化阶段。

 

 

  第一个阶段是淘宝早期的建立，业务简单，一个业务系统、几台机器就支撑了。刚开始系统不稳定，每天晚上都需要把系统重新启动一下。这是2003年的界面，我们还是保留了历史的痕迹。 这个阶段也分两个部分，最早是花50万买的别人的一个PHP的系统。随着业务的发展，逐步改造成了Java技术体系。系统名字叫Denali。随着电商的迅猛发展，业务品类的快速增长以及淘宝商城起来之后，技术人员的增加，这个系统搞不定了，效率和稳定性都变差了。

 

 

  到2007年团队已经有了上千人，这个时候我们的项目支撑面临巨大的挑战，系统架构必须升级进化。这就到了第二个分布式业务系统阶段。我们开始做分布式战略，把原来的单一系统拆分成多个高内聚，低耦合的中心化系统。现在耳闻目详的用户中心，商品中心，交易中心，店铺中心，就是这个阶段出现的。同时也意味着把上千人的团队拆分成了业务相对比较集中的小团队。每个独立的系统可以独立设计、独立接需求、独立发布，整个研发效率和系统稳定性都上了一个台阶。后面小邪要讲的中间件体系也都是在这个阶段发展起来的。

 

 

电商发展的速度实在太快了，到2011年随着各种B2C网站，各种导购网站的出现，公司也在战略上进行了调整，把淘宝拆分成立淘宝、天猫和一淘三个独立的事业部。三个事业部的业务决策链路更短，业务发展更快、技术人员也快速增长。而且三个事业部的定位不一样、业务发展方向不一样、业务的管控规则不一样。而且在一些业务规则上可能还相互冲突。我们都知道在做业务系统的时候，为了快速应对每天的业务需求变更，很多时候都是通过代码来写业务逻辑的。在业务抽象建模，系统架构的开放性方面都是不足的。这就会导致业务逻辑之间的耦合和相互影响，研发效率大幅下降。

 

系统架构必须升级，这就进入了第三个业务中心平台化阶段。业务中心平台化，什么是平台？就是要把基础能力跟每个业务方的特性业务拆分，要把业务和业务之间的逻辑进行隔离。比如说天猫的业务跟淘宝网的业务有可能是冲突的，但他们需要在一个平台上执行，这时候我们必须把业务的逻辑分开。这时候就开始升级会员平台、商品平台、交易平台等等。平台化最核心的是业务抽象建模和系统架构的开放性。业务抽象解决共性的80%问题，系统架构开放性解决20%的个性化问题。

 

 

  比如说我们看到这个商品的平台化，整个电商体系有10几亿的商品，涉及商品本身的物理属性、不同渠道的销售价格、库存等等。还有很多的不同类目的管控规则，比例医疗器械，必须要有企业资质证明，要有检验证明等等。而且还有些类目，因为市场定位不一样，管控的力度也不一样，比例淘宝和天猫在手机的管控上也都有差异。我们怎么去解决差异性的问题，这些东西就是在整个商品平台里面去做的。我们要通过建立元数据中心、规则中心、商品发布界面自动生成、图片扫描等等来实现商品管理的平台化。

 

 

 

 

 

我们知道每一个人去逛淘宝买东西，每一笔交易都在交易平台上发生，但是在不同的交易的流程和规则是不一样的。比如我们买实物商品、买虚拟商品，还有线下洗头服务等等，它的交易流程不同，有些是先支付在发货，有些是先发货后支付。比如说汽车可能需要在购买的时候同时申请贷款。支付宝给我们提供了很多支付方式，但不同业务需要的支付方式是不一样的，这些东西都是需要通过交易平台来实现。平台化要把不同业务的逻辑隔离开，避免相互影响。

 

 

淘宝今年业务方向是内容化，社区化、本地服务化。我们需要为淘宝网未来5年的业务升级搭建新的基础设施，新的业务平台。像这个内容平台就是其中的一个，需要能同时支持所有业务的内容生产、内容管控、内容的检索、内容的组织等等。

 

 

  全球化是整个集团得战略方向。要能把我们中国的货卖到国外，国外货卖到中国，国外不同国家之间的货物买卖。这些东西都涉及我们整个电商基础设施的升级，包括多语言、多币种、多时区的支持。但他不仅仅这些，还有更复杂的电商基础模型的升级。比如中国有一个很好的制造商，商品品质好。但是他们自己本身不具备英语的能力，俄语的能力，这时候在我们的电商体系里面，如何帮助他把货物卖到全球去。国外的品牌如何简单方便的把货物在淘宝、天猫、聚划算、1688、农村淘宝上去卖等等。比如说华为生产的手机，在天猫上卖的价格、AliExpress上的价格不一样，而且整个的营销模式不一样。“双十一”搞活动的时候，你会发现因为时差的问题，我们整个交易营销的控制逻辑都极大的提升了复杂度。会员安全控制的复杂度等等，都会发生天大的变化。当我们面对全球化的时候，所有基础的模型都会发生变化，涉及到我们对电商商业领域的理解升级，基础模型升级，平台能力升级。

 

 

到现在为止，平台化的升级改造还在不断的继续。而且只要这个业务存在，这个公司存在一天我们就要不断的进行平台的升级。

 

但随着生态的复杂度、业务的复杂度、系统复杂度的升级，我们又遇到了新的问题。我们领域的平台化解决了领域内部的问题。但是我们每一个业务的执行都是夸领域的，涉及会员、商品、交易、营销、店铺、评价、支付、物流、售后等等，业务逻辑横跨几十个系统。比如说这个衣服，我们的商品发布规则是什么样的，交易规则什么样的，营销规则什么样的，这些规则分散在不同的系统中，而且还是相互有关联的。逐渐的，没有一个人能说清楚全局情况了。最后发现最厉害的是谁？就是我们的程序员，因为他们能翻代码，能把所有的逻辑还原出来，但代价极大。最后发现做一个需求，我们评估所有系统的需求要1个月时间，开发只需要10天，但测试又花了10天。真正有效的工作占比很少。整个研发效率和业务响应速度都比较差。这个问题已经不是一个技术问题了，而是一个复杂生态的协作问题。我们就到了第4个业务中台化阶段。主要解决4个问题：1、信息获取成本高。2、互联互通成本高。3、服务具有不确定性。4、低水平重复建设。

 

 

如何来解决这些问题呢，我们可去看一下传统的建筑行业和互联网本身的基础设施建设。基本上靠三个东西来共同解决一个复杂生态的协作问题。1、协议标准、运行机制。2、满足标准的分布式执行单元。3、中心化的控制单元。比如说我们的移动互联网，我们现在之所以上网能用手机，它的根本是什么呢？网络的协议，就是我们整个对网络的理解，它是最基本的思考。然后我们有很多设备，不管是什么品牌的手机，只要满足3G协议、4G协议，就可以插上卡上网。也就是通过这张sim卡确定了我们的身份，从运营商控制网络上获取了控制信息。知道我们是谁，能不能上网，网络速率等等信息。回头来看我们的电商生态，就是要根据我们对商业的理解，把一些基础协议梳理出来。例如什么是业务？什么是业务身份？各个业务领域的边界是什么？每个领域提供的基础服务是什么？领域服务和领域服务之间的流程链接标准是什么？再在这些思想的指导下去建立业务平台化的实施标准和业务管控标准。电商业务中台由一系列业务能力标准、运行机制、业务分析方法论，配置管理和执行系统以及运营服务团队构成的体系，提供各业务方能够快速，低成本创新的能力。

 

 

业务中台需要一个中心化控制单元，就是我们的运营平台。它主要由协议标准，能力地图、业务需求结构分解、全局业务身份、业务全景图、业务度量等构成。能让我们有一个地方纵观全局，把控细节。其中能力地图是一个最基础的设施，要能把电商生态里面的能力都呈现出来，并在过程中不断的优化完善。就象我们现在出行离不开高德地图一样，今后所有的业务方需要做业务规划，业务创新，都可以到这儿来寻找需要的基础能力。

 

  

  为了能将业务逻辑本身与实现逻辑分离，可以将业务逻辑下发给不同实现的执行系统，引入竞争，方便业务平台的改造升级，我们要将控制信息从业务平台中抽离到业务中台，以业务身份为主线来进行组织管理和呈现。并以生态角色的视角来重构信息架构。这样的变革对我们原来的系统架构提出了更高的要求。

 

 

  通过业务中台化，我们把所有业务的数据汇集沉淀。每个业务它是怎么出来的，出来之后做了哪些业务需求，业务活动，每个业务活动的效果是怎么样的，都可以沉淀下来。当一个新业务来了之后，我们就可以让他看到前人成功和失败的经验。逐步可以做一些系统建议，建议他怎么去做营销活动，怎么做效果分析。这样我们能通过数据最终反过来支撑我们的业务创新。

   

最后，我想说的是业务平台是在最基础技术和前端大家能感受到交互技术中间的一层。这一层不是外部消费者和入门级技术人员能直接感知到的。但是这一层才是真正制约我们整个商业发展速度的核心地带。业务平台如何能支撑几千种业务，几万人在同一个时间里面进行变更，这个对业务业务的抽象能力和系统架构能力的要求都是极高的。

大家学一个技术，学一个网络的协议，今天学完了以后我一辈子都不会忘记，都可以用。但是我们在做业务抽象建模的时候，今天你的想法跟明天的想法都会不一样。为什么？桌子上的一杯水，今天你看到一个杯子，材质是塑料的，瓶口是小的，肚子是大的，你可能就做了抽象建模，但明天发现另外一个杯子的时候，它是大口小肚子的,你对杯子的理解变化了。所以说它是随着你生活阅历的增长，视野越来越开阔，你对同样一件事情的理解越来越深刻，你的建模能力都在不断的提升，而且基本是无止境的。在业务平台你会对商业的本质有更深入的学习、理解和成长。

 

 

 

 

 

 

 

 

1 背景

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

2 中台的本质理解

2.1 大中台小前台战略的由来

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

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

他们的工作模式是这样的：谁都可以发起新的游戏创意，然后给组织几个人去实施，做出来看看，行不行，火了就进一步推广，风靡一把；火不起来，玩家不活跃，那这个创意立即终止，再来一个新的继续搞。这个想法其实他们不是第一个，很多公司都内部竞争，都有多产品实施。它们的牛逼之处还是在于上线一个游戏竟然只要若干人的小组就可以完成，笔者了解到的大公司中很多互相竞争的项目团队各自都是百人规模，还频繁在招人。SuperCell的快速业务试错模式固然是值得学习的，但支撑这些快速变化的却是背后的那套游戏构建系统。相信很多人，尤其是男生，都会偶尔有个想法：”要是能开发出这样那样玩法的游戏就好了“。现在若是有一个平台，你只需要配置各种事件对应的反馈、游戏的一些设定、建筑的风格等，再配备几个美工，对游戏中的物体进行按需美化，这些操作之后，平台就会给你生成一款全新的符合你设计的游戏，这是多么高效、轻松、低成本的一件事。相信只要熟悉这套系统，谁都可以在极短的时间内，完成一个新游戏的创建。事实证明，SuperCell的这套新游戏研发系统已经炉火纯青了，《皇室战争》和《海岛奇兵》这两个游戏，如果您都玩过，你会发现它们的游戏画风极为相似，本人曾一度以为它们是一款游戏，只是做了APP升级。

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

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

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

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

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

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

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

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

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

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

2.3 中台本质总结

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

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

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

3.1 阿里中台建设之路

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

1. 2003年淘宝事业部成立，推进以淘宝为中心的电商系统。
2. 2008年，从淘宝事业部中抽出了一拨人，成立了天猫（最初期也叫淘宝商城）。天猫瞬间变火，业务话语权飙升，于是晋升成了天猫事业部，与淘宝事业部并驾齐驱。但是由于主要的技术团队都还是淘宝的，所以你懂的，很多公司毛病之一——屁股意识太强，所以天猫的需求优先级总是比不过淘宝自身的。天猫业务团队自然就不爽了。另外，到这个时候，天猫和淘宝的大部分业务系统都是各自建设的，但都是由淘系研发团队负责。
3. 2009年，共享业务事业部应运而生。领导层发现上述的问题后，决定成立一个与淘宝事业部、天猫事业部平级的事业部，用来处理他们的公共业务。这么看起来似乎很棒，但却带来了另一个问题，共享业务事业部自身没有前台业务，自然话语权比较小，所以逐渐演变成一个两头受气、吃力不讨好的角色。纵使研发天天加班，也填满不了铺天盖地的需求。
4. 2010年，基于共享业务搭建的聚划算前台取得了喜人的成绩，从此说话腰杆子都直了。当时集团就要求1688、淘宝、天猫要想上聚划算，必须通过共享业务事业部。目前，阿里集团超过25个业务单元（如淘宝、天猫、聚划算、去啊等）都是基于这个共享业务事业部上构建的。整体架构如下图所示：  
5. 2015年年底，集团“大中台，小前台”战略正式启用，逍遥子张勇在邮件里写道：“构建符合DT时代的更创新灵活的‘大中台、小前台’组织机制和业务机制：作为前台的一线业务会更敏捷，更快速适应瞬息万变的市场；中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑”。尝到了共享业务事业部的甜头后，加上前往超级细胞获得的灵感，集团大胆的走出了激进的一步——构建集团中台，纳入更多的BU。此时的整个中台的大致结构如下：   其中玄难负责业务中台事业群，致力于构建和推行整个集团的业务中台。
6. 2019年，玄难离职创业，方向为电商中台。坊间一个比较靠谱的说法是：2015年阿里制订了一个15~18的三年中台战略，但到19年还没有任何建树，所以中台大将玄难不得不引咎辞职。
7. 2019年阿里组织架构又进行了调整[9]，如下图所示，中台的影子已悄然不见，取而代之的是出现了很多能力型BU和基础基建，这标志着中台回归本质化——复用，既然是复用，自然是被复用的能力型BU躺在下面，面客业务性BU在上面各自发展。  

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

3.2 阿里中台战略败点分析

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

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

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

阿里集团业务繁杂度远高于超级细胞，中台范围应当细化，不适全局中台。治理小区和治理国家固然有一些类似的点和方法论，但是问题规模变大后，很多小规模下的方法也会变得不再适用，这是一个广泛被认可的观点。超级细胞的业务范围很专一，就是手游，所以它可以很容易就做成游戏工厂。放到阿里这样的大集团，业务种类繁杂，性质大相径庭，何必强融？像淘宝、一淘、天猫，这些其实换汤不换药，那么即便没有中台战略，架构师也知道很多业务逻辑可以复用，要说阿里架构师没有超级细胞的架构师懂？怎么可能。文献[7]中提到的第三阶段其实已经在考虑通过搭建业务平台来建设通用业务能力。而管理层想通过打造一个统一的万能中台来支撑所有集团业务前台（参考图8），是未经深度思考的表现，从超级细胞小公司到阿里大集团，业务复杂度规模急剧增大，怎么能照搬模式呢。正如没有一个架构师可以在新问题上做出百分之一百与实际匹配的架构一样，也不会有一个统一的万能中台能在保证开闭原则的基础上适配所有业务。

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

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

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

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

3.3 阿里中台战略的成功之处

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

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

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

4.1 中台建设的通用步骤

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

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

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

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

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

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

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

由2、3步骤可以画出一个各业务线所需的领域能力图。把名字相同(或者类似)的领域能力对齐，如下图所示大致的内容为：   先申明下，该图只是提供一种参考，着重去说明复用设计的通用步骤，不具备实际的参考意义，各企业应当结合自身的具体现状具体分析。图中每一列相同的颜色代表它们可以做成一套系统，给各个前台复用。从图中我们可以看出以下关键信息：

• 一般来说相同业务类别相同的他们的领域划分也比较类似，但也存在反例，比如本地生活中的外卖和到店O2O，可能在商品、营销上有着很大的差异。
• 用户中心一般不带有具体的业务信息，这部分是可以做成全局统一的，也方便统计用户画像。当然了，各个业务线除了对接这个统一的用户中心外，还是要各自记录一些跟自身业务相关的用户信息，比如金融用户的征信信息等，这种信息可能还需要由另外的系统来承载——比如征信中心。
• 同样的商家结算，一般都是B2B之间的资金往来，业务不同仅仅影响的是交易凭证的描述不同，其他的结算方式等完全可以复用。
• 商品中心，看起来各个业务都有商品中心，但是各个业务线的商品结构可能存在差异，比如金融和传统电商的商品中心，其实现逻辑应当是不一样的。当然，硬要把金融产品标上价格，打上SKU去传统电商前台去卖，也是可以的，只是这种方式带来的问题需要事先想好怎么克服，例如，谁来配置这些SKU，谁来进行商品售后等等。
• 一般涉及货物差异性的业务，都会用到评价中心，这是对商户货物品质的一种用户反馈。而在金融行业的贷款业务看来一般不会对不同的资金提供方去做评价，不排除其他业务会有，比如基金业务等。
• 而有些领域是业务特有的，比如电商经常需要用到比价中心，它负责对手商品价格的抓取和匹配等。

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

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

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

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

4.2 万能工厂要不得

“一个强大的集中的流程定制配置后台”是不是企业中台必须要有的部分？个人理解不是必须的，因为互联网业务复杂度规模很大，涉及各种细节，花大代价去整合一个这样的流程配置中台对中小型公司来说是不可取的。前两年阿里内部很火的NBF、TMF框架[10]，可以快速的通过配置和少量研发帮助阿里集团内的其他BU搭建业务项目，说的神乎其神，除了一两个用来打广告的案例之外，真实用的BU并不多，文献[11]对应的知乎回答中也有表达类似看法的。为什么？笔者的答案是“极端陷阱”，只要路子够极端，必定会遇到新的问题，在这一点上，苍天饶过谁？本以为只要把“开闭原则”用到极致，提供通用配置之外，允许需求方编写很多插件接口实现定制化业务，就可以解决任何问题，其实不然。由于要保证灵活和个性化，配置会呈爆炸式增长，多到理解它学习它使用它的成本也到了一个不小的量级，这时候大部分研发会想——还不如我写代码了。而且一旦遇到某些功能不满足业务需要，业务也不想迁就，那么还得依赖这样一个框架去发起新的迭代，这是业务方不想看到的。代码是一种逻辑语言，本质上和配置一样，只是为了保证代码的正确性，需要经过合理的研发环节，比如研发、自测、测试、灰度、上线验证等，这才是让我们抵触研发的根本原因，而一旦配置复杂了，笔者认为一样一套配置实例仍然需要经过一定的验证流程才能上线，而为这样的一套大型配置系统去编写在线测试机制，又是一大坨工作量。

所以笔者建议，中台的建设应当围绕单一职责的领域能力去构建，单一能力又可以提供一些简单配置来实现定制化使用（就像一款款的中间件那样），比如我们只需要申请好支付账号和密钥，就可以在系统里集成支付宝了。在这些可以复用的系统能力至上，我们再去定制化构建自己的前台业务系统。如果前台产品明确的话，我们甚至可以搭建自己的产品工厂，专门生产某一商业模式下的产品。这些产品也代表了小前台中的更小前台，也可以反应框定范围内业务模式的不同，业务们也是可以基于这个工厂去玩不同的花样的，只是这样的工厂不能用来生产其他商业模式的产品。反过来说，本来就没啥关系，为啥要管别的商业模式呢？管的越多，工厂本身越复杂，越耽误事，折射到现实中，一般一个工厂只会生产某一种类的产品，但是产品系列可以有多个。折射到超级细胞，它的那套游戏工厂，生产游戏自然没问题，非得让它生产贷款产品，这得多无聊。所以号称自己可以快速搭建某行业任何业务系统的“万能工厂”，多半是陷入了“极端陷阱”，最后只能是庸人自扰，舍本逐末。记得《最强大脑第七季》的某一场比赛，娄云皓对宋佳昌，单位时间内根据解开的“异形谜盘”数量来得分，娄云皓选择了低阶的盘面，而宋佳昌选择的是高阶的盘面，最后娄云皓大获全胜。这个例子告诉我们，过于追求更大复杂度的成功，很可能陷入自己跟自己过不去的尴尬境地。笔者不否认理论上是存在一套全能的系统，仅通过配置就可以完成各类电商的业务系统定制，但也别忘了，当配置足够复杂时，也许写写代码更容易解决问题，毕竟底层通用能力有的话，已经可以极大的提高研发效率了。

中台建设本质是复用能力的建设，能力系统的建设应当聚焦某一领域，切实的去解决众多前台业务的某一类复杂性子问题，并封装出简洁的接口提供给前台业务开发使用。万能工厂的做法不可取，这种方法的本质是简单问题复杂化，分布式前台业务的集中式抽象，若是前台业务逻辑本身就相似，那么不用系统工厂也能做的很通用；若是差异很大的前台业务，用了系统工厂可能更难如期交付。举个例子，一个稍经通用设计的商品中心，从日用百货，到飞机大炮，再到房产基金都可以卖！何必去搞一个万能电商工厂，根据所卖的货物不同而生成一套新的电商系统呢？如果担心很多定制化个性化的逻辑无处表达，那就做好基础能力建设，然后一个小团队就可以基于这些通用能力去快速构建出新的电商系统了。笔者有信心，这种方式比搞一个万能电商工厂来的更加现实和经济，以下是笔者眼中的合理中台架构：

不同的前台可以有自己的产品工厂，比如金融业务可以有自己的贷款产品工厂、电商业务可以有自己的商品中心等。在写该部分的时候，由于内容很抽象，笔者在极力寻找生活中的例子来帮助读者理解笔者的意图。关于这个部分，可以这样来比拟：如果您某天特别想吃川菜，可以选择自己买菜来做；如果你想能定时吃到按照自己口味做的菜又不想自己做，你可以开个该菜系的小饭馆，请个川菜厨师；如果你还想吃湖南菜，那么你可以尝试招聘一个又会川菜又会湖南菜的厨师（类似业务线是存在抽象复用的可能性的）；如果你心血来潮，想着自己还喜欢看书，就想着开一个超级工厂，可以生产你想要的任何东西（食物、书和其他），很可能您会落到一个舍本逐末、烂尾收场的境地。因为本来成立这个工厂就是为了节省成本，而建设它的投入已经远大于分别去搭建按现有需求所需的小生产线了。即便万幸你的超级工厂建成了，你也会发现它的内部很可能也是一条条小生产线组成的，写书和炒菜毕竟差的太远了。这个例子告诉我们以下几点：

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

4.3 各大互联网中台实施现状

具体内容参考文献[12]。笔者看完的感受是：广观各大互联网中台建设，都是打着中台的幌子在进行复用性设计战略实施，而且他们的战略实施都有个规律，都是从稳固底部做起，从下至上[12]。似乎只有大阿厂是锚定了一个理想化终态从上至下的大搞特搞的。从腾讯中台定义来看就知道阿厂中台大而泛了，腾讯都是建设了具体的内容中台、用户中台等，而阿厂上来就是业务中台、数据中台和技术中台。不过随着2019年组织结构调整，”大中台、小前台“战略已经无人提及了，提出中台的阿里正在像行业理解的中台前进！这就好比老师跟学生说了某个知识，结果学生理解到了精髓，而老师却曲解了知识本意。互联网业务参差不齐、细节差异大，很难像超级细胞那样搞个超级中台工厂，业务随便来配置一下就可以生成一个新的业务前台了。不如从基础能力复用性做起，建设好通用基础业务领域能力，其他的个性化前台业务还是需要各自的研发团队负责。从本质上看，全局中台没有意义，但能想的很清楚的领域能力一定要提供出来，比如用户、物流、支付、营销、数据管理等，能减轻多少上层的负担是多少，不必逞强。另外，前台业务的研发团队是需要保留的，他们需要基于全局的通用基础能力去构建属于自己业务的“小”中台。

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

5 总结

火极一时的阿里”大中台、小前台“战略折射出的是高层管理者在初尝复用技术的甜头后引发的一系列创造性思考，表明企业的管理者正开始思考自身研发体系的科学性和可持续性。中台的提出是粗犷研发转向精益研发的重要里程碑，就像冷兵器时代早期打仗靠堆人，后面慢慢的演化出高效用兵的兵法。很难想象如果没有中台思想的提出，还有多少公司要陷入研发滚雪球、竖烟囱的状态并且管理层还认为就应该是这样，业务催着要交付产品，研发毫无机会去思考复用性，大家都为着短期的利益做着极端的取舍：前台业务需求第一，不管合不合理，先怼上去，烟囱先竖起来。中台战略，就像是一场革命，革掉了“唯短期利益主义”，当然我们也要避免走入另外一个极端——唯远期利益，这种情况下可能死的更快，对应了过度设计。适合企业的优秀研发架构的实现没有一条黄金定律，架构师和技术TL需要担起这个识别复用点的责任。最后引用一段超级细胞一位开发同学在受采访时说的话[13]：I feel like when you’re chasing short-term goals, you can end up stepping on your own toes —— Seth Allison。

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

6 参考文献

[1] 阿里、腾讯等巨头追捧的“中台”，到底有多重要？https://www.sohu.com/a/316496280_115035

[2] 阿里要拆分马云提出的“大中台，小前台”模式？ 官方回应：假的。https://xw.qq.com/cmsid/20190502A051I3/20190502A051I300

[3] 第一性原理：从埃隆·马斯克谈独立思考的力量（深度好文）。https://baijiahao.baidu.com/s?id=1621647480822229180&wfr=spider&for=pc

[4] 游久网。http://www.uuu9.com/

[5] 那些年，他们用过的《魔兽争霸3》地图编辑器。https://zhuanlan.zhihu.com/p/32057966

[6] 超级细胞官网企业介绍。https://supercell.com/en/our-story/

[7] 阿里研究员玄难：如何做电商业务中台。https://developer.aliyun.com/article/30340

[8] 企业IT架构转型之道-阿里巴巴中台战略思想和架构实践，第一章。钟华著。

[8] 一次性讲透阿里中台架构。http://www.uml.org.cn/zjjs/201911134.asp

[9] 看2019阿里集团最新组织架构，回顾阿里战略变迁（附阿里组织架构战略变迁PDF下载）。https://www.jianshu.com/p/d51ce6db6d8c

[10] 2017双11交易系统TMF2.0技术揭秘，实现全链路管理。https://segmentfault.com/a/1190000012541958

[11] TMF2.0 是只是一个业务框架吗? https://www.zhihu.com/question/371738242

[12] 互联网各大厂的中台建设怎么样了？腾讯/百度/头条/滴滴/小米。https://www.sohu.com/a/342952046_692515

[13] Success and sustainability at Supercell. https://www.gamesindustry.biz/articles/2019-01-15-success-and-sustainability-at-supercell