Dubbo-go k8s注册中心设计方案与实现

随着云原生的推广，越来越多的公司或组织将服务容器化，并将容器化后的服务部署在k8s集群中。

今天这篇文章将会介绍dubbo-go将k8s作为服务注册中心的方案设计，以及具体实现。到目前为止该方案的实现已经被合并到dubbo-go的master分支。具体实现为关于Kubernetes的PullRequest。

k8s管理资源的哲学

k8s作为容器集群化管理方案可以将管理资源的维度可主观的分为服务实例管理和服务接入管理。

• 服务实例管理，主要体现方式为Pod设计模式加控制器模式。控制器保证具有特定标签（Label）的Pod保持在恒定的数量（多删，少补）。
• 服务接入管理，主要为Service，该Service默认为具有特定标签（Label）的一批Pod提供一个VIP（ClusterIP）作为服务的接入点，默认会按照round-robin的负载均衡策略将请求转发到真正提供服务的Pod。并且CoreDNS为该Service提供集群内唯一的域名。

k8s服务发现模型

为了明确k8s在服务接入管理提供的解决方案，我们以kube-apiserver 提供的API(HTTPS)服务为例。k8s集群为该服务分配了一个集群内有效的ClusterIP，并通过CoreDNS为其分配了唯一的域名 kubernetes 。如果集群内的Pod需要访问该服务时直接通过https://kubernetes:443即可完成。

具体流程如上图所示(红色为客户端，绿色为kube-apiserver)：

1. 首先客户端通过CoreDNS解析域名为kubernetes的服务获得对应的ClusterIP为10.96.0.1。
2. 客户端向10.96.0.1发起HTTPS请求。
3. HTTPS之下的TCP连接被kube-proxy创建的iptables的PREROUTING链拦截并DNAT 为 10.0.2.16或10.0.2.15。
4. Client与最终提供服务的Pod建立连接并交互。

由此可见，k8s提供的服务发现为域名解析级别。

Dubbo服务发现模型

同样为了明确Dubbo服务发现的模型，以一个简单的Dubbo-Consumer发现并访问Provider的具体流程为例。

具体流程如上图所示：

1. Provider将本进程的元数据注册到Registry中，包括IP，Port，以及服务名称等。
2. Consumer通过Registry获取Provider的接入信息，直接发起请求

由此可见，Dubbo当前的服务发现模型是针对Endpoint级别的，并且注册的信息不只IP和端口还包括其他的一些元数据。

K8s service vs dubbo-go 服务

通过上述两个小节，答案基本已经比较清晰了。总结一下，无法直接使用k8s的服务发现模型的原因主要为以下几点:

1. k8s的Service标准的资源对象具有的服务描述字段 中并未提供完整的Dubbo进程元数据字段因此，无法直接使用该标准对象进行服务注册与发现。
2. dubbo-do的服务注册是基于每个进程的，每个Dubbo进程均需进行独立的注册。
3. k8s的Service默认为服务创建VIP，提供round-robin的负载策略也与Dubbo-go自有的Cluster模块的负载策略形成了冲突。

Dubbo-go 当前的方案

服务注册

K8s基于Service对象实现服务注册/发现。可是dubbo现有方案为每个dubbo-go进程独立注册，因此dubbo-go选择将该进程具有的独有的元数据写入运行该dubbo-go进程的Pod在k8s中的Pod资源对象的描述信息中。每个运行dubbo进程的Pod将本进程的元数据写入Pod的Annotations字段。为了避免与其他使用Annotations字段的Operator或者其他类型的控制器（istio）的字段冲突。dubbo-go使用Key为 http://dubbo.io/annotation value为具体存储的K/V对的数组的json编码后的base64编码。

样例为：

apiVersion: v1
kind: Pod
metadata:
  annotations:
    dubbo.io/annotation: W3siayI6Ii9kdWJibyIsInYiOiIifSx7ImsiOiIvZHViYm8vY29tLmlrdXJlbnRvLnVzZXIuVXNlclByb3ZpZGVyIiwidiI6IiJ9LHsiayI6Ii9kdWJiby9jb20uaWt1cmVudG8udXNlci5Vc2VyUHJvdmlkZXIvY29uc3VtZXJzIiwidiI6IiJ9LHsiayI6Ii9kdWJibyIsInYiOiIifSx7ImsiOiIvZHViYm8vY29tLmlrdXJlbnRvLnVzZXIuVXNlclByb3ZpZGVyIiwidiI6IiJ9LHsiayI6Ii9kdWJiby9jb20uaWt1cmVudG8udXNlci5Vc2VyUHJvdmlkZXIvcHJvdmlkZXJzIiwidiI6IiJ9LHsiayI6Ii9kdWJiby9jb20uaWt1cmVudG8udXNlci5Vc2VyUHJvdmlkZXIvY29uc3VtZXJzL2NvbnN1bWVyJTNBJTJGJTJGMTcyLjE3LjAuOCUyRlVzZXJQcm92aWRlciUzRmNhdGVnb3J5JTNEY29uc3VtZXJzJTI2ZHViYm8lM0RkdWJib2dvLWNvbnN1bWVyLTIuNi4wJTI2cHJvdG9jb2wlM0RkdWJibyIsInYiOiIifV0=

由于每个dubbo-go的Pod均只负责注册本进程的元数据，因此Annotations字段长度也不会因为运行dubbo-go进程的Pod数量增加而增加。

服务发现

依赖kube-apiserver 提供了WATCH的功能。可以观察特定namespace内各Pod对象的变化。dubbo-go为了避免dubbo-go进程WATCH到与dubbo-go进程无关的Pod的变化，dubbo-go将WATCH的条件限制在当前Pod所在的namespace，以及仅WATCH具有Key为 http://dubbo.io/label Value为 dubbo.io-value 的Pod。在WATCH到对应Pod的变化后实时更新本地Cache，并通过Registry提供的Subscribe接口通知建立在注册中心之上的服务集群管理其他模块。

总体设计图

具体流程如上图所示：