Dubbo-kubernetes 基于 Informer 服务发现优化之路

作者：丛国庆

在 Kubernetes（简称 K8s，一个可移植容器的编排管理工具）体系中，etcd 存储集群的数据信息，kube-apiserver 作为统一入口，任何对数据的操作都必须经过 kube-apiserver。因此 Dubbo 想要以 Kubernetes 作为注册中心，必须调用 kube-apiserver 获取服务地址列表，那是以什么样的机制保持信息的可靠性、实时性、顺序性、高性能呢？答案就是基于 List/Watch 的 Informer 组件。

List/Watch 机制介绍

List / Watch 机制是 Kubernetes 中实现集群控制模块最核心的设计之一，它采用统一的异步消息处理机制，保证了消息的实时性、可靠性、顺序性和性能等，为声明式风格的API奠定了良好的基础。

List 是向 kube-apiserver 调用 list API 获取资源列表，基于 HTTP 短链接实现。

Watch则是向 kube-apiserver 调用 watch API 监听资源变更事件，基于 HTTP 长链接，通过 Chunked transfer encoding(分块传输编码) 来实现消息通知。

当客户端调用 watch API 时，kube-apiserver 在 response 的 HTTP Header 中设置 Transfer-Encoding 的值为 chunked，表示采用分块传输编码，客户端收到该信息后，便和服务端连接，并等待下一个数据块，即资源的事件信息。例如：

$ curl -i http://{kube-api-server-ip}:8080/api/v1/watch/endpoints?watch=yes
HTTP/1.1 200 OK
Content-Type: application/json
Transfer-Encoding: chunked
Date: Thu, 14 Seo 2022 20:22:59 GMT
Transfer-Encoding: chunked

{"type":"ADDED", "object":{"kind":"Endpoints","apiVersion":"v1",...}}
{"type":"ADDED", "object":{"kind":"Endpoints","apiVersion":"v1",...}}
{"type":"MODIFIED", "object":{"kind":"Endpoints","apiVersion":"v1",...}}