互联网分布式服务的特点是高并发，服务的每个服务节点都可能由于访问量过大而引起一系列的问题，比如业务处理耗时过长、负载过高、CPU 飙高、频繁 Full GC 、内存耗尽以及服务进程直接宕机等等。为了保证服务的稳定性和高可用性，我们就需要业务进行自我保护。

一. 常用手段

1. 压测——进行性能优化及容量规划

2. 限流——防止服务端被流量高峰压垮

落地方式有：Guava RateLimiter、lua+Redis、Sentinel等；

3. 降级——优先保证核心服务高可用

服务降级，就是对不怎么重要的服务进行低优先级的处理，甚至某些条件下可以忽略。

4. 熔断——防止当前服务被下游慢服务拖垮

落地方式有： Hystrix、Resilience4j；

5. 自动扩缩容——可以扛住流量洪峰，需要资源冗余

二. 熔断限流机制

1. 服务端限流机制自我保护

1.1 要考虑到应用和 IP 级别，方便在服务治理的时候，对部分访问量特别大的应用进行合理的限流；

1.2 服务端限流阈值配置都是作用于单机的，而有些场景下，例如对整个服务设置限流阈值，服务进行扩容时，限流的配置并不方便，我们可以在注册中心或配置中心下发限流阈值配置的时候，将总服务节点数也下发给服务节点，让 RPC 框架自己去计算限流阈值；

1.3 还可以让 RPC 框架的限流模块依赖一个专门的限流服务，对服务设置限流阈值进行精准地控制，但是这种方式依赖了限流服务，相比单机的限流方式，在性能和耗时上有劣势。

2. 调用端熔断机制自我保护

熔断器的工作机制主要是关闭、打开和半打开这三个状态之间的切换。

2.1 在正常情况下，熔断器是关闭的；

2.2 当调用端调用下游服务出现异常时，熔断器会收集异常指标信息进行计算，当达到熔断条件时熔断器打开，这时调用端再发起请求是会直接被熔断器拦截，并快速地执行失败逻辑；

2.3 当熔断器打开一段时间后，会转为半打开状态，这时熔断器允许调用端发送一个请求给服务端，如果这次请求能够正常地得到服务端的响应，则将状态置为关闭状态，否则设置为打开。

总结：防止调用下游服务出现异常，或者耗时过长影响调用端的业务逻辑，RPC 框架可以在动态代理的逻辑中去整合熔断器，实现 RPC 框架的熔断功能。

感谢你的阅读，喜欢的话欢迎点赞和转发哦[玫瑰]
本头条号专注于互联网领域的技术交流与经验分享，期待您的关注。