flowchart LR
N0["01 分层与职责"]
N1["02 模块化单体"]
N2["03 领域与依赖"]
N3["04 微服务治理"]
N4["05 事件与读写"]
N5["06 部署与组合"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
常见后端架构
从请求、数据与业务边界学到后端架构、可靠性和部署实践
0 子目录6 文档
CHAPTER OVERVIEW · 章节概览
先建立职责边界，再比较不同架构解决的问题和额外成本；这些方案不是必须逐级升级的一条产品路线。
本章学习路线
箭头表示建议的学习顺序；先理解问题，再逐步进入实现与实践。
按顺序学习
6分层架构与 MVC：把请求处理和业务规则分开刚写后端时，最容易把解析参数、查数据库、算价格、发邮件全塞进一个接口函数。功能少时很快，后来换一个入口、加一个优惠规则，就开始担心改坏其他地方。分层的目的，是让变化有明确的位置。模块化单体：先把边界分清，再决定是否拆服务一个应用可以有很多模块，却只部署一个产物。用户、订单、库存各有自己的职责，通过明确接口合作，这就是模块化单体的一种常见组织方式。它不要求代码杂乱，也不意味着只能运行一个实例。六边形架构、Clean Architecture 与 DDD：相近但不同的三个问题想给下单逻辑写测试，却必须先启动数据库、消息队列和 HTTP 服务。这通常说明业务与外部技术粘得太紧。端口和适配器提供一种拆法：业务需要什么能力，就声明什么约定；具体技术在外面实现。微服务、SOA 与服务治理：拆开以后要多承担什么把库存从订单应用里抽出来，调用从函数变成 HTTP，代码看起来只是换了几行。但原来同进程的确定性已经变了：请求可能延迟、超时、重复，服务可能只坏一部分，发布版本也可能不同步。事件驱动、CQRS 与 Event Sourcing：别把三个概念混成一套订单创建后，通知、搜索和统计都想知道这件事。订单接口如果逐个等待它们，任何一个变慢都会拖住用户。可以把已发生的事实发布出去，让各方按自己的节奏处理；这就是事件驱动的一种用途。Serverless、BFF 与 Web-Queue-Worker：按不同轴线组合架构移动端需要精简首页，管理后台需要复杂报表，报表导出又可能花几分钟。这里同时涉及面向谁提供接口、耗时工作放哪里、程序怎样部署。BFF、Worker 和 Serverless 分别回答不同问题，可以组合使用。