Dubbo 如何使用 Spring Cloud 服务注册与发现？

Dubbo 使用 Spring Cloud 服务注册与发现 Dubbo Spring Cloud 基于 Spring Cloud Commons 抽象实现 Dubbo 服务注 册与发现，应用只需增添外部化配置属性 “dubbo.registry.address = spring-cloud:/ /localhost”，就能轻松地桥接到所有原生 Spring Cloud 注册中心，包括： - Nacos- Eureka - Zookeeper - Consul 注：Dubbo Spring Cloud 将在下个版本支持 Spring Cloud 注册中心与 Dubbo 注册中心并存，提供双注册机制，实现无缝迁移

1、抽象 接触Spring久了，就会发现Spring最擅长的事情就是抽象和封装。所以我们听到最多的就是今天整合这个功能、明天整合那个中间件，把流行的好用的全部都整合进来。

很少听到Spring去发明一个东西，或优化一个算法啥的。其实能整合好就已经足够了，就这已经估值几十亿美金了吧。其实要把这么多东西整合进来，还要保证不乱套，必须进行良好的接口抽象。就像电脑主板上要插很多东西，必须要进行合理的位置布局和插口设计。其实Spring Cloud现在已经是一块主板了，上面插满了各种组件，它用自己的“电源”和“总线”为大家“供电”和“传输数据”，保证整体的良好、平稳运行即可。

下面来解说下抽象过程，其实很容易理解。假如有一个和用户相关的工程叫langjitianya-account-service。把它运行起来，可以对外提供服务啦。但是任何东西如果只有一个的话，都存在单点问题。这很好解决，那就多运行几个呗。此时这个工程只有一个，就像是一个“类”（class），但它可以运行多份（IP和端口不同而已），就像是这个“类”new出来的多个实例（instance）。比如langjitianya-account-service运行如下：

192.168.10.1 : 8080 192.168.10.2 : 8080 192.168.10.3 : 8080 192.168.10.4 : 8080

类运行起来后通常称为对象。那工程运行起来后叫什么呢？上面刚刚说过，工程其实就是个服务，所以工程运行起来就叫服务实例。同一个工程同时运行多份，就表示同一个服务同时存在多个服务实例。所以服务是一个静态的概念，服务实例是一个动态的概念。因为只有运行起来后才能向外提供服务，否则代码再好，没有运行起来，就是一坨死代码，毛用都没有。因此Spring Cloud只关注运行起来的服务，于是就有了服务实例的抽象： 在这里插入图片描述 接口名字就叫ServiceInstance。Host和Port就是ip和端口，ServiceId就是服务的标识，其实就是指的工程本身，一般默认的就是spring.application.name表示的值。InstanceId就是服务实例的标识，其实就是指的工程的一份运行，假如工程运行了四份，那就有四个InstanceId，可以分别用: npfdev1 : langjitianya-account-service: 8080 npfdev2 : langjitianya-account-service: 8080 npfdev3 : langjitianya-account-service: 8080 npfdev4 : langjitianya-account-service: 8080 上面是根据默认的规则生成的，默认就是： 主机名：服务名：端口。

2、注册 在不严格的情况下，可以把服务与服务实例当作是一回事儿，只要根据语境能分开就行。所以服务注册与发现里的服务就是服务实例。其实只需把服务实例注册上就可以啦，但是为了概念统一，Spring Cloud还是抽象出了一个注册（Registration）： 在这里插入图片描述 可以看到它只是单纯的继承服务实例接口，只是一个标记接口，就是为了概念上的统一。上面这个接口表示的是被注册的内容，是名词语义的。还应该有一个表示注册动作的动词语义接口，是的，那就是ServiceRegistry： 在这里插入图片描述 可以看出服务注册接口可以注册一个Registration或取消注册一个Registration。整天讲的服务注册其实就是两个接口而已，使用ServiceRegistry接口来注册Registration接口。这就是Spring Cloud提供的服务注册的抽象，一般般吧，不过够用就行了。那么思考下，这些服务实例信息都注册到哪里了呢？答案自然是注册中心了。这个注册中心不是Spring Cloud里的内容，是第三方组件，常见的有Eureka, Consul，还有阿里的Nacos。

所以Spring Cloud既不管注册中心是谁家的，也不管服务是怎么被注册上的，它只有一个要求，那就是只要实现我提供的这两个接口就行了。这样就可以被我管理了。

3、发现 服务被注册上后，自然要有发现机制，要能找到它们。于是就又有了一个抽象，DiscoveryClient接口， 其实我觉得这个接口的名字起的不是很贴切，叫DiscoveryServiceInstanceClient可能会更好。 在这里插入图片描述 这个接口比较核心的功能是获取所有的serviceId，即都注册上了哪些服务。还有就是获取某个服务对应的所有服务实例，即某个工程的多份运行实例。Spring Cloud还是不管具体实现细节，只要实现了DiscoveryClient这个接口就行了。