Nacos配置成系统服务，开机自动启动及注意事项

设置开机启动

vim /lib/systemd/system/nacosservice

[Unit]

Description=nacos

After=networktarget

[Service]

Type=forking

ExecStart=/usr/local/nacos/bin/startupsh

ExecReload=/usr/local/nacos/bin/shutdownsh

ExecStop=/usr/local/nacos/bin/shutdownsh

PrivateTmp=true

[Install]

WantedBy=multi-usertarget

--------------------------------------------------------------------------------------

如果是单机模式这个语句需要修改为如下

ExecStart=/usr/local/nacos/bin/startupsh -m standalone

保存后执行以下命令

systemctl daemon-reload

systemctl enable nacosservice

systemctl start nacosservice

如果报错：

nacosservice: Service hold-off time over, scheduling restart

是service启动文件没有加载进来  需要重启系统 reboot   就可以了

注意事项：

需要修改/usr/local/nacos/bin/startupsh 中的一个参数

原：

修改后：

保存后就不会启动是报错了。

首先启动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 Gateway通过集成nacos实现路由动态配置，达到不重启API网关实现动态暴露内部微服务接口的目的。主要流程如下：

一、创建Maven项目test-gateway, pom文件如下：

二、创建启动类Apllicationjava，内容如下：

三、创建网关调用nacos配置类GatewayConfigjava

四、创建动态路由管理服务

1、创建动态路管理类DynamicRouteServiceImpljava

2、创建通过nacos对路由动态管理类DynamicRouteServiceImplByNacosjava

1、test_gateway_commonsyml配置文件内容下：

2、JSON路由配置文件gateway_dynamic_router的内容如下：

通过以上步骤就实现了Spring Gateway集成nacos实现路由动态配置的功能。以后只要修改gateway_dynamic_router 文件就可以实现服务的微服务的接口暴露和下线功能。

demo代码地址如下：>

这里分析下Nacos Config在Spring Cloud下的使用。整体调用链路如下表所示。

加载了springcloudnacos相关配置，生成NacosConfigProperties。

初始化了NacosConfigManager，主要是根据NacosConfigProperties初始化了ConfigService，这个也是Nacos Client 对外保留的核心对象，用于获取配置，添加监听等。

用于初始化了NacosPropertySourceLocator对象，实现了PropertySourceLocator接口，用于加载额外的配置信息。

加载分布式的配置，形如springcloudnacosconfigshared-configs[0]=xxx 的配置。

加载扩展配置，如springcloudnacosconfigextension-configs[0]=xxx ，其实我没搞明白这俩有啥区别。

加载应用主配置信息，这里会加载默认的两个配置，dataIdPrefix+group与dataIdPrefixfileExtension+group，如果不想加载可以通过配置springcloudnacosconfiggroup=来避免加载，只加载上面的shared-configs与extension-configs的配置。

这里会判断是否有父Context并且包含了NacosConfigProperties，如果有从父Context中直接获取。

初始化了NacosRefreshHistory，用于存储Nacos数据更新历史，最大存储20条。

初始化了NacosConfigManager，与上面的一致。

初始化了NacosContextRefresher，这个是比较核心的类，这个类实现了ApplicationListener，监听ApplicationReadyEvent事件，在Application完成的时候，执行Nacos变化监听。

registerNacosListenersForApplications() --> registerNacosListener() --> 这里会新建一个Listener，并通过configService#addListener()方法添加到Nacos的变化监听中。当收到变化的时候，首先添加了刷新纪录nacosRefreshHistory#addRefreshRecord()，其次发布了RefreshEvent事件。

在发布了RefreshEvent事件之后，就可以使用 Spring Cloud自带的RefreshScope机制 来实现属性的刷新了。在Spring Cloud 监听到变化，会执行ContextRefresher#refresh()。首先会重新加载引导信息，也就会重新调用NacosPropertySourceLocator#locate()，从而从Nacos中读取最新的配置。其次会清空缓存对象，重新以最新的Enviroment生成对象，来达到属性更新的目的。

整体来说Nacos Config在Spring Cloud的实现比较简单。核心使用了Spring Cloud的RefreshScope机制来实现对象属性的动态刷新。

Nacos（注册中心）是通过 IP+PORT 的形式调用其他服务。

问题：

Docker 容器使用虚拟 IP，当 Docker 中的服务 A，向 Nacos 注册的时候，Nacos 获取到了 Docker 的内部 IP，导致另外一个服务 B，想通过注册中心调用服务 A，但由于服务 B从 nacos 注册中心获取到的是服务 A 的内部 IP，这样导致了两个处于公网的微服务之间无法互相访问。

当然,配置了上述网络类型后，nacos 是可以拿到宿主机的 IP，但是此时拿到的是宿主机的内网 IP，解决办法如下:

启动 Docker 的时候，用 --network 参数，可以指定网络类型

Nacos 另一个非常重要的特性就是服务注册与发现，说到服务的注册与发现相信大家应该都不陌生，它们是服务治理的最基础功能。

Nacos 支持几乎所有主流类型的 “服务” 的发现、配置和管理。

了解过 Dubbo 的同学，应该对 Dubbo 的架构非常熟悉，最经典的一张架构图如下所示：

图中的6个步骤的含义解释如下：

0、服务容器负责启动，加载，运行服务提供者。

1、服务提供者在启动时，向注册中心注册自己提供的服务。

2、服务消费者在启动时，向注册中心订阅自己所需的服务。

3、注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4、服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

5、服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

其中图中最上方的 Registry 就是注册中心，负责服务的注册与发现。Dubbo 有自己的 Registry 实现，而 Nacos 则是另一种 Registry 实现。

相对服务注册而言服务发现就简单很多了。就是Nacos客户端调用Open API或者SDK查询服务列表，服务端接受到请求后根据将查询到服务包装成json格式返回。

既然如此，客户端是啥时候发起服务列表查询？

如果客户端查的时差内，刚好有服务实例有down掉，那客户端的请求岂不是有请求到刚好down的服务实例？下面进行解答。

客户端有一个HostReactor类，在comalibabanacosclientnamingcore包下。

HostReactor它里面有一个UpdateTask线程，每 1s 发送一次pull拉取请求，获取服务最新的地址列表。

更新服务的核心逻辑在updateService方法中：

再看看processServiceJson方法， 本地维护一个Map<String,ServiceInfo> serviceInfoMap 存储服务信息，同时调用 DiskCachewrite(serviceInfo, thiscacheDir) 方法把服务信息写入本地缓存文件中;

服务端采取的是基于push的方式向客户端通知，由于服务端和服务提供者（各个微服务provider）建立了心跳机制，一旦某个服务出现故障，服务端察觉出后，会发送一个push消息给Nacos客户端，也就是我们的消费者。这个push消息是使用DatagramSocket来实现的。

服务消费者收到服务端发来的push消息之后，使用HostReactor中提供的ServiceInfo processServiceJson(String json)方法解析消息，并更新本地服务地址列表。

可以参照下面的图更容易理解服务动态感知原理，包括：客户端主动轮训查询服务列表及服务端Push变故后的服务列表。

本文主要介绍自己将nacos作为spring boot的配置中心的实践过程，希望对有需求的小伙伴提供一些帮助。

通过nacos实现配置管理：支持分布式系统中的外部化配置，配置更改时自动刷新。

在linux系统中可以通过以下命令安装 docker-compse：

使用如下命令创建部署文件 nacos-standalone-mysql-8yaml ：

文件内容如下：

使用如下命令启动nacos：

使用下面的命令可以查看启动日志：

启动成功后访问： >

以上就是关于Nacos配置成系统服务，开机自动启动及注意事项全部的内容，包括:Nacos配置成系统服务，开机自动启动及注意事项、微服务初体验（二）：使用Nacos作为配置中心并集成Dubbo、Spring Gateway集成nacos实现动态路由配置等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！