gRPC

gRPC是什么可以用官网的一句话来概括："A high-performance, open-source universa/ RPC framework"

特点：

• 多语言：语言中立，支持多种语言。
• 轻量级、高性能：序列化支持 PB （Protocol Buffer） 和JSON, PB是一种语言无关的高性能序列化框架。
• 可插拔
• IDL：基于文件定义服务，通过proto3 工具生成指定语言的数据结构、服务端接口以及客户端 Stub
• 移动端：基于标准的HTTP/2设计，支持双向流、消息头压缩、单TCP的多路复用、服务端推送等特性， 这些特性使得 gRPC 在移动端設备上更加省电和节省网络流量
• 服务而非对象、消息而非引用：促进微服务的系统问粗粒度消息交互设计理念。
• 负载无关的：不同的服务需要使用不同的消息类型和编码，例如 protocol buffers、JSON、XML 和 Thrit。
• 流：Streaming APl。
• 阻塞式和非阻塞式：支持异步和同步处理在客户端和服务端间交互的消息序列。
• 元数据交换：常见的横切关注点，如认证或跟踪，依赖数据交换。
• 标准化状态码：客户端通常以有限的方式响应API调用返回的错误。

不要过早关注性能问题，先标准化。

gRPC-HealthCheck

gRPC有一个标准的健康检测协议，在gRPC的所有语言实现中基本都提供了生成代码和用于设置运行状态的功能。

多脚鸭状态：优雅下线

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

服务发现 - 客户端发现

一个服务实例被启动时，它的网络地址会被写到注册表上；当服务实例终止时，再从注册表中删除；这个服务实例的注册表通过心跳机制动态刷新；客户端使用一个负载均衡算法，去选择一个可用的服务实例，来响应这个请求。

带有服务注册、发现、限流的客户端又叫 smart client（智能客户端），缺点是逻辑很重

服务发现 - 服务端发现

客户端通过负载均衡器向一个服务发送请求，这个负载均衡器会查询服务注册表，并将请求路由到可用的服务实例上。服务实例在服务注册表上被注册和注销（Consul Template+Nginx，kubernetes+etcd）。

缺点：没有去中心化

Service Mesh

服务注册发现下沉到基础架构层，SDK 很轻，但是两个服务间还是有一层代理，只是这个 proxy 和应用容器部署在一起，去了大中心化。结合了两者的优点

服务发现

• 通过 Family （appid）和 Addr （IP:Port）定位实例，除此之外还可以附加更多的元数据：权重、染色标签、集群等。

  • appid：使用三段式命名，business.service.xxx

• Provider 注册后定期（30s）心跳一次，注册， 心跳，下线都需要进行同步，注册和下线需要进行长轮询推送。

  • 新启动节点，需要load cache,JVM预热。
  • 故障时，Provider 不建议重后和发布。

• Consumer 启动时拉取实例，发起30s长轮询。

  • 故障时，需要client 侧cache 节点信息。
• Server 定期（60s）检测失效（90s）的实例， 失效则剔除。短时间里丢失了大量的心跳连接 （15分钟内心跳低于期望值*85%），开启自我保护，保留过期服务不删除。