前言

　　在数字化浪潮席卷的当下，业务的高效运营与创新发展离不开强大的技术支撑。对于各类线上业务而言，交易系统作为连接用户与服务的关键枢纽，其成熟度与完整性直接决定了业务的竞争力。一套卓越的交易系统，不仅是业务流程的数字化载体，更是提升运营效率、优化用户体验、推动业务创新的核心驱动力。大会员业务精心打造的交易系统，正是这样一个集高效、灵活、稳定于一身的强大平台，它以模块化的架构、先进的技术组件和完善的功能体系，为业务的持续增长和生态的繁荣发展奠定了坚实基础。

　　系统架构全景洞察

　　大会员交易系统采用模块化设计理念，将复杂的交易流程拆解为交易、订单、签约、商品及清结算等多个核心模块。这些模块既相互独立又紧密协同，共同驱动着整个交易链路的顺畅运转，构建起一个高效、灵活且易于维护的系统架构，确保系统能够快速响应业务需求的变化，为业务的创新发展提供有力支持。

　　因我们本身所属业务的特性，所以设计的交易系统可能跟传统电商的交易系统不同，更适配虚拟物品相关的业务。

　　核心流程深度解析

　　交易系统的核心流程从用户下单的那一刻开始启动，订单作为贯穿始终的关键纽带，串联起支付、履约、退款等各个环节。在这个过程中，订单系统负责维护交易状态、管理交易生命周期，与商品系统、支付系统、营销系统以及清结算系统紧密配合，共同完成整个交易流程。每一个环节都经过精心设计和严格把控，确保交易的顺利进行和数据的安全可靠。

　　架构设计实践

　　系统架构图　　

　　核心流程示例

　　交易系统的核心流程始于用户下单，订单贯穿支付、履约、退款等环节。订单系统负责维护交易状态和生命周期，与商品系统、支付系统、营销系统、清结算系统协同完成整个交易的流程。　　

　　核心技术组件说明

　　交易配置

　　1.业务身份管理

　　业务身份管理为每个业务分配唯一 ID，该 ID 在整个订单、支付和结算链路中贯穿始终，为每个业务颁发了一张专属 “身份证”，凭借这一 ID，不同业务的数据得以相互隔离且可精准追踪，有力保障了业务管理的清晰性和数据的完整性。

　　2.⽀付中枢配置

　　支持灵活选择支付渠道和优先级，能够根据业务需求和用户偏好，快速切换和调整支付渠道顺序。

　　同时，通过管理支付协议模板，实现前端展示与不同支付需求的快速适配。

　　3.⻛险控制

　　通过风控控制通过主动防御（如黑名单）和智能拦截机制（如恶意退款），识别并阻止异常交易，保障支付安全。

　　订单服务

　　订单服务涵盖交易流程编排、业务数据管理和交易数据安全。它维护订单从创建到完结的全生命周期，通过状态机模式管理订单状态流转，支持超时取消和自动确认等规则。订单系统提供实时数据查询和业务指标分析，借助分布式事务保障数据一致性，通过分级隔离的熔断降级机制应对流量洪峰，建立自动化对账体系防控资金风险。

　　1. 交易流程编排

　　交易场景中，订单的生命周期分为：

　　订单创建：即用户触发购买后生成新的订单

　　用户支付：按照商品价格营销策略计算的支付相应金额

　　订单履约：购买的商品（权益）的下发

　　订单完结：交易完成后订单完成

　　订单退款：出现退款，订单需要退回支付金额，商品（权益）触发回收

　　订单关单：支付失败关单，超时关闭订单，用户取消关闭订单

　　订单系统负责维护上述生命周期，通过状态机模式流转订单状态，并且支持订单的超时取消合自动确认等规则，配合上下游其他系统提供完整的订单服务。

　　2. 业务数据管理

　　订单提供了完成的交易数据管理能力，提供了实时的订单数据查询服务，以及业务的数据指标的分析。

　　3. 交易数据安全

　　通过分布式事务保障数据一致性

　　实施分级隔离的熔断降级机制抵御流量洪峰

　　建立自动化对账体系防控资金风险

　　4.订单事件驱动的状态机引擎：

　　订单的状态管理采用了事件驱动有限状态机的设计模式，通过事件订阅订单的状态流转：　　

　　签约服务

　　负责订阅类业务的签约管理，例如包月充电业务，可以为业务提供连续包月的签约对接能力，为付费业务提供更多的运营方案。

　　1.签约及续费处理流程

　　用户下签约单后，订单会触发签约系统执行签约逻辑，向支付中心创建签约单，并维护签约状态　　

　　2.可扩展的签约服务设计

　　对于签约的业务，需要定时的完成续约、扣款、解约以及用户的签约状态维护签约系统。

　　签约系统可分业务、分片的定时完成自动化的续约、扣款、和解约，以及用户的签约状态的维护。

　　抽象出签约和扣款接口，接入的订阅类业务只需实现业务逻辑即可接入签约续费能力。　　

　　3.签约数据一致性处理

　　签解约流程设计遵循幂等性原则，同时，通过上下游数据对账，确保签约数据与订单、支付渠道的续费信息保持高度一致，保障签约数据的准确性和完整性。

　　商品系统

　　商品系统解决了交易系统中“买什么”的能力，交易系统中的具体交易实体我们称为“商品”，实际表现上单个商品就是一个SKU，用户下单购买的实体则是一个具体的SKU，归于同一个组的商品集合为一个SPU

　　1.商品信息展示与管理：

　　商品系统是平台展示商品信息的核心模块，负责存储和呈现商品的基本属性、图片、描述、规格参数等内容，提供了商品以及商品属性的配置能力，为消费者提供全面的商品认知，帮助其做出购买决策。

　　2.交易基础支撑：

　　在整个交易流程中，商品系统为订单生成、支付结算、库存管理等环节提供关键数据支持。准确的商品价格、库存数量等信息是保障交易顺利进行的基础，直接影响到订单的有效性和消费者的体验。

　　3.营销活动支持：

　　商品系统与营销系统紧密配合，实现各种促销活动的配置和执行。通过对商品进行折扣、满减、赠品等活动设置，激发消费者的购买欲望，提高商品销量和平台销售额。

　　4.定制化的商品配置：

　　商品除了基础的属性规则等配置，应对虚拟物品的不确定性，以及内部各业务的差异性，实现了定制属性规则，以及适配我们的交易系统的商品特殊绑定的交易规则，清分规则，结算规则配置。

　　清结算系统

　　正常的交易流程走完之后，用户视角下，消费流程已经完结；清结算则是业务视角下的后续流程，售卖的商品被用户购买之后，平台需要对收益进行结算，并对商品的供应商或者拥有者进行分成，清结算系统是大会员交易系统中负责处理交易完成后资金分配和结算的关键模块，它确保了平台和各方合作伙伴在交易中的收益能够准确、及时地进行计算和分发。

　　清分系统：交易⾦额按预定⽐例拆解，为结算做准备。每笔交易的收益将根据协议分配到相应的分成⽅。

　　结算系统：清分数据准备完毕后，结算系统根据结算周期，计算每个分成⽅的应得⾦额，并将资⾦转⼊相应账户。

　　这里以一个简化的例子快速解释一下清结算的概念。　　

　　按照上图描述，一笔消费完成之后，会先由清分将消费分为多方的分成，再由结算按照结算周期进行计算，并且按照对应的打款方式将收益转移到对应的分成方的账户中。

　　了解了清结算的基础概念之后，下面来具体聊一下我们是如何实现整个清分-结算的流程的。

　　1.清分系统

　　1. 清分系统支持多种数据源接入，不同的业务数据通过标准化的数据接口和数据解析，将各类数据源的数据转化为系统可识别和处理的格式，为后续的清分计算提供统一的数据基础。例如，它可以同时接入大会员业务、装扮业务等不同业务板块的交易数据，并将其进行整合处理。

　　2. 清分规则支持高度个性化的配置，以满足不同业务场景和合作模式的需求。通过配置清分执行器链表，系统能够按照特定顺序对业务数据进行精确的清分计算。清分执行器是实现清分规则的核心组件，它可以根据业务需求进行定制开发。例如，在涉及多方分成的场景中，清分执行器可以根据不同的分成比例、优先级等规则，对交易金额进行准确的拆分。

　　清分执行器实现　　

　　通过实现不同的清分策略可以配置各种不同的清分执行器，来满足不同的业务分成诉求。

　　整体清分流程　　

　　在进行清分时，系统首先会获取需要清分的交易数据，这些数据可能来自于交易系统的实时推送，也可能是定时从数据库中获取的批量数据。然后，根据预设的清分规则匹配相应的清分执行器。匹配成功后，运行清分执行器对数据进行计算，计算过程中会考虑到各种因素，如不同业务的分成比例、是否有运营奖惩等。计算完成后，得到清分结果并将其落库存储，以便后续结算系统使用。在这个过程中，系统会对每一步操作进行记录和监控，确保清分过程的准确性和可追溯性。

　　2.结算系统

　　结算系统结算系统通过订阅清分数据，即可实现结算指定分成方的分成的汇总结算：

　　结算系统支持到了最小时间粒度为天，最小实体粒度为SPU的结算

　　接入了装扮&收藏集&充电+和单片充电多个业务的结算

　　商品SPU纬度或者mid纬度可通过结算规则的绑定对公或者对私结算方式

　　通过对私结算和财务系统满足的业务的对公&对私打款，实现了合作方的打款流程线上化　　

　　前端

　　统一营收支付SDK：

　　这是连接用户与交易系统的重要桥梁，集成了通用支付业务的各项功能。它提供支付全流程服务，包括根据商品信息和用户选择生成订单、调用支付渠道接口发起支付请求、通过轮询实时获取支付结果以及处理支付超时、失败等异常情况。同时，封装了通用 UI 组件库，包含商品信息展示、商品数量选择、支付渠道选择、支付协议确认、支付按钮等模块。业务方可以根据自身需求，灵活组合这些模块，定制个性化的支付面板，也可以直接使用现成的通用支付面板，快速接入支付功能。

　　活动类业务可通过配置实现全链路接入；定制业务可通过模块化、插件化开发适配不同需求。

　　支付sdk分层设计架构图　　

　　支付SDK：收敛通用支付业务，提供支付链路全流程SDK

　　订单创建：根据商品信息和用户选择生成订单。

　　支付发起：调用支付渠道接口发起支付请求。

　　轮询支付结果：通过轮询实时获取支付结果，确保支付状态同步。

　　异常处理：处理支付超时、失败等异常情况，提供友好的用户提示。

　　通用 Headless UI 组件库：商品信息展示、商品数量选择、支付渠道选择、支付协议确认、支付按钮等模块。

　　开箱即用的解决方案：可以结合业务需求， 灵活组合支付模块，实现面板的完全定制，也可以使用开箱即用的通用支付面板。

　　业务接入

　　活动类新业务接入

　　交易系统0开发量全链路通过配置，客户端适配sdk后，可实现全流程的商品展示，下单支付，发放业务权益

　　已有其他业务接入

　　1. 业务适配评估阶段

　　异构系统兼容性分析

　　需对存量业务进行全量接口扫描（如订单创建、支付回调、权益发放），识别与标准交易协议差异点（如字段缺失、异步流程阻塞）

　　数据模型映射改造

　　新老系统数据兼容，历史数据差异清洗处理

　　2. 前端支付面板适配

　　通用支付面板适用场景：适用于对支付面板UI样式无深度定制需求的场景。

　　接入方式：通过npm包 @bilibili/ogv-basic-cashier 快速接入。

　　核心能力：

　　灵活配置：支持通过配置动态开启或关闭部分支付面板功能。

　　主题化支持：内置多套通用主题，可轻松切换，满足不同场景的视觉需求。

　　推荐场景：适合追求快速接入、功能标准化且无需复杂UI定制的项目。

　　定制支付面板适用场景：当通用支付面板无法满足个性化需求时，可选择定制支付面板。

　　接入方式：基于原子化的 headless UI 组件库，自由组合面板视图。

　　核心能力：

　　高度定制化：支持深度定制UI样式与业务逻辑，满足个性化需求。

　　支付逻辑解耦：开发者只需专注于UI设计与交互，底层支付逻辑由系统自动处理。

　　推荐场景：适合需要高度定制化UI或特殊业务逻辑的项目。

　　特殊支付流程

　　适用场景：当通用和定制支付面板均无法满足需求时，可选择特殊支付流程。

　　接入方式：通过npm包 @bilibili/ogv-quick-pay 接入，直接调用底层支付链路。

　　核心能力：

　　底层链路开放：提供底层支付能力，支持完全自定义支付流程。

　　极致灵活性：开发者可完全掌控支付逻辑，适配复杂或特殊业务场景。

　　推荐场景：适合需要完全自定义支付流程或处理特殊支付逻辑的项目。

　　3. 服务端迁移技术难点

　　核心链路灰度策略

　　入口灰度隔离，保证一单请求只会走单一链路

　　采用四层灰度机制：功能开关 → 白名单放量 → 比例灰度 → 全量切换

　　订单数据兼容方案：新老系统并行处理，通过分布式锁确保幂等性

　　订单下游业务支持2个系统的数据兼容处理

　　离线数仓数据底表兼容，各类数据统计、BI报表

　　业务系统兼容适配

　　交易相关交互接口的兼容实现

　　订单数据的兼容处理

　　总结

　　一致性、稳定性

　　1.数据库事务控制

　　通过数据库事务机制，确保数据操作具备原子性、一致性、隔离性和持久性，保障系统数据的完整性和准确性。交易中多表操作由事务管理，异常时回滚避免数据错误。

　　2.分布式锁机制

　　在分布式系统环境下，采用分布式锁机制，防止多进程或线程同时操作同一数据，避免数据冲突和不一致。如在高并发订单处理场景中保障订单状态更新准确。

　　3.幂等性设计

　　系统遵循幂等性原则，多次执行同一操作结果相同，避免因网络问题或重复提交导致数据错误和重复操作，如支付场景中防止重复扣款。

　　4.对账系统

　　建立自动化对账体系，定期核对订单数据，及时发现和处理数据不一致问题，防控资金风险，确保订单准确性和安全性。

　　5.超时异常补偿任务

　　针对系统异常，设计补偿任务机制，减少异常对业务和用户的影响。如系统故障导致履约失败时，为用户退还费用或提供补偿。

　　6.分级的限流策略

　　根据不同付费场景，对请求进行隔离，为不同业务方配置限流保护，确保系统在高流量下稳定运行。

　　展望

　　系统架构优化：

　　持续优化系统架构，采用更先进的技术架构和设计理念，提高系统的性能、扩展性和可维护性。

　　创新业务模式：

　　结合市场需求和技术发展趋势，探索创新业务模式和产品服务，满足业务多样化的需求。

　　构建生态系统：

　　构建开放、共享、协同的交易生态系统，整合上下游资源，实现各方协同发展和价值共创。

　　本文全面呈现了大会员交易系统的建设情况，涵盖架构设计、核心模块实现、稳定性保障，为同类系统建设提供部分参考。