在微服务架构中，服务之间的调用是通过网络进行的，网络的不确定性和依赖服务的不可控性，可能导致某个服务出现异常或性能问题，进而引发整个系统的故障，这被称为 微服务雪崩。为了防止这种情况发生，常用的一些保护措施包括超时处理、熔断降级、限流、线程池隔离和信号量隔离等。
（1）超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待。
（2）熔断降级：当服务的异常数或异常比例超过了预设的阈值时，熔断器会进入开启状态，暂时中断对该服务的请求，此时走降级方法，能够快速响应，确保系统的基本功能能够继续运行。
（3）限流：限制对服务的请求速率，避免短时间内大量的请求导致系统崩溃。
（4）线程池隔离：给要请求的资源分配一个线程池，通过线程池去控制请求数量
（5）信号量隔离：使用计数器模式，记录请求资源的并发线程数量，达到信号量上限时，禁止新的请求。
信号量隔离适合同步请求，控制并发数，比如：对文件的下载并发数进行控制。
大多数场景都适合使用线程池隔离，对于需要同步操作控制并发数的场景可以使用信号量隔离。
1. 熔断降级的背景
在微服务架构中，服务之间的依赖复杂，任何一个服务的故障都有可能引发连锁反应，导致服务雪崩。为此，引入熔断和降级机制，当某个服务长时间无法响应或者发生错误时，系统可以快速进入降级模式，避免对外提供错误服务。
熔断降级的核心流程包括：
降级：当远程调用发生异常时，不继续等待，而是直接执行降级逻辑，返回预设的结果。
熔断：当异常达到某个阈值时，熔断器打开，短时间内不再调用出问题的服务，而是走降级处理，防止继续调用带来更多问题。
恢复：当经过一段时间后，系统尝试再次调用原服务，如果服务恢复正常，则关闭熔断，恢复正常调用。
2. 熔断降级的具体实现步骤
当远程调用发生异常首先走降级方法，当异常比较或异常数达到阈值将触发熔断，在熔断时间内不再走原来的方法而是走降级方法，可以快速进行响应。
当服务恢复后，熔断时间结束此时会再次尝试请求服务，如果成功请求将关闭熔断，恢复原来的链路。
2.1 在客户端 api 工程定义远程调用接口
在 api 工程中，定义远程调用的接口。这个接口将通过 Feign 进行服务调用。接口通过 @FeignClient 注解进行标注，指定服务名称和请求的路径。
