SpringCould-Ribbon

客户端负载均衡

负载均衡在系统架构中是一个非常重要，并且是不得不去实施的内容。因为负载均衡是对系统的高可用、网络压力的缓解和处理能力扩容的重要手段之一。我们通常所说的负载均衡都指的是服务端负载均衡，其中分为硬件负载均衡和软件负载均衡。硬件负载均衡主要通过在服务器节点之间按照专门用于负载均衡的设备，比如F5等；而软件负载均衡则是通过在服务器上安装一些用于负载均衡功能或模块等软件来完成请求分发工作，比如Nginx等。不论采用硬件负载均衡还是软件负载均衡，只要是服务端都能以类似下图的架构方式构建起来：

负载均衡架构图

硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个下挂可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。当客户端发送请求到负载均衡设备的时候，该设备按某种算法（比如线性轮询、按权重负载、按流量负载等）从维护的可用服务端清单中取出一台服务端端地址，然后进行转发。
而客户端负载均衡和服务端负载均衡最大的不同点在于上面所提到服务清单所存储的位置。在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单，而这些服务端端清单来自于服务注册中心，比如上一章我们介绍的Eureka服务端。同服务端负载均衡的架构类似，在客户端负载均衡中也需要心跳去维护服务端清单的健康性，默认会创建针对各个服务治理框架的Ribbon自动化整合配置，比如Eureka中的org.springframework.cloud.netflix.ribbon.eureka.RibbonEurekaAutoConfiguration，Consul中的org.springframework.cloud.consul.discovery.RibbonConsulAutoConfiguration。在实际使用的时候，我们可以通过查看这两个类的实现，以找到它们的配置详情来帮助我们更好地使用它。
通过Spring Cloud Ribbon的封装，我们在微服务架构中使用客户端负载均衡调用非常简单，只需要如下两步：
▪️服务提供者只需要启动多个服务实例并注册到一个注册中心或是多个相关联的服务注册中心。
▪️服务消费者直接通过调用被@LoadBalanced注解修饰过的RestTemplate来实现面向服务的接口调用。
这样，我们就可以将服务提供者的高可用以及服务消费者的负载均衡调用一起实现了。

第一步：启动类加入

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

第二步：接口类执行调研方法

   @Autowired
   private RestTemplate restTemplate;

Map<String,Object> forObject = restTemplate.getForObject("http://product-service/api/v1/product/selectById?id=" + productId, Map.class);
System.out.println(forObject.toString());

第三步：结果

数据访问到了
{id=3, name=毛笔, pice=5, num=100}
最后代码：

@Autowired
private RestTemplate restTemplate;
@Override
public Order addOrder(int memberId ,int productId) {
    Order  order =new Order();
    order.setCodeNumber(UUID.randomUUID().toString()); //订单号
    order.setMemberId(memberId);                       //用户Id
    order.setProductId(productId);                     //商品Id
    //    准备从  商品服务 获取数据  ：更具商品id查询商品详情
    //    /api/v1/product/selectById?id=1
    Map<String,Object> forObject = restTemplate.getForObject("http://product-service/api/v1/product/selectById?id=" + productId, Map.class);
    System.out.println(forObject.toString());
    order.setName(forObject.get("name").toString());                                                  //商品名称
    order.setPice(new BigDecimal(forObject.get("pice").toString()));                                  //商品价格
    order.setNum(Integer.valueOf(forObject.get("num").toString()));                                   //商品库存
    return order;
}

第四步：负载均衡

扩展：idea启动多个项目
项目启动是优先使用这里的配置

-Dserver.port=8771

负载均衡有好几种实现策略，常见的有：
Ribbon 的负载均衡策略
     策略类                                              命名                             说明
RandomRule                                    随机策略                             随机选择 Server
RoundRobinRule                           轮训策略                             按顺序循环选择 Server
RetryRule                                          重试策略                             在一个配置时问段内当选择 Server 不成功，则一直尝试选择一个可用的 Server
BestAvailableRule                         最低并发策略                     逐个考察 Server，如果 Server 断路器打开，则忽略，再选择其中并发连接最低的 Server
AvailabilityFilteringRule           可用过滤策略                      过滤掉一直连接失败并被标记为 circuit tripped 的 Server，过滤掉那些高并发连接的 Server（active connections 超过配置的网值）
ResponseTimeWeightedRule   响应时间加权策略             根据 Server 的响应时间分配权重。响应时间越长，权重越低，被选择到的概率就越低；响应时间越短，权重越高，被选择到的概率就越高。这个策略很贴切，综合了各种因素，如：网络、磁盘、IO等，这些因素直接影响着响应时间
ZoneAvoidanceRule                       区域权衡策略                      综合判断 Server 所在区域的性能和 Server 的可用性轮询选择 Server，并且判定一个 AWS Zone 的运行性能是否可用，剔除不可用的 Zone 中的所有 Server