中台框架之困-技术圈

中台讨论了好几年，我自己之前研究中台或参与中台建设也有近两年的时间了，那中台那一套方法论还香吗？

很多公司、团队引入中台的目的无外乎两个：降本增效+业务创新。

那中台究竟怎么和这两件事产生关系的呢？

我们首先看第一个问题，和降本增效的关系。

我们可以想象下，影响整体研发效率的原因有哪些呢？

一、协作成本

研发不等于写代码，实际上我们交付一个需求的大部分时间不是在写代码，而是在沟通和协调上，跟人打交道的时间远远大于跟机器打交道的时间。

如果中台深度介入到业务侧系统太多，会导致协作成本增加。同时过度的工程耦合进一步带来协作成本的增加。

星环是阿里中台2.0的解决方案，一些业务同学反应过星环的问题：

星环对外宣称业务方可以7*24小时想发就发，事实上远远做不到，有很多限制，效率也很低，只有体验过才知道多恶心。

二、认知成本

使用星环效率低的另一个原因，是需要巨大的认知成本。

星环里面有一堆新概念：业务身份、活动、领域服务、领域能力、扩展点、扩展实现、奥创、Lattice、业务容器等。

研发同学的体感可能是这样的：

在现代生活中，其实简单一直是很难实现，因为很多人寻求用复杂的方式做事，证明其工作的合理性和自己的努力。

三、稳定性成本

《反脆弱》里说：越是精巧的东西越脆弱。

现在业务中台往往设计的很巧妙，但也证明了其背后的脆弱性。

架构是对现实业务的映射。但现实中业务是灵活的、有差异的，我们很难提前进行归纳、抽象。因为归纳、抽象是建立在现状之上的，没有现状谈何抽象。

同时由于平台代码是被所有业务共享的，这就给稳定性带来极大的隐患，可能出现A改了代码，导致B挂了。

冗余代码是一种解决这种稳定性问题的方式，通过冗余代码实现更好的隔离，两者互不影响。

但在复用、成本、稳定性之间权衡取舍出一种解决方案就非常考验技术能力。

中台之变

怎么让业务中台避免以上问题呢？

协作成本与稳定性问题之所以出现，是因为前台与中台之间的深度耦合造成的。

星环这种集中式的代码控制和部署的大单体模式急需解决。

解决“大”这种问题，最好的方式就是分而治之，也就是让其服务化。

可以让前台与中台的关系，从代码与部署的耦合状态，变为分布式的服务关系。

可以尝试以下几类事情。

一、业务能力做薄

做薄是为了解耦，只有业务最懂自己业务，不要尝试去控制他们，可以套用张一鸣的那句话“context，not control”。中台可以更多关注在业务无关的能力建设上，比如稳定性、监控、性能、运维工具等非功能属性的事情上。

二、中台能力做强

中台除了建设上面提到的非功能性的属性，还可以建设丰富的业务解决方案库、业务组件库等框架与工具，赋能于业务，让其快速发展。做强主要体现在这里。

三、系统结构简单

复杂是万恶之源，太精巧也代表着太脆弱。

以商品业务为例

淘宝的商品、盒马的商品、零售通的商品之间存在着巨大的差异，他们的扩展属性也不同，业务校验规则也不同。

这种情况下，合适的方式是将中台做薄，让其退化成类似于Entity Bean的形式。

如果这种形式的中台，其实他就是对外提供了API，解决了商品的存储、扩展、性能、稳定性、工具、搜索等和业务不相关的功能。

我们讨论的更多的是对存量老业务和中台的协作方式上，那对于新业务有没有真正提效的方式呢？

可以通过脚手架的方式解决。比如下图：

一个值得思考的问题是，这个脚手架的生成操作究竟由谁决定呢？

再进一步的话，可以在脚手架基础之上增加一些组件库。

也就是把一些公用的逻辑封装成组件，打造一个中台组件库，业务可以按需组合这种组件，实现自己的业务定制。

但打造有价值、可迭代的组件不是件轻松的事情，同样需要考虑组件与业务之间的耦合关系，不要让组件绑架业务，困住业务的手脚。