课程介绍

面向工作年限5年及以上的研发骨干与架构师，本两天实战工作坊聚焦核心命题：高复杂系统下如何做出正确的架构决策——既不陷入照搬模式的教条主义，也不停留在空谈原则的表层认知。

高复杂系统的架构设计面临三重挑战：

l 业务复杂度：业务规则繁多，领域概念交织，系统规模庞大——缺乏从领域模型到微服务的系统化分解方法，易出现”大泥球”架构；

l 技术复杂度：需要同时应对高可用、高性能、容灾等质量属性要求——架构师缺乏从质量属性出发、风险驱动的系统化架构方法；

l 设计决策复杂度：架构模式与设计模式繁多，在真实场景中如何取舍、如何组合——团队缺乏统一的架构决策语言与设计评审话语体系。

其根因往往在于：领域驱动设计一体化方法缺失、质量属性与技术架构脱节、架构模式与设计模式停留在概念认知而无法实战运用。

本工作坊在两天12学时内，沿”领域驱动与微服务架构设计 → 高复杂系统技术架构设计 → 架构与设计模式综合运用”路径，以期货交易系统为核心案例贯穿全程，形成可迁移到项目实践的方法体系：

l 业务架构层：DDD战略设计（子领域、限界上下文），从业务复杂度中梳理清晰的系统边界

l 技术架构层：质量属性驱动 + 风险驱动，保障高可用、高性能、容灾能力

l 设计运用层：高频架构模式 + 设计模式的真实场景取舍与组合

l 实战演练层：以期货交易业务场景为案例，分组开展端到端架构设计

课程大纲

第一部分 领域驱动与微服务架构设计

本部分引入领域驱动设计（DDD）的战略设计方法，作为复杂业务系统的核心分解手段。与传统的面向对象设计不同，本部分直接通过DDDUP（领域驱动设计统一过程）从业务相关性分析入手，识别子领域和限界上下文，建立从问题空间到解空间的架构映射路径。在获得清晰的业务边界后，引入主流应用架构模式（整洁架构、六边形架构、菱形对称架构、CQRS、事件驱动架构），并与微服务架构设计对齐，解决微服务的粒度和划分问题。

本部分内容主要包括：

DDD战略设计要素（DDDUP）

·         问题空间与解空间的映射：子领域（核心/支撑/通用）识别与优先级排序

·         业务相关性分析：通过业务流程泳道图梳理端到端流程，基于业务服务的相关性聚合业务域

·         从业务域到限界上下文：确定知识的边界、业务的边界、团队的边界

·         定义限界上下文API：服务契约设计、开放主机服务（OHS）定义、API时序驱动

·         上下文映射模式：防腐层（ACL）、开放主机服务（OHS）、发布语言（PL）等

应用架构模式

·         整洁架构原则：依赖倒置在架构层的落地——领域层零依赖基础设施

·         六边形架构：端口与适配器——业务逻辑与外部世界的隔离

·         菱形对称架构：应用服务、领域层、基础设施层的协作模式

·         CQRS架构模式：命令与查询的分离——读写分离在金融系统中的运用

·         事件驱动架构（EDA）：发布/订阅、事件总线——降低微服务间的耦合

限界上下文与微服务

·         限界上下文与微服务的关系：一个限界上下文不一定等于一个微服务，但微服务的第一拆分依据是限界上下文

·         微服务粒度与划分原则：基于业务变化频率、团队结构、部署独立性、数据所有权综合判断

·         微服务设计原则：自治性、可观测性、API契约优先、数据去中心化

·         微服务之间的协作机制：同步（gRPC/REST）vs 异步（事件/消息）的选型与权衡

·         微服务通信协议：契约测试与消费者驱动的契约（CDC）

从单体到微服务的重构

·         绞杀者模式（Strangler Fig）与防腐层：逐步替换而非重写

·         数据拆分策略：从共享数据库到数据库按服务拆分

·         分布式事务的处理模式：Saga、TCC、最终一致性

案例讲解与演练：

·         通过业务相关性分析划分期货交易子领域：交易核心子领域、风控核心子领域、清算结算支撑子领域、行情通用子领域

·         对子领域开展限界上下文划分：交易执行上下文、行情上下文、风控上下文、清算上下文、结算上下文、账户上下文、监管报送上下文

·         限界上下文API定义实战：交易上下文的开放主机服务（下单/撤单/查询接口契约）

·         期货交易系统的CQRS与事件驱动架构设计——以交易执行与行情推送的读写分离为例

实战演练——业务域分析与微服务映射：

·         基于期货交易业务场景（开户→交易→清算→结算），分组完成业务流程梳理与业务域划分

·         识别限界上下文并定义上下文API契约（服务序列图、OHS接口定义）

·         完成限界上下文到微服务的映射，确定通信协议与协作机制

收益：

·         掌握DDDUP的DDD战略设计方法，能通过业务相关性分析独立完成限界上下文划分

·         能定义限界上下文的API契约（OHS、服务序列图）

·         理解主流应用架构模式的设计思想与适用场景

·         掌握限界上下文与微服务的映射关系，明确微服务粒度与划分原则

·         了解从单体到微服务的演进路径与实战策略

第二部分 高复杂系统技术架构设计

本部分在DDD限界上下文的基础上，从分布式系统的核心属性出发，引入质量属性驱动设计和风险驱动开发，将技术决策建立在”理解系统固有约束”的根基之上，而非罗列模式清单。本部分围绕三个核心问题展开：如何保证系统持续可用、如何在约束条件下追求极致性能、如何从单站点扩展到跨站点韧性——以期货交易业务场景贯穿始终。

本部分内容主要包括：

质量属性、风险驱动与分布式系统基础

·         从CAP定理理解分布式系统的固有约束：一致性、可用性、分区容错性三者不可兼得

·         质量属性折中的本质：在一致性、可用性、延迟、持久性、可扩展性之间做系统化的取舍——不存在无代价的设计

·         质量属性驱动设计的过程：质量属性场景（6元组） → 架构策略 → 设计决策 → 权衡分析

·         风险驱动开发：以RAIDs识别为核心，风险即优先级，架构决策围绕高优先级风险展开

·         与DDD的结合：在每个限界上下文内部署质量属性场景，不同上下文可以有不同的取舍策略——交易上下文关注强一致与高可用，行情上下文关注低延迟

高可用：故障不可避免，服务必须持续

·         高可用的本质：通过冗余换取可靠性——当部分组件失效时，系统整体仍能正常服务

·         可用性的衡量应从”是否有故障”转向”故障恢复有多快”：MTBF/MTTR → SLA/SLO/SLI

·         故障隔离：通过缩小爆炸半径防止级联故障——线程隔离、进程隔离、机器隔离、可用区隔离

·         故障检测与恢复：心跳检测、健康检查、自动故障转移——核心在于”自动”，而非人工介入

·         流量控制：限流防止系统过载、熔断快速失败保护上游、重试补偿临时故障、超时释放挂起资源——四类策略分工不同，共同构成系统的自我保护层

·         幂等性设计：在重试机制下保证业务正确性——交易系统中的撤单重复提交、结算重复处理等场景尤为关键

·         架构模式的选择由RTO/RPO目标反向驱动：主备（分钟级恢复）→ 同城双活（秒级）→ 异地多活（接近于零）

·         案例：以期货交易为背景的高可用设计——熔断应对市场异常波动、限流应对集合竞价海量订单排队、幂等机制防止订单重复提交

高性能：在约束条件下追求极致响应

·         性能的本质：延迟和吞吐量的平衡——区分”快”（单次响应时间）与”多”（单位时间处理量）两个维度，优化手段各有侧重

·         选择不同的性能分位值决定了优化方向的侧重点：平均响应时间反映了普遍体验，高百分位响应时间反映了极端场景下的长尾问题

·         数据访问路径的优化——从”数据如何到达处理单元”出发：

o   多级缓存：浏览器缓存 → CDN → 本地缓存（Caffeine） → 分布式缓存（Redis），每一级解决不同距离的数据访问延迟

o   读写分离（CQRS）：对”高频读、低频写”这一不对称负载的自然回应——命令端与查询端独立部署扩缩容

o   数据本地化：将计算推向数据，减少物理距离带来的延迟

·         计算处理路径的优化——从”请求如何在系统中流转”出发：

o   异步化：将同步等待转化为事件驱动，释放线程资源——消息队列削峰的本质是”用时间换空间”

o   并行化：大任务拆分为独立子任务并发执行，缩短整体处理时间

o   高性能网络模型（Reactor）：通过事件循环处理海量连接，而非为每个连接分配一个线程——Netty的核心设计

o   零拷贝：减少数据在内核空间与用户空间的复制次数——Netty的FileRegion实现

·         案例：期货行情推送的高性能链路设计——多级缓存、异步分发、Reactor网络模型的组合运用；LMAX Disruptor（开源金融交易中间件）的无锁架构对交易订单处理的启发

容灾：从单点到跨站点的韧性设计

·         容灾的本质从”设计可预期的故障应对”出发，而非事后补救——两个核心指标决定方案等级：RPO（数据丢失容忍度）、RTO（服务恢复时间目标）

·         容灾层次的递进设计：

o   同城双活：应对单数据中心故障，RTO<1分钟——适用于对交易连续性高要求的核心业务

o   两地三中心：应对城市级灾难，RTO<15分钟——金融行业的经典容灾架构

o   异地多活：应对区域级灾难，RTO接近于零——单元化架构为异地多活提供了数据分片与流量路由的基础

·         容灾设计中的关键权衡：交易链路的同城双活保障（RTO目标秒级）与清算数据的异地灾备保障（RPO目标趋于零）之间的差异决定了不同的技术方案

案例与开源参考：

·         期货交易场景中的质量属性分析：交易可用性（5个9）、行情推送延迟（毫秒级）、清算数据一致性（强一致）

·         容灾递进方案选择由RPO/RTO反向驱动：不同的业务场景（交易vs清算）需要不同的容灾等级和方案

·         期货交易中集合竞价场景的限流设计：令牌桶+排队策略保障核心交易通道

·         期货行情推送的高性能链路设计：多级缓存 + Reactor网络模型 + 异步分发

·         LMAX Disruptor：金融交易系统高性能架构设计参考

实战演练——质量属性场景与技术架构设计：

·         基于期货交易案例的限界上下文，为各上下文定义关键质量属性场景（可用性、延迟、一致性）

·         开展RAIDs风险识别，确定风险优先级并制定架构策略

·         针对交易上下文设计高可用方案，针对行情上下文设计高性能方案，针对清算上下文设计容灾方案

收益：

·         掌握从CAP定理和质量属性出发的架构分析方法，理解可用性、一致性、延迟之间的折中关系

·         理解高可用的本质是”故障隔离与快速恢复”，能围绕这一目标设计自我保护策略

·         掌握从”数据路径”和”计算路径”两个维度优化性能的系统化方法

·         理解容灾层次的递进关系和RPO/RTO驱动的决策过程

第三部分 架构与设计模式综合运用

本部分不对每个模式做孤立讲解，而是将核心架构模式与设计模式放在真实项目场景中，围绕”可扩展性”和”高性能”两个核心目标，讲解模式在面对复杂业务时的取舍、组合与权衡。

架构模式

·         发布-订阅模式：在事件驱动架构中的核心地位——期货交易系统中行情推送、订单状态变更通知的应用

·         高并发架构模式：

o   反应器模式（Reactor）：Netty/Nginx的事件驱动模型

o   生产者-消费者模式：Kafka的消息处理模型

o   主从多线程模式：请求处理与业务处理的线程隔离

·         单元化架构：以单元（Cell）为单位的可扩展与容灾架构——金融系统的异地多活设计

设计模式

·         单例模式：全局唯一实例的管理——交易所核心配置管理器、日志工厂

·         策略模式：算法族的封装与替换——期货交易系统的手续费计算策略、风控规则策略（ShardingSphere策略模式参考）

·         观察者模式：事件通知与监听——交易状态变更通知、行情订阅推送

·         状态模式：有限状态机的建模——期货订单生命周期（已报、待撤、部撤、全成、废单）、交易所热备机制的状态转换

·         代理模式：间接访问与增强控制——远程代理（RPC）、虚拟代理（延迟加载）、保护代理（Spring AOP）

·         职责链模式 + 管道-过滤器模式：请求的分阶段处理——Netty管道、Servlet Filter、交易系统的风控过滤管道（黑白名单检查、资格校验、资金检查、限仓检查）

·         适配器模式：接口转换与系统集成——期货交易系统的交易所接口适配（CTP接口适配、FIX协议适配）

·         外观模式：统一的高层接口——微服务网关（BFF）、交易系统的一站式下单接口

·         插件模式（微内核/插件架构）：可扩展的基础架构——Kubernetes的微内核设计、交易系统的规则引擎插件

模式运用的核心思路

·         高扩展性设计：通过策略+职责链+插件模式构建可插拔的风控规则引擎；通过适配器+防腐层保证外部系统变更不污染核心领域

·         高性能设计：状态模式减少条件分支、单例减少对象创建开销、观察者的异步通知不阻塞主流程；明确”高性能不代表不用模式，而要用对模式”

案例与开源参考：

·         期货交易系统的综合模式运用分析：

o   订单生命周期管理：状态模式（订单状态流转）

o   风控规则引擎：策略模式（规则可配置）+ 职责链模式（规则链式检查）+ 插件模式（规则可扩展）

o   行情订阅推送：观察者模式（行情发布-订阅）+ 发布-订阅模式（Kafka主题分区）

o   交易所接口适配：适配器模式 + 防腐层（隔离CTP/FIX等不同协议）

o   核心交易通道：代理模式（远程代理封装RPC调用）+ 单例模式（通道管理器）

o   交易系统BFF：外观模式（统一下单/撤单/查询入口）

·         Netty管道：职责链模式与管道-过滤器模式的实际应用

·         ShardingSphere：策略模式（分片策略可替换）

·         Kubernetes：插件模式（微内核架构）

实战演练——核心场景模式落地与设计评审：

·         选取期货交易系统的核心场景（如风控规则引擎、订单生命周期管理），为关键业务场景选定并组合设计模式

·         各分组输出《核心模块架构设计说明书》草案

·         分组展示架构设计成果，开展设计评审与答辩，讲师点评与团队互评

·         输出《架构决策记录（ADR）》草案