RPC 开发系列十：熔断限流（自我保护）

一、概述

         RPC 是解决分布式系统通信问题的一大利器，而分布式系统的一大特点就是高并发，所以说 RPC 也会面临高并发的场景。在这样的情况下，提供服务的每个服务节点就都可能由于访问量过大而引起一系列的问题，比如业务处理耗时过长、CPU 飘高、频繁 Full GC 以及服务进程直接宕机等等。但是在生产环境中，要保证服务的稳定性和高可用性，这时就需要业务进行自我保护，从而保证在高访问量、高并发的场景下，应用系统依然稳定，服务依然高可用。

二、自我保护方式

       最常见的方式就是限流了，简单有效，但 RPC 框架的自我保护方式可不只有限流，并且 RPC 框架的限流方式可以是多种多样的。我们可以将 RPC 框架拆开来分析，RPC 调用包括服务端和调用端，调用端向服务端发起调用。下面就分别说明一下服务端与调用端分别是如何进行自我保护的。

2.1 服务端的自我保护

       举个例子，假如要发布一个 RPC 服务，作为服务端接收调用端发送过来的请求，这时服务端的某个节点负载压力过高了，该如何保护这个节点？

        这个问题还是很好解决的，既然负载压力高，那就不让它再接收太多的请求就好了，等接收和处理的请求数量下来后，这个节点的负载压力自然就下来了。

        那么就是限流吧？是的，在 RPC 调用中服务端的自我保护策略就是限流，那如何实现限流的呢？是在服务端的业务逻辑中做限流吗