引言
书接上篇 微服务管家婆-Nacos Discovery 使用Nacos对微服务做了服务治理，通过Nacos维护的服务清单找到目标微服务，此时有个小问题，如果目标微服务是多个时，该怎么办，应该调用谁？这就牵扯出微服务扩展问题啦。
背景铺垫
微服务项目有一个重要的功能：可以很容易动态扩缩容
这里我们不谈容器技术(docker/k8s这些)，传统的扩缩容简单理解就是服务集群。
扩：特定时期(比如促销，天灾人祸)一个微服务可能容易挂掉(撑不住/宕机)，那么多开几个就行，此为扩。
缩：特定时期过后，多开的微服务可以适当关掉多余的，此为缩
这里考虑扩的问题，以订单与商品服务为例子，
设想一种场景：如果某天公司要促销，单一的订单服务，商品服务不一定能撑得住，该怎么扩容。
扩容常用的手段就是集群，如下：
集群存在一个很大问题，客户端发起的请求让哪个微服务处理？解决方案：负载均衡服务器
负载均衡
通俗的讲， 负载均衡就是将负载（工作任务，访问请求）进行分摊到多个操作单元（服务器,组件）上进行执行。
根据负载均衡发生位置的不同,一般分为服务端负载均衡和客户端负载均衡。
服务端负载均衡指的是发生在服务提供者一方,比如常见的Nginx负载均衡
服务端负载均衡
而客户端负载均衡指的是发生在服务请求的一方，也就是在发送请求之前已经选好了由哪个实例处理请求
客户端负载均衡
微服务调用关系中一般会选择客户端负载均衡，也就是在服务调用的一方来决定服务由哪个提供者执行。那问题来：代码上如何实现？
自定义负载均衡
说明：还是以前的订单服务--商品服务例子
需求：开启2个商品客户端(localhost:8081/localhost:8082)，这里说明一下，真实开发服务器可定是部署在不同的服务器中，ip不一样，端口可以一样。此时为学习，只有一台电脑，使用不同端口模拟一下。
步骤1：通过idea再启动一个 shop-product 微服务，设置其端口为8082： -Dserver.port=8082
步骤2：通过nacos查看微服务的启动情况
步骤3：修改 OrderServiceImpl 的代码，实现负载均衡
@Service
public class OrderServiceImpl extends ServiceImpl<OrderMapper, Order> implements IOrderService {
@Autowired
private RestTemplate restTemplate;
@Autowired
private DiscoveryClient discoveryClient;
@Override
public Order createOrder(Long pid, Long uid) {
Order order = new Order();
//商品
//方案1：通过restTemplate方式
//String url = "http://localhost:8081/products/" + pid;
//Product product = restTemplate.getForObject(url, Product.class);
//方案2：使用注册中心api方式-discoveryClient
//List<ServiceInstance> instances = discoveryClient.getInstances("product-service");
//ServiceInstance instance = instances.get(0); //当前只有一个
//String host = instance.getHost();
//int port = instance.getPort();
//String url = "http://" + host + ":" + port + "/products/" + pid;
//Product product = restTemplate.getForObject(url, Product.class);
//方案3：使用注册中心api方式-discoveryClient--带负载均衡
List<ServiceInstance> instances = discoveryClient.getInstances("product-service");
int index = new Random().nextInt(instances.size());
ServiceInstance instance = instances.get(index);
String host = instance.getHost();
int port = instance.getPort();
String url = "http://" + host + ":" + port + "/products/" + pid;
System.out.println("从nacos中获取的微服务地址为：" + url);
Product product = restTemplate.getForObject(url, Product.class);
order.setPid(pid);
order.setProductName(product.getName());
order.setProductPrice(product.getPrice());
//用户
order.setUid(1L);
order.setUsername("dafei");
order.setNumber(1);
System.out.println(order);
super.save(order);
return order;
}
}步骤4：启动两个服务提供者和一个服务消费者，多访问几次消费者测试效果
效果实现了。
基于Ribbon实现负载均衡
方案3 负载均衡方式存在问题：编写太麻烦了，有没有更加优雅的方式呢？答案是yes：Ribbon组件
Ribbon是Spring Cloud的一个组件， 它可以让我们使用一个注解就能轻松的搞定负载均衡
步骤1：在RestTemplate 的生成方法上添加@LoadBalanced注解
@Bean
@LoadBalanced
public RestTemplate restTemplate(){
return new RestTemplate();
}步骤2：修改OrderServiceImpl服务调用的方法
@Service
public class OrderServiceImpl extends ServiceImpl<OrderMapper, Order> implements IOrderService {
@Autowired
private RestTemplate restTemplate;
@Autowired
private DiscoveryClient discoveryClient;
@Override
public Order createOrder(Long pid, Long uid) {
Order order = new Order();
//商品
//方案1：通过restTemplate方式
//String url = "http://localhost:8081/products/" + pid;
//Product product = restTemplate.getForObject(url, Product.class);
//方案2：使用注册中心api方式-discoveryClient
//List<ServiceInstance> instances = discoveryClient.getInstances("product-service");
//ServiceInstance instance = instances.get(0); //当前只有一个
//String host = instance.getHost();
//int port = instance.getPort();
//String url = "http://" + host + ":" + port + "/products/" + pid;
//Product product = restTemplate.getForObject(url, Product.class);
//方案3：使用注册中心api方式-discoveryClient--带负载均衡
//List<ServiceInstance> instances = discoveryClient.getInstances("product-service");
//int index = new Random().nextInt(instances.size());
//ServiceInstance instance = instances.get(index);
//String host = instance.getHost();
//int port = instance.getPort();
//String url = "http://" + host + ":" + port + "/products/" + pid;
//System.out.println("从nacos中获取的url地址：" + url);
//Product product = restTemplate.getForObject(url, Product.class);
//方案4：使用Ribbon方式--带负载均衡
String url = "http://product-service/products/" + pid;
Product product = restTemplate.getForObject(url, Product.class);
order.setPid(pid);
order.setProductName(product.getName());
order.setProductPrice(product.getPrice());
//用户
order.setUid(1L);
order.setUsername("dafei");
order.setNumber(1);
System.out.println(order);
super.save(order);
return order;
}
}步骤3：为了更直观看到请求是进行负载均衡了，我们修改一下ProductController代码
@RestController
@RequestMapping("products")
public class ProductController {
@Autowired
private IProductService productService;
@Value("${server.port}")
private String port;
@GetMapping("/{pid}")
public Product findById(@PathVariable Long pid){
Product product = productService.getById(pid);
product.setName(product.getName() + "—" + port);
return product;
}
}步骤4：调用订单保存的方法，查看日志.
可以看到不停的切换端口
Ribbon支持的负载均衡策略
默认情况下，Ribbon 采用ZoneAvoidanceRule的策略，判断server所在区域的性能和server的可用性选择具体的server
Ribbon内置了多种负载均衡策略，内部负载均衡的顶级接口为com.netflix.loadbalancer.IRule , 具体的负载策略如下图所示:
策略名 | 策略描述 | 实现说明 |
BestAvailableRule | 选择一个最小的并发请求的server | 逐个考察Server，如果Server被 了，则忽略，在选择其中ActiveRequestsCount最小的server |
AvailabilityFilteringRule | 先过滤掉故障实例，再选择并发较小的实例； | 使用一个AvailabilityPredicate来包含过滤server的逻辑，其实就就是检查status里记录的各个server的运行状态 |
WeightedResponseTimeRule | 根据相应时间分配一个weight，相应时间越长，weight越小，被选中的可能性越低。 | 一个后台线程定期的从status里面读取评价响应时间，为每个server计算一个weight。Weight的计算也比较简单responsetime 减去每个server自己平均的responsetime是server的权 |
RetryRule | 对选定的负载均衡策略机上重试机制。 | 在一个配置时间段内当选择server不成功，则一直尝试使用subRule的方式选择一个可用的server |
RoundRobinRule | 轮询方式轮询选择server | 轮询index，选择index对应位置的server |
RandomRule | 随机选择一个server | 在index上随机，选择index对应位置的server |
ZoneAvoidanceRule(默认) | 复合判断server所在区域的性能和server的可用性选择server | 使用ZoneAvoidancePredicate和AvailabilityPredicate来判断是否选择某个server，前一个判断判定一个zone的运行性能是否可用，剔除不可用的zone（的所有server），AvailabilityPredicate用于过滤掉连接数过多的Server。 |
我们可以通过修改配置来调整Ribbon的负载均衡策略，在order-server项目的application.yml中增加如下配置:
product-service: # 调用的提供者的名称
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule结语
到这，Ribbon实现的负载均衡操作就完成啦~好学的你肯定有很多问题，为啥贴了@LoadBalanced注解就能让RestTemplate实现负载均衡调用呢？不急，欲知后事如何，请听下回分解。
