汽车电商平台发展趋势：汽车之家电商系统架构演进与平台化架构实践

威哥 2022-11-06 11:30:17 650

汽车电商平台发展趋势：汽车之家电商系统架构演进与平台化架构实践服务拆分的好处无需赘述，但是要实现业务价值，不是看单个服务的能力，而是要协调所有服务保证企业端到端业务流程的成功。业务中台是企业业务的集成平台，集成技术必须松散地耦合组成流程的应用程序和资源，否则流程的逻辑将被硬编码到特定的技术平台中，更改可能代价高昂，从而违背业务流程复用的整个目标。其二是使用服务编排。通过服务编排现有微服务进行服务组合服务，然后一次性的返回前台需要的信息。不同业务线的能力执行不同的流程，通过图形化、XML、JSON的编排框架，即可以让流程清晰，也可以屏蔽代码细节。比如在汽车电商领域，业务身份我们通过人、货、场三个维度进行抽象。人的维度有是否开通会员、是否是认证车主、开通了哪些增值服务等；货的维度有商品类型（整车、实物商品、虚拟商品等），交付方式（核销、兑换、4S店交付）等；场的维度有线上下单、线下下单、在哪个线上商城下单，在哪个交付店下单、商品投放渠道来源等。根

如图所示：整个订单平台化架构分为四层，从下往上依次是：

基础设施层：提供存储、消息、RPC等中间件

基础服务层：按域组织的基础服务、域服务内针对不同业务的差异提供扩展点。

业务能力层：串联不同域服务形成可供外部使用的业务能力，比如下单、支付等。

业务流程层：对业务能力进行编排、形成订单交易流程、完成订单交易过程。

业务层：制定业务身份、扩展点实现以及业务流程配置等，实现不同业务差异。

整个订单平台化架构升级实践过程，总结为以下几点：

业务身份化

业务身份的概念最早由阿里巴巴提出，业务平台在对各业务同时提供服务时，需要能区分每一次业务服务请求的业务身份要素，以便提供差异化个性化的服务；因此需要对企业各业务的身份和特征进行建模和区分，其产出即为业务身份。业务身份具有唯一性，业务身份类似于身份证号码一样，需要保证在整个业务中台上必须是唯一的。

有了业务身份业务中台就可以针对抽象这个业务流程和业务规则，并基于业务身份实现服务路由、业务监控。其次业务身份就类似SAAS系统中的租户的概念，不同的业务方在中台通过业务身份进行数据权限隔离，这样能保证各业务的运营只能看见自己业务部分的数据。

比如在汽车电商领域，业务身份我们通过人、货、场三个维度进行抽象。人的维度有是否开通会员、是否是认证车主、开通了哪些增值服务等；货的维度有商品类型（整车、实物商品、虚拟商品等），交付方式（核销、兑换、4S店交付）等；场的维度有线上下单、线下下单、在哪个线上商城下单，在哪个交付店下单、商品投放渠道来源等。根据这些维度确定了唯一的业务身份后，每笔交易的业务流程就确定下来了。

服务编排化

电商业务中台整体采用微服务架构、将整个电商系统拆分为商家中心、用户中心、商品中心、促销中心、交易中心、履约中心、售后中心。每个中心在逻辑上分成了带有业务属性的能力和不带业务属性的基础能力两层。基础能力层关注领域模型的实体属性、行为、事件，不会随着业务的需求调整而发生变化，聚焦于行业共性行为、收敛业务模型，保障基础服务的稳定性。带有业务属性的能力是在基础能力层之上通过服务组合、流程编排之类的技术手段，构成面向业务的解决方案，完成业务共性到个性化的转变。有两种常见的做法如下：

其一是使用硬编码来实现。随着不同业务线的逻辑不断增加，各个业务能力调用的基础能力会变得盘根错节，很难做到可配置、灵活化。当发生需求变更的时候，测试人员很难评估修改的影响范围，回归测试的成本周期长，这样很难真正做到敏捷开发、快速响应业务。

其二是使用服务编排。通过服务编排现有微服务进行服务组合服务，然后一次性的返回前台需要的信息。不同业务线的能力执行不同的流程，通过图形化、XML、JSON的编排框架，即可以让流程清晰，也可以屏蔽代码细节。

服务拆分的好处无需赘述，但是要实现业务价值，不是看单个服务的能力，而是要协调所有服务保证企业端到端业务流程的成功。业务中台是企业业务的集成平台，集成技术必须松散地耦合组成流程的应用程序和资源，否则流程的逻辑将被硬编码到特定的技术平台中，更改可能代价高昂，从而违背业务流程复用的整个目标。

服务编排框架

在服务编排领域，已经有很多的工业界解决方案，我们参考了 基于API网关的服务编排[13]，基于工作流系统的编排框架Flowable和Activiti[14]、基于微服务架构编排框架的Netflix Conductor[16]和Zeebe[17]。 通过对技术原理进行分析，发现它们都存在某些程度上的不足，无法应用到电商业务中台的服务编排，最终我们选用 Apache Camel [18] 做为服务编排的底层引擎进行二次封装开发。Apache Camel 诞生于2007年，2009年前后成为Apache顶级项目更名为Apache Camel，目前最新版本是3.0。Apache Camel的优点在于在发布后十多年的时间里，已经拥有三百多种扩展组件；扩展机制也极其方便和灵活；通过开箱即可用的最佳实践来解决应用集成问题； 它基于事件驱动的架构，有着良好的性能和吞吐量[19]。

以下是一个简单的服务流程编排样例：

汽车电商平台发展趋势：汽车之家电商系统架构演进与平台化架构实践(1)

业务中台使用服务编排技术一方面可以将交易的能力自动识别出来作为组件可视化的呈现，形成能力地图；另一方面，基于这些基础能力实现服务流程的编排，能够通过拖拉拽的方式快速搭建出适合业务的全部或者部分交易流程，类似积木，复用基础组件，灵活搭配，进而实现电商企业级能力的复用，节约开发成本，快速赋能业务的目标。

扩展点框架

扩展点的全称是Service Provider Interface，简称为SPI。是Java提供的一套用来加载和运行第三方扩展的接口实现类的机制，一般用在组件替换和框架扩展的场景。SPI将服务接口与服务实现分离以达到解耦、提升了应用程序的可扩展性。在程序设计中，模块之间采用面向接口编程而不做具体的实现类引用，通过动态加载实现类达到应用程序的插件化。

COLA框架是阿里巴巴技术专家提出的一种应用架构的扩展点框架[20] 。COLA框架的扩展是通过注解的方式来实现的，Extension扩展注解里面使用用例（useCase）、业务（bizId）、场景（scenario）三个属性用来标识身份。使用COLA框架的扩展点可以在代码层面支持不同业务身份的逻辑隔离，因为不同的逻辑分散在不同的实现类里面，符合软件设计的开闭原则。

COLA框架在应用Spring上下文初始化完毕阶段，开始扫描带有Extension注解的bean进行扩展点注册，以Map的结构存储，Key是useCase、bizId、scenario的字符串拼接，value是该bean。

在运行时，通过业务身份定位扩展点实现类，然后执行扩展点实现的逻辑。定位扩展点实现的时候支持三层路由，首先会按照useCase bizId scenario找扩展点实现，如果没有则按照useCase bizId scenario默认值查找，如果还未找到则根据useCase bizId默认值 scenario默认值查找，具体原理如图所示：

汽车电商平台发展趋势：汽车之家电商系统架构演进与平台化架构实践(2)

对于简单的业务场景，对应用系统的高扩展性、业务隔离的非功能性要求并不多。但是随着同一应用系统支撑的业务变多、业务场景变复杂，在架构层面需要提供统一的扩展解决方案，将变化的业务规则固化下来，这不仅有助于统一技术规范，还能减少硬编码的IF-ELSE、策略模式等因开发人员水平不一致带来的理解上复杂度、规范上的一致性。

通过扩展点机制，业务中台就可以从业务身份和框架层面实现对不同的业务的管理像SAAS管理租户一样管理业务，不同业务身份在不同场景下对预定义的扩展点进行扩展。阿里巴巴的业务中台也正是基于扩展点的思想，实现的核心业务逻辑和技术细节的分离和解耦，共享事业部才能对集团内几百条业务线进行支撑的。

服务编排扩展点应用举例

在验证功能后对电商交易系统的的场景进行了分类，首先选取用户感知度小、即使出问题也对用户影响最小的节点进行重构试用，如未支付订单超时关闭、用户取消订单。

以用户取消订单场景为例，在修改前各业务的用户取消订单的逻辑为修改订单状态为已取消状态然后执行同一个流程，流程的执行顺序为硬编码，伪代码如图所示：

汽车电商平台发展趋势：汽车之家电商系统架构演进与平台化架构实践(3)