注册中心要集成 SpringCloud实现负载均衡，需要哪些接口和规范？

前几天有个大兄弟问了我一个问题，注册中心要集成SpringCloud，想实现SpringCloud的负载均衡，需要实现哪些接口和规范。

既然这个兄弟问到我了，而我又刚好知道，这不得好好写一篇文章来回答这个问题，虽然在后面的聊天中我已经回答过了。

接下来本文就来探究一下Nacos、OpenFeign、Ribbon、loadbalancer等组件协调工作的原理，知道这些原理之后，就知道应该需要是实现哪些接口了。

Nacos

先从Nacos讲起。

Nacos是什么，官网中有这么一段话

这一段话说的直白点就是Nacos是一个注册中心和配置中心！

在Nacos中有客户端和服务端的这个概念

服务端需要单独部署，用来保存服务实例数据的
客户端就是用来跟服务端通信的SDK，支持不同语言

当需要向Nacos服务端注册或者获取服务实例数据的时候，只需要通过Nacos提供的客户端SDK就可以了，就像下面这样：

引入依赖

<dependency>
    <groupId>com.alibaba.nacos</groupId>
    <artifactId>nacos-client</artifactId>
    <version>1.4.4</version>
</dependency>

示例代码

Properties properties = new Properties();
properties.setProperty("serverAddr", "localhost");
properties.setProperty("namespace", "8848");

NamingService naming = NamingFactory.createNamingService(properties);

//服务注册，注册一个order服务，order服务的ip是192.168.2.100，端口8080
naming.registerInstance("order", "192.168.2.100", 8080);

//服务发现，获取所有的order服务实例
List<Instance> instanceList = naming.selectInstances("order", true);

当服务注册到Nacos服务端的时候，在服务端内部会有一个集合去存储服务的信息

这个集合在注册中心界中有个响亮的名字，服务注册表。

如何进行服务自动注册？

用过SpringCloud的小伙伴肯定知道，在项目启动的时候服务能够自动注册到服务注册中心，并不需要手动写上面那段代码，那么服务自动注册是如何实现的呢？

服务自动注册三板斧

SpringCloud本身提供了一套服务自动注册的机制，或者说是约束，其实就是三个接口，只要注册中心实现这些接口，就能够在服务启动时自动注册到注册中心，而这三个接口我称为服务自动注册三板斧。

服务实例数据封装--Registration

Registration是SpringCloud提供的一个接口，继承了ServiceInstance接口

Registration

ServiceInstance

从ServiceInstance的接口定义可以看出，这是一个服务实例数据的封装，比如这个服务的ip是多少，端口号是多少。

所以Registration就是当前服务实例数据封装，封装了当前服务的所在的机器ip和端口号等信息。

Nacos既然要整合SpringCloud，自然而然也实现了这个接口

NacosRegistration

这样当前服务需要被注册到注册中心的信息就封装好了。

服务注册--ServiceRegistry

ServiceRegistry也是个接口，泛型就是上面提到的服务实例数据封装的接口

ServiceRegistry

这个接口的作用就是把上面封装的当前服务的数据Registration注册通过register方法注册到注册中心中。

Nacos也实现了这个接口。

NacosServiceRegistry

并且核心的注册方法的实现代码跟前面的demo几乎一样

服务自动注册--AutoServiceRegistration

AutoServiceRegistration

AutoServiceRegistration是一个标记接口，所以本身没有实际的意义，仅仅代表了自动注册的意思。

AutoServiceRegistration有个抽象实现AbstractAutoServiceRegistration

AbstractAutoServiceRegistration是个抽象类

AbstractAutoServiceRegistration实现了ApplicationListener，监听了WebServerInitializedEvent事件。

WebServerInitializedEvent这个事件是SpringBoot在项目启动时，当诸如tomcat这类Web服务启动之后就会发布，注意，只有在Web环境才会发布这个事件。

ServletWebServerInitializedEvent继承自WebServerInitializedEvent。

所以一旦当SpringBoot项目启动，tomcat等web服务器启动成功之后，就会触发AbstractAutoServiceRegistration监听器的执行。

最终就会调用ServiceRegistry注册Registration，实现服务自动注册

Nacos自然而然也继承了AbstractAutoServiceRegistration

NacosAutoServiceRegistration

对于Nacos而言，就将当前的服务注册的ip和端口等信息，就注册到了Nacos服务注册中心。

所以整个注册流程就可以用这么一张图概括

当然，不仅仅是Nacos是这么实现的，常见的比如Eureka、Zookeeper等注册中心在整合SpringCloud都是实现上面的三板斧。

Ribbon

讲完了SpringCloud环境底下是如何自动注册服务到注册中心的，下面来讲一讲Ribbon。

我们都知道，Ribbon是负载均衡组件，他的作用就是从众多的服务实例中根据一定的算法选择一个服务实例。

但是有个疑问，服务实例的数据都在注册中心，Ribbon是怎么知道的呢？？？

答案其实很简单，那就是需要注册中心去主动适配Ribbon，只要注册中心去适配了Ribbon，那么Ribbon自然而然就知道服务实例的数据了。

Ribbon提供了一个获取服务实例的接口，叫ServerList

ServerList

接口中提供了两个方法，这两个方法在众多的实现中实际是一样的，并没有区别。

当Ribbon通过ServerList获取到服务实例数据之后，会基于这些数据来做负载均衡的。

Nacos自然而然也实现了ServerList接口，为Ribbon提供Nacos注册中心中的服务数据。

NacosServerList

这样，Ribbon就能获取到了Nacos服务注册中心的数据。

同样地，除了Nacos之外，Eureka、Zookeeper等注册中心也都实现了这个接口。

到这，其实就明白了Ribbon是如何知道注册中心的数据了，需要注册中心来适配。

在这里插个个人的看法，其实我觉得Ribbon在适配SpringCloud时对获取服务实例这块支持封装的不太好。

因为SpringCloud本身就是一套约束、规范，只要遵守这套规范，那么就可以实现各个组件的替换，这就是为什么换个注册中心只需要换个依赖，改个配置文件就行。

而Ribbon本身是一个具体的负载均衡组件，注册中心要想整合SpringCloud，还得需要单独去适配Ribbon，有点违背了SpringCloud约束的意义。

就类似mybatis一样，mybatis依靠jdbc，但是mybatis根本不关心哪个数据库实现的jdbc。

真正好的做法是Ribbon去适配SpringCloud时，用SpringCloud提供的api去获取服务实例，这样不同的注册中心只需要适配这个api，无需单独适配Ribbon了。

而SpringCloud实际上是提供了这么一个获取服务实例的api，DiscoveryClient

DiscoveryClient

通过DiscoveryClient就能够获取到服务实例，当然也是需要不同注册中心的适配。

随着Ribbon等组件停止维护之后，SpringCloud官方自己也搞了一个负载均衡组件loadbalancer，用来平替Ribbon。

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-loadbalancer</artifactId>
    <version>2.2.5.RELEASE</version>
</dependency>

这个组件底层在获取服务实例的时候，就是使用的DiscoveryClient。