由于系统之前使用的Nacos2.0.4有反序列化漏洞，故需要将Nacos升级到2.2.3版本。
该Nacos在本地运行没有问题，但是在Windows服务器运行就会报错：
rocksdb java.lang.UnsatisfiedLinkError: C:\Users\Administrator\AppData\Local\Temp\2\librocksdbjni5975940319059115965.dll: Can't find dependent libraries
表面上看是找不到dll文件，于是去百度，发现各种解决办法均无效。
刨根究底，发现这个问题是由于Nacos引用了rocksdb导致的，于是从rocksdb着手解决。
猜想过是因为jar包没有Temp目录的权限，从而导入文件失败导致，直接手动复制文件进目录，已然报错。
后来发现有网友说手动导入rocksdb依赖：
<dependency>
<groupId>org.rocksdb</groupId>
<artifactId>rocksdbjni</artifactId>
<version>版本号改成了跟Nacos依赖相同的版本</version>
<classifier>win64</classifier>
</dependency>
导入后发现这个依赖只是Nacos原有依赖排除掉除win64外的其他版本，并没有什么帮助。
陷入思考……
突然想到，之前旧版本(5.18.4)可以正常使用，这次Nacos2.2.3依赖的7.7.3却无法正常使用，怀疑是导入的依赖与系统(CPU?)不兼容。
于是将导入的rocksdb依赖改为：
<dependency>
<groupId>org.rocksdb</groupId>
<artifactId>rocksdbjni</artifactId>
<version>5.18.4</version>
<classifier>win64</classifier>
</dependency>
也就是改成了Nacos2.0.4依赖的rocksdb。
但是启动报了另外一个错，具体就不贴了，意思就是有一个方法不存在，猜想是7.7.3对5.18.4增加了新的方法，而且Nacos2.2.3使用了。
于是直接上mvn仓库找到最新版rocksdb，将依赖改为：
<dependency>
<groupId>org.rocksdb</groupId>
<artifactId>rocksdbjni</artifactId>
<version>9.2.1</version>
<classifier>win64</classifier>
</dependency>
然后本地测试的时候发现aliyun没有这么高等级的依赖，只能降到7.10.2才能依赖进来。
但是7.10.2和7.7.3存在着相同的问题。
于是打算从5.18.4 ~ 7.7.3之间来寻找一个能用的依赖。
直接试了6.29.5，也就是升级大版本7之前的最高版本。
然后启动成功！
总结：
Nacos项目新增依赖如下(放到所有依赖最上面)：
<dependency>
<groupId>org.rocksdb</groupId>
<artifactId>rocksdbjni</artifactId>
<version>6.29.5</version>
<classifier>win64</classifier>
</dependency>
