protobuf和grpc实战GRPC 是一个高性能、开源和通用的 RPC 框架。ProtoBuf是一种轻便高效的结构化

携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第4天，点击查看活动详情 >>

GRPC

是一个高性能、开源和通用的 RPC 框架，基于ProtoBuf(Protocol Buffers) 序列化协议开发，且支持众多开发语言。

面向服务端和移动端，基于 HTTP/2 设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特。

即 Protocol Buffers，是一种轻便高效的结构化数据存储格式，与语言、平台无关，可扩展可序列化，类似于XML。主流版本是pb3

gRPC 默认使用 protocol buffers，这是 Google 开源的一套成熟的结构数据序列化机制

protobuf的准备：

brew install autoconf automake libtool
brew install protobuf//安装protoc
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest // golang protobuf 库

小demo尝试对比一下Protocol和json的压缩率：

教程，可以得出结论：Protocol Buffer比json的压缩后的带下少一半多

命令：

grpc的准备：

go install google.golang.org/grpc/cmd/protoc-gen-go-grpc下载grpc包依赖
protoc --go_out=. --go_opt=paths=source_relative --go-grpc_out=. --go-grpc_opt=paths=source_relative *.proto同时生成proto文件和grpc文件
建在不同的文件夹下，运行代码

grpc的流模式：

简单RPC：客户端发起一次请求，服务端响应一个数据。
服务器端流式RPC：这种模式是客户端发起一次请求，服务端返回一段连续的数据流。比如实时传送检测信息。
客户端流式RPC：与服务端数据流模式相反，这次是客户端源源不断的向服务端发送数据流，而在发送结束后，由服务端返回一个响应。比如物理端采集数据。
双向流式RPC：这是客户端和服务端都可以向对方发送数据流，这个时候双方的数据可以同时互相发送，也就是可以实现实时交互。比如实时通讯。

4种方式与以下定义四种服务对应: test.proto文件: service Test{
```
rpc LZX1(SayReq) returns (SayResp) {}
rpc LZX2(SayReq) returns (stream SayResp) {}
rpc LZX3(stream SayReq) returns (SayResp) {}
rpc LZX4(stream SayReq) returns (stream SayResp) {}
```
生成的test.pb.go文件:

type TestClient interface {
```
LZX1(ctx context.Context, in *SayReq, opts ...grpc.CallOption) (*SayResp, error)
LZX2(ctx context.Context, in *SayReq, opts ...grpc.CallOption) (Test_LZX2Client, error)
LZX3(ctx context.Context, opts ...grpc.CallOption) (Test_LZX3Client, error)
LZX4(ctx context.Context, opts ...grpc.CallOption) (Test_LZX4Client, error)
```
所以无流的函数,也就是第一种简单的RPC,都只是一一对应.只要有流,返回的类型都是服务结构名_函数名Client;只要客户端是流式,传参将不包含其他参数.

负载均衡三种解决方案

构建高可用、高性能的通信服务，通常采用服务注册与发现、负载均衡和容错处理等机制实现。根据负载均衡实现所在的位置不同，通常可分为以下三种解决方案：

gRPC 默认使用 protocol buffers，这是 Google 开源的一套成熟的结构数据序列化机制

6种负载均衡算法

1、轮询法

2、随机法

3、源地址哈希法

4、加权轮询法

5、加权随机法

6、最小连接数法