Go网络编程☞RPC

RPC 远程过程调用（Remote Procedure Call）

RPC并不是一种协议，而是通过网络实现跨机器、跨语言的服务通信方式。而HTTP实际就是一种RPC。

RPC 与 HTTP

	RPC	HTTP
实现协议	TCP 或 HTTP2.0	HTTP1 或 HTTP1.1
适用范围	定制化程度高（TCP方式的RPC完全是自主定制化 而 HTTP2.0不够广泛，很多浏览器不支持）	运用广泛
编码方式	效率更高的protobuf（也支持JSON）	JSON、XML
性能	效率更高：采用更高效的传输协议和序列化方式	效率较差

虽然RPC效率高，但是适用性不太广泛，，目前RPC主要用于企业服务间调用！

---

GRPC（传输协议：HTTP/2.0）

gRPC是 Google 发起的一个开源远程过程调用系统，是在RPC协议上创建的最新框架。它利用自身的优势，试图解决传统RPC存在的问题。

在实践中，客户端发起一个与gRPC服务器的长连接，并为每个RPC调用打开一个新的HTTP/2流。

最重要的是gRPC使用protocol buffer作为序列化和通信的接口定义语言，而不是JSON/XML。Protocol buffer可以描述数据的结构，并且可以根据该描述生成代码，以生成或解析表示结构化数据的字节流。这就是为什么gRPC更适合使用polyglot(使用不同的技术部署)的web应用程序。二进制数据格式使得通信更加轻量，gRPC也可以与其他数据格式一起使用，但首选的格式仍然是protocol buffer。

---

Go语言中的RPC：net/rpc 和 net/rpc/jsonrpc

Go实现的RPC支持tcp或http数据传输方式

net/rpc ：采用gob为数据描述语言
net/rpc/jsonrpc：采用json为数据描述语言

要想进行跨语言调用，则其他RPC服务必须使用相同的数据描述语言，而encoding/gob并不广泛，而encoding/json性能太差，RPC最常用的还是protobuf数据描述语言。所以最常还是使用Google实现的RPC通用框架GRPC：github.com/grpc/grpc-go

protobuf和json对比（什么是序列化？）

	优势	劣势
protobuf	数据压缩，序列化后数据量更小；类型安全；易用性好；序列化/反序列性能好；兼容性好；不仅可以定义结构体，还可以定义rpc服务接口	可读性较差：没有schema的情况下，难以阅读和编辑；灵活性较差：无法动态修改schema。
json	可读性好：方便理解和编辑；易用性好：使用简单；灵活性好：支持动态修改schema	序列化/反序列化性能差；编码问题导致解析失败之类的