目录一. 场景了解二. 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发送请求后首先会被拦截那这个类既然实现了接口就会实现这个方法我们来看一下这个方法的具体内容1final URL originalUri request.getURL()首先得到url地址对比上面也就是order-service发送的请求http://userservice/user/12String serviceName originalUrl.getHost()这段代码的目的是得到主机地址。即userservice服务名称3this.loadBalance.execute(...)之后又调用了这个方法我们点进跟入查看继续跟入execute在方法返回值中得到了一个loadBalance对象我们点开看一下可以看到一个allServerList服务列表列表中已经可以看到我们的端口8081和端口8082的两个用户模块。然后第二行代码 Server server getServer(loadBalancehint)就是要得到一个server服务端口我们点进 getServer() 方法跟进看一下它又调用了chooseServer方法点进看一下这个chooseServer方法又调用了 super.chooseServer() 方法它找该方法的父亲去了我们继续跟入发现这里找到了一个rule这个rule又是什么呢我们找到可以发现这个IRule是一个接口那么它就一定有实现类如下这里看到它有好几个实现类我们来看其中两个就可以了RandomRule和RoundRobinRule翻译过来分别是随机规则和轮询调度规则。看到了这里我们应该就豁然开朗了我把上面讲的所有总结成了下面这幅图1order-service发送http请求2该http请求会被LoadBalanceInterceptor拦截获取其中的url地址和服务id3DynamicServerListLoadBalance会向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是可以指定多个服务的后续有多个微服务都可以通过饥饿加载的方式进行配置。
目录一. 场景了解二. 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发送请求后首先会被拦截那这个类既然实现了接口就会实现这个方法我们来看一下这个方法的具体内容1final URL originalUri request.getURL()首先得到url地址对比上面也就是order-service发送的请求http://userservice/user/12String serviceName originalUrl.getHost()这段代码的目的是得到主机地址。即userservice服务名称3this.loadBalance.execute(...)之后又调用了这个方法我们点进跟入查看继续跟入execute在方法返回值中得到了一个loadBalance对象我们点开看一下可以看到一个allServerList服务列表列表中已经可以看到我们的端口8081和端口8082的两个用户模块。然后第二行代码 Server server getServer(loadBalancehint)就是要得到一个server服务端口我们点进 getServer() 方法跟进看一下它又调用了chooseServer方法点进看一下这个chooseServer方法又调用了 super.chooseServer() 方法它找该方法的父亲去了我们继续跟入发现这里找到了一个rule这个rule又是什么呢我们找到可以发现这个IRule是一个接口那么它就一定有实现类如下这里看到它有好几个实现类我们来看其中两个就可以了RandomRule和RoundRobinRule翻译过来分别是随机规则和轮询调度规则。看到了这里我们应该就豁然开朗了我把上面讲的所有总结成了下面这幅图1order-service发送http请求2该http请求会被LoadBalanceInterceptor拦截获取其中的url地址和服务id3DynamicServerListLoadBalance会向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是可以指定多个服务的后续有多个微服务都可以通过饥饿加载的方式进行配置。
到int 0x80的硬件级执行链)
