学习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，发现可以正常访问到信息！

         当然，由于现在服务提供者只有一个，无法体现负载均衡，因此我们还需要至少再弄一个服务提供者。这里我们采用复制的方式添加，这个在第五课的时候说过了，大家可以参考：http://blog.csdn.net/u012453843/article/details/55662184这篇博客进行操作，不过值得一提的是，由于已经有microservice-provider-user了，同一目录下不允许有同名文件夹存在，因此我们给工程起名为"microservice-priovider-user2"，如下图所示。

         把复制的工程添加到Maven之后，我们为了简单起见，把microservice-provider-user工程的src和pom.xml文件直接拷贝到microservice-provider-user2工程下。我们别的都不用改，唯一需要改的便是application.yml文件中的端口号，如下图所示。

         复制的工程配置好了之后，我们启动它（当然，也是到启动类中去启动），启动之后，我们刷新http://localhost:8761，发现当前user微服务有两个，都已成功注册到了eureka server当中了。

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

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

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