gRPC

gRPC

• 多语言：语言中立，支持多语言。
• 轻量级，高性能：序列化支持PB(Protocol Buffer)和JSON，PB是一种语言无关的高性能序列化框架。
• 可插拔；
• IDL: 基于文件定义服务，通过proto3工具生成指定语言的数据结构，服务端接口以及客户端Sub
• 移动端：基于HTTP2.0设计，支持双向流，消息头压缩，单TCP的多路复用，服务端推送等特性的，这些特性使得GRPC在移动端设备商更加省电和节省网络流量。
  

gRPC是基于HTTP2.0 实现，因此能够支持双向流，消息头压缩和单TCP的多路复用，而Restful是基于HTTP1.x实现的，HTTP1.x的连接是通过连接池来实现连接，而HTTP连接后不能被其他的HTTP连接所复用，知道该TCP断开，导致在大流量或者大吞吐的情况下，性能较HTTP2.0差。因此移动端大多数是基于gRPC over HTTP2.0实现。

服务而非对象，消息而非引用：促进微服务的系统间粗粒度消息交互设计理念。

负载无关：不同的服务需要使用不同的消息类型和编码，例如protocol buffer，JSON，XML和Thrift

流：Streaming API

阻塞式和非阻塞式：支持异步和同步处理在客户端和服务端间交互的消息序列；

元数据交换：常见的横切关注点，如认证和跟踪，依赖数据交换

标准化状态码：客户端通常以有限的方式响应API调用返回的错误。

gRPC - healthcheck

gRPC有标准的健康检测协议，在gRPC的所有语言实现中都提供了生成代码和用于设置运行状态的功能。
主动健康检测healthcheck，可以在服务提供者不稳定时，被消费者感知，临时从负载均衡中摘除，减少错误请求。当服务提供者重新稳定后，healthcheck成功，重新加入到消费者的负载均衡，恢复请求。healthcheck,同样也被用于外挂方式的容器健康检测，或者流量检测(k8s liveness& readiness)

1. kubernets向discovery发起注销请求。
2. kubernets向APP发送SIGTER信号，进入优雅退出过程。
3. 其他客户端在2个心跳周期内退出
4. Kubernetes退出超时(一般10-60s)强制退出SIGKILL

服务发现

• 客户端发现
  一个服务实例被启动时，它的网络地址被写到注册表上；当服务实例终止时，再从注册表中删除；这个服务实例的注册表通过心跳机制动态刷新；客户端使用一个负载均衡算法，去选择一个可用的服务实例，来响应这个请求。
  客户端发现就是当 A 需要调用 B 服务时，请求注册中心（B 服务在启动时会将信息注册到注册中心），注册中心将一份完整的可用服务列表返回给 A 服务，A 服务自行决定使用哪个 B 服务。
  

• 服务端发现
  服务端发现相对于客户端发现，多了一个代理，代理帮 A 从众多的 B 中挑选一个 B
  

客户端发现：直连，比服务端服务少一次网络跳转，Consumer需要内置的服务发现客户端和发现逻辑。
服务端发现：Consumer无需关注服务发现的具体细节，只需知道服务DNS域名即可，支持异构语言开发，需要基础设施支撑，多了一次网络跳转，可能有性能损失。
微服务是为了去中心化，倾向使用客户端发现。