学习Spring Cloud第七课（Ribbon的基本使用）

        上节课我们一起学习了如何在Eureka Server上注册微服务，这节课我们一起学习服务消费者如何动态调用服务消费者以及如何实现负载均衡。

        首先我们来说下最常见的负载均衡策略，那就是使用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便采用默认的轮询的方式进行调用服务。

         好，本节我们便一起学习到这儿