Nacos的超级大坑你踩了吗?
文章目录前言1.注册中心的特性对比:1.1总结:2.nacos问题总结:2.1资源耗尽问题;2.2资源耗尽问题解决;2.3权限管理问题;总结前言去年的时候上家公司进行架构升级,ddubbo的服务改造成SpringCloud,注册中心由ZooKeeper改为Nacos,这种架构改变并不是真的因为业务扩展需要,存粹的是技术上有些领导听从有些"技术大牛"追求新技术创新,结果就是出现了很多莫名其妙的问题,
前言
去年的时候上家公司进行架构升级,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时间屋 来进行交流。
更多推荐
所有评论(0)