Kubernetes中gRpc的服务发现

目录

gRpc负载均衡的特别之处

gRpc服务发现的实现

客户端侧服务发现的方案

1.基于外部注册中心组件做服务发现

2.客户端基于Kubernetes的DNS做服务发现

最佳实践

3.客户端基于Kubernetes Api接口做服务发现

如何开发gRpc客户端实现服务发现

NameResolverProvider 和 NameResolver 接口

---

在 k8s 的网络环境下，一个 grpc 的服务，同一个 namespace 下，可以直接通过 service 访问，不同的 namespace 可以通过 service.namespace 访问。

gRpc负载均衡的特别之处

如果是SpringCloud集群之间的通信，是可以借助k8s service 使用服务端负载均衡的。虽然HTTP/1.1 默认开启 Keepalive时也会保持长连接，但是 HTTP/1.1 多个请求不会共享一个连接，如果连接池里没有空闲连接则会新建一个，经过 Service 的负载均衡，各个 pod 上的连接是相对均衡的。

但是gRpc本身是基于Http 2 长连接多路复用的，也就是说无论server端开启了多少个 pod 实例，客户端一般只会与一个pod建立连接并进行连接复用，当然如果并发超出了单连接并发数可能会触发新连接的建立，但是在客户端和服务端数量不对等时，打到 server 侧的流量大概是不均衡的

gRpc客户端负载均衡的原理

客户端与集群中每个后端服务提供者实例都建立一个长连接，在请求时使用客户端的LB算法选择一个连接通道写入请求。

gRpc服务发现的实现

上面说了gRpc负载均衡的特别之处，很显然gRpc是无法依靠服务端的负载均衡机制来做LB的，那么常见的 grpc 负载均衡方法可以分为两类，一类是客户端侧实现负载逻辑，一类是代理侧实现负载逻辑，例如service mesh对客户端侧是透明的。 

客户端侧服务发现的方案

在Kubernetes网络环境里， gRpc客户端侧的负载均衡有几种常见的实现方案。

1.基于外部注册中心组件进行服务发现

笼统来说这种实现方式相当于把微服务架构中的zk，nacos等注册中心组件又搬到了k8s集群中，有点多此一举。

而且对于SpringCloud迁移k