Nacos常规问题汇总

一、Nacos常规问题

Nacos是什么

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。详情可以参考Nacos官网介绍。

Nacos如何支持多环境

在日常使用中常常需要不同的环境，比如日常，预发，线上环境，如果是逻辑隔离可以使用命名空间，Nacos支持命名空间来支持多环境隔离，可以在Nacos控制台创建多个命名空间。如果需要物理隔离，就要部署多套Nacos环境。

Nacos是否生产可用

Nacos在2019.1发布了Pre-GA版本，支持了安全隔离、监控和服务迁移等上生产的最后一公里，以更稳定的支撑用户的生产环境。详情可以参考Nacos 发布 v0.8.0 Pre-GA 版本，安全稳定上生产。

Nacos有什么依赖

在单机模式下，Nacos没有任何依赖，在集群模式下，Nacos依赖Mysql做存储，详情可以参考Nacos部署。

Nacos使用什么开源协议

Nacos使用Apache 2.0。

二、Nacos运维问题

Nacos如何单机部署

可以参考Nacos官网部署手册quick start。

Nacos单机部署如何使用mysql

Nacos单机模式默认使用内嵌的数据库作为存储引擎，如果想换成自己安装的mysql，可以按照官网文档。

生产环境如何部署Nacos

生产环境使用Nacos为了达到高可用不能使用单机模式，需要搭建nacos集群，具体详情可以参考集群部署手册。

Nacos如何Docker部署

除了使用压缩包部署Nacos，Nacos也提供了相应的Docker镜像，当Nacos发布新的版本的时候，Nacos会发布对应的镜像版本支持Docker部署。具体详情可以参考Nacos Docker。

如何在k8s中部署Nacos

在生产环境部署Nacos集群，如果要对Nacos进行扩容操作，需要手动更改集群ip文件，启动新的Nacos服务。为了能进行自动化运维，Nacos和k8s结合利用StatefulSets提供了自动运维方案，能对Nacos进行动态扩缩容，具体详情参考Kubernetes Nacos。

如何监控Nacos

Nacos0.8版本提供了Metrics数据暴露能力，能通过Metrics数据的内容对Nacos的运行状态进行监控，详情参考Nacos监控。

Nacos在Docker环境下集群部署，无法正常启动，日志一直打印 Nacos is starting...

原因可能是由于Docker环境下，内存不足导致另外的服务无法正常启动，最后导致服务报错，一直重启，可以通过增大Docker限制内存尝试解决。

三、Nacos使用问题

Zookeeper上的服务可以迁移到Nacos上吗

可以通过Nacos-Sync把Zookeeper服务迁移到Nacos，也可以从Nacos迁移到Zookeeper，具体可以参考Nacos Sync 使用。

Nacos支持多配置文件

Nacos通过Spring Cloud Alibaba Nacos Config支持了多配置文件，可以将配置存储在多个独立的配置文件中。关联的issue，详情参考文档Spring Cloud Alibaba Nacos Config。

Nacos支持Dubbo

Nacos 0.6版本和Dubbo集成，支持使用Nacos作为注册中心，关联issue,具体文档参考 Dubbo 融合 Nacos 成为注册中心。

Nacos支持Spring体系

Nacos完善支持了Sping技术栈，具体可以参考Nacos Spring、Nacos Spring Boot、Spring Cloud。

不使用Nacos SDK如何访问Nacos

Nacos的网络交互都是基于Http协议实现的，提供了Open-API可以很容易实现Nacos的访问。

Nacos对多语言的支持

Nacos目前只支持Java，对于其他语言的支持还正在开发中，需要大家大力支持一起共建。

Nacos0.8版本登陆失败

Nacos 0.8版本当使用openjdk并且没有JAVA_HOME的环境变量时，nacos可以启动成功，是因为yum install安装的openjdk 会把java命令注册一份到/bin目录下面,所以会引发SignatureException异常。这个问题已经修复，0.9版本会发版，具体详情可以参考issue。

服务端报错 java.lang.IllegalStateException: unable to find local peer: 127.0.0.1:8848

这个问题是因为Nacos获取本机IP时,没有获取到正确的外部IP.需要保证InetAddress.getLocalHost().getHostAddress()或者hostname -i的结果是与cluster.conf里配置的IP是一致的。

Nacos如何对配置进行加密

Nacos计划在1.X版本提供加密的能力，目前还不支持加密，只能靠sdk做好了加密再存到nacos中。

Nacos报401错误

Nacos服务端报错了，可以检查服务端日志，参考issue。

Nacos权重不生效

Nacos控制台上编辑权重, 目前从SpringCloud客户端和Dubbo客户端都没有打通, 所以不能生效. 对于SpringCloud客户端, 应用可以实现Ribbon的负载均衡器来进行权重过滤。

Nacos如何扩缩容

目前支持修改cluster.conf文件的方式进行扩缩容, 改完后无需重启, Server会自动刷新到文件新内容。

Nacos客户端修改日志级别

配置-D参数com.alibaba.nacos.naming.log.level设置naming客户端的日志级别，例如设置为error： -Dcom.alibaba.nacos.naming.log.level=error 同样的，-D参数com.alibaba.nacos.config.log.level用来设置config客户端的日志级别。

Nacos与Zipkin 整合出现 Service not found 问题

配置spring-cloud-seluth参数：spring.zipkin.discovery-client-enabled=false。

如果仍然存在Service not found错误，则建议先使用open-api将Zipkin-server注册为永久实例服务：

curl -X POST 'http://127.0.0.1:8848/nacos/v1/ns/instance?port=9411&healthy=true&ip=127.0.0.1&weight=1.0&serviceName=zipkin-server&ephemeral=false&namespaceId=public'

然后，前往nacos控制台，找到服务名为zipkin-server的服务，找到集群配置，设置健康检查模式为TCP，端口号为9411(即zipkin-server的端口)。

如何依赖最新的Nacos客户端？

很多用户都是通过Spring Cloud Alibaba或者Dubbo依赖的Nacos客户端，那么Spring Cloud Alibaba和Dubbo中依赖的Nacos客户端版本，往往会落后于Nacos最新发布的版本。在一些情况下，用户需要强制将Nacos客户端升级到最新，此时却往往不知道该升级哪个依赖，这里将Spring Cloud Alibaba和Dubbo的依赖升级说明如下：

Spring Cloud Alibaba

用户通常是配置以下Maven依赖来使用的Nacos：

<!--Nacos Discovery-->
<dependency>
     <groupId>com.alibaba.cloud</groupId>
     <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
     <version>[latest version]</version>
 </dependency>

<!--Nacos Config-->
<dependency>
     <groupId>com.alibaba.cloud</groupId>
     <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
     <version>[latest version]</version>
 </dependency>

这两个jar包实际上又依赖了以下的jar包：

<dependency>
  <groupId>com.alibaba.nacos</groupId>
  <artifactId>nacos-client</artifactId>
  <version>[a particular version]</version>
</dependency>

如果nacos-client升级了，对应的spring-cloud客户端版本不一定也同步升级，这个时候可以采用如下的方式强制升级nacos-client（以nacos-discovery为例）：

<dependency>
     <groupId>com.alibaba.cloud</groupId>
     <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
     <version>[latest version]</version>
     <excludes>
          <exclude>
                 <groupId>com.alibaba.nacos</groupId>
                 <artifactId>nacos-client</artifactId>
          </exclude>
     </excludes>
 </dependency>

<dependency>
  <groupId>com.alibaba.nacos</groupId>
  <artifactId>nacos-client</artifactId>
  <version>[latest version]</version>
</dependency>

Dubbo

Dubbo也是类似的道理，用户通常引入的是以下的依赖：

    <dependency>
        <groupId>com.alibaba</groupId>
        <artifactId>dubbo-registry-nacos</artifactId>
        <version>[latest version]</version>
    </dependency>   
    
    <!-- Dubbo dependency -->
    <dependency>
        <groupId>com.alibaba</groupId>
        <artifactId>dubbo</artifactId>
        <version>[latest version]</version>
    </dependency>

需要升级Nacos客户端时，只需要如下修改依赖：

 <dependency>
  <groupId>com.alibaba.nacos</groupId>
  <artifactId>nacos-client</artifactId>
  <version>[latest version]</version>
</dependency>

客户端CPU高，或者内存耗尽的问题

问题的现象是依赖Nacos客户端的应用，在运行一段时间后出现CPU占用率高，内存占用高甚至内存溢出的现象，可以参考issue：[https://github.com/alibaba/nacos/issues/1605](https://github.com/alibaba/nacos/issues/1605)。这种情况首先要做的是分析CPU高或者内存占用高的原因，常用的命令有top、jstack、jmap、jhat等。其中一种情况是Nacos客户端实例在Spring Cloud Alibaba服务框架中被反复构造了多次，可以参考issue：[https://github.com/alibaba/spring-cloud-alibaba/issues/859](https://github.com/alibaba/spring-cloud-alibaba/issues/859)。这个问题已经得到了修复，预期会在下个Spring Cloud Alibaba版本中发布。

日志打印频繁的问题

在老的Nacos版本中，往往会有大量的无效日志打印，这些日志的打印会迅速占用完用户的磁盘空间，同时也让有效日志难以查找。目前社区反馈的日志频繁打印主要有以下几种情况：

access日志大量打印，相关issue有：log of nacos optimization · Issue #1510 · alibaba/nacos · GitHub。主要表现是{nacos.home}/logs/access_log.2019-xx-xx.log类似格式文件名的日志大量打印，而且还不能自动清理和滚动。这个日志是Spring Boot提供的tomcat访问日志打印，Spring Boot在关于该日志的选项中，没有最大保留天数或者日志大小控制的选项。因此这个日志的清理必须由应用新建crontab任务来完成，或者通过以下命令关闭日志的输出（在生产环境我们还是建议开启该日志，以便能够有第一现场的访问记录）：

server.tomcat.accesslog.enabled=false

服务端业务日志大量打印且无法动态调整日志级别。这个问题在1.1.3已经得到优化，可以通过API的方式来进行日志级别的调整，调整日志级别的方式如下：

# 调整naming模块的naming-raft.log的级别为error:
curl -X PUT '$nacos_server:8848/nacos/v1/ns/operator/log?logName=naming-raft&logLevel=error'
# 调整config模块的config-dump.log的级别为warn:
curl -X PUT '$nacos_server:8848/nacos/v1/cs/ops/log?logName=config-dump&logLevel=warn'

客户端日志大量打印，主要有心跳日志、轮询日志等。这个问题已经在1.1.3解决，请升级到1.1.3版本。

集群管理页面，raft term显示不一致问题

在Nacos 1.0.1版本中，Nacos控制台支持了显示当前的集群各个机器的状态信息。这个功能受到比较多用户的关注，其中一个被反馈的问题是列表中每个节点的集群任期不一样。如下图所示（图片信息来自issue：https://github.com/alibaba/nacos/issues/1786）：

对于这个任期不一致的问题，原因主要是因为获取这个信息的逻辑有一些问题，没有从对应的节点上获取集群任期。这个问题会在下一个Nacos版本中修复。目前一个手动检查集群任期的办法是在每个节点上执行以下命令：

curl '127.0.0.1:8848/nacos/v1/ns/raft/state'

然后在返回信息中查找本节点的集群任期。因为每个节点返回的集群任期中，只有当前节点的信息是准确的，返回的其他节点的信息都是不准确的。

找不到符号`com.alibaba.nacos.consistency.entity`

这个包目录是由protobuf在编译时自动生成，您可以通过mvn compile来自动生成他们。如果您使用的是IDEA，也可以使用IDEA的protobuf插件。

启动报错java.lang.IllegalArgumentException: the length of secret key must great than or equal 32 bytes...

启动报错java.lang.IllegalArgumentException: The specified key byte array is x bits which is not secure enough for any JWT HMAC-SHA algorithm.

默认鉴权插件需要密钥来生成访问token，密钥格式需要长度大于32。若secret.key进行BASE64解密后的长度小于32，则会在启动过程中此错误。您可以在application.properties中设置正确的secret.key，详情见用户指南-权限认证.

启动报错Empty identity, Please set `nacos.core.auth.server.identity.key` and `nacos.core.auth.server.identity.value`

2.2.1后的版本，移除了配置中间中nacos.core.auth.server.identity.key 和 nacos.core.auth.server.identity.value的默认值，并添加了启动校验。如果在开启鉴权但未设置nacos.core.auth.server.identity.key 和 nacos.core.auth.server.identity.value的情况下，nacos server会提示以上报错信息，并阻止启动。可查看用户指南-权限认证文档中相关内容，进行设置后启动。