WangCw的夏天

...... 永远年轻,永远热泪盈眶

如何使用Ribbon实现负载均衡?

        首先我们来说下最常见的负载均衡策略,那就是使用nginx作为反向代理服务器,对服务的调用进行负载均衡,这种方式是服务器端负载均衡。如下图所示。这个不是我们本节课一起学习的重点。


        下面我们来说说另一种负载均衡策略,如下图所示。ribbon可以在客户端经过一系列算法来均衡调用服务。Ribbon工作时分两步:

第一步:选择Eureka Server,它优先选择在同一个Zone且负载较少的Server。

第二步:根据用户指定的策略,在从Server取到的服务注册列表中选择一个地址,其中Ribbon提供了多种策略,例如轮询round robin、随机Random、根据响应时间加权等。


       接下来我们便开始使用Ribbon来进行负载均衡,我们从Spring Cloud官网可以看到相关说明,如下图所示,文档中明确说明使用Ribbon的第一步便是要在pom.xml文件中添加ribbon的依赖"spring-cloud-starter-ribbon"。但是我们不用加,这是因为我们的movie微服务中添加过了spring-cloud-starter-eureka的依赖,而这个依赖中已经有ribbon的依赖了。


       movie微服务pom.xml文件中spring-cloud-starter-eureka的依赖,如下图所示。


        我们找到spring-cloud-starter-eureka的Maven依赖包,并打开它的pom.xml文件,发现,在它的pom.xml文件中已经有spring-cloud-starter-eureka的依赖了,因此我们的movie微服务不必添加ribbon的依赖了。


     使用Ribbon的第二步便是到movie的启动类中添加一个注解@LoadBalanced,这一个注解作用可不小,它就可以帮我们做负载均衡的复杂工作。


       使用Ribbon的第三步便是修改movie的controller类,我们把地址由原来的http://localhost:7900/simple改成了http://microservice-provider-user/simple,这一改,我们可以看到去掉了端口,也就意味着客户端访问的服务可能来自于多个。其中microservice-provider-user是我们注册到Eureka Server上的IP,也称为Virtual IP(简称VIP)


      此时我们的movie的application.yml配置文件的内容如下,为了避免与user微服务的端口有所冲突,因此我们把movie微服务的端口改为8010。(值得注意的是:配置文件中的application.name的名字最好与工程名保持一致


        下面,我们启动movie工程。但是前提是我们要先依次启动eureka工程和user工程,启动完三个工程后,我们访问http://localhost:8761,如下图所示。可以看到,服务端和消费端都已在eureka server上成功注册。


         下面我们来通过movie工程消费user微服务,我们输入地址:http://localhost:8010/movie/1,发现可以正常访问到信息!


         当然,由于现在服务提供者只有一个,无法体现负载均衡,因此我们还需要至少再弄一个服务提供者。

         弄第二个服务提供者其实非常简单,只需要改一下端口号并配置工程不是单实例即可

         首先我们来修改一下user工程的端口号,由于已经有7900这个端口了,我们改为7901端口,如下图所示。


        其次我们需要配置工程支持多实例,如下图点击"Edit Configurations..."


          找到user工程,如下图所示,把右侧"Single instance only"这个复选框变为不勾选状态。然后点击"Apply"和"OK"。


         配置好之后,我们启动第二个user工程实例,还是到user工程的启动类当中去启动,如下图所示。


         启动之后,我们刷新http://localhost:8761,发现当前user微服务有两个,都已成功注册到了eureka server当中了。


         下面我们多次刷新地址:http://localhost:8010/movie/1,然后我们查看两个user微服务的控制台信息,看看负载均衡是否真的起了作用。首先我们看看7900端口所对应的user微服务被调用的情况,如下图所示,发现被调用了四次。


        下面我们再看看7901端口的user微服务,如下图所示,发现该微服务被调用了两次,这里值得说明的是,刚开始的时候消费者是调不到7901微服务的,这是因为刚开始ribbon还没有从eureka server的注册表中同步7901的信息,因此ribbon还不知道有7901这个微服务的存在,后来同步成功之后,ribbon便采用默认的轮询的方式进行调用服务。

阅读更多
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_33404395/article/details/80694009
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭