RPC 使用中的一些注意点
最近线上碰到一点小问题，分析其原因发现是出在对 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 的异步交互场景示意图如下：
