gRPC

gRPC 是什么可以用官网的一句话来概括

“A high-performance, open-source universal RPC framework”高性能、开源的统一的rpc框架

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

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

protoc –go_out=. –go_opt=paths=source_relative –go-grpc_out=. –go-grpc_opt=paths=source_relative helloworld/helloworld.proto

gRPC-HealthCheck

gRPC有一个标准的健康检测协议，主动健康检查，可以在服务提供者不稳定的时候，被消费者感知，临时从负载均衡中摘除，减少错误检查。恢复稳定后，健康检查成功，重新加入负载均衡中。
可用于外挂方式的容器健康检测或者流量检测
- 服务发现时，provider和discovery，discovery和consumer之间是通的，所以provider会在discovery的注册列表中，但是provider和consumer之间不通，实际是不可用的，这个时候consumer可以通过健康检测去嗅探provider是否存活
用于平滑发布：跛脚鸭状态，一个服务进入待上线或者待下线状态，那就是跛脚鸭状态（半残，不能正常提供服务）
- k8s向应用发送下线信号，应用告知discovery，并且变为待下线状态，该状态同时应用于健康检测接口，当其他应用来调健康检查接口时，告知其处于待下线状态，从负载均衡连接池中摘除，减少服务发现延迟的风险，双保险
- 双保险都无法让应用正常下线，那k8s就采用兜底策略，kill -9
- 上线也是同理，健康检查+跛脚鸭状态，可以得知刚上线的应用是否已经预热完毕

概念：一个服务实例被启动时，它的网络地址会被写到注册表上；当服务实例终止时，再从注册表中删除；这个服务实例的注册表通过心跳机制动态刷新；客户端使用一个负载均衡算法，去选择一个可用的服务实例，来响应这个请求。
就是服务提供者和消费者直连，少一次网络跳转，但是consumer需要内置服务发现代码（智能客户端），变复杂了，这种情况可以通过抽一层proxy，把服务发现逻辑放到同一个pod的另外一个容器中，减轻客户端的逻辑，然后客户端容器和proxy通过IPC(进程间通信)通信，proxy再直连服务提供者（搞不定的就抽一层）

概念：客户端通过负载均衡器向一个服务发送请求，这个负载均衡器会查询服务注册表，并将请求路由到可用的服务实例上。服务实例在服务注册表上被注册和注销(Consul Template+Nginx，kubernetes+etcd)。
consumer无需关注服务发现细节，只要知道域名就行，但是多了一次网络跳转，而且采用了集中式负载均衡，不符合去中心化的思想

尽量保证服务发现中心的可用，多数情况采用AP系统，接受最终一致
- 新节点注册延迟最多导致负载短时间内不均衡，可以接受
- 节点注销延迟，可以通过健康检查+跛脚鸭来感知，也可以接受
本地缓存快照，服务发现中心不可用时使用本地快照链接
一旦服务注册中心大面积故障，provider不建议重启和发布，因为consumer可以通过本地缓存继续与provider通信，一旦provider这时候重启了，consumer就找不到可用的provider了
一旦大面积节点失效，服务注册中心可以开启自保护机制，保留过期服务不删除（Euerka），令consumer有provider可用，过期信息比没有信息好
不同中间件对比