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） 上找到其原始目的。
摘要其核心内容如下：

gitHub

springboot 有一个非常好用的监控和管理的源软件,这个软件就是spring boot admin,该软件能够将Actuator中的信息进行图形化的展示,也可以监控 Spring Boot 应用的健康状况,提供实时报警功能

主要的功能点有

pomxml

设置启动类

bootstrapyml注册到nacos(配置nacos地址,开启actuator全部端点,配置日志打印路径)

由于多种方法可以解决分布式Web应用程序中的身份验证和授权,因此SpringBootAdmin不会提供默认方法,默认情况下Spring-boot-admin-server-ui提供了登录页面和注销功能

添加配置

编写Security的配置

启动项目,即可看到登录页面,输入配置的账号密码登录,能看到注册的服务

页面还是挺好看的

由于Spring Admin Server UI 里有很多js和css,在我们上生产时,大多数选择nginx代理加重定向头的组合,这会是页面加载崩溃,找不到元素,所以我们要配置nginx代理的proxy_set_header 以及服务端跨域处理

在我们服务宕机或上线时可以自动触发邮件发送,需要提前开启邮件的imtp和smtp功能,请自行了解

pomxml

配置账号

手动停止一个服务看下效果,成功发送报警邮件

pomxml

启动类

client端相对简单,因为nacos自动帮我们整合了与admin的关联工作,只需要注册进nacos,并且与服务端保持在同一命名空间和分组下即可

bootstrapyml

一切就绪就可以在控制台看到我们的服务了

首先启动Nacos，按照上篇文章的步骤，启动Nacos服务和项目，访问Nacos的web页面。确保项目中的服务都注册到注册中心当中了。在applicationyml同级目录下添加bootstrapyml，在Spring boot项目中bootstrapyml会比applicationyml优先初始化，所以我们需要在bootstrapyml中引入Nacos官方指定的配置文件即可（上篇文章中已经把Nacos作为配置中心的配置写入了applicationyml，现在只需要把它从applicaitonyml中剪切出来即可， 其中的spring:application:name会作为Nacos中新增配置时的Data ID，需要留意 ），再新增属性gorup进行分组测试，如下图

接着打开Nacos的服务的web页面，打开配置管理->配置列表，点击右侧新增按钮，进行新增。
Data ID： bootstrapyml配置文件中spring:application:name对应的名称 ；
Group：指定分组（便于不同环境下的项目配置管理，因为笔者这里属于测试，所以填写的是和上文中的配置文件中group对应的test一致）；
描述：针对于该配置的描述；
配置格式：配置文件的格式，要和Data ID中的后缀格式一致（这里笔者用的是yml，那么下面就选择yaml，注意该位置也可以选择properties，但是必须和上面bootstrapyml文件中的file-extension的值相匹配）；
配置内容：具体的配置内容（这里笔者将项目中的applicationyml中的配置全部拷贝至其中）；

测试启动consumer服务，在applicationyml中为空的时候，项目启动端口还是如Nacos配置中的9011，说明项目依赖Nacos的配置中心成功，其他服务如法炮制即可：

新增一个测试Controller，然后加上@RefreshScope注解，表明该Controller中的配置数据为自动刷新 。

编辑Nacos中的配置文件consumer新增相关参数type: test，访问Controller，返回test。效果如下图：

将Nacos中consumeryml文件的type: test修改为type: prod，在不重启项目的情况下重新访问对应的controller，效果如下图：

因为Dubbo是属于各个服务之间都要公用的依赖，所以将其引入cloud-common当中，详细的版本可以去 mvnrepository 搜索合适自己项目的

引入依赖后需要编写消费者服务中的配置文件，将Dubbo服务注册至Nacos，新增如下内容，其中subscribed-services指的是生产者服务，prot：-1指的是端口随机，registry:address:指的是Dubbo对应的注册中心那这里就应该设置为Nacos

接下来新增接口服务，项目类型为Maven项目，在项目中新增一个接口。并在cloud-provider（生产者）和cloud-consumer（消费者）pomxml文件中都引入该模块

在生产者实际服务中实现该接口对应的方法

在服务消费者的Controller中引入该Service，并在该Service上加入@Reference注解，注意在引入jar包的时候选择带有Dubbo的，不要使用Jdk原生的

编写消费者服务中测试Dubbo调用的接口，进行测试，测试结果如下图：

参考资料 ：
《Spring Microservices in Action》
《Spring Cloud Alibaba 微服务原理与实战》
《B站 尚硅谷 SpringCloud 框架开发教程 周阳》

为方便理解与表达，这里把 Nacos 控制台和 Nacos 注册中心称为 Nacos 服务器（就是 web 界面那个），我们编写的业务服务称为 Nacso 客户端；

由于篇幅有限，这里将源码分析分为上下两篇，其中上篇讲获取配置与事件订阅机制，下篇讲长轮询定时机制；在 《微服务架构 | 22 Alibaba Nacos 的统一配置管理》 中提到一张 Nacos 动态监听的长轮询机制原理图，本篇将围绕这张图剖析长轮询定时机制的原理；

上篇 《微服务架构 | 24 Nacos 配置中心的源码分析（获取配置与事件订阅机制）》 中的 11 提到，ConfigService 是 Nacos 客户端提供的用于访问实现配置中心基本 *** 作的类，我们将从 ConfigService 的实例化开始长轮询定时机制的源码之旅；

近期由于搭建公司整套测试环境中使用Docker 容器化部署Dubbo一直出现找不到服务提供者
经过两天断断续续的摸索以及资料（说到这理要落泪了）的查询该问题得意解决这就是本次要扯的内容。

本次 dubbo 服务 是以docker-compose进行服务编排部署，服务者与消费者也在同一个Java 工程目录下

当我们服务者工程开启的时候会在Nacos中服务列表中产生新的一项接口其内容是这样的，根据下方的可以很清楚的看到IP及端口是不是有点似曾相识的感觉呢，特别是20880端口！
又经历了一资料的查询之后，我发现20800端口并没有被我映射出来。于是我把服务提供者配置文件改这样：

消费者配置文件改成这样

终于在我本地以及不同的服务器之间可以正常运行了！

其实如果不在测试环境上遇到这些问题以后在生产环境上也同样会遇到，我们能做的就是在问题到来之前做一定的知识储备避免一些常见的坑。

添加依赖。

注意：版本 02xRELEASE 对应的是 Spring Boot 2x 版本，版

本 01xRELEASE 对应的是 Spring Boot 1x 版本。

使用@NacosPropertySource加载 dataId 为 example 的配置源，并开启自动更新：

通过 Nacos 的 @NacosValue 注解设置属性值。

内容是 false。

为useLocalCache=true

curl -X POST " >

MODE：设置使用单机模式
注意：如果服务器是多网卡，配置NACOS_SERVER_IP参数来指定IP，否则可能会导致外网无法访问；

启动成功后，访问 >