软件架构没有万能银弹，但有一套实用的模式组合，可以在复杂业务、快速迭代和团队协作之间找到平衡。本文用通俗的方式拆解 7 个常见架构模式，并展示它们如何在同一个电商系统里协同工作。

架构不是炫技，而是用尽量简单、可演进的方式，解决当下最关键的问题。

软件架构没有标准答案，不同业务、团队规模和技术栈，往往需要完全不同的方案。但有一点是共通的：优秀的架构师往往不会从“框架选型”开始，而是从“模式组合”开始。

这篇文章结合实际经验，聊聊几个在真实项目中非常实用的架构模式：

• 有助于拆分复杂业务的 有界上下文（Bounded Contexts）
• 给旧系统“挂外挂”的 边车模式（Sidecar）
• 异步解耦的 发布-订阅（Publisher-Subscriber）
• 统一入口的 应用网关（Application Gateway）
• 大家谈之色变却又离不开的 微服务（Microservices）
• 拆分前端的 微前端（Microfrontends）
• 在读写上动刀的 CQRS 与事件溯源（Event Sourcing）
• 最后，把它们组合在一起的 多样化架构（Polyglot Architecture）

不必一次性全用上，但理解它们适合解决什么问题，会极大提升你的架构判断力。

1. 有界上下文：从“一个系统”到“若干清晰的小世界”

很多项目一开始只有一个“单体应用”：单一代码仓库、单一数据库，所有领域概念搅在一起。时间一长，你会发现：

• 同一个词在不同模块中含义不一样（比如「订单」在风控、结算、客服里的含义都不同）
• 改一个小需求，要改一大堆看不懂的代码
• 想拆服务，却不知道从哪里下手

有界上下文（Bounded Context） 就是用来给这些概念设定“边界”的：

• 每个上下文只关心一小块业务，例如：商品目录、下单流程、支付、账号与权限等
• 每个上下文内部，术语、数据结构和业务规则是统一的
• 上下文与上下文之间，通过明确的接口或消息进行沟通

在代码组织层面，可以这样落地：

• 以业务上下文为维度拆分目录结构、模块或服务
• 每个上下文内有自己的领域模型、用例、基础设施
• 未来如果要做微服务或模块化，只需顺着这些上下文天然拆分

适用场景：

• 业务复杂度中高、概念众多的系统（例如电商、金融、SaaS 平台）
• 已经感觉到“牵一发而动全身”，但还没正式上微服务
• 想给未来的服务拆分、团队拆分铺路

2. 边车模式（Sidecar）：不给旧系统做大手术的外挂方案

现实世界里，大量核心系统是旧的：

• 技术栈陈旧，不好改
• 稳定运行多年，没人敢动
• 但又需要增加鉴权、日志、监控、限流等横切能力

边车模式（Sidecar） 的做法是：在主应用旁边，部署一个“伴生进程”，统一接管进出流量或公共能力：

• 所有流量先经过 Sidecar，再转发到主应用
• Sidecar 里实现认证、授权、访问控制、日志、熔断、重试、限流等功能
• 主应用基本不需要改动，就能享受一整套通用能力

在 Kubernetes 世界里，Service Mesh（服务网格） 就是把 Sidecar 发挥到极致：

• 每个 Pod 里都有一个代理 Sidecar
• 所有服务间通信都走 Sidecar，方便统一加密、监控、限流

适用场景：

• 无法轻易修改的遗留系统，需要补齐安全或观测能力
• 希望在多语言、多技术栈的服务之间，统一实现横切逻辑

3. 发布-订阅：用消息中间件解耦系统

当系统之间存在大量“谁调用谁”的同步 HTTP 调用时：

• 上游挂了，下游全挂
• 扩容、限流、熔断都变得很复杂

发布-订阅（Publisher-Subscriber） 模式通过消息中间件，把发送者和接收者解耦：

• 发布者（Publisher） 只负责往 Topic 里发消息，不关心具体是谁在消费
• 订阅者（Subscriber） 只负责订阅感兴趣的 Topic，异步处理消息

常见有两种投递机制：

• 竞争消费者（Competing Consumers）：一条消息只会被某个订阅组里的一个消费者处理，适合将耗时任务并行分摊给多台 Worker
• 广播 / 扇出（Fanout）：同一条消息会被多个订阅者分别消费，适合同步事件到多个下游系统

适用场景：

• 需要异步处理的长耗时任务（例如生成报表、发送邮件 / 短信）
• 一个业务事件需要通知多个下游（例如订单已支付，需要通知库存、物流、营销等）
• 希望系统间解耦，提升整体容错能力

4. 应用网关：给复杂后端的统一“门面”

当后端服务越来越多时，如果每个服务都直接对外暴露：

• 前端要记很多不同的域名和端口
• 统一的鉴权、限流、防火墙配置都很麻烦

应用网关（Application Gateway） 提供了一个统一入口：

• 客户端只访问一个域名，例如 api.example.com
• 网关根据路径前缀、Host、Header 等信息，把请求路由到具体的后端服务
• 同时在网关层统一处理 SSL 终止、WAF、防爬、限流、黑白名单、统一鉴权等

和传统的四层负载均衡相比，应用网关工作在七层（HTTP 协议级别），可以做“看得懂业务”的路由与策略。

适用场景：

• 需要在一个或少量域名后面，承载大量后端服务
• 希望统一处理安全策略、流量治理、监控统计

5. 微服务：拆还是不拆，这是个问题

微服务（Microservices） 是把一个应用拆成一组小而独立的服务：

• 每个服务有自己的 API 和数据库
• 服务之间通过网络协议交互，可以独立部署、独立扩缩容
• 可以选择不同的技术栈与存储方案

听上去很美，但实践中踩坑无数：

• 分布式事务、数据一致性更难
• 调试和排错成本大幅上升
• 部署、监控、配置管理复杂度飙升

因此，微服务更像是一组架构 trade-off 的打包选择：

• 用更高的运维复杂度，换取更好的团队并行开发、独立部署、可扩展性

适用场景（真的需要时）：

• 不同业务模块对性能、扩展性、高可用有明显不同要求
• 不同团队需要相对独立的迭代各自的模块
• 已有清晰的有界上下文划分和较成熟的 DevOps 体系

如果应用还不复杂、团队不大，一个结构清晰的单体 + 有界上下文 + 模块化，往往比微服务更务实。

6. 微前端：把“大前端”拆给不同团队

在微服务火了之后，很多团队发现前端也遇到了类似问题：

• 单一前端工程越来越大，构建、发布越来越慢
• 多个团队改同一个仓库，冲突频发
• 不同页面由不同团队维护，生命周期不一致

微前端（Microfrontends） 的想法是：

• 把一个 Web 前端拆成多个独立的前端“小应用”
• 每个小应用负责一块功能区域，有自己的发布节奏
• 再通过 Portal 或壳应用把它们拼接在一起

随着 Web Components 等标准成熟，不同微前端甚至可以使用不同框架，只要最终暴露为统一的组件接口即可。

适用场景：

• 大型 Web 应用，需要由多个团队长期维护不同功能区
• 希望不同业务模块可以独立发布、独立回滚
• 前端代码规模快速增长，单仓库已难以维护

7. CQRS 与事件溯源：为性能和审计而“分家”

在很多系统中，读请求远多于写请求，或者读写对数据的关注点完全不同。

CQRS（Command Query Responsibility Segregation，命令查询职责分离） 提出：

• 写入（命令）和读取（查询）使用不同模型甚至不同数据存储
• 写端专注于正确性、业务规则、事务一致性
• 读端专注于查询效率、报表需求和多维视图

在更极端的版本里，会配合 事件溯源（Event Sourcing）：

• 写端不直接存“当前状态”，而是存一串不可变事件（例如账户“存入 100”“支出 30”）
• 需要当前状态时，通过回放这些事件来“还原”
• 任意时刻都可以重建不同视图，天然具备强审计能力

适用场景：

• 对性能、可扩展性、审计追踪有极高要求的系统（比如支付、风控）
• 读写模型截然不同、读远大于写的业务

需要注意的是：CQRS + 事件溯源的学习和维护成本极高，没有足够收益时不要轻易上。

8. 多样化架构：在同一个系统里“拼装”模式

在一个真实的电商系统中，上面这些模式往往是组合使用的，而不是“择一而用”：

• 用 有界上下文 拆出商品、订单、支付、账号等领域
• 每个上下文内部，可以选择是否做 微服务 拆分
• 前端用 微前端 把不同业务团队维护的页面拼在一起
• 跨上下文的事件同步，用 发布-订阅 和消息中间件来解耦
• 对外只暴露一个域名，由 应用网关 把请求路由到不同后端
• 在关键核心链路上，用 CQRS / 事件溯源 保证审计与可追溯
• 对老系统或第三方服务，用 Sidecar 补上安全与观测

这类组合式方案，可以称为 多样化架构（Polyglot Architecture）：

• 不执着于某一种“统一架构风格”
• 而是根据每个有界上下文的特性，选择最合适的模式与技术栈

写在最后：别为模式而模式

在架构设计时，可以反向问自己三个问题：

1. 这块业务目前 最大的痛点是什么？是复杂度、性能、可用性，还是团队协作？
2. 现有架构哪里已经明显“不够用了”？
3. 如果引入一种模式，能具体缓解哪些问题，同时又会增加哪些新的复杂度？

理解模式，是为了在关键决策点有更多可用的“工具”，而不是为了把系统堆成「炫技合集」。永远从问题出发，再选择最简单可行的模式组合，这也许就是架构这门“艺术”的核心。

Hi，我是俞凡，一名兼具技术深度与管理视野的技术管理者。曾就职于 Motorola，现任职于 Mavenir，多年带领技术团队，聚焦后端架构与云原生，持续关注 AI 等前沿方向，也关注人的成长，笃信持续学习的力量。在这里，我会分享技术实践与思考。欢迎关注公众号「DeepNoMind」，星标不迷路。也欢迎访问独立站 www.DeepNoMind.com^[1]，一起交流成长。