Dubbo如何通过 DNS Client 的形式与 Kubernetes 对接？

DNS Client Kubernetes DNS 是 Kubernetes 提供的一种通过 DNS 查询的方式获取 Kubernetes Service 信息的机制，通过普通的 DNS 请求就可以获取到服务的节点信 息。全去中心化的元数据服务 由于 DNS 协议本身限制，目前并没有一个统一的较为简单的方式向 DNS 附加更多 的信息用于写入 Revision 信息。对于 DNS 的实现方案我们将元数据服务进行了改造， 使其不再强依赖往注册中心写入 Revision 信息，实现只需要知道 Dubbo 应用的 IP 即 可以实现正常的服务发现功能。改造后的元数据服务可以分为两大功能，一个是基于 revision 的获取 URL 信息等 的能力，另外一个是获取对应 revision 的能力。Dubbo 服务消费者在通过注册中心获取 到实例 IP 后会主动去与每一个实例的元数据服务进行连接，获取 revision 信息后，对于 revision 信息一致的实例随机选择一个去获取完整的元数据信息。由于 Revision 信息采用了点对点的方式获取，当这个信息更新时要及时通知给消费 者端进行更新。在当前版本的实现中，我们依赖了 参数回调 机制实现服务者主动推送给消 费者。未来会基于 3.0 的全新 Triple 协议，实现流式推送。 Provider 侧细节 与 Kubernetes API Client 实现方式类似的，组建服务的过程均需要由运维侧进行， 在服务提供者启动的时候会进行元数据信息本地缓存、对外暴露元数据服务接口的机制。 这里需要特别注意的是，为了使服务发现过程与业务服务本身解耦，元数据服务接口与 业务接口对应的端口可以不一致，在使用 DNS 实现方案的时候全集群所有应用的元数据 服务端口都需要统一， 通过 metadataServicePort 参数进行配置。这样亦可以适配那些 不支持通过 SRV 获取端口的 DNS。 Consumer 侧细节 对于 DNS 注册中心来说，获取实例的流程主要通过向 DNS 发起 A （或 AAAA） 查询请求来获取，而 Kubernetes DNS 也提供了 SRV 记录请求来获取服务的信息。 在获取到 Revision 信息之后，对于具有相同 Revision 信息的实例，Dubbo 会随 机选择其中一个获取完整元数据信息，至此完成服务发现的全过程。

Dubbo与Kubernetes集成 Dubbo应用迁移到docker的问题 Dubbo是阿里开源的一套服务治理与rpc框架,服务的提供者通过zookeeper把自己的服务发布上去