最近线上碰到一点小问题，分析其原因发现是出在对 RPC 使用上的一些细节掌握不够清晰导致。很多时候我们做业务开发会把 RPC 当作黑盒机制来使用，但若不对黑盒的工作原理有个基本掌握，也容易犯一些误用的微妙错误。
虽然曾经已经写过一篇《RPC 的概念模型与实现解析》 从概念模型和实现细节上讲述了 RPC 的原理，这一篇就从使用上的一些注意点来捋一捋吧。
同步
RPC 的调用通常为了方便使用，会被伪装成普通方法调用的形式。但实际二者之间存在巨大的差异，进程内的方法调用的时间量级是 ns（纳秒），而进程间的 RPC 方法调用时间量级通常是 ms（毫秒），它们之间差着 10 的六次方呢。RPC 的冰山底部透视图如下：
但在目前流行的微服务架构模式下，跨服务的同步调用隐藏着巨大的风险。一般微服务化架构下，通常一个业务的调用会跨 N（N 一般大于 2） 个服务进程，整个调用链路上的同步调用等待的瓶颈会由最慢（或脆弱）的服务决定，A-B-C 像这样一个链路，A 同步调用 B 并等待返回，B 同步调用 C 并等待返回，以此类推，就像一组齿轮链，级级传动，这很容易产生雪崩效应。若 C 服务挂住了，会导致前面的服务全部都因为等待超时而占用大量不必要的线程资源。
因此，微服务架构下，内部主服务链之间的 RPC 调用需要异步化，服务之间的调用请求和等待结果相互之间解耦，如下是一个服务链路调用的示意图：
外部用户通过服务网关（API Gateway）发起调用并等待结果，随后网关派发调用请求给后续服务，其主调用链路为 A-B-C，其内部为异步调用，链路上不等待，最后由 C 返回结果给服务网关。其中 B 又依赖两个子服务，S1 和 S2，B 需要 S1 和 S2 的返回结果才能发起 C 调用，因此在支线上 B 针对 S1 和 S2 调用就需要是同步的。
异步
RPC 的同步调用确保请求送达对方并收到对方响应，若没有收到响应，框架则抛出 Timeout 异常。这种情况下调用方是无法确定调用是成功还是失败的，需要根据业务场景（是否可重入，幂等）选择重试和补偿策略。
而 RPC 的异步调用意味着 RPC 框架不阻塞调用方线程，调用方不需要立刻拿到返回结果，甚至调用方根本就不关心返回结果。RPC 的异步交互场景示意图如下：
在上面的示意图中，对于是否需要返回值的异步请求，其中的细微差异在于是否返回一个 Future 对象给调用方，以便未来（Future）调用方可以再通过它来获取返回值。正是因为这种 Future 机制的存在，所以针对前面（图2）中 S1 和 S2 的调用就可以采用一种异步并行的调用机制来提升并行性和性能，如下图所示：
这样调用 S1 和 S2 的总时间就由最慢的一个服务响应时间来决定了。（上图中其实调用 S1 和 S2 不可能做到同时，有细微的时间差异，但相对跨进程的调用本身来说这种差异基本忽略不计。）
线程
RPC 的线程模型一般如下所示：
其中，RPC 的网络层通常采用非阻塞型 I/O 模型，放在 Java 的实现语境下就是 NIO 了。而 RPC 框架通常共享一个 I/O 线程池，处理所有连接上的 I/O 事件派发。通常业务事件会派发到内部的一个固定大小（可配置）的业务执行线程池，再由业务执行线程调用应用实现层的代码。
但有些 RPC 框架在实现客户端的 I/O 线程模型时，也采用了针对每个不同的服务端一个独立的 I/O 线程池，这样就变成了下面这个图所示：
这带来了一个潜在的问题，在一个客户端需要连接大量服务端时（这在基于 RPC 实现的服务框架中很常见），客户端的 I/O 线程池数就和需连接的服务数相等。在现在的微服务部署模式下，一般一个服务部署在一个 Docker 容器中，同一个服务会有很多个（几十上百个）进程共同组成集群提供服务，这样就导致客户端 I/O 线程数可能会很多。
而在 Docker 环境下 Java 的 Runtime.availableProcessors() 获取的 CPU 数量实际是物理机的，而不是 Docker 隔离的核数。另外，像 Netty 这样的网络框架经常默认是基于 CPU 核数来启动默认的 I/O 线程数的，所以导致针对每个服务的客户端会启动 CPU 核数个 I/O 线程再乘上服务实例数，这个线程数量也是颇为客观，出现单进程好几千固化的线程，线程调度和切换的成本颇高，另外服务的水平扩展性也有一定的受限。这也是需要注意的另一点。
...
在曾经那篇《RPC 的概念模型与实现解析》 的的结尾，我曾写到：
无论 RPC 的概念是如何优雅，但是“草丛中依然有几条蛇隐藏着”，只有深刻理解了 RPC 的本质，才能更好地应用。
所以这一篇大概就是抓出了几条隐藏着的蛇吧。
