grpc简介

参考文章

• rpc简介：https://www.jianshu.com/p/b0343bfd216e
• grpc官方中文文档：http://doc.oschina.net/grpc?t=56831
• 知乎：https://zhuanlan.zhihu.com/p/148139089，非常推荐

RPC作用

• 可以像调用本地方法一样调用远程方法
• 微服务的基础
• Http有用信息占比少

Grpc简介

• 基于HTTP2 + protobuf3实现

为什么GRPC基于HTTP2.0而不是基于私有协议

• 成熟、通用性好
• 支持流式传输
• 相较于HTTP1，性能好
• 安全性好，支持ssl

RESTful HTTP JSON

• HTTP的header和Json的数据冗余和低压缩率使得传输性能差
• JSON难以表达复杂的参数类型，如结构体等

protobuf3

• 体积小、传输快
• 冗余字符少：
  • json需要传输field名称，并且有{}””等冗余字符
  • pb中由于双端共享proto文件，无需传输field名称，只需要传递field编号即可
  • pb中一个kv的结构为Tag（1字节，field编号+数据类型）-Leg（value字符串长度，方便取值）-Value
• 编码时进行压缩：
  • 整数采用varint类型，即变长整数，不固定为32字节而是根据数据的实际大小进行位数分配
  • 负数采用zigzag类型，可以避免补码使用较多位数的情况

服务发现

rpc服务的实例启动后将自己注册到服务中心，调用方通过服务中心拉取到可调用地址

etcd

负载均衡

Docker Swarm

Docker Swarm 提供了一套高可用 Docker 集群管理的解决方案，完全支持标准的 Docker API，方便管理调度集群 Docker 容器，合理充分利用集群主机资源

• 管理节点
• 工作节点
• 任务：一个容器
• 服务：多个容器

负载均衡

参考文章

• VIP：分配独立的虚拟IP，DNS记录解析到服务名中作为代理IP。
• dnsrr：DNS记录不解析VIP，而去解析每个容器内的IP。dnsrr模式不支持端口对外暴露。

I/O复用：epoll

服务端采用epoll处理请求

Grpc

特性

1. 基于服务的思想：服务端和客户端均存有服务
2. 使用protobuf作为IDL(接口描述语言)，并且实现通信数据之间的序列化和反序列化
3. 支持同步调用和异步调用
4. 基于HTTP2：支持流式传输
5. 没有直接实现负载均衡和服务发现的功能，但是已经提供了自己的设计思路。已经为命名解析和负载均衡提供了接口

ProtoBuf

1. 支持比较复杂的数据结构
2. 向后兼容
3. 数据压缩率高

• 冗余字符少：
  - json需要传输field名称，并且有{}””等冗余字符
  - pb中由于双端共享proto文件，无需传输field名称，只需要传递field编号即可
  - pb中一个kv的结构为Tag（1字节，field编号+数据类型）-Leg（value字符串长度，方便取值）-Value

• 编码时进行压缩：
  • 整数采用varint类型，即变长整数，不固定为32字节而是根据数据的实际大小进行位数分配
  • 负数采用zigzag类型，可以避免补码使用较多位数的情况

4. 跨语言

实现注册中心

注册中心的作用

• 解耦服务提供者和服务消费者
• 实现负载均衡

注册中心两种方案

集中式 LB (Load Balance)，代理模型

• 代理本身就具备负载均衡算法，心跳检测，失败重试，失败转移等功能
• 不支持动态的新增服务提供者，并发量大以后，代理会成为瓶颈，代理也有可能会成为单点等问题

进程内 LB (Load Balance)，软负载