SpringCloud 核心组件Nacos【NacosRule负载均衡&服务的权重设置】第3章

1，同集群优先的负载均衡

1，同集群优先的负载均衡

上一章节中，已经配置了两个集群，在提供方创建了三个实例服务，在消费方创建了一个实例服务，

提供方三个实例对象：分别属于BJ,JS集群

配置消费方集群在JS，修改消费方的application.yml文件中配置，配置集群JS(如下图)

目的：就是消费方配置和提供方两个实例服务的集群吻合，查看消费方会不会优先访问提供方的相同集群，从消费方发送请求到提供方看一下结果

连续访问了三次，发现并不会因为配置相同的集群环境，就去访问相同的集群，依然默认采用IRule负载均衡轮询的方式进行访问，要怎么做到优先访问同集群环境，我们在application.yml文件中加入一段配置，以用来达到此效果

service-consumer:

ribbon:

NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule

 @Bean
    NacosRule nacosRule() {
        return new NacosRule();
    }

重新访问之后，控制台优先访问相同环境的集群:8170和8270，然后进行随机访问策略。

那么问题来了非本地集群能否访问呢？下面我们把JS集群的两个实例进行关闭，只剩下BJ集群8888端口实例，来看看是否能够访问。

显示是可以访问的，当本地集群停止之后，会去访问非本地集群

总结：这里我们就可以知道nacosRule负载均衡的方式，通过配置nacosRule，可以优先访问相同集群中的实例，

如果相同集群中有好多个实例，再进行随机的策略进行访问实例，例如（JS集群中的8170和8270实例）

如果没有相同的本地集群实例，会去访问其他的集群实例例如：（BJ集群中的8888实例）

2，实例服务的权重配置

实际部署中会出现这样的场景：

服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。

但默认情况下NacosRule是同集群内随机挑选，不会考虑机器的性能问题。

因此，Nacos提供了权重配置来控制访问频率，权重越大则访问频率越高。

在nacos控制台，找到service-provider的实例列表，点击编辑，即可修改权重：修改一下8170端口实例的权重.

在弹出的编辑窗口，修改这个端口8170的权重为0.1，来看一下8170端口的访问频率是否降低：

现在测试一下，发二十次请求，看一下访问8170和8270的频率

这里可以看到调节完0.1的配置之后访问频率变低。

如果权重值调节为0，看一下会出现什么情况：

可以看到权重调低之后，8170这个实例相当于停止了

这种权重配置可以应用到服务的升级

例如：像每次游戏的更新中都会发布通告凌晨几点停机什么的搞得好像月黑风高要干坏事一样，nacos提供权重配置就可以做到平滑升级，在更新版本中，可以调节一个服务的实例权重配置为0反正开启这多个服务也不影响，进行升级，其他服务正常开启不影响用户的体验，在权重为0的服务中进行版本的更新，等更新完毕之后调节权重高一点为0.几几可以放进来一批用户进行体验测试，如果没有问题加大该服务的权重值，进行其他服务权重的降低依次进行更新升级，这样就能做到用户无感知，平滑升级，非常的优雅！！！

3，环境隔离

nacos首当是一个注册中心但nacos也是个数据中心，在nacos中为了做数据和服务的管理，nacos存在环境隔离这一个概念

Nacos中服务存储和数据存储的最外层都是一个名为namespace的东西，用来做最外层隔离

有人会说既然把服务实例划分为集群，然后又服务，像这种划分是基于地域或者说业务上的划分，事实上，我们平时还有开发环境，生产环境，以及测试环境变化呢！这就算是一种归于环境变化上的隔离，

Namespace就是在做这件事情

Group组：我们可以把业务上相关度比较高的服务放在一个组中

这是一个概念上的划分，这不是说必须要用，可以在设计的时候用Namespace或者Group，也可以不用

3.1：创建namespace

来nacos，web控制台

可以看到Group ，因为平时也不怎么配分组，一直都是默认分组，那么NameSpace在哪？

演示一下NameSpace的使用

在左侧命名空间：

我们可以看到有个public（保留空间）也就是nacos默认产生的空间，在你没有设置空间，创建的服务都在public中

默认情况下，所有service、data、group都在同一个namespace，名为public：

然后，填写表单：

就能在页面看到一个新的namespace：

3.2：给微服务配置namespace

给微服务配置namespace只能通过修改配置来实现。

例如，修改service-consumer服务的application.yml文件：

spring:
  application:
    name: service-consumer          #服务名
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848   #nacos服务地址
        cluster-name: JS  #配置集群名称 例如：JS ,江苏
        namespace: 187063b4-f61a-4fb0-bcf4-a884c8d7ffd5  # 命名空间，填ID
    sentinel:
      transport:
        dashboard: 127.0.0.1:18080

重启service-consumer后，访问控制台，可以看到下面的结果：

此时访问service-consumer ，因为namespace不同，会导致找不到service-provider，控制台会报错：

4，Nacos与Eureka的区别

Nacos的服务实例分为两种l类型：

临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。
非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。

配置一个服务实例为永久实例：

spring:
cloud:
nacos:
discovery:
ephemeral: false # 设置为非临时实例

Nacos和Eureka整体结构类似，服务注册、服务拉取、心跳等待，但是也存在一些差异：

Nacos与eureka的共同点
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别
- Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
- 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
- Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
- Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式