rpc (远程过程调用）
远程过程调用。RPC 的主要功能目标是让构建分布式计算（应用）更容易，在提供强大的远程调用能力时不损失本地调用的语义简洁性。比如服务A想要调用服务B上的某个方法/函数，使用方可以忽略底层的传输层的细节，专注于方法的使用。就像调用一个本地函数，使用十分便捷，不需要关心接口的url，校验规则，返回值解析等过程。
thrift:
一种接口描述语言和二进制通讯协议，它被用来定义和创建跨语言的服务。它被当作一个远程过程调用（RPC）框架来使用，是由Facebook为“大规模跨语言服务开发”而开发的RPC框架，现已由Apache管理和开源。
rpc vs http
rpc优点：
- 支持多种编码和传输协议，可以针对不同的场景选择不同的设计方案，更加灵活可用。
- rpc的传输效率更加高效，比restful更加简洁，节约带宽。（比如thirft中的TCompactProtocol， 使用高效率的、密集的二进制编码格式进行数据传输, 比json更加高效）
- 简化了交互逻辑。原来跨系统调用的时候，一般使用 http 的方式进行交互。程序员之间要反复交流，针对接口反复确认。最后花了很多时间在这个上面。而且交互代码会写的比较麻烦：拼接 URL 参数、写调用 http 代码、解析调用结果，如果出错还要写重试代码。使用 thrift 以后，整个这些操作都被封装到框架底层：针对接口的讨论，只要给出 idl ，剩余的事情都让机器去确认。同时，整个开发逻辑也极大简化，基本就几行代码。
- 接口更加明确，有 idl 这个天然的接口文档，少一个参数都编译不通过，大大减少了因为接口参数问题出现的 bug 。
- 可以建立长连接(比如建立长连接TCP通道)，不必每次通信都要像http一样去3次握手什么的，减少了网络开销。
- rpc是建立在TCP协议的socket通信上的，而web api是建立在HTTP/HTTPS协议上的，rpc天然地性能会更高。
rpc不足:
- thrift的IDL是静态化的，客户端调用的时候，依赖于按照接IDL生成的客户端接口代码（SDK），一旦想要变更接口规则，那么对于客户端而言，需要更新客户端SDK，并重新编译、生成可执行代码。 但是基于restful的web服务是动态化的，对于接口的变更，客户端的改动要容易得多。
- 维护成本高，尤其当客户端使用多种不同语言时，每次接口的变动都需要更新一堆不同语言的SDK， 这是维护升级的噩梦。
http 优点:
- 轻量级，简单易用。无需要额外的SDK，维护性和扩展性都比较好 。
- 可以基于https协议，安全性较高
http不足:
- 只支持http/https协议，使用时需要关注协议和网络层的细节，而且http协议交互过程比较复杂(TCP三次握手，http协议报头较为复杂)
http vs 高性能二进制协议
- http相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，相应的，如果采用http，无疑在你实现SDK之前，支持了所有语言，所以，现在开源中间件，基本最先支持的几个协议都包含RESTful。
- RPC协议性能要高的多，例如Protobuf、Thrift、Kyro等，（如果算上序列化）吞吐量大概能达到http的二倍。响应时间也更为出色。
使用场景：
http: 对外提供的服务，更加规范、通用、易扩展、已维护，具有较高的安全性(https)。
rpc: 对内提供的服务，尤其适用于需要进行大量数据交互的服务(thrift提供高效的压缩协议，交互更加简洁，吞吐量更大)、 高频率交互的服务(可以考虑建立TCP长连接，比如即将开工的大权限系统)
性能对比:
还可以参考这篇文章：
IDL
IDL是Interface description language的缩写，指接口描述语言，是CORBA规范的一部分，是跨平台开发的基础。
IDL是用来描述软件组件接口的一种计算机语言。IDL通过一种中立的方式来描述接口，使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信交流；比如，一个组件用C++写成，另一个组件用Java写成。
IDL通常用于远程调用软件。 在这种情况下，一般是由远程客户终端调用不同操作系统上的对象组件，并且这些对象组件可能是由不同计算机语言编写的。IDL建立起了两个不同操作系统间通信的桥梁。
