1. gRPC
1.1 特性
- 多语言：语言中立，支持多种语言。
- 轻量级、高性能：序列化支持 PB(Protocol Buffer)和 JSON，PB 是一种语言无关的高性能序列化框架。
- 可插拔：扩展插件。
- IDL（约束）：基于文件定义服务，通过 proto3 工具生成指定语言的数据结构、服务端接口以及客户端 Stub。
- 基于标准的 HTTP2 设计，支持双向流、消息头压缩、单 TCP 的多路复用、服务端推送等特性，这些特性使得 gRPC 在移动端设备上更加省电和节省网络流量。
- 流：Streaming API。
- 阻塞式和非阻塞式：支持异步和同步处理在客户端和服务端间交互的消息序列。
- 元数据交换：常见的横切关注点，如认证或跟踪，依赖数据交换。
- 标准化状态码：客户端通常以有限的方式响应 API 调用返回的错误。
1.2 HealthCheck
gRPC有个标准的健康检测协议，在gRPC的所有语言实现中基本都提供了生成代码和用于设置运行状态的功能，可以配合用来做服务的优雅启动和优雅中止。
主动健康检查health check，可以在服务提供者服务不稳定时，被消费者所感知，临时从负裁均衡中摘除，减少错误情求。当服务提供者重新稳定后，health check成功，重新加入到消费者的负载均衡，恢复清求。health check同样也被用于外挂方式的容器健康检测，或者流量检测k8s liveness readiness。
2. 服务发现
分为客户端服务发现和服务端服务发现，微服务的核心是去中心化，其实建议使用客户端发现模式。
客户端服务发现：
该模式相对比较简单，除了服务注册中心，没有其他移动部件。客户端能发现可用的服务实例，因此可以实现智能的、特定于应用的负载均衡决策，比如使用一致性哈希。
客户端查询服务注册中心（service registry），它是可用服务实例的数据库。之后，客户端利用负载均衡算法选择一个可用的服务实例并发出请求。
Netflix Eureka 是一个服务注册中心，它提供了一组用于管理服务实例注册和查询可用实例的 REST API。该模式的一个重要缺点是它将客户端与服务注册中心耦合在一起。你必须为你使用的每种编程语言和框架实现客户端服务发现逻辑。
服务端服务发现：
HTTP 服务器和负载均衡器（如 NGINX Plus 和 NGINX）也可以作为服务端发现负载均衡器。
Consumer无需关注服务发现具体细节，只需知道服务的DNS域名即可，支持异构语言开发。
3. 多集群多租户
多集群：利用PaaS平台，给某个appid服务建立多套集群（物理上相当于两套资源逻辑上维护cluster的概念)，对于不同集群服务启动后，从环境变量里可以获取当下服务的cluster，在服务发现注册的时候，带入这些元信息。当然， 不同集群可以隔离使用不同的缓存资源等。
多租户：使用这种方法，内部叫染色发布。从源头传递一个标签，放到RPC的header里面，跨服务传递情求携带上下文(context)，数据隔离的流量路由方案。
4. 参考资料
- https://lailin.xyz/post/go-training-02.html
- 《极客大学-Go进阶训练营》
