消息队列和应用工具产品体系（二）

上一节的消息队列解决了"让服务之间松耦合、扛住流量尖峰"，但故障依然会发生——这一节看怎么主动为故障做准备，而不是等它发生了再救火。

限流、降级、熔断：三个常被混着用的概念

这三个词经常一起出现，容易混，先分开说清楚：

概念	做什么	触发时机
限流	限制单位时间内的请求量，超过阈值的请求直接拒绝或排队	提前设定好阈值，达到就生效，保护系统不被瞬时流量打垮
降级	主动放弃一部分非核心功能，把资源留给核心链路	系统压力大或者某个依赖出问题时，比如大促期间先关掉"猜你喜欢"这类非核心推荐，保住下单支付
熔断	某个依赖持续失败超过阈值，直接停止调用它，一段时间后再小流量尝试恢复	依赖服务本身已经出问题，避免请求持续打到一个已经挂了的服务上，越打越糟

三者的共同点是都在"牺牲一部分"来保住"更重要的部分"——限流保护自己不被外部流量压垮，降级主动放弃非核心以保核心，熔断则是及时止损、不去拖累一个已经出问题的下游。

限流常见的实现思路有令牌桶、漏桶、滑动窗口几种算法，考试更关注"是什么、解决什么问题"，具体算法细节这里不展开。

混沌工程：主动制造故障，而不是被动等故障发生

前面这些机制都是"故障发生时怎么应对"，混沌工程问的是另一个问题：这些应对机制真的管用吗？没出问题之前怎么知道？

混沌工程的做法是主动在生产环境（或者接近生产的环境）里注入故障——比如故意制造网络延迟、杀掉某个进程、把某个依赖服务模拟成不可用——用可控的方式提前验证系统的容错能力，而不是等真实的故障发生了才发现设计上的漏洞。

这个理念最早由 Netflix 的 Chaos Monkey 实践打响：随机关闭生产环境里的实例，逼着整个团队必须把系统设计得能容忍单点故障，因为"实例随时可能挂"变成了一个必然会发生的日常事件，而不是小概率的意外。核心逻辑是：与其祈祷不出故障，不如主动制造可控的故障，验证系统是不是真的扛得住。

AHAS：把这两块能力产品化

AHAS（应用高可用服务）是阿里云把"故障应对"和"故障演练"这两条线整合起来的产品，包含三大模块：

流控降级：对应前面说的限流、降级、熔断。底层是 Sentinel，阿里巴巴双十一技术体系里的核心流量控制组件（开源），AHAS 的流控降级就是 Sentinel 的商业化托管版本，支持应用级和网关级两种防护粒度
架构感知：自动梳理应用之间的调用关系，画出依赖拓扑图——出问题的时候，一眼能看清故障的影响范围可能波及哪些下游
故障演练：也就是 AHAS Chaos，遵循混沌工程的实验原理，融合了阿里巴巴内部多年大促积累的实践经验，提供丰富的故障场景，帮助团队在真正出问题之前，先验证系统的容错和恢复能力

三个模块合起来看，是一条完整的闭环：架构感知让你知道系统长什么样、依赖关系是什么，流控降级在出问题时兜底，故障演练提前验证兜底机制真的有效。

有了限流降级和混沌工程，系统在出问题时能扛住、能兜底。但"扛住"之后还有一个问题：系统的极限到底在哪？下一节看压测和监控。