本文系统梳理架构落地中常见的几种核心架构模式，分析各自的优势与适用场景，并给出选型建议。
一、分层架构（Layered Architecture）
常见分层
- 经典四层：展现层 → 业务层 → 持久层 → 数据库层
- DDD 分层：接口层 → 应用层 → 领域层 → 基础设施层
优势
- 关注点分离：每层职责清晰，便于团队分工
- 可测试性强：各层可独立进行单元测试和 Mock
- 易于维护：修改某一层不影响其他层（接口契约不变）
- 技术栈解耦：例如业务层不依赖具体 ORM 框架
适用场景
- 企业级 CRUD 应用、传统 ERP / OA 系统
- 团队规模较大、需要明确职责边界的项目
二、微服务架构（Microservices Architecture）
核心特征
- 每个服务独立部署、独立数据库
- 服务间通过轻量通信（REST / gRPC / 消息队列）
- 围绕业务能力组织服务边界
优势
- 独立扩展：高负载服务单独扩容，节省资源
- 技术异构：不同服务可用不同技术栈（如 Java + Go 混合）
- 故障隔离：一个服务崩溃不会拖垮整个系统
- 快速迭代：小团队独立开发部署，发布周期缩短至天级
典型配套
- 注册中心（Nacos / Eureka）
- 网关（Spring Cloud Gateway）
- 配置中心（Apollo / Nacos）
- 链路追踪（SkyWalking）
三、事件驱动架构（Event-Driven Architecture, EDA）
两种模式
- 事件通知：生产者发布事件，消费者订阅处理
- 事件溯源：以事件序列作为唯一事实来源
优势
- 高度解耦：生产者和消费者完全不知道彼此存在
- 异步削峰：秒杀、订单等突发流量通过 MQ 缓冲
- 最终一致性：适合跨服务的分布式事务场景
- 可追溯性：事件溯源模式下，所有状态变更都有完整记录
常用组件
- 消息队列：Kafka / RocketMQ / RabbitMQ
- 事件存储：Event Store
- 数据捕获：Debezium（CDC）
四、CQRS（命令查询职责分离）
核心思想
- Command（命令）：写操作（Insert / Update / Delete），使用写模型
- Query（查询）：读操作（Select），使用读模型（可反范式化或使用 ES）
优势
- 读写性能独立优化：读库可以建大量索引甚至用 NoSQL
- 复杂查询友好：避免 JOIN 带来的写性能瓶颈
- 安全管控：读写权限可分别控制
- 与 EDA 天然结合：写端产生事件 → 更新读端
注意代价
- 数据最终一致性，需要处理延迟窗口
- 系统复杂度显著增加（需维护两份数据模型）
五、六边形架构（Hexagonal / Ports and Adapters）
结构
- 内部：核心业务逻辑（纯 POJO，无框架依赖）
- 端口（Port）：定义输入输出接口（Repository 接口、Service 接口）
- 适配器（Adapter）：实现端口的技术细节（JPA 实现、REST 控制器）
优势
- 业务与技术彻底解耦：核心代码可脱离 Spring / Database 运行
- 极致可测试性：核心逻辑无需启动容器即可测试
- 框架无关：更换 ORM、消息中间件只需替换适配器
- DDD 最佳实践载体
六、管道-过滤器架构（Pipe-and-Filter）
结构
- Filter（过滤器）：数据处理单元（验证、转换、增强）
- Pipe（管道）：连接 Filter 的数据通道
优势
- 高度可复用：Filter 可任意组合
- 并行处理：不同 Filter 可部署在不同节点
- 易于扩展：新增 Filter 不影响已有逻辑
典型场景
- ETL 流程、日志处理流水线、数据清洗任务
七、Serverless / FaaS 架构
特点
- 函数即服务（AWS Lambda / 腾讯云 SCF）
- 按调用次数计费，自动弹性伸缩
优势
- 零运维：无需管理服务器
- 极致弹性：从 0 到 10000 并发瞬间完成
- 成本优化：空闲时段几乎零成本
局限性
- 冷启动延迟（Java 尤其明显）
- 有状态场景不友好
- 执行时长有限制
架构选型建议
| 业务特征 | 推荐架构 |
|---|---|
| CRUD 为主、团队成熟度一般 | 分层架构 + 模块化单体 |
| 业务复杂、多团队协作 | 微服务 + DDD 限界上下文 |
| 高并发、异步流 | 事件驱动 + CQRS |
| 核心业务需长期演进 | 六边形架构 + DDD |
| 数据处理流水线 | 管道-过滤器 |
| 低频、突发型任务 | Serverless |
关键原则
- 不要为了架构而架构——简单系统用分层即可
- 架构是演进而非设计出来的——先单体再拆分
- 一致性比先进性更重要——团队能驾驭的才是好架构