RPC

远程服务调用

RPC出现的最初目的，是为了让计算机像调用本地方法一样，去调用远程方法。

1994 年至 1997 年间，由 ACM 和 Sun 的院士Peter Deutsch、套接字接口发明者Bill Joy、Java 之父James Gosling等众多在 Sun Microsystems 工作的大佬们，共同总结了通过网络进行分布式运算的八宗罪（8 Fallacies of Distributed Computing）：

1. 网络是可靠的（The network is reliable）

2. 延迟是不存在的（Latency is zero ）

3. 带宽是无限的（Bandwidth is infinite）

4. 网络是安全的（The network is secure）

5. 拓扑结构是一成不变的（Topology doesn't change）

6. 总会有一个管理员（There is one administrator）

7. 不考虑传输成本（Transport cost is zero）

8. 网络是同质化的（The network is homogeneous）

RPC协议需要解决的问题

怎么表示数据

即如何序列化和反序列化。

怎么传递数据

如何通过网络，在2个服务间进行互相操作。异常、超时、安全、认证、授权、事务等信息，都可能存在双方交换信息的需求。

怎么表示方法

不同的语言，有不同的方法签名。

围绕着这三个问题，相继出现过 RPC 协议 / 框架：RMI（Sun/Oracle）、Thrift（Facebook/Apache）、Dubbo（阿里巴巴 /Apache）、gRPC（Google）、Motan2（新浪）、Finagle（Twitter）、brpc（百度）、.NET Remoting（微软）、Arvo（Hadoop）、JSON-RPC 2.0（公开规范，JSON-RPC 工作组）……

这些 RPC 的功能、特点都不太一样，有的是某种语言私有，有的能支持跨越多门语言，有的运行在 HTTP 协议之上，有的能直接运行于 TCP/UDP 之上，但没有哪一款是“最完美的 RPC”。都不再去追求大而全的“完美”，而是会找到一个独特的点作为主要的发展方向。

功能强大的框架往往要在传输中加入额外的负载和控制措施，导致传输性能降低，而如果既想要高性能，又想要强功能，这就必然要依赖大量的技巧去实现，进而也就导致了框架会变得过于复杂，这就决定了不可能有一个“完美”的框架同时满足简单、普适和高性能这三个要求。