我要批判中台！｜ 文末赠书 我在阿里巴巴工作期间是一个名副其实的“刺头”，批判中台、批判架构师、批判技术管理者，当然，也包括自我批判。 今天就先聊聊批判中台！前些年，阿里巴巴提出了“大中台、小前台”战略，在业界掀起了不小的波澜，一时间，各种中台建设的方法论和最佳实践满天飞。 中台的底层逻辑是什么？中台能带来的价值到底是什么？ 我们有必要用批判的眼光来审视一下中台建设。 中台的底层逻辑 中台的底层逻辑，用一句话解释就是通过复用提升研发效率。 建一所房子，首先要打地基、铺钢筋，然后往上一块一块地垒砖头。没办法，原子世界就是这么物质，一块砖头都少不了。软件是比特世界，软件开发很少是从买服务器开始的，特别是在云原生时代，云厂商通常已经帮我们做好了“基建”的事情。IaaS是对算力、网络、存储、操作系统等基础设施的复用，PaaS是对中间件的复用。 如图1所示，基于这样的演进路径，有没有可能做一个Business-PaaS（业务中台），提炼业务中具有共性的内容，减轻前台业务，提升研发效率呢？ 图1 业务中台的位置 单看图1，这个逻辑似乎是通的。于是，在“大中台、小前台”的旗帜下，业务中台诞生了。可是不管是一线研发人员的反馈，还是高层人员的质疑声，都表明了业务中台似乎并没有解决问题，反而制造了更多的阻碍和困难，这是为什么呢？ 业务中台为何低效 中台战略没有错，大中台也没有错，技术中台、数据中台都没问题，为什么到业务中台就出现问题了呢？我想问题就出在这个“业务”身上。 IaaS也好，PaaS也罢，之所以能提效，是因为其具有业务无关性，它们和业务的边界很清晰，彼此正交，互不干扰。IaaS和PaaS解决的是技术问题，业务解决的是业务问题。PaaS偶尔也会侵入业务应用，为了与应用隔离解耦，于是有了PandoraBoot、Service Mesh等技术。 业务中台却没有这样的“好命”，它解决的是复杂、多变的业务问题。如果你把镜头拉近一点看，会发现业务和业务中台的关系并不是像我们理想的一样在中间有一道清晰的边界线，而是像图2一样，犬牙交错地耦合在一起。 图2 业务和业务中台的关系 前台业务要借助业务中台一起去完成业务逻辑，所以有一部分埋在了业务中台里，至于埋得多深，则取决于使用中台能力的多少，用得多就埋得深，用得少就埋得浅。 因此，用一句话来说，业务中台低效的根本原因在于，前台业务和业务中台的“深度单体耦合”。这种耦合性至少在以下3个方面严重影响了整体的研发效率。 1. 协作成本 研发≠写代码，实际上我们大部分时间不是在写代码，而是在沟通协调，况且与人打交道要比与机器打交道麻烦得多。这也是《人月神话》一书中说“加人只会让项目更糟糕”的原因，因为额外增加了更多的协作成本。 除了组织协作成本倍增，耦合带来的工程协作成本也很高。试想一下：如果几百名研发人员在同一个代码库上修改代码并部署，会是怎样的体验？ 以下是一位同事的真实反馈： “业务中台在外面宣传的是业务方7í24小时想发就发，实际远远做不到，很多限制，效率很低，体验过才知道。” 2. 认知成本 就阿里巴巴的业务中台体系来说，不可谓不复杂，其中有大量的新概念——业务身份、活动（Activity）、领域服务（Domain Service)、领域能力（Ability）、扩展点（ExtensionPoint），扩展实现（Extension）、奥创、Lattice、业务容器，等等。这些概念显著增加了开发者的认知负荷，让系统变得异常复杂。 正如尼古拉斯所说， 在现代生活中，简单的做法一直难以实现，因为它有违某些努力寻求复杂化以证明其工作合理性的人所秉持的精神。 3. 稳定性成本 现在的业务中台很精巧，同时也很脆弱。它与所有的大设计（Big design up front）犯了同一个错误，即忽视了那些“对未知的未知（Unknow unknows）”。业务的灵活性和差异性导致我们很难提前抽象，因为抽象在归纳之后，可是新的业务需求还没出现。 理想的情况是我们能预见所有的业务变化，提前做抽象，预留所有的业务扩展点，这样针对不同的业务只需要在扩展点中定制就好了。但没人能预见未来，这样就难免要改动平台代码，比如加一个扩展点。由于平台代码是被所有业务共享的，这就给稳定性带来了极大的隐患。比如，A业务改动了平台代码，然而B业务什么也没做就出了故障。 解决中台的困境 为了解决上述业务中台碰到的问题，我认为可以尝试做以下工作。 （1）把业务能力做薄。做薄是为了解耦，业务最懂自己，因此不要尝试去“control”它们。中台可以更多地关注与“业务无关”的能力建设，比如稳定性、性能、监控、运维工具等非功能属性。 （2）把中台能力做强。除了非功能属性，中台还可以通过建设丰富的业务解决方案库、业务组件库等工具，赋能业务快速发展，用enable代替control。 （3）把系统结构做简单。这一点很好理解，因为复杂是万恶之源。 1. 解耦 协作成本和稳定性问题都是由前台业务和业务中台的深度耦合造成的，因此，中台这种集中式的代码管控和部署的“大单体”模式亟需改变。解决方案显而易见，解决“大”的问题的方法就是分而治之，解决“单体”的问题的方法就是服务化。 也就是说，前台业务和业务中台的关系，必须从代码和部署的耦合状态变成分布式的服务关系，如图3所示。就像BPaas这个名字所隐喻的一样，让业务中台真正变成服务（Business Platform as a Service）。 图3 业务和中台解耦 解耦不难，关键是这一刀要从哪里切？我认为这一刀可以切在“业务无关”这个界面上。 所谓“业务无关”，就是想办法在业务中台中找到和具体业务无关的内核（kernel）。这样既可以最大程度上复用中台能力，又可以保持业务的灵活性。比如，所有的业务都需要对数据进行增删改查（CRUD）操作，这就是业务无关的，而业务的各种校验逻辑是业务相关的。 当然，这个边界具体放在哪里，还是要针对具体情况进行具体分析，但结果肯定会比现在的业务中台要薄。 例如对于商品业务，淘宝的商品、盒马的商品、零售通的商品之间可能存在巨大的差异，它们的扩展属性和业务校验规则都不一样。这种情况就适合把中台做得很薄，让其退化成EJB中的Entity Bean。这也是业务中台的底线，即业务中台要做统一的数据收口，防止产生数据孤岛。 即使是薄中台，也是极其有价值的，因为它能帮助我们解决商品的存储、存储扩展、性能、稳定性、工具（商品360、forest类目管控）、搜索构建等一系列和业务无关的非功能属性问题，这就足够了。 但对于支付业务，情况可能会不一样。支付的共性相对比较强，中台可以做得厚一点。比如，对接不同的支付渠道、建设统一的支付网关等业务都存在支付的共性需求。 2. Platform as Code 简单不等于简陋，帮助业务快速发展的主要职责不能丢。 假如需要启动一个全新的业务，因为中台做薄了，之前在业务中台沉淀的业务能力很多都释放给业务自己了，中台要怎么帮助快速搭建新业务呢？ 这时可以考虑借鉴DevOps中的概念——IaC（Infrastructure as Code），这里暂时将它命名为PaC（Platform as Code）。 如图4所示，可以由中台的产品经理（Product Designer，PD）和研发人员共同设计一个针对不同业务场景的中台解决方案库。 图4 PaC中台解决方案 具体的实现方式可以是用Maven的Archetype，并用版本的方式进行迭代。这样当面对一个全新的业务时，业务方可以快速地通过Archetype生成一个实际可用的业务应用，再由前端业务部署到自己的服务器集群中，按需修改完成自己的业务诉求即可上线。之后如有需求变更，业务就可以按照自己的意愿在自己的“一方乐土”上自由奔跑了。 实际上，重复（Duplication）也是一种重用（Reuse）。这样做可能会导致不同的业务代码之间出现一些代码冗余（实际上，出于快速发展和稳定性的考虑，有些业务已经在采用重复代码的方式，比如淘特、APOS）。然而，在稳定性、可理解性、可维护性、工程效率的综合权衡之下，这点代码冗余会显得微不足道。 正如Neal Ford在《软件架构》一书中提到， 当一个架构师设计一个系统的时候，他如果选择重用，那么同时也选择了耦合。因为重用不管是通过组合（Composition）还是继承（Inheritance）实现，都会引入耦合。然而，如果你不想耦合，可以采用重复代替重用。 也就是说，架构需要在重用高耦合和重复低耦合之间做一个权衡，所以代码重复（Ctrl+C/Ctrl+V）并不总是差的，而是一种设计选择。 3. Platform as Code + 组件化 在PaC的基础上，可以进一步考虑组件化，即把一些共用的逻辑封装成组件，打造一个“中台组件库”，如图5所示。业务可以按需组合这些组件去实现业务，同时，业务也可以把自己沉淀的组件“反哺”给组件库，形成一个良性循环的“大集市”——好的组件会被大量使用、迭代和演化，不好的组件会被逐渐淘汰。 图5 PaC+组件化的中台解决方案 然而，业务具有易变、不确定、复杂和模糊性（Volatility Uncertainty Complexity Ambiguity，VUCA），很难标准化，如何设计组件并让组件和业务之间松耦合——即不要让组件绑架业务，困住业务的手脚，将是一个极大的挑战。这也是我在一开始提出PaC的时候，没有提组件化的原因。 本文节选自《程序员的底层思维》一书，想要了解更多相关内容，欢迎阅读本书！ ▊ 《程序员的底层思维》 张建飞 著 这是一本超越具体编程技法的技术书：职场晋升不仅需要技术能力，更重要的是思维能力。本书带你学会用底层思维解决复杂技术问题，突破职场“天花板”。 这也是一本培养思维能力的通用技能书：打破认知局限，培养通用的思维能力。本书帮你跳出思维定势，轻松解决生活及工作中遇到的问题。 本书涵盖程序员应知应会的16种思维能力，共18章，分为三部分。 第一部分主要介绍抽象思维、逻辑思维、结构化思维、批判性思维、维度思维、分类思维、分治思维、简单思维，以及成长型思维等解决日常问题的基础思维能力。 第二部分结合软件行业的特点，主要介绍解耦思维、契约思维、模型思维、工具化思维、量化思维、数据思维，以及产品思维等专业思维能力。 第三部分主要是对上述思维能力的综合运用实践。 粉丝专享六折优惠，扫码即购！ 活动推荐AI 前线为粉丝准备了《程序员的底层思维》纸质书籍 3 本！长按识别下图小程序，参与抽奖活动，由小程序随机抽出 3 位，每人赠送一本书。开奖时间：4 月 4 日（下周一） 18:30，获奖者每人获得一本。 你也「在看」吗？??