Springcloud + nacos + gateway 负载均衡(ribbon)

Ribbon是客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用

负载均衡,英文名称为Load Balance,其含义就是指将负载(工作任务)进行平衡、分摊到多个操作单元上进行运行,从而协同完成工作任务。 负载均衡构建在原有网络结构之上,它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性

本文主要测试，在Springcloud + nacos + gateway基础上，如何实现负载平衡

前面我们已经整合了Springcloud + nacos + gateway，实现了，当启动3个provider时候，通过gateway,可以对该3个provider进行轮询

1 nocas负载均衡。

   a nocas本身已集成了ribbon，默认使用轮询的方式

   b 在nocas设置weight,实现权重的方式

   c 自定rule(IRule实现类)

   d 顺提，在权重的方式下，可使用先设置权重为0，再关闭单一服务的方式，优雅地下线服务

2 使用ribbon直连ip

   a 使用ribbon提供的自动策略，轮询，随机等

   b 健康检查

   v 自定义rule

关掉其中一个provider，立即通过gateway进行轮询，发现gateway仍然会call已经down掉的provider，导致查询失败。但在大约5秒后，轮询恢复正常，不再call已经prodiver

gateway call provider首先经nacos注册中心，nacos心跳机制默认每5秒钟检查一次provider是否正常，因此就会出现上面现象。

1 在启动类，将配置类 将IRule 的实现类注册到spring容器中即可

2 分别测试轮询和随机，可正常按规则负载

1 增加gatewayriboonip模块

2 pom添加依赖spring-cloud-starter-gateway和spring-cloud-starter-netflix-ribbon

3 修改applicationyml，设置负载均衡

4 启动，测试可正常进行轮询

5 修改applicationyml 如下，可测试到从轮询方式变成了随机的方式

   NFLoadBalancerRuleClassName: comnetflixloadbalancerRandomRule

这个时候down掉一个provider，然后轮询，到这个provider时候，会一直查询失败。我们需要增加一个健康检查处理，在服务down掉的时候，可感知到并将该服务从服务列表去除，在服务上线后，可检查到服务已上线

1 增加健康检查

   provider模块增加rest接口HealthController

   增加config类，产生RestTemplate

   增加健康检查类HealthExamination implements IPing。继承IPing接口，判断服务是否可用。我们在微服务中增加heath接口，在gateway中调用该接口，如果返回正常则认为微服务可用。

    修改applicationyml 增加Ping如下

          NFLoadBalancerPingClassName: comroyspringnacosgatewayribboniploadBalanceHealthExamination

2 重启provider和gateway，进行测试

   a 轮询成功

   b down掉其中一个provider，轮询到该provider时候，查询失败

    这里测试未能成功，使用RoundRobinRule还是一直出现查询失败，未能自动skip掉down掉的provider

   但是自定义LoadBalancerRule的话，是能够成功skip掉down掉的provide的

1 增加MyRule extends AbstractLoadBalancerRule

2 重启后，测试成功按规则查询

最近有项目组同学问到为什么自己配置了nacos，但配置不生效？我简单看了下，发现问题出在相关配置的优先级模式不同。

spring-boot项目，有bootstrap、application两个配置文件，结合profile，和支持的文件格式properties、yaml，已经有6个配置文件了。然后使用了spring-cloud-starter-alibaba-nacos-config 后，又提供了三级配置。这些配置之间的组合关系，将在无形中影响配置的效果。很多同学只知道其中的一种，因此在无意识引入两种或以上的配置后，就会发现有奇怪的配置不生效问题发生。

spring-boot项目依赖bootstrapyml 用于应用程序上下文的引导阶段，由父Spring ApplicationContext加载，其工作的阶段为父ApplicationContext 被加载到使用applicationyml的之前。也就是说 bootstrap 加载优先于 applicaton。

bootstrap 主要用于从额外的资源来加载配置信息，还可以在本地外部配置文件中解密属性。这两个上下文共用一个环境，它是任何Spring应用程序的外部属性的来源。bootstrap 里面的属性会优先加载，它们默认也不能被本地相同配置覆盖。

bootstrap 配置文件有以下几个应用场景：

由于spring-boot支持多种文件格式，所以多种格式之间，其优先级是平等的，只要找到了一个，就会被使用。一般有：properties、yaml、xml等格式。

应用级别的spring-boot配置文件，主要用于 Spring Boot 项目的自动化配置，其加载优先级低于bootstrapyaml。

nacos作为外部配置服务器，通过spring-boot的bootstrapyaml引入。但nacos本身，也提供了三级配置体系：主配置(只有一个，但会按照不同后缀名，去找到相关配置）、扩展配置、共享配置。

三级配置的优先级如下：主配置 > 扩展配置 > 共享配置

nacos提供的配置路径 springcloudnacosconfig 下，有一系列的属性用于定位主配置。基于 prefix（默认为 ${springapplicationname} 的值）、namespace、group（默认为字符串 DEFAULT_GROUP ）、file-extension（默认为字符串 properties ），按组装规则 ${prefix}-${springprofilesactive}${file-extension} 去找到一个配置。

在nacos的所有配置中，主配置（存在的情况下）具有最高的优先级，其同名配置值不能被扩展配置或共享配置中定义的同名属性所覆盖。

上述两类配置都支持三个属性： data-id 、 group （默认为字符串 DEFAULT_GROUP ）、 refresh （默认为 true ）。

实际上，nacos中并未对 extension-configs 和 shared-configs 的差别进行详细阐述。我们从他们的结构，看不出本质差别；除了优先级不同以外，也没有其他差别。那么，nacos项目组为什么要引入两个类似的配置呢我们可以从当初 该功能的需求（issue） 上找到其原始目的。

摘要其核心内容如下：