Nacos的超级大坑你踩了吗?

文章目录

  • 前言
    • 1.注册中心的特性对比:
      • 1.1总结:
    • 2.nacos问题总结:
      • 2.1资源耗尽问题;
      • 2.2资源耗尽问题解决;
      • 2.3权限管理问题;
  • 总结

前言

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

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

特性 Nacos Eureka Consul CoreDNS Zookeeper
一致性协议 CP+AP AP CP CP
健康检查 TCP/HTTP/MYSQL/Client Beat Client Beat TCP/HTTP/gRPC/Cmd Keep Alive
负载均衡策略 权重/metadata/Selector Ribbon Fabio RoundRobin
雪崩保护
自动注销实例 支持 支持 支持 不支持 支持
访问协议 HTTP/DNS HTTP HTTP/DNS DNS TCP
监听支持 支持 支持 支持 不支持 支持
多数据中心 支持 支持 支持 不支持 不支持
跨注册中心同步 支持 不支持 支持 不支持 不支持
SpringCloud集成 支持 支持 支持 不支持 支持
Dubbo集成 支持 不支持 支持 不支持 支持
K8S集成 支持 不支持 支持 支持 不支持

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的出发点并不在用户管理和权限管理,所以并没有进行好好的设计。

总结

之前我也认为阿里出品必属精品,虽然fastjson和dubbo也会被人吐槽,但是市场的使用率完全的说明了问题,但是经过nacos这一次,我真是觉的,一个新的技术组件出来之后一定不能贸然使用,其中有些坑真是能埋死人。现在可能刚别业的同学一上手也是springcloud、nacos使用的各种新的框架,但是当服务出现问题的时候发现会是一头雾水,根本解决不了。新技术组件出现,大家可以很积极的去学习,但是生产省一定不要贸然使用。如果你有什么想跟我交流的欢迎关注我的公众号:Java时间屋 来进行交流。

你可能感兴趣的:(Nacos的超级大坑你踩了吗?)