视频资源获取失败
你好,我是何小锋。上一讲我讲解了 RPC 框架中的优雅启动,这块的重点就是启动预热与延迟暴露。今天,我们换一个新的话题,看看在使用 RPC 时,业务是如何实现自我保护的。
我在开篇词中说过,RPC 是解决分布式系统通信问题的一大利器,而分布式系统的一大特点就是高并发,所以说 RPC 也会面临高并发的场景。在这样的情况下,我们提供服务的每个服务节点就都可能由于访问量过大而引起一系列的问题,比如业务处理耗时过长、CPU 飘高、频繁 Full GC 以及服务进程直接宕机等等。但是在生产环境中,我们要保证服务的稳定性和高可用性,这时我们就需要业务进行自我保护,从而保证在高访问量、高并发的场景下,应用系统依然稳定,服务依然高可用。
那么在使用 RPC 时,业务又如何实现自我保护呢?
最常见的方式就是限流了,简单有效,但 RPC 框架的自我保护方式可不只有限流,并且 RPC 框架的限流方式可以是多种多样的。
我们可以将 RPC 框架拆开来分析,RPC 调用包括服务端和调用端,调用端向服务端发起调用。下面我就分享一下服务端与调用端分别是如何进行自我保护的。
我们先看服务端,举个例子,假如我们要发布一个 RPC 服务,作为服务端接收调用端发送过来的请求,这时服务端的某个节点负载压力过高了,我们该如何保护这个节点?

作者回复: 对,取舍很重要
作者回复: 异步RPC可以提升吞吐量。
作者回复: 是的。
作者回复: 熔断可以避免进一步恶化,比如某个节点性能不行,可以通过熔断的手段,避免调用发整体TP性能下降
作者回复: 利用consul推送能力
作者回复: 不一定要采用集中式限流