1. 事件驱动型 微服务架构的实践 华泰证券 / 毕成功

2. 删除水印 Wondershare PDFelement

3. 背景简介 荣誉 大象交易平台 大象交易平台是FICC多资产实时定价、做市和风险对冲平台。 在量化做市交易领域以“ 极速交易 ” 、 “ 实时风控 ” 、 “ 策略驱动 ” 和 “ 投资管理 ” 四项核心能力为服务底座，提供了覆盖境内外、跨市场、全资产交易品种的低 延时极速交易与风控能力、全自动量化定价与策略做市报价能力以及实时全景 风险指标监控与风险对冲能力。 • 近期荣获中国人民银行颁发 的金融科技发展一等奖 • 2023年斩获中国外汇交易中 心“年度市场影响力机构”和“市 场创新业务机构”等奖项 • 荣获三家政策性银行颁发的 大象平台建设了“ 交易员工作站 ” 、 “ 风险与投资管理中心 ” 和 “ 策略研发工作 室 ”三大应用终端，为相关部门固定收益做市交易各岗位用户提供专业用户体 验。平台支持公司现券、IRS、国债期货、债券通等做市业务快速发展，做市 报价数量、质量及市场大幅波动时风险控制能力都极大增强，综合报价能力位 居同业前列。 “优秀做市商” • ...... 共计14个奖项 毕成功 哈尔滨工业大学07级计算机硕士。在十余年的职业生涯中，致力于软件开发和团队管理工作，涉 足过搜索、手游、O2O、电商、金融等多种领域，并有过多次创业经历。2021年加入华泰证券， 带领FICC平台架构团队，负责大象交易系统的平台架构工作。目前主要着力于建设具有“超低延 时、内存计算、事件驱动”的金融型架构体系。

4. CONTENTS 01 经典微服务架构的问题 The problems of traditional MS-Arch 02 事 件 驱 动 型 架 构 的 方 案 T h e d e s i g n s o f E D A 03 事 件 驱 动 型 架 构 的 问 题 T h e 04 总 p r o b l e m s o f E D A 结 和 推 荐 建 议 S u m m a r y a n d r e c o m m a n d s

5. 01 经典微服务架构的问题 这真的是银弹吗？

6. 耦合问题 p 上下游服务强依赖 Ø 服务的稳定性差 Ø 要降级处理地方的太多 p 调用链长 Ø 稳定性进一步下降 Ø 接口性能下降 p 数据库依然是中心节点 Ø 数据库的稳定性影响大 Ø 数据库是整体瓶颈，难扩展

7. 接口膨胀问题 数据操作的场景多 调用关系复杂

8. 不同场景技术选型的权衡 互联网场景 金融交易场景 高吞吐 低延迟 易扩容 快速开发 ...... VS 高稳定性 复杂业务的易维护 ......

9. 02 事件驱动型架构的方案 模块化和简单性是软件工程的基石。 —— 蒂姆·伯纳斯·李

10. EDA主要特征 服务之间的关系发生变更 p 转变一：异步化 ü 无需同步等待 ü 支持一对多 避免了 上下游依赖 调用链长 p 转变二：数据自治 ü 自主订阅，本地保存 ü 本地数据调用 本质上是对数据依赖的解耦！ 避免了 DB依赖 接口膨胀

11. 事件的类型与特征 有状态变更 无状态变更 trade order() getOrders() Data Command Query 不用RPC? Data驱动 Request驱动

12. 数据：存哪里 命令对数据的影响 p 模式一：本地缓存 l 数据读取加速 l 避免对上游的依赖 p 模式二：旁路集中存储 l 获取未缓存的数据 l 内存状态的恢复 天然的CQRS （Command Query Responsibility Segregation） p 模式三：可选快照文件 l 数据获取加速

13. 数据：存储结构 物化(materialization) upsert mode 流水 append-only mode Data1 Data2 Data1 Data1(v1) Data2(v1) Data3(v1) Data1(v2) Data2(v2) Data1(v3) 用于历史回放 Data1(v1) Data2(v1) Data3(v1) Data1 Data1(v2) Data2(v1) Data3(v1) Data2 Data1(v2) Data2(v2) Data3(v1) 用于查询或快速恢复 Data4 Data1(v2) Data2(v2) Data3(v1) Data4(v1)

14. 数据：怎么获取 原则：用统一的方式获取上游数据，不论是query还是sub（非OLAP场景） 推论一：数据获取都采用SQL描述 l 总线的订阅分发模式不支持SQL，需要改造 l query就是对历史数据的sub 推论二：sub和query用同一个SQL l 但query历史数据比sub会多一个范围条件 l query与sub的能力对等，query需要阉割

15. 可用性：内存状态的异常恢复 q&s（query and subscribe） 即组合查询和订阅的逻辑实现原子语 义，用于服务重启后的内存状态恢复。 p 方式一：从流水恢复 ü query要增加范围条件 ü 与sub的逻辑完全一致 p 方式二：从快照恢复 ü query条件要映射到对应的快照文件 ü query的数据要定制处理逻辑

16. 可用性：有状态服务的高可用 同步消费 复用回放恢复的逻辑 状态同步 数据库主备复制的逻辑 优势： • 主备独立、无交互，运行延迟最低 优势： • 对代码逻辑侵入性低，支持并发处理 • 通用性强，不依赖总线支持 劣势： • 要保证两边执行的一致性，有些情况只能串行， 一方面对开发有侵入性，另外限制了并发能力 • 难以对账机制，问题难发现，也难做补偿 • 主备切换需依赖总线能力支持 劣势： • 需要支持内存的日志同步 • 同步过程会有额外代价，可采用事后异步+补偿 • 临界会有重复消费保证不丢，所以对幂等性有强要求

17. 03 事件驱动型架构的问题 如果我不能比这世界上最聪明的人更能反 驳这个观点，我就不配拥有这个观点。 —— 查理·芒格

18. 事务难以支持 分布式+异步 BASE是常规思路 A：Atomicity C：Consistency I：Isolation D：Durability 需要支持Batch能力 client.pub(<Topic>, <List>); msgId classType serializationType batchId batchCnt batchSeq 数据包头 payload void onSubMessage(<Topic>, <List>); 批量回调 & 事务写入

19. 异步通讯更需要管理 矛盾点：异步就是为了松耦合，那如何避免用乱了? 围绕Topic&DTO进行管理 p 开发态——定义 ü 统一管理 ü 规则严控 p 运行态——生产/消费 ü 增强可观测性 ü 流控（兜底保护）

20. 总线天生的集中式风险 最好是完全隔离 Ø 每个场景一套自己专用的总线，避免有任何的互相 交叉。 Ø 但这要求业务场景本身天然存在这种划分。 正常采用多接 Ø 每个服务根据自己的使用场景，接到对应的总线 上，能保证在效率上是最优的。 Ø 但这要求对应的配套管理能力要跟上，避免混乱和 使用上的复杂性。 旁路采用桥接 Ø 桥接会增加整个链路的复杂度以及延迟，而桥接服 务本身又是一个稳定性的风险点。 Ø 建议只有主路对旁路的数据拷贝才采用此种方式。

21. 总结和推荐建议 前提 在复杂业务场景中才值得考虑 必须能接受最终一致性的场景 建议一 • 采用EDA模式进行开发，以异步通讯来避免同步等待 • 把高可用、高扩展等特性放到第二目标 开始时局部使用，但上下游要包含进来 建议二 • 此架构与传统差异较大，对开发模式是有冲击的，推广是存在较大难度 • 需上下游整体切换才能更好的发挥EDA架构的优势 若想真正提升生产力，中台投入是必须的 建议三 • 异步带来运行上的灵活性，也带来了管理上的复杂性，需要有中台来在开发阶段进行约束 • 市面上没有成熟的EDA架构，很多能力还依赖于自研

22.