Thrift
Apache顶级项目，早期由Facebook开发，集成了序列化/反序列化和传输层，传输层基于TCP，服务端提供高并发NIO等多种模式支持。
通过 .thrift文件直接生成客户端和服务端的代码，支持语言种类比较多：
1 | C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml and Delphi and other languages. |
Thrift支持众多通讯协议：
- TBinaryProtocol – 一种简单的二进制格式，简单，但没有为空间效率而优化。比文本协议处理起来更快，但更难于调试。
- TCompactProtocol – 更紧凑的二进制格式，处理起来通常同样高效。
- TDebugProtocol – 一种人类可读的文本格式，用来协助调试。
- TDenseProtocol – 与TCompactProtocol类似，将传输数据的元信息剥离。
- TJSONProtocol – 使用JSON对数据编码。
- TSimpleJSONProtocol – 一种只写协议，它不能被Thrift解析，因为它使用JSON时丢弃了元数据。适合用脚本语言来解析。
gRPC
gRPC是由Google主导开发的RPC框架，使用HTTP/2协议并用ProtoBuf作为序列化工具（ProtoBuf的数据是二进制），gRPC和Thrift功能很类似，也是集成了序列化/反序列化和传输层。通过 .proto文件直接生成客户端和服务端的代码，支持的语言有：
1 | C++, Java, Python, PHP, Ruby, C#, Node.js, Go, Android Java, Objective-C, Dart, Web |
其中Java的传输层是基于Netty的，Android Java是基于OkHttp。可以看到gRPC不局限于后端微服务的连接，它是支持移动设备端的，完全可以将移动设备、浏览器客户端连接到后端服务，取代目前普遍使用的HTTP RESTful API，免去客户端开发者要编写API接口代码。
Netty + ProtoBuf
觉得这是一种不成熟的RPC方案，个人练手练手是不错的选择。但是基于这两货，厉害的开发者可以开发出一套RPC软件。
Netty自带ProtoBuf的解码器，所以，通过ProtoBuf序列化/反序列化数据，使用Netty来传输非常方便，gRPC-java 就是基于 Netty + ProtoBuf 实现的。
JSON-RPC
是一种基于JSON的跨语言远程调用协议，JSON-RPC 2.0 规范这样描述：
JSON-RPC是一个无状态且轻量级的远程过程调用(RPC)协议。 本规范主要定义了一些数据结构及其相关的处理规则。它允许运行在基于socket,http等诸多不同消息传输环境的同一进程中。其使用JSON（RFC 4627）作为数据格式。
认识 JSON-RPC 是以太坊的接口，以太坊的接口基于 HTTP 来实现。JSON-RPC 和 ProtoBuf 是同一层，只定义数据，不参与数据传输。
总结
RPC（Remote Procedure Call）—远程过程调用，多用于分布式环境下，该协议允许运行于一台计算机的程序通过网络调用另一台计算机的程序，而程序员无需额外地为这个交互作用编程。
RPC与数据格式，传输方式。传输方式比如上述有TCP也有HTTP，甚至还有UDP。
为什么选择RPC ？
提高开发效率，开发人员可以把更多精力放在具体的接口实现，而不必考虑数据的底层传输问题
大多数rpc框架都是很多优秀开发人员的智慧结晶，它们的功能实现和执行效率都很优秀
client端和server端必须遵循统一的接口规范，避免产生client和server之间接口或数据局结构不匹配的情况。
gRPC 和 Thrift 都提供了代码生成和维护传输层，程序猿只需要关心接口定义和调用，对开发效率很有帮助。