软件架构

[wxb]

架构

[wxb]

Event 事件架构

事件机制是开发中非常有用的一种开发模式：发布/订阅模式（观察者模式），这种模式的最大好处就是实现代码的解耦，代码逻辑更加清晰。

EventBus

事件总线是这种模式的一种实现方式。

根据适用架构不同：

• 单进程事件总线：单进程代码快速解耦
• 分布式事件总线：跨进程/集群(跨设备/容器)

[wxb]

监控工具grafana项目中实现的事件总线

参考资料：

• Golang事件系统Event Bus
• grafana/pkg/bus源码

[wxb]

CQRS 架构

一、CQRS架构核心定义与起源

CQRS（Command Query Responsibility Segregation，命令查询职责分离）是一种架构模式，核心是将系统操作明确划分为命令（Command） 和查询（Query） 两类，通过分离读写职责实现针对性优化。其思想源于Bertrand Meyer提出的命令查询分离（CQS） 原则，后经Greg Young扩展为适用于复杂系统的CQRS模式。

• 命令（Command）：负责修改系统状态，如创建、更新、删除数据，无返回结果，需保证事务一致性（例：创建订单、更新商品库存）。
• 查询（Query）：仅读取数据、不改变系统状态，有返回结果，需优化响应性能（例：查询商品列表、获取用户订单历史）。

二、传统CRUD架构痛点与CQRS的解决思路

1. 传统CRUD架构的核心问题

传统架构中读写操作共享同一数据模型（如数据库实体），在业务复杂度提升后会暴露以下问题：

痛点类型	具体表现
性能瓶颈	读写竞争同一资源（如数据库表），查询频繁时会阻塞写操作，反之亦然；复杂查询（多表关联）拖慢整体响应速度
模型臃肿	同一实体需同时满足读写需求，为适配查询添加冗余字段，或为保证事务安全限制查询灵活性
扩展性差	读写负载特征不同（如读多写少），但需共享同一扩展资源，无法针对性扩容
一致性与安全复杂	读写操作使用同一实体，权限控制需兼顾两类场景；同步读写易引发锁竞争，需处理脏读、幻读等问题

2. CQRS的解决逻辑

通过“分离”实现“专岗专责”，具体分为三个层级：

• 接口层分离：将命令操作（如CreateOrder）和查询操作（如GetOrderList）封装为独立服务接口（例：OrderCommandService和OrderQueryService）。
• 模型层分离：命令模型（写模型）专注业务规则与状态一致性（含校验逻辑、事务控制），查询模型（读模型）专注数据展示需求（扁平结构、冗余字段减少关联查询）。
• 存储层分离：命令端使用关系型数据库（如MySQL）保证事务完整性，查询端使用NoSQL数据库（如Elasticsearch）、缓存（如Redis）或宽表优化查询性能；通过事件同步（如消息队列、binlog监听）保证读写数据最终一致性。

三、CQRS架构核心组成与工作流程

1. 核心组件

• 命令处理器（Command Handler）：接收命令请求，验证业务规则，更新写模型，生成领域事件。
• 查询处理器（Query Handler）：接收查询请求，从读模型中获取数据，返回适配展示的结果（如DTO）。
• 写模型（Write Model）：对应DDD中的领域模型，包含实体、值对象、聚合根，负责维护业务状态与一致性。
• 读模型（Read Model）：面向查询优化的数据结构，可根据不同场景设计多个版本（如PC端/移动端视图），无业务逻辑。
• 事件总线（Event Bus）：传递命令执行后生成的领域事件，触发读模型更新（例：OrderCreatedEvent触发订单读模型同步）。
• 数据同步机制：实现读写模型数据一致性的核心，常见方式包括消息队列（Kafka/RabbitMQ）异步同步、数据库主从复制（写主库、读从库）、binlog监听（如Canal）。

2. 典型工作流程（以电商订单为例）

1. 命令执行流程：

   • 客户端发起“创建订单”请求 → 命令处理器接收CreateOrderCommand；
   • 命令处理器调用写模型（Order聚合根），执行业务校验（如库存检查、用户权限）；
   • 写模型更新状态，通过事务将数据写入命令端数据库（MySQL）；
   • 生成OrderCreatedEvent，发送至事件总线。

2. 查询同步流程：

   • 事件总线将OrderCreatedEvent推送给读模型更新服务；
   • 更新服务消费事件，将订单数据转换为查询模型（如OrderSummaryDTO），写入查询端存储（如Elasticsearch宽表）；
   • 客户端发起“查询订单列表”请求 → 查询处理器从Elasticsearch读取数据，返回结果。

四、CQRS架构的优缺点分析

1. 核心优势

优势维度	具体表现
性能优化	读写独立扩展，读端可横向增加从库/缓存节点，写端可通过消息队列削峰；查询端使用专储减少关联操作，响应速度提升10-100倍
业务逻辑清晰	写模型专注复杂业务规则（如订单状态流转），读模型专注数据展示，代码可维护性提升，新成员上手成本降低
架构灵活性	支持多读模型设计，可针对不同场景（运营报表、用户端查询）定制数据结构；技术选型解耦，写端用MySQL、读端用Elasticsearch
团队协作高效	可按职责拆分团队（命令团队负责业务逻辑，查询团队负责性能优化），减少代码冲突，并行开发效率提升
兼容事件驱动与DDD	天然适配事件溯源（Event Sourcing），可通过事件重建系统状态；与DDD结合时，命令端对应领域层，查询端对应展示层需求

2. 主要劣势

• 复杂度提升：需维护两套模型（读写）及同步机制，架构设计、开发测试成本增加；团队需理解DDD、事件驱动等概念，学习门槛较高。
• 一致性挑战：异步同步会导致短暂数据不一致（如订单创建后1秒内查询不到），需业务层接受“最终一致性”，并设计补偿机制（如重试、告警）。
• 运维成本上升：多存储系统（MySQL+Elasticsearch+Redis）需独立部署监控；同步链路（消息队列、binlog监听）需保障高可用，避免数据丢失。
• 过度设计风险：对于简单CRUD系统（如小型管理后台），引入CQRS会增加不必要的复杂度，反而降低开发效率。

五、CQRS适用场景与落地建议

1. 适配场景

• 读写比例极端不平衡：读多写少（如电商商品详情页、社交平台信息流）或写多读少（如日志系统、实时交易记录）。
• 复杂业务领域：业务规则多（如金融交易、订单履约），需清晰分离业务逻辑与查询需求。
• 高并发与高性能需求：需支撑每秒数万次查询，或要求毫秒级响应（如秒杀系统、实时报表）。
• 多团队协作场景：不同团队负责业务逻辑与数据展示，需明确接口边界减少沟通成本。

2. 不适配场景

• 简单CRUD系统（如小型办公系统、个人项目）；
• 强一致性要求场景（如银行转账、库存扣减需实时同步）；
• 团队技术栈不匹配（无DDD、事件驱动经验）。

3. 落地实践建议

• 渐进式实施：从局部场景切入（如先将“商品查询”与“商品更新”分离），而非一次性改造全系统；初期可保留同一数据库，仅分离模型与接口，降低风险。
• 结合DDD与事件驱动：命令端复用DDD领域模型，查询端根据限界上下文设计读模型；使用事件溯源（Event Sourcing）存储状态变更历史，便于问题排查与状态回滚。
• 选择成熟中间件：同步机制优先用Kafka（高吞吐）或Canal（binlog监听）；查询端优先用Elasticsearch（全文检索）或Redis（缓存热点数据）。
• 监控与容错设计：监控读写数据一致性（如定时校验数据差异）；同步失败时触发重试，重试失败则告警并记录死信队列，人工介入处理。

六、CQRS与DDD的协同关系

CQRS与领域驱动设计（DDD）具有天然契合性，两者结合可更好地应对复杂业务：

• 命令端对应DDD领域层：命令模型即DDD中的聚合根/实体，包含业务规则与领域服务；命令处理器对应应用服务，负责协调领域对象执行操作。
• 查询端对应DDD展示需求：读模型根据前端/报表需求设计，无需映射领域概念；查询处理器简化应用服务职责，仅专注数据组装。
• 限界上下文界定CQRS边界：每个限界上下文可独立决定是否启用CQRS（如“订单上下文”启用，“用户上下文”不启用）；上下文间通过防腐层（ACL）交互，避免耦合。

七、总结

CQRS并非“银弹”，而是解决复杂系统读写矛盾的“精准工具”。其核心价值在于通过“分离职责”实现“针对性优化”，让写操作专注一致性、读操作专注性能。落地时需结合业务复杂度、团队能力与性能需求综合判断，避免为了“架构先进”而过度设计。在高并发、复杂业务场景中，CQRS结合DDD与事件驱动，可构建出高可用、易扩展的系统架构，支撑业务长期演进。

[wxb]

DDD 架构

#163

[wxb]

Clean Architecture（整洁架构）

Clean Architecture，由 Robert C. Martin（Bob 大叔）提出，是一套分层、单向依赖、关注点分离的软件架构设计思想。

核心目标：

1. 业务领域为核心，业务逻辑不依赖任何框架、数据库、第三方组件；
2. 依赖规则：外层依赖内层，内层绝不依赖外层；
3. 系统高度解耦、易测试、易替换底层组件、易维护、适配复杂业务。

---

Clean Architecture 标准分层（由内到外）

越内层越核心、越稳定；越外层越易变、越贴近基础设施。

1. 领域层（Domain）
   系统核心：业务实体、领域模型、业务规则、核心枚举、业务常量。
   ✅ 最稳定，不依赖任何外部。

2. 应用层（Application）
   业务用例、业务流程、服务编排、工作流调度。
   只依赖「领域层」，负责串联领域能力，完成完整业务动作。

3. 接口/适配层（Interface & Adapters / 接入层）
   定义抽象接口、端口、契约。
   隔离内外层，给上层提供抽象，下层做具体实现。

4. 基础设施层（Infrastructure）
   数据库、缓存、消息队列、对象存储、第三方 SDK、LLM、Temporal、OCR 等外部依赖的具体实现。

5. 表示层（Presentation）
   入口层：HTTP 接口（FastAPI）、RPC、定时任务、控制台、前端交互对接。

---

黄金依赖规则（Clean 架构灵魂）

所有依赖必须由「外层 → 内层」

• 表示层 → 应用层
• 应用层 → 领域层
• 基础设施 → 接入层抽象
• ❌ 领域层/应用层 绝对不能 依赖数据库、框架、第三方服务

简单理解：
业务代码纯纯净净，框架和存储都是“外挂”，随时可换。

---

Clean 架构核心优势

1. 业务与技术解耦
   换数据库、换向量引擎、换调度框架，不用改核心业务代码。
2. 可测试性极强
   领域逻辑无外部依赖，轻松单元测试、mock 外部组件。
3. 结构清晰
   分层职责单一，新人上手快，便于大型团队协作。
4. 抗变化
   技术栈迭代、第三方服务变更，影响范围极小。

---

总结

Clean 架构 = 以业务领域为中心 + 分层隔离 + 单向向内依赖 + 外部依赖全部抽象适配，
让软件业务稳定不变，技术组件灵活可替换。