1.负载均衡Ribbon

负载均衡就是将用户请求（流量）通过一定的策略，分摊在多个服务实例上执行，它是系统处理高并发、缓解网络 压力和进行服务端扩容的重要手段之一。它分为服务端负载均衡和客户端负载均衡。

服务器端负载均衡

在负载均衡器中维护一个可用的服务实例清单，当客户端请求来临时，负载均衡服务器按照某种配置好的规则(负载均衡算法)从可用服务实例清单中选取其一去处理客户端的请求。这就是服务端负载均衡。

例如Nginx，通过Nginx进行负载均衡，客户端发送请求至Nginx，Nginx通过负载均衡算法，在多个服务器 之间选择一个进行访问。即在服务器端再进行负载均衡算法分配。

客户端服务负载均衡：

上边使用的 LoadBalancerClient就是一个客户端负载均衡器，具体使用的是Ribbon客户端负载均衡器。
Ribbon在发送请求前通过负载均衡算法选择一个服务实例，然后进行访问，这是客户端负载均衡。即在客户端就进行负载均衡的分配。

Ribbon是一个客户端负载均衡器，它的责任是从一组实例列表中挑选合适的实例，如何挑选？取决于负载均衡策略 。

Ribbon核心组件IRule是负载均衡策略接口，它有如下实现，大家仅做了解：

• RoundRobinRule( 默认):轮询，即按一定的顺序轮换获取实例的地址。

• RandomRule: 随机，即以随机的方式获取实例的地址。

• AvailabilityFilteringRule: 会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务,以及并发的连接数量超过阈值的服务,然后对剩余的服务列表按照轮询策略进行访问;

• WeightedResponseTimeRule: 根据平均响应时间计算所有服务的权重,响应时间越快,服务权重越大,被选中的机率越高;刚启动时,如果统计信息不足,则使用RoundRobinRule策略,等统计信息足够时,会切换到WeightedResponseTimeRule

• RetryRule: 先按照RoundRobinRule的策略获取服务,如果获取服务失败,则在指定时间内会进行重试,获取可用的服务;

• BestAvailableRule: 会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务,然后选择一个并发量最小的服务;

• ZoneAvoidanceRule: 复合判断server所在区域的性能和server的可用性选择服务器;

接下来，我们就来使用Ribbon实现负载均衡。

1.1.启动两个服务实例

首先我们启动两个user-service实例，一个8081，一个8082。

为了端口不冲突，并不改application.yml,我们采用动态端口配置

1.2.开启负载均衡

可通过下面方式在服务消费方的 配置文件中修改默认的负载均衡策略：

nacosRestfulProvider:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

因为Nacos中已经集成了Ribbon，所以我们无需引入新的依赖。直接修改代码：

在RestTemplate的配置方法上添加@LoadBalanced注解：

@Bean
@LoadBalanced
public RestTemplate restTemplate() {
    return new RestTemplate(new OkHttp3ClientHttpRequestFactory());
}

修改调用方式，不再手动获取ip和端口，而是直接通过服务名称调用：

@Repository
public class UserDao {
    @Resource
    private RestTemplate restTemplate;
    public User queryUserById(Long id){
        // 获取ip和端口信息
        String url = "http://nacosRestfulProvider/user/"+id;
        return this.restTemplate.getForObject(url, User.class);
    }
}

1.3.源码跟踪

为什么我们只输入了service名称就可以访问了呢？之前还要获取ip和端口。

显然有人帮我们根据service名称，获取到了服务实例的ip和端口。它就是LoadBalancerInterceptor

1.4.负载均衡策略

Ribbon默认的负载均衡策略是简单的轮询，我们可以测试一下：

编写测试类，在刚才的源码中我们看到拦截中是使用 来进行负载均衡的，其中有一个choose方法，是这样介绍的：

现在这个就是负载均衡获取实例的方法。

我们对注入这个类的对象，然后对其测试：

导入test依赖：

        <dependency>
            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter-test</artifactId>

        </dependency>

新建单元测试类

@RunWith(SpringRunner.class)
@SpringBootTest(classes = UserConsumerDemoApplication.class)
public class LoadBalanceTest {

    @Autowired
    private RibbonLoadBalancerClient client;

    @Test
    public void test(){
        for (int i = 0; i < 100; i++) {
            ServiceInstance instance = this.client.choose("nacosRestfulProvider");
            System.out.println(instance.getHost() + ":" + instance.getPort());
        }
    }
}

符合了我们的预期推测，确实是轮询方式。

我们是否可以修改负载均衡的策略呢？

SpringBoot也帮我们提供了修改负载均衡规则的配置入口：

nacosRestfulProvider:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

格式是：{服务名称}.ribbon.NFLoadBalancerRuleClassName，值就是IRule的实现类。

再次测试，发现结果变成了随机：

1.5.重试机制

Eureka的服务治理强调了CAP原则中的AP，即可用性和可靠性。Nacos可以AP和CP,它与Zookeeper这一类强调CP（一致性Consistency，分区容错性Partition tolerance）的服务治理框架最大的区别在于：Eureka,Nacos可以为了实现更高的服务可用性，牺牲了一定的一致性，极端情况下它宁愿接收故障实例也不愿丢掉健康实例（当故障实例过多，会导致健康实例压力太大导致雪崩效应），这就是健康保护阈值。

但是，此时如果我们调用了这些不正常的服务，调用就会失败，从而导致其它服务不能正常工作！这显然不是我们愿意看到的。

但是此时，8081服务其实是正常的。

因此Spring Cloud 整合了Spring Retry 来增强RestTemplate的重试能力，当一次服务调用失败后，不会立即抛出一次，而是再次重试另一个服务。

只需要简单配置即可实现Ribbon的重试：

spring:
  application:
    name: nacosRestfulConsumer
  cloud:
    nacos:
      discovery:
        server‐addr: 127.0.0.1:8848
    loadbalancer:
      retry:
        enabled: true # 开启Spring Cloud的重试功能
nacosRestfulProvider:
  ribbon:
#    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
    ConnectTimeout: 250 # Ribbon的连接超时时间
    ReadTimeout: 1000 # Ribbon的数据读取超时时间
    OkToRetryOnAllOperations: true # 是否对所有操作都进行重试
    MaxAutoRetries: 0 # 对当前实例的重试次数
    MaxAutoRetriesNextServer: 1 # 切换实例的重试次数

根据如上配置，当访问到某个服务超时后，它会再次尝试访问下一个服务实例，如果不行就再换一个实例，如果不行，则返回失败。切换次数取决于MaxAutoRetriesNextServer参数的值

引入spring-retry依赖

<dependency>
    <groupId>org.springframework.retry</groupId>

    <artifactId>spring-retry</artifactId>

</dependency>

加入日志依赖

<dependency>
            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter-logging</artifactId>

</dependency>

application.yml

logging:
  level:
    root: info
    org:
      springframework: debug

我们重启user-consumer-demo，以及启动刚刚停掉的user-service，测试，发现即使user-service2宕机，也能通过另一台服务实例获取到结果！