所以这将导致 kube-proxy 只有在连接建立时才会做负载均衡，而在这之后的每一次 RPC 请求都会利用原本的连接，那么实际上后续的每一次的 RPC 请求都跑到了同一个地方。
注：使用 k8s service 做负载均衡的情况下
总结
gRPC 基于 HTTP/2 + Protobuf。
gRPC 有四种调用方式，分别是一元、服务端/客户端流式、双向流式。
gRPC 的附加信息都会体现在 HEADERS 帧，数据在 DATA 帧上。
Client 请求若使用 grpc.Dial 默认是异步建立连接，当时状态为 Connecting。
Client 请求若需要同步则调用 WithBlock()，完成状态为 Ready。
Server 监听是循环等待连接，若没有则休眠，最大休眠时间 1s；若接收到新请求则起一个新的 goroutine 去处理。
grpc.ClientConn 不关闭连接，会导致 goroutine 和 Memory 等泄露。
任何内/外调用如果不加超时控制，会出现泄漏和客户端不断重试。
特定场景下，如果不对 grpc.ClientConn 加以调控，会影响调用。
拦截器如果不用 go-grpc-middleware 链式处理，会覆盖。
在选择 gRPC 的负载均衡模式时，需要谨慎。
参考
https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md
https://juejin.im/post/5b88a4f56fb9a01a0b31a67e
https://www.ibm.com/developerworks/cn/web/wa-http2-under-the-hood/index.html
https://github.com/grpc/grpc-go/issues/1953
https://www.zhihu.com/question/52670041
微信公众号【程序员黄小斜】作者是前蚂蚁金服Java工程师，专注分享Java技术干货和求职成长心得，不限于BAT面试，算法、计算机基础、数据库、分布式、spring全家桶、微服务、高并发、JVM、Docker容器，ELK、大数据等。关注后回复【book】领取精选20本Java面试必备精品电子书。