【SpringCloud】二、服务注册发现Eureka与负载均衡Ribbon

服务提供者：一次业务中，被其它微服务调用的服务。（提供接口给其它微服务）

服务消费者：一次业务中，调用其它微服务的服务。（调用其它微服务提供的接口）

很明显，这是一个相对的概念。

上一篇中，远程调用时，url参数是写死在代码中的，而不同的测试、生产、开发环境IP不同，有集群时，端口也不能固定。

很明显，硬编码肯定行不通。Eureka就是来解决这个问题的。

接下来开始搭建Eureka，并进行服务注册和服务发现

接下来将user和order服务注册到eureka中：

上面完成的注册都是单服务实例的，接下来在IDEA中模拟启动多个服务实例：

接下来实现：在order服务中完成服务信息的拉取，然后通过负载均衡挑选一个user服务，实现远程调用

服务拉取是基于服务名称获取服务列表，然后在对服务列表做负载均衡

我在浏览器中直接访问http://userservice/user/，访问失败，这是因为userservice既不是可用域名，也不是IP。那order调用到user服务的过程中经历了什么呢？

具体信息，在源码中打断点来调试看看。

@LoadBalanced注解，就标识了调用方当前这个restTemplate这个对象发起的请求，要被Ribbon拦截

LoadBalancerInterceptor实现了ClientHttpRequestInterceptor接口：

在LoadBalancerInterceptor接口重写的intercent方法上打断点，调用order接口（中途会对user服务发起远程调用），断点进入到了这里：

继续往下，看到了Ribbon对象

继续往下：成功从eureka拿到服务列表信息

继续往下调试，看到了IRule这个接口，决定了负载均衡的策略

Ribbon的负载均衡策略是由IRule接口来定义的，它的每一个子接口就是一种策略。

具体的含义为：

以上策略中，Ribbon默认的是ZoneAvoidanceRule。想修改负载均衡策略有这两种方法：

代码方式：在order-service中的OrderApplication类中，定义一个新的IRule：

配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则

此时，多次调用order接口（代码中途远程调用user)：

可以看到转发到user实例上的请求不再有明显规律。

重启order服务，然后两次访问order接口，发现耗时相差巨大：

Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，因此请求时间会很长。

饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下配置开启饥饿加载：