转自 http://mp.weixin.qq.com/s?__biz=MzAxMTEyOTQ5OQ==&mid=2650610778&idx=1&sn=630db2a23f4f465de2417cba3f1371cb&chksm=834c7baeb43bf2b82550baf37d4b8595e0c59f82ebbda5bf8eeb6d7bf37b6857035877fb4f89#rd
最近线上碰到一点小问题，分析其原因发现是出在对 RPC 使用上的一些细节掌握不够清晰导致。很多时候我们做业务开发会把 RPC 当作黑盒机制来使用，但若不对黑盒的工作原理有个基本掌握，也容易犯一些误用的微妙错误。
虽然曾经已经写过一篇《RPC 的概念模型与实现解析》 从概念模型和实现细节上讲述了 RPC 的原理，这一篇就从使用上的一些注意点来捋一捋吧。
同步
RPC 的调用通常为了方便使用，会被伪装成普通方法调用的形式。但实际二者之间存在巨大的差异，进程内的方法调用的时间量级是 ns（纳秒），而进程间的 RPC 方法调用时间量级通常是 ms（毫秒），它们之间差着 10 的六次方呢。RPC 的冰山底部透视图如下：
因此，微服务架构下，内部主服务链之间的 RPC 调用需要异步化，服务之间的调用请求和等待结果相互之间解耦，如下是一个服务链路调用的示意图：
异步
RPC 的同步调用确保请求送达对方并收到对方响应，若没有收到响应，框架则抛出 Timeout 异常。这种情况下调用方是无法确定调用是成功还是失败的，需要根据业务场景（是否可重入，幂等）选择重试和补偿策略。
而 RPC 的异步调用意味着 RPC 框架不阻塞调用方线程，调用方不需要立刻拿到返回结果，甚至调用方根本就不关心返回结果。RPC 的异步交互场景示意图如下：
线程
RPC 的线程模型一般如下所示：
但有些 RPC 框架在实现客户端的 I/O 线程模型时，也采用了针对每个不同的服务端一个独立的 I/O 线程池，这样就变成了下面这个图所示：
而在 Docker 环境下 Java 的 Runtime.availableProcessors() 获取的 CPU 数量实际是物理机的，而不是 Docker 隔离的核数。另外，像 Netty 这样的网络框架经常默认是基于 CPU 核数来启动默认的 I/O 线程数的，所以导致针对每个服务的客户端会启动 CPU 核数个 I/O 线程再乘上服务实例数，这个线程数量也是颇为客观，出现单进程好几千固化的线程，线程调度和切换的成本颇高，另外服务的水平扩展性也有一定的受限。这也是需要注意的另一点。
...
在曾经那篇《RPC 的概念模型与实现解析》 的的结尾，我曾写到：
无论 RPC 的概念是如何优雅，但是“草丛中依然有几条蛇隐藏着”，只有深刻理解了 RPC 的本质，才能更好地应用。
所以这一篇大概就是抓出了几条隐藏着的蛇吧。
