企业官网建设流程全解析

目录

一. 场景了解

二. Ribbon 负载均衡功能验证

三. Ribbon 工作原理简介

一. 场景了解

在讲解 Ribbon 负载均衡原理之前，我们要先了解服务的拉取，我们知道，在微服务中，一个模块想要调用另一个模块中的某个功能，需要调用被调用模块对外暴露的业务接口，而我们的Eureka又可以将所有业务模块都注册到其中，方便各个业务模块互相调用。

在不使用Eureka之前，如果只一个模块想要调用另一个模块的功能，可以发送 http 请求，如下

此时，我们在写 url 路径时，还是采用的硬编码的形式，而在实际开发过程中，通常是不会这样写的，微服务之间的通信通常会采用 Feign 来进行远程调用；但这里不说 Feign，我们用另一种办法，写服务的名称，如下所示，将 localhost 改成相应的业务名称

这就是我们服务发现的第一步；

二. Ribbon 负载均衡功能验证

第二步：就是在相对应的启动类中，在之前创建的 RestTemplate 上添加@Loadbalanced，注解，其实该注解的意思就是负载均衡，那它有什么用呢？

看上面，我已经启动并注册了 Order-service 业务以及两个 User-service 业务对应了8081和8082两个端口号，如果我们现在在浏览器发送请求，那么这个请求会被端口号为8081的接收？还是8082的接受？我们来验证一下

我们可以看到，我在浏览器发送了四次请求，都得到了成功相响应，那我们再来打开idea看看，可以看到

user-service 模块被调用了两次

user-service2 模块也被调用了两次

上面的情况是巧合吗？其实不是的，这是因为负载均衡原理，这个负载均衡原理就是在Eureka客户端工具当中，不需要我们管。

那么一定有很多人好奇，是什么东西完成负载均衡这个功能的呢？

其实就是Ribbon来完成的，下面我们就来深入探究一下Ribbon的底层实现。

看到上面我所写的例子(如下图所示)，大家可以看到，我们的order-service发送了http请求给我们的user-service，那么这个请求是真是可用的吗？

我们来试一下，打开浏览器输入图中所示的http请求，看看会有什么结果

可以看到，我们是没有任何响应结果的，order-service发送的请求是无法直接到达user-service去的，那它又是怎么帮我们实现上面的四个响应功能的呢？

不难猜想，中间一定有一个角色，帮我们实现了这个功能，它就是我们上面所提到的Ribbon；

三. Ribbon 工作原理简介

首先，order-service 发送请求，但请求会被 Ribbon 给拦截，它会识别要发送请求的对象是哪个模块的，然后向我们的 eureka-server 去要，eureka-server 有就会返回给它，然后 Ribbon 将 HTTP 请求进行加工处理，通过自身的负载均衡算法，去挑选其中一个 user-service 发送请求，再得到返回的结果，然后将结果返回给 order-service。

那么它到底是怎么实现上述功能的呢？这就要我们一起来看一下源码才能知道了。

首先我们想，既然 Ribbon 能拦截 http 请求，那么它一定是一个 http 请求拦截器，就是下面这个 LoadBalancerInterceptor。

这个类翻译过来就是负载均衡拦截器。它实现了一个接口，接口的名称翻译过来就是客户端HTTP请求拦截器。它实现了这个请求拦截器，那么它就会拦截从客户端发送出来的HTTP请求。

而我们的微服务模块之间的调用正是通过发送HTTP请求来实现的，所以也就是说，微服务模块之间的调用都要通过HTTP请求拦截器，再经过自身的一些负载均衡规则，从而实现了微服务之间负载均衡的调用。

我们点进 ClientHttpRequestInterceptor 接口中去看一下

在接口的上面，我们可以看到一段英文描述，我们不用全看，只看第一句，Interceptor clent-side HTTP requests，这句话的意思是 “客户端HTTP请求拦截器”。那么到这里就知道了，我们的order-service发送请求后，首先会被拦截

那这个类既然实现了接口，就会实现这个方法，我们来看一下这个方法的具体内容

（1）final URL originalUri = request.getURL()，首先得到url地址，对比上面也就是order-service发送的请求：http://userservice/user/1

（2）String serviceName = originalUrl.getHost()，这段代码的目的是得到主机地址。即userservice服务名称

（3）this.loadBalance.execute(...)之后又调用了这个方法，我们点进跟入查看

继续跟入execute

在方法返回值中，得到了一个loadBalance对象

我们点开看一下

可以看到一个allServerList服务列表，列表中已经可以看到我们的端口8081和端口8082的两个用户模块。

然后第二行代码 Server server = getServer(loadBalance，hint)；就是要得到一个server服务端口，我们点进 getServer() 方法跟进看一下

它又调用了chooseServer方法，点进看一下

这个chooseServer方法又调用了 super.chooseServer() 方法，它找该方法的父亲去了，我们继续跟入

发现这里找到了一个rule，这个rule又是什么呢？

我们找到可以发现，这个IRule是一个接口，那么它就一定有实现类，如下：

这里看到它有好几个实现类，我们来看其中两个就可以了，RandomRule和RoundRobinRule

翻译过来分别是随机规则和轮询调度规则。

看到了这里我们应该就豁然开朗了，我把上面讲的所有总结成了下面这幅图：

（1）order-service发送http请求；

（2）该http请求会被LoadBalanceInterceptor拦截，获取其中的url地址和服务id；

（3）DynamicServerListLoadBalance会向eureka-server拉取服务；

（4）返回服务列表

（5）得到服务列表后，会再调用负载均衡规则从服务列表中按照规则挑选一个

（6）将选中的服务返回

（7）将返回后的服务端口与http请求重新拼接，生成新的http请求

（8）发送请求，即可得到响应结果。

以上就是负载均衡的策略以及实现步骤

那么大家现在是否有疑问呢？比如这个负载均衡策略（IRule）到底是什么？

我们来看下面

可以看到，这里有很多种规则，那么我们该怎么去使用他呢？

其实很简单，我们只需要在定义一个Rule的Bean对象即可，在返回时，想使用那种规则，就直接返回那种规则的对象，如下所示：

@Bean public IRule randomRule() { return new RandomRule(); }

这里我就是直接返回一个随机Rule。

其实，配置Rule是有两种方式的，第一种方式就是上面的直接在启动类中定义Rule的Bean对象，

这个Bean对象是定义在OrderApplication的启动类中的，这种方法有一个缺点，它是全局的，不管你这个模块调用哪个模块，都是采用的Bean对象的Rule规则，这个方法显然有些死板。

第二种方法就是在它的application.yml文件中配置，指定针对于userservice模块的规则为随机；当然如果后续有其他模块，也可以设置其他模块。

userservice: ribbon: NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则

这里再做一点补充，就是Ribbon的默认是懒加载，所以首次访问某个服务时，耗时会比较长，因为他要去加载服务列表以及SpringMVC容器的初始化。

而一旦开启了饥饿加载(在ymn文件中配置)，只要服务器启动，他就会把所有的东西全部加载到服务器上，不管用得上用不上。

ribbon: eager-load:true enabled: true clients: # 指定饥饿加载的服务名称 - userservice

但是建议在clients属性中设置想要饥饿加载的服务名称，这里的clients属性是一个List，是可以指定多个服务的，后续有多个微服务，都可以通过饥饿加载的方式进行配置。