共计 4251 个字符，预计需要花费 11 分钟才能阅读完成。
Kubernetes 是以后寰球最风行的容器服务平台，在 Kubernetes 集群中，Dubbo 利用的部署形式往往须要借助第三方注册核心实现服务发现。Dubbo 与 Kubernetes 的调度体系的联合，能够让本来须要治理两套平台的运维老本大大减低，而且 Dubbo 适配了 Kubernetes 原生服务也能够让框架自身更加融入云原生体系。基于 Dubbo 3.0 的全新利用级服务发现模型能够更容易对齐 Kubernetes 的服务模型。
Kubernetes Native Service
在 Kubernetes 中，Pod 是能够在 Kubernetes 中创立和治理的、最小的可部署的计算单元。通常一个 Pod 由一个或多个容器组成，利用则部署在容器内。
对于一组具备雷同性能的 Pod，Kubernetes 通过 Service 的概念定义了这样一组 Pod 的策略的形象，也即是 Kubernetes Service。这些被 Kubernetes Service 标记的 Pod 个别都是通过 Label Selector 决定的。
在 Kubernetes Service 内，服务节点被称为 Endpoint，这些 Endpoint 也就是对应提供服务的利用单元，通常一对一对应了 Pod。
因而，咱们能够将微服务中的利用自身应用 Service 来进行调度，而微服务间的调用通过 Service 的一系列机制来实现服务发现，进而将微服务整合进 Kubernetes Service 的体系中。
Dubbo 利用级服务发现
在 Dubbo 体系结构内，为了更好地合乎 Java 开发人员的编程习惯，Dubbo 底层以接口粒度作为注册对象。然而这个模型对当初支流的 Spring Cloud 注册模型和 Kubernetes Service 注册模型有很大的区别。
目前在非 Dubbo 体系外的注册模型次要是以服务粒度作为注册对象，为了买通 Dubbo 与其余体系之间的注册发现壁垒，Dubbo 在 2.7.5 版本当前引入了服务自省的架构，次要通过元数据服务实现从服务粒度到接口粒度的过渡。在 2.7.5 版本当前到 3.0 版本，服务自省模型进行了很多方面的优化，并且在生产环境下进行了验证。
1. 元数据服务
元数据服务次要是存储了服务（Instance）与接口（Interface）的映射关系，通过将本来的写入到注册核心的接口信息形象到元数据进行存储，一方面能够大大减少注册核心存储的数据量、升高服务更新时集群的网络通信压力，另一方面，实现了注册核心层面只存储利用粒度信息的指标，对齐了其余注册模型。
在服务自省模型中，服务提供者不仅仅往注册核心写入以后实例的信息，还须要往（本地或者近程的）元数据服务写入裸露的服务 URL 信息等；而对于服务消费者，在从注册核心获取实例信息后，还须要（通过 RPC 申请内建或者中心化配置核心获取）元数据服务获取服务提供者的服务 URL 信息等来生成接口粒度体系下的接口信息。
2. Revision 信息
Revision 信息是元数据服务引入的一种数据缓存机制，对于同一组利用很多状况下裸露的接口其实都是一样的，在进行服务（Instance）与接口（Interface）映射的时候会有许多反复的冗余数据，因而能够应用相似对元数据信息进行 MD5 计算的形式来对实例自身加上版本号，如果多个实例的版本号统一能够认为它们的元数据信息也统一，那么只须要随机抉择一台来获取元数据信息即可，能够实现把通行量从一组实例都须要通信到只须要与一个实例通信的压缩。
如上图所示，服务消费者注册核心的工作机制能够总结为：
- 服务消费者向注册核心获取服务实例列表。
- 注册核心向服务消费者返回服务实例信息，在实例列表中包含了服务提供者向注册核心写入的 Revision 参数。
- 服务消费者依据获取到实例信息的 Revision 参数进行分组，别离从每组实例中随机抉择一台获取元数据服务。
- 服务消费者通过 RPC 发动调用或者通过配置核心获取失去指定实例的元数据信息。
- 服务消费者依据获取到的元数据信息组建接口粒度的服务信息。
对于利用级服务发现更多的信息能够参考：《Dubbo 迈出云原生重要一步 – 利用级服务发现解析》
对接实现形式
本次实现的与 Kubernetes 对接的形式有两种，一种是通过 Kubernetes API Client 的模式获取信息，另外一种是通过 DNS Client 的模式获取。
1. Kubernetes API Client
Kubernetes 管制立体的外围是 API Server，API Server 提供了 HTTP API，以供用户、集群中的不同局部和集群内部组件互相通信。对于 Dubbo 来说，通过应用 Kubernetes API Client 便能够做到与 Kubernetes 管制立体通信。
1）Provider 侧细节
依据前文说到 Dubbo 利用级服务发现模型，对于 Provider 侧在利用启动、接口更新时须要向注册核心写入 Revision 信息，因而大抵的逻辑如上图所示。
Label 标签作为 Selector 与 Service 进行匹配，Annotation 中则次要存储了 Revision 等信息，其中 Revision 信息须要由 Dubbo 利用被动向 Kubernetes API Server 发动更新申请写入，这也对应了服务注册的流程。
在目前版本的实现中，Kubernetes Service 的创立工作是交由运维侧实现的，也即是 Label Selector 是由运维侧去治理的，在 Dubbo 利用启动前就曾经配置结束了，Service 的名字也即是对应接口注解中的 Services 字段（对于不依赖任何第三方配置核心的须要在接口级别手动配置此字段）。
2）Consumer 侧细节
对于 Consumer 侧的逻辑大抵上与利用级服务发现的模型设计的一样，在通过 API 获取到服务信息后通过获取对应 Pod 的 Annotation 信息补齐 ServiceInstance 信息，后续逻辑与服务自省统一。
3）优缺点
- 须要指出的是，让利用自身间接与 Kubernetes 治理平台的 API 交互自身就存在肯定安全隐患，如果配置不当有肯定可能性导致拖垮整个 Kubernetes 集群。
- 当利用大量更新时会给 Kubernetes API Server 带来肯定压力。
- 本计划间接将 Dubbo 的服务发现过程对接到 Kubernetes 集群的治理上，能够在 Kubernetes 环境下进一步简化治理的复杂度。
2. DNS Client
Kubernetes DNS 是 Kubernetes 提供的一种通过 DNS 查问的形式获取 Kubernetes Service 信息的机制，通过一般的 DNS 申请就能够获取到服务的节点信息。
1）全去中心化的元数据服务
因为 DNS 协定自身限度，目前并没有一个对立的较为简单的形式向 DNS 附加更多的信息用于写入 Revision 信息。对于 DNS 的实现计划咱们将元数据服务进行了革新，使其不再强依赖往注册核心写入 Revision 信息，实现只须要晓得 Dubbo 利用的 IP 即能够实现失常的服务发现性能。
革新后的元数据服务能够分为两大性能，一个是基于 revision 的获取 URL 信息等的能力，另外一个是获取对应 revision 的能力。Dubbo 服务消费者在通过注册核心获取到实例 IP 后会被动去与每一个实例的元数据服务进行连贯，获取 revision 信息后，对于 revision 信息统一的实例随机抉择一个去获取残缺的元数据信息。
因为 Revision 信息采纳了点对点的形式获取，当这个信息更新时要及时告诉给消费者端进行更新。在以后版本的实现中，咱们依赖了 参数回调 机制实现服务者被动推送给消费者。将来会基于 3.0 的全新 Triple 协定，实现流式推送。
2）Provider 侧细节
与 Kubernetes API Client 实现形式相似的，组建服务的过程均须要由运维侧进行，在服务提供者启动的时候会进行元数据信息本地缓存、对外裸露元数据服务接口的机制。
这里须要特地留神的是，为了使服务发现过程与业务服务自身解耦，元数据服务接口与业务接口对应的端口能够不统一，在应用 DNS 实现计划的时候全集群所有利用的元数据服务端口都须要对立，通过 metadataServicePort 参数进行配置。这样亦能够适配那些不反对通过 SRV 获取端口的 DNS。
3）Consumer 侧细节
对于 DNS 注册核心来说，获取实例的流程次要通过向 DNS 发动 A（或 AAAA）查问申请来获取，而 Kubernetes DNS 也提供了 SRV 记录申请来获取服务的信息。
联合前文说到的全去中心化的元数据服务机制，Consumer 会去被动连贯获取到的每一个实例的元数据服务，获取对应的 Revision 信息，同时以参数回调的模式向提供者提交回调函数用于更新本地信息。
在获取到 Revision 信息之后，对于具备雷同 Revision 信息的实例，Dubbo 会随机抉择其中一个获取残缺元数据信息，至此实现服务发现的全过程。
4）优缺点
- 本计划与前一种计划比照起来防止了 Kubernetes API 的间接交互，防止了交互的平安问题。
- 因为 DNS 没有像 API Watch 的告诉机制，只能采纳轮询的形式判断服务的变更，在没有利用变更时集群内仍有一定量的 DNS 网络查问压力。
- 本方案设计的时候指标是对任何只有可能通过 A（或 AAAA）查问获取到 Dubbo 利用自身的 IP 的 DNS 都能够适配，对 Kubernetes DNS 并不是强依赖关系。
总结
本次 Dubbo 对接 Kubernetes 原生服务是 Dubbo 往云原生化倒退的一次尝试，将来咱们将基于 xDS 协定实现与 Service Mesh 管制立体的交互，相干性能正在紧锣密鼓的策划中。同时，在将来 Dubbo 3.0 的发版上，Java 社区和 Dubbo-go 社区将同步发版，本次 Kubernetes 的性能也将对齐上线。
系列文章举荐：
- 《Dubbo 云原生之路：ASF 毕业一周年、3.0 可期》
- 《Dubbo 迈出云原生重要一步 – 利用级服务发现解析》
- 《Dubbo 3.0 前瞻：重塑 Spring Cloud 服务治理》
- 《Dubbo 3.0 前瞻：罕用协定比照及 RPC 协定新形态摸索》
- 《2020 双 11，Dubbo3.0 在考拉的超大规模实际》
- 《Dubbo 3.0 前瞻系列：服务发现反对百万集群，带来可伸缩微服务架构》
- 《Dubbo 版 Swagger 来啦！Dubbo-Api-Docs 公布》
作者简介
江河清 ，Github 账号 AlbumenJ，Apache Dubbo Committer。在读本科生，目前次要参加 Dubbo 社区云原生 Kubernetes 和 Service Mesh 模块对接。
