在生产环境比较恶劣的情况下，我们需要通过负载均衡对服务的流量分散到多个服务器中，避免单点故障，而Nacos支持多种负载均衡策略，包括权重，同机房，同地域，同环境等。
1.服务下线
当一个节点上接口的性能较差时，我们可以第一时间对该节点进行下线，等排查完故障后，我们在上线该节点
操作步骤：详情->下线
下线端口号为9091的接口后，当再进行访问订单服务后，发现通过IDEA日志发现该服务没有接收到请求
再次点击上线端口为9091的节点，接着多次访问订单服务，观察运行日志，发现端口号为9091的节点又可以重新接收请求
2.权重配置
2.1 权重配置
除了下线接口性能较差的节点之外，我们还可以配置这个节点的流量权重
操作步骤：找到对应的节点->编辑->在弹出的窗口修改权重值
2.2 开启Nacos的负载均衡策略
如果我们仅仅是在Nacos修改了权重配置，这样是不生效的。
因为Spring Cloud LoadBalance组件自身有负载均衡的配置方式，所以不支持Nacos的权重属性配置，我们需要开启Nacos的负载均衡策略，让权重配置生效
我们需要在服务消费者（订单服务）的配置文件中添加一下配置，如下图
修改完配置后记得重新启动服务，然后继续多次访问订单服务，此时观察日志发现端口号为9090的节点接收到的请求流量就会明显减少
2.3 常见问题
修改权重配置时，可能会出现下图的报错日志
原因：Nacos采用raft算法来计算Leader，并且会计算前一次启动的集群环境，当服务器的IP改变时会导致raft记录的集群地址失效，导致Leader出现问题（网络环境发生变化时，IP地址可能会发生变化）
解决方法：删除Nacos根目录下data文件中的protocol文件夹中的raft文件夹，如下图
3.同集群优先访问
Nacos把可以把同一个机房内的实例，划分为一个集群，所以同集群优先访问，在一定程度上也可以理解为同机房的实例优先访问
在微服务架构中，一个服务通常可以由多个实例共同提供服务，这些实例可以部署在不同的机器上，这些机器也可以分布在不同的机房，比如produc-service
实例1和实例2部署在上海机房，而实例3部署在北京机房
微服务访问时，应尽量访问同机房的实例，当本机房实例不可用时，才去访问其他机房的实例
比如order-service服务在上海机房，product-service在北京和上海都有实例，当使用订单服务时，希望优先访问上海机房，如果上海机房没有实力或者实例不可用，订单服务在去访问部署在上海机房的产品服务。
通常情况下，希望优先访问同一个机房间的服务，因为同一个机房属于一个局域网，局域网的访问速度更快一点
3.1 给实例配置集群名称
通过在添加一下配置来实现
注意：也要添加配置开启Nacos的负载均衡策略，如果之前添加过开启Nacos负载均衡策略的配置，这次就不用再次配置了
此时，就发现有一个product-service的实例是在名字为BJ的集群中的，而orders-service服务也是配置在BJ集群
此时，再去调用订单服务时，订单服务就会先优先访问与自己在同一个集群中的产品服务
此时，在将端口号为9091和9092的产品服务放在SH集群中
通过观察Nacos主页发现成功将端口号为9091和9092的产品服务放在SH集群中，当我们将部署在BJ集群的产品服务下线后，这时候再去调用订单服务时，此时订单服务访问的就是部署在SH集群中的产品服务
4.Nacos检查机制
Nacos作为注册中心，需要感知服务的健康状态，才能为服务消费者提供良好的服务，Nacos中提供了两种健康检查机制：
1.客户端主动上报机制：
1.服务注册方通过上传心跳的上报方式告知Nacos注册中心自己的健康状态，默认心跳的间隔为5秒
2.如果Nacos在15秒内没有接收到来自服务注册方的心跳，会将该服务的健康状态设置为不健康状态，如果Nacos没有接收心跳的时间间隔超过30秒，Nacos就会将该注册的服务删除。
2.服务端反向探测机制：
1.Nacos主动探知客户端的健康状态，默认间隔为20秒
2.健康检查失败后对应注册在Nacos的服务会被标记为不健康的状态，不会立即被删除
但是Nacos中的健康检查机制不能主动设置，健康检查机制是和Nacos的服务实例类型强相关的
4.1 Nacos服务类型实例
Nacos的服务实例（注册的服务）分为临时实例和非临时实例
临时实例：如果该注册的服务宕机超过一定时间，会从服务列表中删除，这是向Nacos注册服务时默认的实力类型
非临时实例：如果实例宕机，不会从服务列表中删除，也可以叫永久实例
Nacos对临时实例采取的是客户端主动上报机制，对非临时实例采取服务端反向探测机制
4.2 配置永久实例
只需要给注册的服务类型添加一下配置即可
重新启动服务，观察Nacos服务列表
去IDEA停止服务，再去观察Nacos服务列表，发现即使停止服务，注册在Nacos中的服务也不会从服务列表中删除
4.3 常见问题
Nacos服务实例类型是不允许改变的，此时如果直接增加上面的配置，重新启动该服务，就会包下图的错误
原因：因为Nacos会记录每个实例的IP和端口号，当发现IP和端口号都没有发生变化时，Nacos不允许服务类型发生变化，比如从临时实例变为非临时实例，或者从非临时实例变成临时实例
解决方法：
1，先停掉Nacos
2，删除nacos目录下的/data/protocol中的raft文件夹，raft文件夹里面会保存应用实例的元数据信息，注意如果你访问的是云服器上的Nacos，就去删云服务器上的raft文件夹，如果是本机上的Nacos，就去删除本机上的raft文件夹，路径都是一样的
5. Nacos环境隔离
在开发中，一个服务会分为开发环境，测试环境和生产环境，我们希望开发环境的服务只能访问开发环境中的服务，不能跨环境访问
Nacos中提供了namespace（命名空间）来实现环境的隔离，不同的namespace的服务之间不可相互访问
先在Nacos创建几个环境，如下图
新增命名空间
在服务列表页面就可以看到三个环境了
配置namespace
namespace创建完成后，对服务进行配置 ，如下图
重新启动服务，发现两个服务都被部署在了test的环境下
进行测试：发现服务调用成功
测试不同环境下能否访问成功：
public环境下只有product-service服务
dev环境下只有order-service 
此时去访问订单服务，会出现下图的报错
通过实验证明，在Nacos中，不同环境下的服务是不可相互调用的。
6.Nacos配置中心
除了注册中心和负载均衡之外，Nacos还是一个配置中心，具备配置管理的功能
为什么需要配置中心呢？
我们当前的代码有一个问题，就是我们的配置都是写在代码里面的，当我们需要对配置进行修改时，就要对代码的配置文件进行修改，然后重新打包和上线，且一个微服务中可能有成百个实例，挨个部署容易出错
配置中心就是对这些配置项进行统一管理，通过配置中心，可以集中查看，修改和删除配置，无需再逐个修改配置文件，提供效率的同时，也降低了出错的分险
6.1配置中心的工作流程
1.服务启动时，从配置中心读取配置项的内容，进行配置的初始化
2.当配置中心的配置项发生改变时，配置中心会通知微服务，实现配置的更新加载
6.2Nacos配置中心的快速上手
1.添加配置
在Nacos控制台中添加配置项
注意事项：配置管理的命名空间和服务列表的命名空间是隔离的，两个是分别设置的，默认都是public，也就是服务列表的命名空间≠配置管理的命名空间
新建配置项
2.获取配置
1.在对应项目中的pom文件中引入下面的依赖
XML
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
<!-- SpringCloud 2020.*之后版本需要引⼊bootstrap-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>2.增加bootstrap.propertities配置文件
微服务启动前，需要先获取Nacos中的配置，并于application.yml配置合并，在微服务启动前，Nacos要求必须使用bootstrap.properties配置文件来配置Nacos Server地址
3.编写controller层代码
java
@RefreshScope
@RestController
public class NacosController {
@Value("${nacos.config}")
private String config;
@RequestMapping("/getConfig")
public String getConfig(){
return "从Nacos中获取配置信息nacos.config："+config;
}
}
4.测试接口
发现获取配置成功
此时，修改配置中心的配置，刷新发现此时也成功获取修改后的配置信息
3.常见问题
1.配置格式出现错误
此时访问接口时会出现下面的报错
此时如果重新启动服务则会出现下图的报错
2.未引入相关依赖
出现下图的报错
原因：bootstrap.properties是系统及的资源配置文件，用于程序执行更加早期配置信息读取，但是SpringCloud2020.*之后的版本把bootstrap禁用了，导致在读取文件时读取不到而报错，此时将bootstrap包重新导入进来进行了
6.3配置中心详解
1.设置命名空间
Nacos配置中心的命名空间和服务列表的命名空间是分别设置，默认都是public，Nacos命名空间的配置依然是在bootstrap.properties文件中进行配置
添加一下配置
重启服务，接着去获取Nacos配置中心的配置，此时就是从test环境下获取配置
2.Data Id详解
Data Id格式介绍
在Nacos Spring Cloud中，Data Id的完整格式如下：
{prefix}-{spring.profiles.active}.${file-extension}
信息介绍
1.prefix默认为spring.application.name的值
2.spring.profiles.active对应当前环境的profile，当spring.profiles.active为空时，对应的连接符-也将不存在，dataId的拼接格式变成{prefix}.{file-extension}
3.file-extension为配置内容的数据格式，现在只支持yaml和properties这两种格式
当微服务启动时，会从Nacos中读取读个配置文件，我们可以通过启动服务时的日志来观察
要想读取product-service.properties和product-service-test.properties里面的配置信息，需要在bootstrap配置文件中添加下面的配置
这三个配置文件的读取的优先级为：
product-service-test.properties>product-service.properties>product-service
实验证明
有这3个配置文件时，从Nacos中获取配置时
在Nacos中 product-service-test.properties配置
然后从Nacos中删除product-service.properties
