微服务保护 - 技术栈

下表汇总了微服务保护中的几个核心概念。

概念	定义与描述	核心目标
服务雪崩	在微服务链中，某个服务因资源耗尽、响应延迟或故障，导致其上游服务线程阻塞，进而引发级联失败，最终使整个系统瘫痪的现象。	认识问题，从而制定预防策略。
服务限流	通过控制请求的速率或次数（如设置QPS阈值），防止服务因突发流量过大而崩溃。	应对高并发流量，保护系统不被冲垮。
服务熔断	由断路器统计服务调用的异常比例或慢请求比例，当超过阈值时，主动熔断对该服务的调用，快速失败。	防止故障服务拖垮调用方，避免雪崩。
服务降级	当服务调用失败（如触发熔断）时，提供一种备用的处理逻辑，例如返回默认数据或友好提示，以保证核心业务流程可用。	保证系统基本可用，提升用户体验。
线程隔离	为不同的服务调用分配独立的线程池或信号量，限制每个服务能使用的最大资源。这样某个服务的故障会被隔离，不会耗尽所有资源。	实现故障隔离，避免局部问题全局扩散。

可以把服务雪崩想象成一次连锁反应：

解决这一问题的关键，就在于下面介绍的几种保护策略。

限流是系统稳定性的第一道防线。常见的算法有：

令牌桶算法 ：系统以恒定速率向桶中放入令牌，处理请求前需要先获取令牌。它能允许一定程度的突发流量 （取决于桶的容量），是实践中很常用的算法。Guava库中的 RateLimiter 就是其典型实现。
漏桶算法 ：请求像水一样以任意速率流入漏桶，但桶底出口的处理速率是固定的。它能强行限制数据的传输速率，平滑突发流量，但无法应对突发流量。
滑动窗口算法：是对固定窗口（如每分钟限流100次）的优化，将时间窗口划分为更细粒度的小窗口，每次滑动一个小格。这样可以避免固定窗口在临界时间点出现的流量突增问题，控制更精准。

这两者通常协同工作，其核心是"断路器"机制，它有三种状态：

降级逻辑就是为失败场景准备的预案，比如返回一个默认值、静态数据或友好提示，确保用户体验不会完全中断。

其思想来源于轮船的舱壁模式：将船舱隔成多个独立空间，即使一个舱室进水，也不会导致整艘船沉没。在微服务中，实现方式主要有：

在Spring Cloud生态中，主要有以下选择：

特性	Sentinel (阿里巴巴)	Hystrix (Netflix)	Resilience4j
隔离策略	信号量隔离	线程池隔离/信号量隔离	信号量隔离
熔断降级	基于慢调用比例、异常比例、异常数	基于失败比率	基于失败比率、响应时间
限流能力	强大，支持QPS限流、基于调用关系的限流、预热等	支持有限	支持，功能丰富
流量整形	支持慢启动、匀速排队	不支持	支持
配置方式	支持代码、文件、控制台动态配置	代码、配置文件	代码、配置文件
实时监控	提供开箱即用的控制台，支持秒级监控	监控需结合其他工具	需结合Micrometer等

综合建议：

新项目首选 Sentinel。它功能全面，性能损耗低（采用信号量隔离），并且拥有非常友好的控制台，可以实时查看系统状态和动态修改规则。
Hystrix 目前已经进入维护模式，对于老项目可以继续使用，但新项目不推荐。
Resilience4j 是一个轻量级、模块化的现代库，如果你更倾向于函数式编程风格，或者需要与Micrometer等监控系统深度集成，它是一个不错的选择。