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

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

请求多了或依赖坏了怎么办

限流可以看 QPS，也可以看并发数；熔断看慢调用、异常比例或异常数等统计。图中的熔断恢复以 Sentinel 为例，具体阈值、统计窗口和探测规则需要配置。降级的备用结果则由业务定义，不能把“熔断了”自动等同于“已经有可用的替代结果”。见 Sentinel 的流量控制与熔断降级说明。

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

排队等待如何削峰

排队等待可以按规则控制请求通过的间隔，把短时突发摊到后面处理。它和消息队列都有缓冲尖峰的效果，但这里等待的是当前调用，并非持久化消息；等待时间也要有上限，不能无限排队。

如何验证防护真的有效

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

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

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

AHAS 提供哪些能力

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

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

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

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