RPC 也会面临高并发的场景。在这样的情况下，我们提供服务的每个服务节点就都可能由于访问量过大而引起一系列的问题，比如业务处理耗时过长、CPU 飘高、频繁 Full GC 以及服务进程直接宕机等等。但是在生产环境中，我们要保证服务的稳定性和高可用性，这时我们就需要业务进行自我保护，从而保证在高访问量、高并发的场景下，应用系统依然稳定，服务依然高可用。
我们先看服务端，举个例子，假如我们要发布一个 RPC 服务，作为服务端接收调用端发送过来的请求，这时服务端的某个节点负载压力过高了，我们该如何保护这个节点？
这个问题还是很好解决的，既然负载压力高，那就不让它再接收太多的请求就好了，服务端可以在执行业务逻辑之前先执行限流逻辑，如果发现访问量过大并且超出了限流的阈值，就让服务端直接抛回给调用端一个限流异常，否则就执行正常的业务逻辑。
调用端也可以有自己的自我保护机制
服务 B 调用服务 C，服务 C 执行业务逻辑出现异常时，会影响到服务 B，甚至可能会引起服务 B 宕机。
此时为了保护B服务，最有效的自我保护方式就是熔断。
熔断器的工作机制主要是关闭、打开和半打开这三个状态之间的切换。在正常情况下，熔断器是关闭的；当调用端调用下游服务出现异常时，熔断器会收集异常指标信息进行计算，当达到熔断条件时熔断器打开，这时调用端再发起请求是会直接被熔断器拦截，并快速地执行失败逻辑；当熔断器打开一段时间后，会转为半打开状态，这时熔断器允许调用端发送一个请求给服务端，如果这次请求能够正常地得到服务端的响应，则将状态置为关闭状态，否则设置为打开。
降级
降级也就是服务降级，当我们的服务器压力剧增，为了保证核心功能的可用性，可以选择性的降低一些功能的可用性，或者直接关闭该功能。典型的弃车保帅！ 就比如贴吧类型的网站，当服务器吃不消的时候，可以选择把发帖功能关闭，注册功能关闭，改密码，改头像这些都关了，为了确保登录和浏览帖子这种核心的功能。
服务保护一般就是限流、熔断、降级。
限流的落地方式有：Guava RateLimiter、lua+Redis、Sentinel等；
熔断：Hystrix、Resilience4j；
降级：服务降级，就是对不怎么重要的服务进行低优先级的处理。说白了，就是尽可能的把系统资源让给优先级高的服务。资源有限，而请求是无限的。
下一篇讲讲项目中sentinel是如何实现限流熔断，持久化和网关结合的
本篇文章来源：RPC 实战与核心原理第15章《熔断限流：业务如何实现自我保护?》
网友评论