业务中台的困境、及可能的解，java 基础笔试题判断题

通过下面新人的日报片段，可以感受下其高昂的认知成本。

KISS 是一种美德，正如尼古拉斯所说：

“在现代生活中，简单的做法一直难以实现，因为它有违某些努力寻求复杂化以证明其工作合理性的人所秉持的精神。”

稳定性成本

=====

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

现在的业务中台很精巧，同时也很脆弱。跟所有的“Big design up front”犯了同一个错误，即忽视了 unknow unkowns。业务的灵活性、差异性，导致我们很难提前抽象，因为抽象是归纳之后的抽象，可是新的业务需求还没出现，你让我怎么归纳，怎么抽象？

理想的情况是我能预见所有的业务变化，提前做抽象，把所有的业务扩展点都预留好，这样不同的业务只需要在扩展点中定制就好了。但没人能预见未来，难免会动到平台代码，加一个扩展点啥的，因为平台代码是被所有业务共享的，这就给稳定性带来了极大隐患。会出现 A 业务改了平台代码，B 业务啥事也没做，就出了故障。

这就是为什么对稳定性要求比较高的业务场景，比如 APOS，宁愿冗余代码，也不愿被动出故障。实际上，代码冗余（Repeat）也是一种代码复用（Reuse），在很多情景下，Repeat 是解耦更彻底，更简单高效的做法。比如在写测试代码的时候，用 copy-paste 的方式去准备测试数据就是很好的解耦方式，通过代码的 Repeat，可以更好的隔离不同 test case 之间的相互影响。

总之，在精巧的、不稳定的复用和简单、高效的重复之间，后者会是一个不错的选择。软件架构无其他，只是权衡（trade-off）。DRY（Dont Repeat Yourself）和 Decoupling（解耦）都是对的，选择哪种方案，应该是仔细权衡后的选择，而不应该是“拍脑袋”或基于”屁股“的选择。

可能的解决方案

=======

针对上面的问题，如果让我来重新设计业务中台的话，我会尝试做以下事情：

1. 把业务能力做薄。做薄是为了解耦，业务自己最懂自己的业务，不要尝试去 control 他们，放过他们，也放过自己。中台可以更多的关注在“业务无关”的能力建设上，比如稳定性、性能、监控、运维工具等非功能属性。

2. 把中台能力做强。除了非功能属性，中台还可以通过建设丰富的业务解决方案库、业务组件库等工具，赋能业务快速发展，用 enable 代替 control。

3. 把系统结构做简单。复杂是万恶之源，星环太精巧了。

解耦

==

协作成本、稳定性问题皆是因为前台业务和业务中台的深度耦合造成的。因此，星环的这种集中式的代码管控和部署的“大单体”模式亟需得到解决。

其实解决方案大家都知道，解决“大”的问题就是分而治之，解决“单体”的问题就是服务化。

也就是说，前台业务和业务中台的关系，必须从代码和部署的耦合状态，变成分布式的服务关系，就像 BPass 这个名字所隐喻的一样，让业务中台真正变成服务（Business Platform as a Service）。

解耦不难，关键是这一刀要从哪里切？我个人认为这一刀可以切在“业务无关”这个切面上。

所谓的“业务无关”就是想办法在业务中台中找到和具体业务无关的内核（kernel）。这样可以最大程度的复用中台能力，又可以保持业务的灵活性。比如所有的业务都需要对数据进行 CRUD 操作，这个就是业务无关的，而业务的各种校验逻辑就是业务相关的。

当然，这个边界具体放在哪，还是要具体情况具体对待，但是肯定会比现在的业务中台要薄。

举两个例子，比较合理的方式可能会像这样：

• 商品业务：同样是电商业务，但是淘宝的商品、盒马的商品、零售通的商品之间可能存在巨大的差异。他们的扩展属性不一样，业务校验规则也不一样。这种情况就适合把中台做得很薄，让其退化成 EJB 中的 Entity Bean。这也是业务中台的底线，即业务中台要做统一的数据收口，防止数据孤岛。

然而，即使是这样的薄中台也是极其有价值的，因为它帮助我解决商品的存储、存储扩展、性能、稳定性、工具（商品 360、forest 类目管控）、搜索构建等一些列和业务无关的非功能属性问题。说实话，这就足够了。

• 支付业务：支付业务的细节我不是特别清楚，但感觉在这里业务中台可以做得厚一点，因为像对接不同的支付渠道，建设统一的支付网关，很多业务都是存在这样的共性需求的。

简单

==

通过上面的解耦工作之后，星环这一套基本就可以 deprecate 掉了，因为业务中台只会保留“业务无关”的通用原子服务，自然也就不需要那套扩展机制了。

于此同时，因为前台业务和业务中台从之前的星环耦合关系，变成简单的服务调用关系、组件组合关系，系统的复杂度和认知成本也会极大的改善。这样前台和中台的同学就都解放了。

我相信，如果能按照这种“业务的归业务，中台的归中台”简单设计，边界清晰，职责清晰。不同 BU 的业务的演变、部署都在自己的掌控中，彼此正交、互不干扰，便可以极大的提升业务团队和中台团队的研发效能。

Platform as Code

================

简单不等于简陋，帮助业务快速奔跑的职责不能丢。

假如有这样一个场景，一个全新的业务需要启动，因为中台做薄了，之前在业务中台沉淀的业务能力很多都释放给业务自己了，中台要怎么帮助新业务快速搭建呢？

这里可以考虑借鉴 DevOps 里的 IaC（Infrastructure as Code）的概念，我暂时给它起个名字叫 PaC（Platform as Code）。

如下图所示，可以由中台的 PD、研发同学设计一个针对不同业务场景的业务解决方案库。

具体的实现方式可以是 Maven 的 Archetype，并用版本的方式进行迭代，这样针对一个全新的业务，业务方可

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

以快速的通过 Archetype，生成一个 functional 的业务应用。再由前端业务部署到自己的服务器集群，按需修改完成自己的业务诉求上线即可。之后需求变更时，业务方便可以按照自己的意愿，在自己的“一方乐土”上自由奔跑了。

实际上这也是一种 Reuse（重用），只不过是用代码 Repeat（重复）的方式在重用。这样做，可能会导致不同的业务代码之间出现一些代码冗余（实际上，有些业务为了快速发展、稳定性的考虑，已经在采用 copy 代码的方式，比如陶特、APOS）。但是请相信我，这点代码冗余，在稳定性、可理解性、可维护性、工程效率的综合权衡之下，会显得微不足道。

正如《Fundamentals of Software Architecture》一书中所说：“There is no best architecture, but the least worst architecture"。