业务挑战

在很多的互联网领域中，会根据领域服务来建设分布式架构；而随着业务领域的不断交叉，业务生命周期的不断延长，从招商、选品、供应链、仓储、营销/导购、下单、履约、物流、售后等，其业务链路长、业务逻辑上游对下游又有影响。在这业务主线的链路上，又建设了众多系统进行支撑，比如商品平台、购物车系统、下单系统、履约系统、优惠系统、物流系统、供应链系统等，围绕这些核心系统，还有数不清的辅助系统/服务。

业务型平台在面对业务数量和类型的不断增加，在支持效率和成本上都受到挑战，单靠平台侧的人员无法独立解决好这个问题，需要和业务团队的同学更好的协同才有可能。在微服务与云原生 篇中，我们讨论过某个交付的系统是受该组织的内部结构极大的影响；那么在每一次跨团队的对焦、分析、协作中，也存在着很多的痛点。

业务与平台耦合性高

业务本身会分成“垂直”和“水平”两个维度。在一次业务交互过程中，其业务复杂度就在于业务“垂直”维度与“水平”维度产生的叠加，并由叠加而产生的业务规则上的冲突。针对业务叠加的处理，各系统基本上还是基于 SPI 扩展机制，这些 SPI 缺少按照业务维度进行组织与隔离。在业务种类少，不同业务在逻辑叠加度小的情况下还是可以在很大程度上解决业务可定制化、多样化的问题。但随着各类业务越来越多时，就会导致各类业务在同一个扩展点上的叠加效应越来越突出。其中最薄弱的点就是 SPI 接口中是否需要执行的过滤方法（filter）的编写。一旦过滤方法写得不好，就可能会造成不该执行的逻辑被执行了，或者把后续本该执行的逻辑给跳过了。

在共享的各个平台中，提供给业务方可扩展的 SPI 多达几百个。一个业务的最终逻辑是否正确，就需要该业务确保这几百个 SPI 决策树中每个节点注册的位置正确，过滤方法中的过滤条件正确，同时执行逻辑也必须确。不仅如此，本业务注册的 SPI 都正确了，还需要其他的业务注册的 SPI 也都是正确的，这最终导致了业务与业务之间高度耦合。这种耦合，又进一步导致了各业务方之间、业务方与平台之间的大量联调、集成与回归等配合工作，无法做到自助式的业务设计、开发与交付

协同效率低，口径难以统一

跨团队协作时候，往往缺少业务全链路视角的需求管理机制，协同效率低。往往需求的描述非常简单，或者存在着大量的重复建设的需求。并且需求传递效率低，需要反复沟通。

而从技术同学的角度来看，因为业务与平台耦合性高，因此技术同学也很难给出准确的排期，从而导致双方的预期值有一定差异，对于业务的支持也就难以及时到位。

缺少可复用的业务资产

一个企业的 IT 体系建设是否成熟，业界是有一些指导框架来进行评估的，比如 TOGAF 框架。在该信息系统建设框架中，有一个很重要的系统成熟度评估项目：Enterprise Continumm（企业统一体）。这里面的关键是企业需要建立：

• 架构统一体（Architecture Continuum）：该统一体能从特定架构中提取出可复用的组件到仓库中（Reposity），为后续的类似业务的重用（Gerneralization for future re-use）。在具体应用中，可以从组件仓库中选择可复用的组件并进行与实际应用场景适配（Adaptation for use）。

• 解决方案统一体（Solutions Continuum）：与架构统一体类似，在面对不同的市场，需要能从可复用的解决方案库中选择并快速复制。对于新兴市场的交付，也能提取成可复用的解决方案到资产库中。

中台接入门槛高

对于大型的业务平台而言，其链路流程往往较长，整个迭代周期也会愈发缓慢。而很多的新业务需要的是快速试错，这就需要我们提供精简的、能够快速转向的中台能力。