行程平台中台化建设

前言

中台的理解

中台化建设不是简单的技术建设，整个运营、产品、技术团队的组织架构划分都会影响中台化建设。中台化建设最重要的是实现能力的灵活复用和扩展的成本最小化。由此会带来的中台臃肿导致的稳定性问题，环境资源竞争问题会在中台化建设中凸显。

中台化带来的不仅是技术上的变革，更带来的是产品思维模式的转变。中台能力一旦成熟，新的业务线接入、或者是老业务线接入中台其他业务线通用能力，从产品侧应该考虑的是基于中台现有能力基础上，最好、最快的实现新需求的开发，和新业务线的快速接入。

技术角度

通过抽象和组件化的设计，搭建一个灵活的、可快速应对变化的架构，最大程度的实现相同逻辑的复用，实现差异点的最小化改造。

业务角度

借助中台现有能力，通过对能力的组合和扩展，快速支持业务创新，降低新需求和新业务的试错成本，从而快速应对不可预知的市场变化。

业务身份

解释

基于业务特性和业务规划转化为技术特征的全链路透传和隔离标识。基于业务身份可做差异化配置，差异化代码隔离，差异化流程编排等差异化逻辑的处理。基于业务身份可以进行整个业务的全链路的呈现和管理。业务身份之间的数据和权限应该严格隔离。

业务身份定义

团队之前达成的业务身份定义的一些共识

基于业务身份中台化的建议

业务线的差异在业务发展过程中会因为用户的需求不同的变化，中台要做的是在业务身份从单个拆成多个，或者从多个合成单个的时候，能够快速支持业务身份的变更。

扩展点

解释

基于业务身份实现业务差异化最小化开发的能力。由中台抽象扩展点的能力，业务方根据自身需求，实现个性化的逻辑处理。在此基础上，中台也可提供扩展点的几种通用实现，业务方可根据业务特性进行抉择。

业务中台架构

阿里大中台小前台简易架构

特点

• 前台之间的流量入口相互独立，业务中台直接对接端面逻辑。
• 业务扩展点贯穿整个后台系统，包括和端面的交互。
• 不同业务线对中台同个结果的不同解析通过配置化的方式实现，如：同个业务处理的异常的不同展示，同个字段的不同展示文案。

优势

• 整个业务中台直接对接端面，有新业务线出现的时候，中台团队可根据业务线特性快速选择相近业务线进行最小化的配置和开发，从而快速支持整个业务线的上线。

劣势

• 业务扩展点贯穿整个后台系统，扩展点多且杂乱，随着业务线接入越来越多，代码的可维护性会越来越低。
• 资源的竞争会越来越严重，包括开发环境的竞争，发布窗口的竞争等。

普惠中台化简易架构

特点

• 前台之间的流量入口统一，业务线向上对接端面逻辑，向下对接中台主链路。
• 业务扩展点只贯穿业务中台内部。不同业务线对中台同个结果的不同解析通过业务线的应用层单独处理，如：同个业务处理的异常的不同展示，同个字段的不同展示文案。

优势

• 业务扩展点只贯穿整个业务中台，扩展点较为收拢，并且在业务中台之前，业务方可在对接端面那层做前置逻辑处理，从而避免扩展点的滥用，大大降低了扩展点的梳理和扩展逻辑的梳理，后期可维护性较高。

劣势

• 整个业务中台不直接对接端面，有新业务线出现的时候，必须新起一个新的应用，对接业务中台和端面，有一定的成本，对快速支持新业务友好性偏低。

行程平台中台化的落地

行程平台业务架构

行程平台中台化技术架构

• 行程平台基于原子组件和BCF流程编排，对原子组件进行编排，从而组合成为一个个组件（如：开城校验原子组件+司机认证原子组件+其他多个原子组件，编排为司机发单组件）。
• 原子组件内部之间的差异通过BCF扩展点进行代码的隔离和差异的开发。业务中台通过组建对接业务线，业务线通过业务特性可对行程平台的组件进行编排。

BCF流程编排示例

BCF扩展点示例

扩展点的演进思路

模式一

特点

• 中台业务逻辑层直接集成业务线的扩展点jar包或者子项目进行开发、打包、编译、部署。一次请求处理的N多个扩展点都属于本地调用。

优势

• 扩展点本地调用，性能较好。子项目可以通过单独的jar包进行隔离，可做到代码完全隔离。

劣势

• 由于中台依赖所有扩展点的实现包，因此在扩展点越来越大的情况下，中台包会越来越大，且扩展点内部可以做内存处理，也可以做远程调用，因此中台依赖的包会越来越多，由此带来的稳定性问题会增加。
• 多个业务线同时修改各自业务方扩展点带来的编译冲突，发布冲突会越来越严重。
• 中台通用逻辑会对所有业务线生效，如果中台通用逻辑出现bug，可能会导致所有业务线的不可用。

模式二

特点

• 中台业务逻辑层只定义扩展的spi，所有的扩展点业务逻辑实现都在业务方的单独应用进行实现。中台逻辑调用扩展点是远程调用。

优势

• 扩展点的实现都是远程调用，且中台业务层不直接依赖扩展点的实现，可以有效规避由此带来的项目臃肿问题。
• 可规避由于业务线对相同的依赖导致的包版本不同的冲突问题，稳定性问题。
• 各业务线之间，业务线和中台之间在代码开发，编译，发布过程中完全隔离。

劣势

• 扩展点远程调用，性能较差。且扩展点的实现在业务方，中台无法把控业务方的具体实现。
• 中台通用逻辑会对所有业务线生效，如果中台通用逻辑出现bug，可能会导致所有业务线的不可用。

模式三

特点

• 中台通用能力通过jar包方式集成在业务线的逻辑中，中台根据业务需求不断的演进和沉淀中台通用能力，业务线可根据自己需求选择中台相应版本的jar包。且扩展点的调用都是本地调用。

优势

• 扩展点本地调用，性能较好。
• 业务线直接的代码开发、编译、发布互不影响。且业务线只依赖中台的通用jar包和自己的扩展点实现jar包，可规避由于业务线对相同的依赖导致的包版本不同的冲突问题，稳定性问题。
• 中台通用逻辑会对只对当前业务线生效，如果中台通用逻辑出现bug，只会影响当前业务。

劣势

• 中台的通用jar包版本升级需要考虑兼容问题。

（本文作者：柳健强）

本文系哈啰技术团队出品，未经许可，不得进行商业性转载或者使用。非商业目的转载或使用本文内容，敬请注明“内容转载自哈啰技术团队”。