Dubbo、SpringCloud、Kubernetes 是怎么实现自动化的实例地址自动发现？

a) Spring Cloud Spring Cloud 通过注册中心只同步了应用与实例地址，消费方可以基于实例地址与 服务提供方建立链接，但是消费方对于如何发起 http 调用（SpringCloud 基于 rest 通 信）一无所知，比如对方有哪些 http endpoint，需要传入哪些参数等。 RPC 服务这部分信息目前都是通过线下约定或离线的管理系统来协商的。这种架构的 优缺点总结如下。 优势：部署结构清晰、地址推送量小。 缺点：地址订阅需要指定应用名， provider 应用变更（拆分）需消费端感知；RPC 调用无法全自动同步。 b) Dubbo Dubbo 通过注册中心同时同步了实例地址和 RPC 方法，因此其能实现 RPC 过程 的自动同步，面向 RPC 编程、面向 RPC 治理，对后端应用的拆分消费端无感知，其缺 点则是地址推送数量变大，和 RPC 方法成正比。 c) Dubbo + Kubernetes Kubernetes Service 作为一个抽象概念，怎么映射到 Dubbo 是一个值得讨论的 点：Service Name - > Application Name，Dubbo 应用和 Kubernetes 服务一一 对应，对于微服务运维和建设环节透明，与开发阶段解耦： apiVersion: v1 kind: Service metadata: name: provider-app-name spec: selector: app: provider-app-name ports: - protocol: TCP port: targetPort: 9376 Service Name - > Dubbo RPC Service，Kubernetes 要维护调度的服务与应 用内建 RPC 服务绑定，维护的服务数量变多： --- apiVersion: v1 kind: Service metadata: name: rpc-service-1 spec: selector: app: provider-app-name ports: ## ... --- apiVersion: v1 kind: Service metadata: name: rpc-service-2 spec: selector: app: provider-app-name ports: ## ... --- apiVersion: v1 kind: Service metadata: name: rpc-service-N spec: selector: app: provider-app-name ports: ## ... 结合以上几种不同微服务框架模型的分析，我们可以发现，Dubbo 与 SpringCloud、 Kubernetes 等不同产品在微服务的抽象定义上还是存在很大不同的。SpringCloud 和 Kubernetes 在微服务的模型抽象上还是比较接近的，两者基本都只关心实例地址的同步， 如果我们去关心其他的一些服务框架产品，会发现它们绝大多数也是这么设计的，即 REST 成熟度模型中的 L3 级别。 对比起来 Dubbo 则相对是比较特殊的存在，更多的是从 RPC 服务的粒度去设计 的。对应 REST 成熟度模型中的 L4 级别。 如我们上面针对每种模型做了详细的分析，每种模型都有其优势和不足。而我们最初决 定 Dubbo 要做出改变，往其他的微服务发现模型上的对齐，是我们最早在确定 Dubbo 的云原生方案时，我们发现要让 Dubbo 去支持 Kubernetes Native Service，模型对齐是一个基础条件；另一点是来自用户侧对 Dubbo 场景化的一些工程实践的需求，得益 于 Dubbo 对多注册、多协议能力的支持，使得 Dubbo 联通不同的微服务体系成为可能， 而服务发现模型不一致成为其中的一个障碍。

Spring Cloud

Spring Cloud 通过注册中心只同步了应用与实例地址，消费方可以基于实例地址与服务提供方建立链接，但是消费方对于如何发起 HTTP 调用(SpringCloud 基于 rest 通信)一无所知，比如对方有哪些 HTTP endpoint，需要传入哪些参数等。

RPC 服务这部分信息目前都是通过线下约定或离线的管理系统来协商的。这种架构的优缺点总结如下：

优势：部署结构清晰、地址推送量小；

缺点：地址订阅需要指定应用名， provider 应用变更(拆分)需消费端感知；RPC 调用无法全自动同步。

Dubbo

Dubbo 通过注册中心同时同步了实例地址和 RPC 方法，因此其能实现 RPC 过程的自动同步，面向 RPC 编程、面向 RPC 治理，对后端应用的拆分消费端无感知，其缺点则是地址推送数量变大，和 RPC 方法成正比。

Dubbo + Kubernetes

Dubbo 要支持 Kubernetes native service，相比之前自建注册中心的服务发现体系来说，在工作机制上主要有两点变化：

服务注册由平台接管，provider 不再需要关心服务注册；

consumer 端服务发现将是 Dubbo 关注的重点，通过对接平台层的 API-Server、DNS 等，Dubbo client 可以通过一个 Service Name(通常对应到 Application Name)查询到一组 Endpoints(一组运行 provider 的 pod)，通过将 Endpoints 映射到 Dubbo 内部地址列表，以驱动 Dubbo 内置的负载均衡机制工作。

Kubernetes Service 作为一个抽象概念，怎么映射到 Dubbo 是一个值得讨论的点

Service Name - > Application Name，Dubbo 应用和 Kubernetes 服务一一对应，对于微服务运维和建设环节透明，与开发阶段解耦。

apiVersion: v1

kind: Service

metadata:

name: provider-app-name

spec:

selector:

app: provider-app-name

ports:

• protocol: TCP

port:

targetPort: 9376

Service Name - > Dubbo RPC Service，Kubernetes 要维护调度的服务与应用内建 RPC 服务绑定，维护的服务数量变多。

apiVersion: v1

kind: Service

metadata:

name: rpc-service-1

spec:

selector:

app: provider-app-name

ports: ##

...

apiVersion: v1

kind: Service

metadata:

name: rpc-service-2

spec:

selector:

app: provider-app-name

ports: ##

...

apiVersion: v1

kind: Service

metadata:

name: rpc-service-N

spec:

selector:

app: provider-app-name

ports: ##

...