关于后端:行程平台中台化建设

前言

中台的了解

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

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

技术角度

通过形象和组件化的设计，搭建一个灵便的、可疾速应答变动的架构，最大水平的实现雷同逻辑的复用，实现差别点的最小化革新。

业务角度

借助中台现有能力，通过对能力的组合和扩大，疾速反对业务翻新，升高新需要和新业务的试错老本，从而疾速应答不可预知的市场变动。

业务身份

解释

基于业务个性和业务布局转化为技术特色的全链路透传和隔离标识。基于业务身份可做差异化配置，差异化代码隔离，差异化流程编排等差异化逻辑的解决。基于业务身份能够进行整个业务的全链路的出现和治理。业务身份之间的数据和权限应该严格隔离。

业务身份定义

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

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

业务线的差别在业务倒退过程中会因为用户的需要不同的变动，中台要做的是在业务身份从单个拆成多个，或者从多个合成单个的时候，可能疾速反对业务身份的变更。

扩大点

解释

基于业务身份实现业务差异化最小化开发的能力。由中台形象扩大点的能力，业务方依据本身需要，实现个性化的逻辑解决。在此基础上，中台也可提供扩大点的几种通用实现，业务方可依据业务个性进行抉择。

业务中台架构

阿里大中台小前台繁难架构

特点

• 前台之间的流量入口互相独立，业务中台间接对接端面逻辑。
• 业务扩大点贯通整个后盾零碎，包含和端面的交互。
• 不同业务线对中台同个后果的不同解析通过配置化的形式实现，如：同个业务解决的异样的不同展现，同个字段的不同展现文案。

劣势

• 整个业务中台间接对接端面，有新业务线呈现的时候，中台团队可依据业务线个性疾速抉择相近业务线进行最小化的配置和开发，从而疾速反对整个业务线的上线。

劣势

• 业务扩大点贯通整个后盾零碎，扩大点多且芜杂，随着业务线接入越来越多，代码的可维护性会越来越低。
• 资源的竞争会越来越重大，包含开发环境的竞争，公布窗口的竞争等。

普惠中台化繁难架构

特点

• 前台之间的流量入口对立，业务线向上对接端面逻辑，向下对接中台主链路。
• 业务扩大点只贯通业务中台外部。不同业务线对中台同个后果的不同解析通过业务线的应用层独自解决，如：同个业务解决的异样的不同展现，同个字段的不同展现文案。

劣势

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

劣势

• 整个业务中台不间接对接端面，有新业务线呈现的时候，必须新起一个新的利用，对接业务中台和端面，有肯定的老本，对疾速反对新业务敌对性偏低。

行程平台中台化的落地

行程平台业务架构

行程平台中台化技术架构

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

BCF 流程编排示例

BCF 扩大点示例

扩大点的演进思路

模式一

特点

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

劣势

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

劣势

• 因为中台依赖所有扩大点的实现包，因而在扩大点越来越大的状况下，中台包会越来越大，且扩大点外部能够做内存解决，也能够做近程调用，因而中台依赖的包会越来越多，由此带来的稳定性问题会减少。
• 多个业务线同时批改各自业务方扩大点带来的编译抵触，公布抵触会越来越重大。
• 中台通用逻辑会对所有业务线失效，如果中台通用逻辑呈现 bug，可能会导致所有业务线的不可用。

模式二

特点

• 中台业务逻辑层只定义扩大的 spi，所有的扩大点业务逻辑实现都在业务方的独自利用进行实现。中台逻辑调用扩大点是近程调用。

劣势

• 扩大点的实现都是近程调用，且中台业务层不间接依赖扩大点的实现，能够无效躲避由此带来的我的项目臃肿问题。
• 可躲避因为业务线对雷同的依赖导致的包版本不同的抵触问题，稳定性问题。
• 各业务线之间，业务线和中台之间在代码开发，编译，公布过程中齐全隔离。

劣势

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

模式三

特点

• 中台通用能力通过 jar 包形式集成在业务线的逻辑中，中台依据业务需要一直的演进和积淀中台通用能力，业务线可依据本人需要抉择中台相应版本的 jar 包。且扩大点的调用都是本地调用。

劣势

• 扩大点本地调用，性能较好。
• 业务线间接的代码开发、编译、公布互不影响。且业务线只依赖中台的通用 jar 包和本人的扩大点实现 jar 包，可躲避因为业务线对雷同的依赖导致的包版本不同的抵触问题，稳定性问题。
• 中台通用逻辑会对只对以后业务线失效，如果中台通用逻辑呈现 bug，只会影响以后业务。

劣势

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

（本文作者：柳健强）

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