Spring Cloud 之 Nacos

本篇主要介绍另一种更为流行的注册中心Nacos的相关使用。

一、Nacos的安装

Nacos是阿里推出的一种注册中心组件，并且已经开源，目前是国内最为流行的注册中心组件。下面我们来了解一下如何安装并启动Nacos。

Nacos是一个独立的项目，我们可以去GitHub上下载其压缩包来使用，地址如下：

https://github.com/alibaba/nacos/releases/tag/2.2.3

大家觉得下载的太慢，也可以使用百度网盘进行下载（提供了一个2.2.3版本的Nacos压缩包），链接如下：

链接：https://pan.baidu.com/s/1lpgkP0dxnGTOHsZX9xqB5A
提取码：oxc4
--来自百度网盘超级会员V1的分享

下载完成之后解压缩，打开Nacos下的bin文件夹，我们可以看到下面这四个文件

我们可以依据自己机器的环境选择要运行哪个启动脚本，但需要注意的是，Nacos默认是集群启动，如果你当前是单机环境进行启动，运行脚本会闪退。如果我们想进行单机启动，需要修改一下相关配置。下面，我们来了解一下Windows环境下修改的方式：

首先我们用记事本打开start.cmd文件，找到下面这行配置

将cluster改为standalone后保存退出，此时再运行启动脚本，就能正常启动Nacos了

并且nacos默认是使用Nacos端口，如果我们想修改这个端口，需要打开{Nacos文件夹所在目录}/conf/applictaion.preperties文件，并将下面这行配置代码的端口改为自己想要设置的端口 需要注意的是端口号必须是未被使用的，否则启动时会因为端口已被占用而启动失败。

成功启动Nacos后，我们可以通过浏览器来访问{Nacos所在机器Ip} :{Nacos端口号}/nacos，用来获取一个nacos的可视化管理页面。

二、Nacos的使用

下面我们来了解一下如何使用Nacos。

服务注册

将服务注册到Nacos，我们需要在各服务父工程中的pom文件中的<DependeceMannager>中声明Spring Cloud Alibaba的相关依赖， 需要注意的是其版本需要与你当前的spring boot版本进行兼容，两者之间的兼容关系大家可以去官网上查询。然后在各服务的pom文件中引入Nacos的相关依赖，具体可以参考下面的代码

<dependency>
 <groupId>com.alibaba.cloud</groupId>
 <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

然后我们需要去设置Nacos的相关配置

配置好之后我们就可以启动服务了，成功启动后就能在前面的Nacos的服务列表中看到我们注册的服务了 Nacos对比Eureka，Nacos的功能要更为丰富，下面我们来具体一下。

权重

Nacos可以为服务分配权重，权重越高的服务，在进行负载均衡时被选中的概率就越大。在Nacos提供的网页中，我们可以去设置服务的权重。这里我们先启动三个product-service服务（由于机器不足，都部署到一台机器的不同端口上了），并注册到Nacos中

然后点开服务最右边的详情页，可以看到具体的三个服务实例，然后在点击实例右边的编辑按钮

在弹出的页面里我们就可以自己去编辑权重的大小了.这里我们把9092端口的服务权重设置成1，其它的设置为0.1

设置完成之后，权重并不会立马生效，因为这里权重的配置可以说算是一种负载均衡策略，而我们本地服务的负载均衡策略使用的是LoadBalance默认的轮询策略（这里需要提前开启负载均衡，详细请看我的上一篇文章），因此要想让权重生效，我们需要通过修改配置文件将负载均衡策略调整为Nacos的负载均衡策略，具体配置参考下面的代码：

spring:
 cloud:
  loadbalancer:
   nacos:
    enabled: true

配置完成后，Nacos的负载均衡策略就生效了，我们刚才配置的权重也随之生效了。

下面 我们来访问一下order-service的接口（这个接口会远程调用product-service，并在调用的服务中打印一条信息）。

打印的结果如下：

可以发现9092端口的product-service服务被调用的次数要远远多于另外两个服务。

服务下线

在Nacos中可以让一个服务下线，一个服务下线后，在其它服务进行服务发现时，就不会在获取这个已下线服务的信息，也就不再会被远程调用到。在Nacos中下线一个服务非常简单，只需要在Nacos网页服务列表中找到要下线的服务，打开详情页，选择要下线是实例进行下线即可

在这里，我们下线9092端口的服务，此时我们再多次访问order-service的接口，各服务实例的控制台如下：

可以发现9092端口的服务一次都没有被调用了。然后我们再让其上线看看，还是再刚刚下线的地方上线，再进行几次接口访问，可以发现，9092端口的服务又被调用到了

同集群优先

在进行服务调用时，服务的提供者和服务的调用者如果在同一个机房或者同一个地区会比在不同机房不同地区受到网络的影响要小很多，因为网络的延迟通常是与距离成正比的。因此Nacos提供了一种同集群优先的负载均衡策略，在这种策略下，Nacos会把不同服务按地区分为不同集群，并在进行服务调用时，优先调用同一集群的服务，例如上海集群中的服务在进行服务调用时，会优先调用上海集群中的服务。下面我们来具体了解一下如何使用同集群由先：

首先我们需要在服务的配置文件中设置服务集群名称，具体可以参考下面的代码：

spring:
 cloud:
  nacos:
   discovery:
    server-addr: 110.41.51.65:10020
    cluster-name: SH #集群名称: 上海集群 

然后启动服务，当前服务就被设置为在上海集群中了。

接下来我们通过添加VM opition的方式将我们的9091.9092端口的product-service的服务设置为在上海集群，将9093设置为在北京集群,具体的设置方式可以参考下图一个一个设置

设置完成后，重启服务打开Nacos，就能看到上海和北京两个集群中的实例信息了 此时我们再多次访问order-service的接口（SH集群），控制台的信息如下：

9091（SH集群）

9092（SH）

9093（BJ)

可以发现与order-service在同一集群中的9091.9092服务都有被调用，而不同集群中的9093则一次没有被调用。 但也并不是说完全不会调用其它集群中 的服务，如果调用的服务在当前集群中没有，也是会去调用其它集群中的服务的。例如，我们把9091.9092下线，再访问几次接口

通过控制台可以发现9093也被调用到了

健康检查

Nacos会对注册的服务进行健康检查，具体来说就是去检查看看服务还能不能被访问到。Nacos健康检查的机制有两种，具体如下：

• 客户端主动上报：服务主动向Nacos发送心跳来告知健康状态，一般5s上报一次，如果超过15s未上报，该服务会被标记为不健康状态，超过30s则会被直接删除。
• 服务端反向探测 ：Nacos主动探知服务进行健康检查，间隔20s探测一次，如果检查失败，则会被标记为不健康状态，并不会直接删除

Nacos具体使用哪种机制依据当前服务实例的类型。下面 ，我们来了解一下服务实例的类型。

服务实例类型

在Nacos中，服务实例有两种类型，一种是临时实例，一种是非临时实例。临时实例在处于非健康状态时，会被删除，而非临时实例在非健康状态时则不会被删除，而是会被标记为非健康。因此，临时实例使用客户端主动上报的健康检查机制，而非临时实例则是使用服务端反向探侧。

我们可以在服务的配置文件中来配置当前服务是临时实例还是非临时实例，具体配置参考下面的代码

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

接下来我们将product-service全设置成临时实例，oreder-servie设为非临时实例，Nacos网页中的显示如下：

此时，如果我们终止一个product-service，再次查看Nacos网页可以发现，product-service只剩下两个了

而我们终止order-service，再次查看网页，可以发现order-service仍然还在，只是健康状态为false了

需要注意的是Nacos服务实例的类型一旦确定就不能再更改了，因为Nacos会保存每一个服务对应的实例类型，如果服务以不同于先前的实例类型启动（修改了ephemeral配置再启动），就会报错，解决办法有两种，一种是直接重启Nacos，一种则则是删除nacos目录下/data/protocol/raft这个文夹这里面报存的服务的元数据。

环境隔离

在企业中，一个服务的开发通常会经历三个环境，开发环境（dev) ,测试环境（test），生产环境（prod）。处于不同环境下的服务之间是不能够进行调用的，因此要对不同环境下的服务进行环境隔离。

在Nacos中通过Namespace（命名空间）来实现环境隔离，默认情况下所有注册的服务都位于public命名空间中，我们可以自己创建一个命名空间，具体流程如下：

打开Nacos网页，选择命名空间

点击新建命名空间

在弹出来的页面就可以自定义创建我们的命名空间了

这里我们创建两个命名空间，一个dev，一个prod

接下来我们需要将我们的服务分配到这些命名空间中，具体为设置以下配置：

spring:
 cloud:
  nacos:
   discovery:
    namespace: 51152a13-7911-49e3-bbdc-16fd5670a257

这里namespace的值为Nacos自动生成的命名空间id，可以去前面的命名空间页面查看。

接下来我们将9091.9092的product-service服务和order-service放到dev命名空间中，剩下的9093端口的product-service放到prod服务中

此时再多次调用order-service的接口，三个product-service服务的输出信息如下：

9092 9091

9093

可以发现和order-service 同样位于dev命名空间中的9091.9092端口的product-service服务被调用到，而位于不同命名空间的9093则一次都没用被调用到。

配置中心

Nacos除了上面的功能以外，还能作为配置中心进行使用。什么是配置中心呢？我们来了解一下。

在微服务项目中，同一个服务通常会采取集群模式部署到多台主机上，当服务的配置需要修改时，如果一台一台机器去修改，就会显得十分的麻烦，如果有一个统一的组件能够让我们在组件上修改配置，并将修改的配置信息推送到各个相关的服务主机上，那就会高效很多，而配置中心就是这样一个组件。Nacos中就提供了配置中心的功能。

我们可以在Nacos中添加配置，添加的具体步骤如下

打开Nacos中的配置列表页，点击创建配置

在弹出的页面，就可以自定义我们的配置了

这里的DataId暂且设置为服务名称，配置格式选择为properties，命名空间为我们前面的dev

设置完成后点击发布，就能看到我们刚才设置的配置了。

下面我们来看一下如何在服务端获取Nacos中的配置。

首先我们需要在服务中引入Nacos配置中心的依赖，具体如下：

<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>

然后我们需要再创建一个bootstrap配置文件，这个文件会在appliaction前缀的配置文件被加载之前被加载，在这个文件中，我们需要去配置Nacos作为配置中心的相关信息。在服务启动前，会先去读取bootstrap前缀的配置文件，然后根据里面的配置内容去Nacos中获取Nacos中的配置并整合到我们的application前缀的配置文件中。

下面我们来看一下bootstrap中的具体配置：

spring:
 application:
  name: product-service
 cloud:
  nacos:
   config:
   server-addr: 110.41.51.65:10020

这里主要配置了两个信息一个是服务名称，一个则是Nacos配置中心地址，这个地址与Nacos注册中心的地址配置是隔离的。

下面我们通过@Value去获取一下这个配置信息，代码如下

接下来我们来访问一下这个接口

通过控制台的输出可以发现，在Nacos中设置的配置已经读取到服务的配置文件中了。

在Nacos中配置中心也是有命名空间的，在前面创建配置时也能看到当前创建的配置位于哪个命名空间中，因此我们在去获取配置时，需要去指定命名空间，如果不指定，就只能从默认的命名空间（public）中去获取配置。指定命名空间的配置如下（在bootstrap中配置）：

spring:
  application:
   name: product-service
  cloud:
   nacos:
    config:
     server-addr: 127.0.0.1:8848
     namespace: c419711e-7909-43fe-a047-36a348350142

配置好后，就会去指定的命名空间下去获取配置了。

在获取配置时，并不是命名空间中创建的所有配置文件都会去获取，只会去获取对应DataId的配置，这个Dataid有固定的格式

${prefix}-${spring.profiles.active}.${file-extension}

其中prefix默认为服务名称，也可以通过 spring.cloud.nacos.config.prefix来配置。

spring.profiles.active为服务当前所处环境，可以通过spring.profiles.active配置项配置，这部分内容可以为空，为空时前面的‘-’会消除

file-extension为读取的配置格式，可以不设置，不设置为默认的properties，可以通过spring.cloud.nacos.config.file-extension配置项来配置，不过只支持yaml何properties两种

需要注意的是上面的配置项在设置时，只能在bootstrap前缀的配置文件中设置

服务在去Nacos中获取配置时，会获取下面这三种DataId的配置内容${prefix},${prefix}-${spring.profiles.active}.${file-extension} 和${prefix}.${file-extension} 。

在Nacos中如果不止存在这三种DataId的配置文件中的一个，则会根据优先级选择一个来获取，优先级为 ${prefix}-${spring.profiles.active}.${file-extension} > ${prefix}.${file-extension} > ${prefix}