第2章 · 整体架构与分层模型
第 2 章 · 整体架构与分层模型
章节摘要：高并发系统是个分层结构，流量从入口进来，一层层往下传，最终落到数据层。每一层有明确的职责，也配对应的治理手段。这一章讲整体架构和流量在入口怎么治理——负载均衡怎么分发、限流熔断降级三板斧怎么落地。读完你会对“一个高并发系统从外到内长什么样”有完整认识。
学习目标
阅读完本章，你应当能够：
- 画出一个典型高并发系统的分层架构
- 说清负载均衡的几种策略及其适用场景
- 说清限流（令牌桶/漏桶）、熔断、降级的原理和实现要点
- 设计一个入口层的流量治理方案
- 解释为什么限流熔断要配着用，单用一种不够
核心概念速览
高并发架构的核心是“分层加治理”——每一层各司其职，每层都有对应的流量治理手段，任何一层失守都要有兜底。
子章节导航
2.1 接入层与流量治理体系
讲流量从用户到应用的第一道关卡：负载均衡（轮询、加权、一致性哈希）、CDN 加速、WAF 防护，以及接入层怎么做第一道限流。这层是系统的门面，也是挡住异常流量的第一道防线。
2.2 限流熔断与降级兜底
三板斧的深入版。讲限流的四种算法（计数器、滑动窗口、令牌桶、漏桶）的原理和差别，熔断器的三种状态（关闭、打开、半开）和恢复机制，降级的策略（返回默认值、读缓存、简化逻辑），以及三者怎么配合形成兜底网。
子章节之间的逻辑关系
2.1 讲流量怎么进系统、在入口怎么分流，2.2 讲流量进了系统后怎么用三板斧治理。前者管“分发”，后者管“控制”，合起来就是入口到应用的完整流量治理。
2.1 分发（负载均衡） + 2.2 控制（限流熔断降级）
前置知识与后续延伸
- 前置知识：第 1 章的指标体系和演进认知；基本的网络和应用开发经验。
- 后续延伸：本章讲架构和流量治理。第 3 章钻进应用层，讲怎么把应用做成无状态、能弹性伸缩的。
延伸：两种分层哲学的对撞
分层这件事存在两种截然不同的哲学，对比之后你会更清楚自己团队该站哪边。一种是"技术分层"——按调用链纵向切：接入层、网关层、服务层、数据层，每层解决一类技术问题，职责与流量方向垂直。另一种是"业务分层"——按领域横向切：交易域、库存域、用户域，每个域内部自带完整的技术栈，领域之间只通过接口交互。技术分层的好处是治理集中、心智简单，坏处是任何一个业务需求都要横穿所有层，跨团队协作成本随层数线性上涨；业务分层反过来，需求收敛在域内、变更快，代价是基础设施重复建设和全局一致的困难。
实践中成熟的大型系统几乎都是两者叠加：先按业务域切分（横向），每个域内部再按技术分层（纵向），形成矩阵结构。矩阵的交点就是一个个可独立部署、可独立故障的服务单元。判断自己的团队该切到哪一步，看的不是公司规模而是变更冲突频率——当两个互不相关的需求频繁在同一批文件里撞车，就是该按域拆分的信号；如果撞车还没发生，过早按域拆只会收获一堆沟通成本。
图：技术分层与业务分层的矩阵结构
本章两节的阅读顺序建议保持先后：先读接入层建立"流量从哪进来、在哪里被治理"的空间图景，再读限流熔断深入每个手段的参数与边界。学完可以用一个自检题验证：给你一个"大促期间库存服务超时率升高"的场景，你应该能说出四道手段各自会不会触发、以什么顺序触发、用户端分别看到什么现象。答得出来，本章就算吃透了；答不出来，回到第一节的纵深次序图再过一遍。
再多说一句本章内容的复习方法：限流熔断的参数手感必须靠演练维持，纸面记忆三个月就钝。建议每季度做一次"防护参数年检"：把所有阈值、窗口、错误率参数列成表，逐个对照近三个月的实际流量数据，该升的升该降的降。参数是活的，流量在长，防护体系也该跟着呼吸。
另外给一个跨章依赖的提示：本章的分层模型是第 4 章数据层设计的输入——数据层怎么拆、缓存放哪里，都取决于本章定下的服务边界。反过来，第 4 章的容量数据也会回头修正本章的分层：某两个服务的数据访问耦合太深，就是合并或调整边界的信号。分层是活的结构，用数据定期校准，不要当成一次性的设计成果。
另外一个绘图练习推荐给你：读完本章，用一页纸画出自己系统的分层图，只画三层以内的抽象（入口、服务、数据），每层标注部署单元数和故障隔离边界。画不出来的地方——比如说不清某两个服务是否共享数据库——就是你对自己系统认知的盲区，也是潜在的故障域。这张图比任何文档都诚实，值得每半年重画一次留档对比。