3.Nacos的超级大坑你踩了吗？

转载: https://zhuanlan.zhihu.com/p/387094160

前言

去年的时候上家公司进行架构升级，ddubbo的服务改造成SpringCloud，注册中心由ZooKeeper改为Nacos，这种架构改变并不是真的因为业务扩展需要，存粹的是技术上有些领导听从有些"技术大牛"追求新技术创新，结果就是出现了很多莫名其妙的问题，去年的时候我刚进去公司，顶着技术专家的头衔，拿着高开的工资，沿路给整个公司的这种架构升级擦屁股。其中我认为解决公司最为头疼的问题就是Nacos的坑。

1.注册中心的特性对比：

特性	Nacos	Eureka	Consul	CoreDNS	Zookeeper

CAP理论科普：

一致性(Consistency): (所有节点在同一时间具有相同的数据)

可用性(Availability): (保证每个请求不管成功或者失败都有响应)

分隔容忍(Partition tolerance): (系统中任意信息的丢失或失败不会影响系统的继续运作)

1.1总结：

从上面的参数对比的话，nacos完胜其他注册中心，简直可以封神，也许也正是因为参数对比之后，再加上老的项目都是采用dubbo也是阿里出品，nacos也是阿里出品天然的支持了dubbo，并且还兼容springcloud，成了很多公司的不二选择。但是nacos真的是完美无缺的吗？

2.nacos问题总结:

2.1资源耗尽问题；

我司当时采用nacos后遇到最直接的问题就是nacos1.x导致的短连接导致服务器资源耗尽的情况，什么是资源耗尽？ 本来基于linux服务部署服务，已经配置了几万端口供应用进行使用，但是nacos1.x的因为使用的是短连接会一直产生新的连接，但是老的链接短时间内有没有关闭，导致linux服务器的端口被使用完，导致资源耗尽问题，这个真的是nacos1.x最大的坑。呈现出来的现象就是nacos刚开始启动很稳定，但是使用一段时间以后就会疯狂的打日志，应用之间连接nacos连接不上，但是各个服务有没有大流量等突发的状况。有的人在这里遇到问题就是重启大法！！！！，但是重启大法针对此问题是一点作用没有，因为是服务资源耗尽，服务器的端口被耗尽，修改服务器端口的最大值，停一段时间又是打满了。

2.2资源耗尽问题解决；

需要说明的是，我们当时使用的是nacos版本1.x，现在2.x版本已经明确使用长连接已经避免了锻炼连资源耗尽的问题。 1.x解决方案： 我当时都没听过nacos，但是无奈是新进来的技术专家，就硬着头皮硬上了。 解决问题的过程很曲折，方案就是修改linux服务器的链接参数，当一定时间内不主动释放的链接进行主动关闭收回。 执行命令：

#修改方式：
#编辑 /etc/sysctl.conf 文件，加入参数内容，以上5个参数是我查到的认为有效的结果，然后我的实际情况仅修改了其中三个：
net.ipv4.ip_forward=1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
编辑完成后执行命令 /sbin/sysctl -p 

对就是这样解决的。 再进行复查看看服务器的链接情况：

查看连接数是不是很多：
netstat -a|grep TIME_WAIT

netstat -ant|grep -i time_wait |wc -l 

已经由几万的阈值降低到几十个，nacos的端口资源耗尽问题解决。

2.3权限管理问题；

使用过apollo作为配置中心的朋友再去使用nacos做配置中心的话，会有很直观的感受，nacos针对用户管理和权限管理做得是真粗糙，两者对待产品的态度简直不在一个量级。也许nacos的出发点并不在用户管理和权限管理，所以并没有进行好好的设计。