亿级交易平台：从 0 到 1 设计思路( 二 ) _业务

2.3.2 提高效率
高扩展性、高复用性，对内对外大幅提高研发效率。交易平台自身对接新业务需求仅需3天；数据模型的统一，降低大数据、财务等外部关联服务的复杂度，提高的这些关联服务支持新需求的效率。
2.3.3 业务赋能
创新项目可以低成本跑通 MVP，降低试错成本；体现技术驱动业务发展的能力。
2.3.4 标杆系统
交易平台率先完成平台化，对标行业领先；随着交易平台的价值的逐步体现，在公司内部树立标杆形象，促进达成建设平台化架构的共识，引领兄弟部门平台化建设的步伐；最终形成业务中台化，打造全链路的高效、稳定的业务赋能能力。
三、技术实现 3.1 业务架构
交易平台承接各业务前台的交易应用的请求，依赖商品、营销、支付等基础服务，处理各业务形态的正向交易、逆向交易，具体业务包括正向交易、逆向交易、履约分发、订单中心、数据处理、运营工具、公共组件等。
图片3.2 系统架构
按照功能，交易平台内部系统划分为4层，包括存储层、数据处理层、业务层和应用层。其中业务层按照订单生命周期划分为生单模块、支付模块、履约模块、逆向模块以及查询模块。
图片3.3 技术保障 3.3.1 差异管理方案 3.3.1.1 业务身份定义
作为平台化架构，定义业务身份是首要任务。业务身份的定义，是用于区分不同业务、不同品类的差异功能，是业务管理单元；需要定义一套合理且具有扩展性的业务身份方便业务管理。基于业务场景，我们使用3个维度定义业务身份：
图片3.3.2 扩展性方案 3.3.2.1 数据模型扩展
订单数据模型，除了通用的买家信息、卖家信息、商品信息、支付信息、买家履约信息(支付信息)、卖家履约信息等基本信息之外，不同业务形态的订单还有差异化的数据需要存储和传递。我们的解决方案是通用信息结构化存储+差异信息JSON存储，具体如下：
3.3.2.2 业务功能扩展
支持多业务问题本质上是业务功能如何抽象的问题，而差异逻辑处理则是在抽象通用基础能力的基础上，如何在部分处理环节支持差异性逻辑。我们采用的是抽象通用能力+预留扩展点的方式，具体如下：
图片3.3.2.3 业务流程扩展
差异化流程的本质是串联能力节点形成业务流程，信息可在能力节点之间传递。我们采用流程编排+标准上下文的方式实现，具体如下：
流程引擎ark-maze组件，以“责任链”模式来组织复杂处理流程的执行过程，保障服务节点能够按照顺序执行，并且能够传递执行结果；发生异常可逆序进行回滚操作；支持节点的串行、并行执行。ark-maze组件架构图如下：
图片3.3.3 稳定性方案 3.3.3.1 服务隔离
一套系统支持多个业务形态，导致业务间相互影响的原因如下：
图片3.3.3.2 分业务监控
多业务监控本质上是在原有监控指标增加业务维度即可，相关监控指标包括：应用指标：异常日志、调用量等；业务指标：下单数、支付数、取消数等；
图片3.3.3.3 业务保障系统
如何保障多业务正常运行？其本质就是如何快速发现问题，并且具有一定的自动修复的能力。我们搭建了业务保障平台，实时地发现业务数据的一致性和正确性问题，某些异常场景能做到自动修复，如果不能自动修复，第一时间报警给相关负责人。业务保障平台通过事件触发执行校验规则，规则支持自定义脚本和自定义api接口。
3.3.4 高性能方案 3.3.4.1 存储高性能
作为交易系统，存储海量订单数据，对外提供高可用、高性能的读写服务是必须要支持的。为了保障高可用、高性能，我们采用如下方案：