汽车行业电商平台化架构演进之道

JavaEdge

发布于 2024-05-26 14:11:55

870

发布于 2024-05-26 14:11:55

文章被收录于专栏：JavaEdgeJavaEdge

1 架构演进

电商系统架构发展历程，每个阶段的业务状况、技术挑战和技术体系的应对策略。

1.1 起步阶段

业务起步&快速迭代试错

架构：从NET技术栈到Java栈。

在业务起步阶段对技术的要求：

快速迭代上线
验证产品可行性

考虑电商系统的可扩展性，研发技术栈逐步从 .NET 体系变成 Java 体系。

1.2 微服务阶段

业务验证可行&快速发展架构：完成按领域划分的微服拆分、各服务独立承接业务需求

随着电商业务迅猛发展，技术人员的增加，到 2016 年技术团队已经有了上百人。单体架构之痛扑来，一个前台商城 git 项目就近 30 个 Maven 的子项目，遇上需求并行开发，经常出现代码的合并冲突、需求上线等待、线上慢 SQL 等问题，整个系统的开发效率和系统稳定性都变差：

系统支撑面临巨大的挑战，系统架构必须升级进化。把原单一系统拆成多个高内聚，低耦合中心化系统。即用户中心、商品中心、订单中心、促销中心、优惠券中心、商家中心，每个独立的系统可以独立设计、独立接需求、独立发布。

此间，在技术上完成支撑电商百万级商品系统、订单系统、优惠券系统构建，并完成了应用的全部上云、自动化测试平台构建。

1.3 主数据阶段

电商系统统一

架构：完成电商主数据建设，API读写切换，业务逻辑复杂化，订单量增长迅速

电商发展的速度实在太快了，公司基于发展战略决定搭建电商中台：

为集中公司优质的产品资源、运营资源，打造具有影响力的垂直类电商交易平台
也是为合理管控技术资源，实现电商系统的统一。在此背景之下，我所在的团队承担起了搭建电商中台的任务，由于各个系统间的业务形态、技术架构差异很大，所以我们面临的第一个问题就是用什么方式能够实现交易类系统的整合。

为此：

开始熟悉不同业务场景下的交易系统的现状
在技术方案思考和讨论

最终选择“以数据归一为基础，提供标准化中台服务，从下层向上层逐个系统整合”的方案：

1.3.1 数据归一

数据是公司的核心资产，任何系统尤其是交易类系统，数据更是重中之重。主数据建设：

统一数据模型，打破系统壁垒
通过集中的数据进行经营性数据分析，为业务决策提供依据，因此我们将主数据的建设作为了系统整合的第一步。

交易流程最重要数据集中在商家、商品、订单、促销活动4个领域，需结合公司交易业务现状，分别对这4个领域主数据进行抽象，统一建模，尽可能适配大多交易场景。订单主数据核心数据模型结构：

完成统一的数据模型后，下一步就要将现有异构型数据导入主数据库，采用读取数据库 Binlog（MySQL、SQL Server）进行数据加工的方式完成初期的数据同步导入，也是对业务侵入最小、最快的实现方案。

1.3.2 API 标准化

完成主数据建设，下一步开始基于主数据的 API 标准化建设，API 可看做系统的神经，高质量的 API 可以串联起一个优质的系统，统一了 API 在一定程度上也就实现了系统的收口。

为此，遵循单一职责原则，按领域区分，明确边界，做到所有底层 API 功能原子化，便于上游使用者组装 API 完成业务逻辑，同时统一 API 参数结构和响应结构，统一错误码，基于 API 网关统一发布、调用，API 的数据统计监控、降级、限流实现统一管控。

1.3.3 API 读写切换

有标准化 API，自然要让业务方进行使用才能体现API价值，为防止步子迈太大，也按业务重要性及量级，采用读写分阶段的方案逐个业务进行调用切换，看似很合理步骤，实际执行过程也暴露很多问题：

读写强依赖场景，如用户下单完成后马上会跳转到订单详情查看订单，这时在未完成写 API 切换时，由于数据同步延迟会导致通过读 API 读取数据失败，这时无法按先读后写分阶段进行切换，最好是读写同时切换
对业务切换影响最小的方式，当然是兼容原接口的参数和返回结果，如强加业务方按我们标准的 API 切换，势必给业务方带来切换成本和不必要负作用

这时要从对方角度出发做取舍。即在标准 API 上增加一层适配层，用于新老协议转换，让业务方只需切换域名和请求的 URL 即可，其他逻辑不变，最大限度做到对业务方友好：

由于我们提供底层 API 都是原子的，但实际场景尤其前后端分离项目，前端不大愿意为一个结果多次调用接口获取，对此，也是在后端增加一层门面层，基于底层原子 API 组合成满足业务场景的 API 对外提供，对差异化接口逻辑做适度兼容
读写切换不可能一蹴而就，在这过程势必会有主数据 API 和原业务 API 并存，鉴于所有 API 入口都由我们统一提供，因此也采用路由机制，通过路由层的 location 进行区分转发，所有 API 做到对调用方的透明
实际 API 切换过程中，还有一种特殊场景，因为最终要实现系统整合，对那些后续会被整合掉的功能强行做 API 切换也是资源浪费，因此提前预判，可适度不做切换，等功能整合后将整体功能切换

1.3.4 系统功能整合

完成 API 读写切换后，基于主数据的功能基本完成聚合，此时需将通用功能进行系统化统一，如统一的商家管理后台、统一的运营后台、统一的 C 端交易体验等，系统层级的统一整合是为给使用者一个统一操作界面，体现平台专业性。

系统整合过程中，采用“共性沉淀，差异取舍”原则，对通用能力如：商品发布、订单列表等功能，抽象出通用能力，提供统一的单元化操作界面，满足各业务方使用。

对业务方特有功能，建议业务方实现，而对那些目前还无法形成通用能力但未来有可能作为通用能力的功能，按 MVP 原则，随业务迭代不断实现功能沉淀。

在整个系统整合过程，必然出现在整合原有系统功能的同时又有新需求加入。对此，采用新老系统同步开发，看似增加成本，其实对新系统整合有好处：

不影响业务开展，不因技术性整合对业务造成停滞
新老系统对比，找出新系统可能问题，这也是验证整合后的新系统功能的最佳途径

在完成绝大部分的系统整合工作后，电商核心交易链路已经可跑通，并在线上经历长时间验证，从商家入驻、商品发布、商品展示、下单、支付、履约、售后，到最终结算，期间遇到问题也在一一化解。在这个阶段完成：

公司内 3 大交易系统整合
并进行电商平台秒杀系统 10 万级 QPS 的架构升级
优惠券系统 10 万级 QPS 的架构升级，支撑了 2020~2021 年的 818 晚会、双 11、双 12 等大型活动的秒杀、发券场景
也在积极探索领域驱动模型 DDD 的理论与业界实践，并在发票总库系统的重构中进行了落地实践 [9]，这也为后续的平台化架构升级提供了技术支撑

1.4 平台化架构阶段

多品类、多业务架构：平台化架构，服务编排化，业务配置化、数据可视化，流程标准化等

电商业务中台继续向业务“逼近”，系统抽象和建设难度指数型增加，出现一系列问题：

建设中台项目结束，人员撤离，电商业务中台在集成这么多业务线逻辑后，充斥大量条件判断，每次需求迭代的开发成本和测试回归成本高，如何隔离不同业务之间的逻辑，减少业务之间的耦合度？
如何抽象出已接入电商业务中台的多条业务线的共性能力，避免重复建设？
当新业务接入电商业务中台，如何基于已有的能力和解决方案快速组装上线，以支撑业务快速迭代创新？
如何能够利用技术手段帮助产品运营日常工作提效呢？

综上所述，电商业务中台在建设过程中抽象业务线的共性能力以及共性能力的复用性设计与实现尤其重要，业务中台要做到能力复用和灵活多变才能让中台建设在企业的发展过程中起到降本增效的效果。系统架构必须升级，进入平台化架构阶段。

2 平台化架构实践

平台化架构：基础能力跟每个业务方的特性业务拆分，把业务和业务之间的逻辑进行隔离。

平台化最核心是业务抽象建模和系统架构开放性：

业务抽象解决共性 80% 问题
系统架构开放性解决 20% 的个性化问题

适合之家电商平台的解决方案：通过领域驱动建模抽象出电商业务中台多业务线的共性能力并预留扩展点，然后利用服务编排对共性能力进行组合。

原理图：

每个在电商业务中台运行的业务可以理解为：业务身份 + 业务流程 + 规则，业务流程通过流程服务编排来实现，扩展点通过扩展点机制来实现。

整个交易流程中 B 端的商家入驻、商品发布相对通用，不同的业务的主要流程差别体现在订单收单前以及支付后的订单履约，这些流程都需定制开发，为此整个解决方案核心在于订单平台化架构设计。

如图，整个订单平台化架构分为四层：

基础设施层：提供存储、消息、RPC 等中间件
基础服务层：按域组织的基础服务、域服务内针对不同业务的差异提供扩展点
业务能力层：串联不同域服务形成可供外部使用的业务能力，比如下单、支付等
业务流程层：对业务能力进行编排、形成订单交易流程、完成订单交易过程
业务层：制定业务身份、扩展点实现以及业务流程配置等，实现不同业务差异

整个订单平台化架构升级实践过程总结：

2.1 业务身份化

业务平台在对各业务同时提供服务时，要能区分每次业务服务请求的业务身份要素，以便提供差异化个性化的服务；因此要对企业各业务的身份和特征进行建模和区分，其产出即为业务身份。业务身份具有唯一性。

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

如汽车电商领域，业务身份通过人、货、场三维抽象：

人维有是否开通会员、是否是认证车主、开通了哪些增值服务等
货维度有商品类型（整车、实物商品、虚拟商品等），交付方式（核销、兑换、4S 店交付）等
场维度有线上下单、线下下单、在哪个线上商城下单，在哪个交付店下单、商品投放渠道来源等

根据这些维度确定了唯一的业务身份后，每笔交易的业务流程就确定下来了。

2.2 服务编排化

电商业务中台整体采用微服务架构、将整个电商系统拆分为商家中心、用户中心、商品中心、促销中心、交易中心、履约中心、售后中心。每个中心在逻辑上分成：

不带业务属性的基础能力基础能力层关注领域模型的实体属性、行为、事件，不随业务需求调整而变化，聚焦于行业共性行为、收敛业务模型，保障基础服务的稳定性
带有业务属性的能力带有业务属性的能力是在基础能力层之上通过服务组合、流程编排，构成面向业务的解决方案，完成业务共性到个性化的转变。

有两种常见做法：

硬编码。随不同业务线逻辑增加，各业务能力调用的基础能力盘根错节，很难做到可配置、灵活化。当需求变更，测试很难评估修改的影响范围，回归测试成本周期长，很难真正做到敏捷开发、快速响应业务
服务编排。通过服务编排现有微服务进行服务组合服务，然后一次性返回前台需要信息。不同业务线的能力执行不同的流程，通过图形化、XML、JSON 的编排框架，即可以让流程清晰，也可屏蔽代码细节

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

2.2.1 服务编排框架

服务编排领域参考：

基于 API 网关的服务编排
基于工作流系统的编排框架 Flowable 和 Activiti
基于微服务架构编排框架的 Netflix Conductor和 Zeebe

都存在某些程度不足，无法应用到电商业务中台服务编排，最终选用 Apache Camel 为服务编排的底层引擎进行二开。

Apache Camel 诞生 2007，2009 成为 Apache 顶级项目更名 Apache Camel，目前最新版本3.0。Apache Camel 的优点在于在发布后十多年的时间里，已经拥有三百多种扩展组件；扩展机制也极其方便和灵活；通过开箱即可用的最佳实践来解决应用集成问题；它基于事件驱动的架构，有着良好的性能和吞吐量。

简单的服务流程编排样例：

业务中台使用服务编排技术：

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

2.2.2 扩展点框架

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

COLA 框架一种应用架构的扩展点框架。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 默认值查找：

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

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

2.2.3 服务编排 + 扩展点应用举例

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

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

修改后根据各业务的特性的进行精细编排，如二手车业务没有使用优惠券的场景，就不需要这环节；积分这通用能力，扩展的是万里通积分。伪代码如：

旅行家业务线的的酒店、机票业务无传统的商品库存的概念，那么就不再需要还商品库存的操作，而是抽象一个新的通用能力：取消供应商订单，并预置了取消酒店供应商订单的扩展以及取消机票供应商订单 2 个扩展点。伪代码如图：

整个系统的应用效果明显，主要体现在性能、人效提升：

性能提升，主要体现在系统RT变短，在修改后取消订单的接口的生产环境的 TP99 值提升30%
人效提升，取消订单增加新流程节点的测试所用的时间对比：
- 修改前，各业务流程间的代码耦合，修改流程增加新节点需要对以前的各业务进行回归测试
- 修改后，无需各业务的回归测试

2.3 业务配置化

平台化架构实践中，将那些影响业务流转的核心配置统一提取，并按业务身份进行属性值配置，确保整个交易流程链路标准统一，减少对交易核心链路代码的频繁修改，不同业务根据不同的属性值在相同的交易流程中的不同节点进行灵活切换。

如商品是否自动推到资源池、下单是否需填写身份证、支付成功是否推送线索、超过 N 天未确认收货是否自动确认收货完成等，所有配置项均通过配置管理后台统一维护。

对电商中台中包括业务身份在内的所有元数据，也通过配置管理后台统一管理并提供统一API对外提供查询服务。

2.4 开发工具化

从业务和技术多维出发，针对日常工作出现的常见业务或技术问题，研发出各类实用便捷的小工具，实现工作效率提升、问题快速定位等效果，如消息分发、检索工具；商品优惠价格速算工具；商品展示价格比对监控工具；缓存管理工具；一键降级工具等。

随工具化意识提升，这类小工具不断出现并汇集，构成研发必不可少的工具箱。

2.5 数据可视化

电商系统的性能指标、资源利用率指标、调用量等系统维度的指标通过云平台实现统一监控，业务数据同理，需提供统一的业务数据可视化工具，为业务方提供决策参照。

为此，采用实时 + 离线开发订单可视化大屏系统，通过该系统能按业务线、订单状态、区域等多维度实时监控订单量变化。若固定时间段内订单量波动超过阈值，发钉钉消息及时通知业务方。

离线数据，也按日、周、月等从多维进行数据统计分析，最终以邮件和办公App消息形式发给业务方，这些手段都是为实现电商数据可视化管理，为业务使用方提供更多便捷的工具对电商业务全方位管控。

2.6 知识沉淀

整个电商中台建设，将这些经验及日常问题解决办法，作为一种财富不断沉淀，以往都是采用 wiki 这种文档管理工具进行汇总。

为让这些知识产生价值，也开始搭建电商知识库系统，将所有能作为知识沉淀的内容，按不同领域分类录入知识库系统，整套知识库对外提供快速检索和定位功能，能服务技术、产品运营人员，进一步培养知识积累意识，提升工作效率。

3 总结

二十年前，互联网刚在中国流行，信息都是通过资讯展示，几乎无在线交易；十年前，互联网经过快速发展，消费者可在淘宝、天猫、京东为代表的在线商城上购买自己需要或喜欢的商品进行在线交易；而如今各种电商形态不断涌现，已百花齐放，如内容电商小红书、兴趣电商抖音快手，社交电商微商、拼多多等，会员电商天猫 88vip、京东 plus 等。这些在线交易形态充分证明电商在互联网领域流量变现重要地位，已成互联网企业基础设施的水电煤。

电商中台建设不光是技术体系搭建，也是一个组织结构重新塑造的过程。但随时间推移，中台价值增长空间愈窄，需有意识寻找创新点，突破现有系统边界，跨界思考，于是也开始与前台业务走近，积极开展对新业务探索和技术架构升级。