资金交易业务综合管理平台（下简称“资金平台”）是中国光大银行新一期科技战略规划“十四五工程”之一的金融市场工程的重点项目，该平台将承载金融市场全品类的业务品种的线上交易，实现交易的前台交易管理、中台风控管理和后台运营管理的前中后一体化管理。
改造面临问题
资金平台2022年进行了微服务改造，系统由单体架构向分布式架构演进。系统改造过程中面临以下问题：
（一）功能复杂，建设周期长
资金平台将承载金融市场全品类业务品种，各业务品种处理逻辑均有差异，平台承载的功能繁多且复杂，同时平台建设周期较长，计划分阶段按业务品种实施。
（二）业务流程较长
金融市场业务的大部分业务品种的完整业务流程都要经历前、中、后台三个阶段的处理。前台完成交易生命周期管理，中台负责信用风险管理、市场风险管理等风险管理职责，后台负责完成清结算工作以及账务核算工作。前中后台前后关联又各成体系，从业务上看是一种相对松散的关联关系。
（三）业务解耦诉求
前台交易达成后，中后台需要根据交易要素完成信用额度扣减、市场风险扫描、收付款和账务核算工作，然而无论中台与后台的工作成功与否都不应影响前台交易数据的落地，因此前中后台的服务之间是需要进行解耦的。
（四）非功能需求
资金平台为C/S架构，用户客户端需要接收服务端的异常提醒、交易状态变化、市场数据刷新等类通知类的消息，服务端任何一个节点产生的消息都需要以广播的方式同步给其他集群，再由该集群的推送服务完成消息推送。
解决方案
（一）引入分布式消息平台
基于以上的业务场景和非功能需求，资金平台希望引入消息中间件来作为解决方案，中国光大银行的企业分布式消息平台是以rocketMQ为基础自主研发的企业级消息平台（简称“消息平台”），因此资金平台通过接入消息平台来完成系统架构的搭建。
（二）制定使用策略
在接入消息平台后，需要根据具体的业务场景和业务数据制定资金平台的使用策略，其策略制定的原则是“先场景后数据再异常”，具体如下:
场景一
前台交易服务与中台风控服务以及后台的运营服务之间的消息通信。
（1）发送/消费方式
服务之间的通信虽然是异步通信模式，但是涉及账务，不能容忍数据丢失，因此为保证消息投递的可靠性，生产者和消费者端分别选择同步发送和同步消费的方式。
（2）消费模式
对于该场景下的业务类消息，需要有且仅有一个消费者进行消费处理，应该需要采用集群消费的模式。不同的消费者组分别进行消费。
（3）消息内容
前台产生的交易成交信息作为消息投递到消息平台，但是交易的品种会包含基金、拆借、债券、外汇等多种类型，过多的相同类型topic，则会造成中台、后台的服务逻辑的冗余，因此需选择将所有品种的交易成交消息放到同一个topic下，但是用tag进行区分。
（4）异常控制
此场景下的异常控制指幂等性保证和顺序性消费，幂等性是指不能重复处理交易处理，而顺序性是指对于某一业务品种的交易要保持其买卖交易的顺序性，依次处理。幂等性由消费者通过交易的唯一编号+版本号来保障。而顺序消费分布式消息平台的shadingkey机制来保证。
场景二
针对前文描述的非功能需求，即消息通知场景。
（1）发送/消费方式
通常无序严格保证消息的可靠投递，一来由于消息变化较快（如市场行情），业务只关系最新的消息，可以容忍个别历史数据的丢失，二来由于业务可以通过主动查询的方式获取最新状态（交易状态变化），因此可以选择oneway的发送方式。
（2）消费模式
该场景下通常可以选用广播模式，即每个消费者都需要消费该消息，以便推送给与本节点相连的客户端。
（3）消息内容
虽然都是通知类消息，消费者端对这类消息的处理方式也以转发和展示为主，但是由于消息产生的频率不一样，为了避免快慢交易的相互影响，需要根据消息产生的频率分类创建topic。
（4）异常情况
主要的异常情况是避免消息的堆积和拥堵。尤其是针对市场行情类变化频率极快的交易。通常应对的方式是选择broker推送的方式将消息实时推送给消费者，然后消费者创建线程池，异步消费处理消息，避免堆积。
以上为资金平台主要的两类应用场景的实践情况，在实际的应用场景中还需要根据具体的业务场景做出一些调整或完成一些辅助性的功能。并需要做好应急预案，避免对消息平台的过度依赖。
资金平台所承载的金融市场业务，有其独有的专业性，同时平台作为中国光大银行自主研发的重点项目，需要与行内现有的技术体系和架构完成很好的融合，以适应未来长期的发展。资金平台将积极探索新技术的可行性，通过实践、创新做好业务赋能，同时在此过程中积极与各方专家沟通交流，充分考虑各类风险，保障系统的稳定及安全运营。
作者 | 陈 优
视觉 | 王朋玉
统筹 | 郑 洁
