中台框架之困
中台讨论了好几年，我自己之前研究中台或参与中台建设也有近两年的时间了，那中台那一套方法论还香吗？
很多公司、团队引入中台的目的无外乎两个：降本增效+业务创新。
那中台究竟怎么和这两件事产生关系的呢？
我们首先看第一个问题，和降本增效的关系。
我们可以想象下，影响整体研发效率的原因有哪些呢？
一、协作成本
研发不等于写代码，实际上我们交付一个需求的大部分时间不是在写代码，而是在沟通和协调上，跟人打交道的时间远远大于跟机器打交道的时间。
如果中台深度介入到业务侧系统太多，会导致协作成本增加。同时过度的工程耦合进一步带来协作成本的增加。
星环是阿里中台2.0的解决方案，一些业务同学反应过星环的问题：
星环对外宣称业务方可以7*24小时想发就发，事实上远远做不到，有很多限制，效率也很低，只有体验过才知道多恶心。
二、认知成本
使用星环效率低的另一个原因，是需要巨大的认知成本。
星环里面有一堆新概念：业务身份、活动、领域服务、领域能力、扩展点、扩展实现、奥创、Lattice、业务容器等。
研发同学的体感可能是这样的：
改动的代码其实不多，但中间会遇到很多问题
星环上接口特别多，注释不是很明确，找到确定的接入点比较困难
buy2对外暴露的接口的参数、切入点的参数、调用其他系统接口的参数，在文档上面没有明确的关系关联，寻找关联关系比较困难
切入点的入参很多是字符串格式，并且参数众多，是否所有参数都需要有值，都是一个未知数
营销侧希望把值添加在指定字段上，但找了半天没找到合适的扩展点
代码编译时间很长、单元测试跑半天还是有很多没跑通
在现代生活中，其实简单一直是很难实现，因为很多人寻求用复杂的方式做事，证明其工作的合理性和自己的努力。
三、稳定性成本
《反脆弱》里说：越是精巧的东西越脆弱。
现在业务中台往往设计的很巧妙，但也证明了其背后的脆弱性。
架构是对现实业务的映射。但现实中业务是灵活的、有差异的，我们很难提前进行归纳、抽象。因为归纳、抽象是建立在现状之上的，没有现状谈何抽象。
同时由于平台代码是被所有业务共享的，这就给稳定性带来极大的隐患，可能出现A改了代码，导致B挂了。
冗余代码是一种解决这种稳定性问题的方式，通过冗余代码实现更好的隔离，两者互不影响。
但在复用、成本、稳定性之间权衡取舍出一种解决方案就非常考验技术能力。
中台之变
怎么让业务中台避免以上问题呢？
协作成本与稳定性问题之所以出现，是因为前台与中台之间的深度耦合造成的。
星环这种集中式的代码控制和部署的大单体模式急需解决。
解决“大”这种问题，最好的方式就是分而治之，也就是让其服务化。
可以让前台与中台的关系，从代码与部署的耦合状态，变为分布式的服务关系。
可以尝试以下几类事情。
一、业务能力做薄
做薄是为了解耦，只有业务最懂自己业务，不要尝试去控制他们，可以套用张一鸣的那句话“context，not control”。中台可以更多关注在业务无关的能力建设上，比如稳定性、监控、性能、运维工具等非功能属性的事情上。
二、中台能力做强
中台除了建设上面提到的非功能性的属性，还可以建设丰富的业务解决方案库、业务组件库等框架与工具，赋能于业务，让其快速发展。做强主要体现在这里。
三、系统结构简单
复杂是万恶之源，太精巧也代表着太脆弱。
以商品业务为例
淘宝的商品、盒马的商品、零售通的商品之间存在着巨大的差异，他们的扩展属性也不同，业务校验规则也不同。
这种情况下，合适的方式是将中台做薄，让其退化成类似于Entity Bean的形式。
如果这种形式的中台，其实他就是对外提供了API，解决了商品的存储、扩展、性能、稳定性、工具、搜索等和业务不相关的功能。
我们讨论的更多的是对存量老业务和中台的协作方式上，那对于新业务有没有真正提效的方式呢？
可以通过脚手架的方式解决。比如下图：
一个值得思考的问题是，这个脚手架的生成操作究竟由谁决定呢？
再进一步的话，可以在脚手架基础之上增加一些组件库。
也就是把一些公用的逻辑封装成组件，打造一个中台组件库，业务可以按需组合这种组件，实现自己的业务定制。
但打造有价值、可迭代的组件不是件轻松的事情，同样需要考虑组件与业务之间的耦合关系，不要让组件绑架业务，困住业务的手脚。