微服务对单个服务保护的思路（详细干货）

👏大家好！我是和风coding，希望我的文章能给你带来帮助！
🔥如果感觉博主的文章还不错的话，请👍三连支持👍一下博主哦
📝点击 我的主页 还可以看到和风的其他内容噢，更多内容等你来探索！
📕欢迎参观我的个人网站：Gentlewind

---

---

雪崩问题

对于为什么需要对微服务中的单个服务进行保护，我们可以先来了解微服务中的雪崩问题

在微服务中，服务之间会存在一条上下游调用的链路。

而一旦在调用的链路中某个服务出现故障，可能会引起链路后的所有微服务都不可用

比如当服务 C 不可用，服务 B 的请求线程也会随之阻塞，直到线程资源消耗殆尽，导致服务 B 也不可用，接着 A 也会不可用，最终整个链路被拖垮。

区别于缓存雪崩：大量 key 同时失效导致服务器压力增大

针对这样的情况，我们有必要对服务进行一些保护措施，尤其是一些热点服务。以下是常用的服务保护方案：

请求限流

限制访问服务请求的并发量，避免大量请求同时打在服务器。

实现方案：

• 单机系统： Redis，Guava RateLimiter ，漏桶算法进行限流
• 分布式系统：Redission，API 网关，Sentinel 进行分布式限流

线程隔离

在并发程序中将不同的工作单元或任务分配到独立的线程中，以确保它们在执行时互不干扰。

可以理解为一种舱壁隔离将船体内部空间区隔划分成若干个隔舱，一旦某几个隔舱发生破损进水，水流不会在其间相互流动，如此一来船舶在受损时，依然能具有足够的浮力和稳定性，进而减低立即沉船的危险。

实现方案：

• 线程池隔离：将任务提交到线程池，由线程池中的线程来执行。线程池可以控制并发的线程数量，避免线程过多导致系统资源耗尽。通常使用 Java 线程池实现
• 信号量隔离：通过信号量来控制并发访问的数量，从而实现资源隔离。信号量可以限制同时访问资源的线程数量，防止过载。通常使用 Hystrix 或 Sentinel 实现

通过限定每个服务的线程数来将业务隔离了，避免故障扩散。

服务熔断

在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。牺牲局部，保全整体

它由一个断路器来统计服务请求异常或慢调用的比例，如果超出阈值就会熔断该服务，并触发降级处理。拦截该接口的请求，在熔断的期间所有请求会直接走 fallback 逻辑.

Fallback（回退机制）是一种应对服务故障的策略。当某个服务不可用或调用失败时，可以通过回退机制提供一个默认的响应或执行替代逻辑，以避免整个系统的崩溃并提升系统的容错能力。像异常，当请求失败了，不报错，给另外设定好的处理逻辑

常见方案：

• 阿里巴巴的Sentinel
• Netflix Hystrix
• Resilience4j
• Spring Cloud Circuit Breake

失败处理

直接定义 fallback 的逻辑，让服务异常时不再抛出异常而是进行一些用户友好的处理。

常见方案：

• 返回默认值
• 返回用户友好提示
• 调用备用服务
• 执行降级处理

服务降级

主动降低服务的质量，通过牺牲部分非核心功能来保证核心功能的正常运行，保证系统整体可用性

常见策略：

• 关闭非核心服务：例如，电商网站在大促期间，可以关闭一些推荐、评论等非核心功能，确保购买流程的顺畅。
• 静态内容替代：用静态页面或缓存内容替代动态内容，减少数据库和后台服务的压力。
• 简化响应：返回简化的响应内容，减少后台处理时间。
• 限流：对一些高耗时的接口进行限流，确保系统不被拖垮。

总结：

在微服务架构中，单个服务的故障可能会引发全局性的雪崩效应，因此，必须对服务进行有效的保护措施。通过请求限流、线程隔离、服务熔断、失败处理和服务降级等策略，可以有效防止雪崩问题，确保系统的稳定性和可用性。合理应用这些保护方案，能够在应对高并发和服务故障时，保障微服务系统的平稳运行。