一、Nacos负载均衡体验
- 在注册中心Nacos（单机部署）中，由于使用的Nacos版本是2.2.1所以手动引入了
loadbalancerspringcloud组件用于服务调用方解析服务名正确调用对应服务。本次学习就以loadbalancer默认使用的轮询负载均衡策略来进行初步体验。
关于SpringCloudAlibaba官网维护的Ribbon负载均衡器后面结合自定义负载均衡策略再学
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-loadbalancer</artifactId>
</dependency>
- 为了直观的观察负载均衡的效果，我们需要在原来的订单-库存案例中添加多个库存服务供订单服务调用，利用IDEA编辑器，我们无需复制多个订单模块修改端口启动，以下是用同一份代码，在多个端口上运行库存服务的步骤：
-
复制库存服务运行配置
复制库存服务运行配置 - 修改配置名称，同时新版本IDEA针对springboot项目覆盖端口配置需要勾选
Modify options中的Override configuration properties
修改配置名
勾选覆盖springboot配置参数选项 - 覆盖springboot
yml文件中的端口配置
覆盖端口配置 -
启动新的库存服务
新的库存服务
5.观察Nacos控制台，库存服务实例及健康实例数据都得到了更新
Nacos控制台服务列表
- 修改库存服务代码，增加端口输出，便于识别订单服务调用的是哪一个库存服务
@RestController
@RequestMapping("/stock")
public class StockController {
@Value("${server.port}")
private String port;
@RequestMapping("/reduct")
public String reduct() throws InterruptedException {
System.out.println("扣减库存");
return "扣减库存:"+port;
}
}
- 观察负载均衡效果，这里借助压测工具JMeter进行服务调用，同时观察库存服务调用情况
-
设置线程组，1秒钟创建10个线程访问循环1次
JMeter线程组设置 -
设置HTTP本地订单服务请求
HTTP请求配置 -
观察结果树，发现10次请求对库存服务是进行轮流访问
结果树
结果树
二、Nacos雪崩保护体验
-
观察服务详情
Nacos服务列表
服务详情
基于上面已经有的两个库存服务实例，那什么是服务雪崩呢？
服务雪崩也就是假设两个服务实例都最多能同时处理10个线程请求，当一个服务实例出现异常，导致之前本应该请求到该异常服务实例的请求， 请求到其他正常服务实例，导致正常服务实例超出最大处理线程数，进而出现处理速度下降，最终导致服务宕机，同时进一步扩散至整个库存服务，导致库存服务整体无法使用的情况。
那什么是服务雪崩保护呢？
Nacos的服务雪崩保护也就是：当服务出现异常导致无法处理请求时，会判断出现异常的服务数量有没有达到保护阈值
- 如果没有则将请求分发到其他正常服务实例中进行处理
- 如果达到保护阈值则将请求正常分发到所有服务实例中，包括异常实例，至于异常实例接收到请求怎么处理，可以结合
sentinelSpringCloudAlibaba组件进行服务降级或者熔断快速失败等处理。
目前需要解决的一个问题就是将服务实例由临时实例改为永久实例，因为临时实例在服务下线的时候会直接删除实例信息，这样就永远不会达到保护阈值，就不会触发服务雪崩保护。
- 更改库存实例为永久实例
-
在Nacos控制台创建服务
创建服务 - 在库存服务文件中设置属性
ephemeral为false，注意：必须先在控制台创建服务否则会抛出异常
库存服务配置文件 -
启动永久库存服务实例（永久实例一旦注册到Nacos中，就不会被删除）
服务列表
服务详情
- 测试服务雪崩保护
-
调整保护阈值为0.4，关闭一个库存服务实例
服务详情
通过观察服务列表信息就可以看到未触发保护阈值，此时所有请求应该都是请求到健康实例上
服务列表
JMeter测试结果 - 调整保护阈值为0.6，关闭一个库存服务实例
服务详情
通过观察服务列表信息就可以看到已经触发保护阈值，此时请求应该有成功请求到健康实例的也有请求到异常实例的，注意：Nacos在重新配置保护阈值后需要整体刷新一下Nacos控制台，否则有可能阈值未生效
服务列表
JMeter测试结果
