关于spring cloud注册中心nacos

为什么会接触nacos?

学习nacos的主要原因是因为eureka2.x的闭源策略,无论其基于什么原因吧,总之长久来看eureka貌似不是最好的选择了,这种情况下悄悄的看一下别的注册中心-nacos。

关于springcloud组件的抽象理解

其实注册中心使用nacos并不会影响到我们应用层多少的,仔细看看,其实还是我该怎样调用怎样调用,跟用不用Nacos没啥关系,确实是这样,对于Spring Cloud老手来说,就算我们更换了Nacos作为新的服务注册中心,其实对于我们应用层面的代码是没有影响的。那么为什么Spring Cloud可以带给我们这样的完美编码体验呢?实际上,这完全归功于Spring Cloud Common的封装,由于在服务注册与发现、客户端负载均衡等方面都做了很好的抽象,而上层应用方面依赖的都是这些抽象接口,而非针对某个具体中间件的实现。所以,在Spring Cloud中,我们可以很方便的去切换服务治理方面的中间件。

nacos与eureka有什么区别?

说说我最近研究的一些心得,总结几点区别,如下:

  • nacos与springboot版本冲突性太强,比如官方文档说明的0.2.x版本对应的是springboot2.x版本,实则不然,当我用springboot2.1x时是无法实现服务发现与注册的,而eureka不存在这方面问题,就这个问题,整整折腾了我大半天,最后发现springboot2.0.x版本就可以完成注册,亏死了。

  • nacos的配置管理做得比较好点,可视化界面发起配置的编辑,和springconfig一样,使用springcloud原生注解@RefreshScope可以实现动态刷新,这点体现还是不错的,对比springcloud config而言的话,是要方便一些。

  • nacos集群基于mysql数据库来实现动态管理调用,与其他的中间件相比,在实现上并没有采用分布式算法来解决一致性问题,而是采用了比较常规的集中化存储来实现。由于采用单一数据源的方式,直接解决了分布式一致性问题,所以从学习成本的角度上来说,Nacos的实现原理会更容易被理解和接受。但是,从部署的负责度和硬件投入成本上来说,与etcd、consul、zookeeper这些通过算法方式解决一致性问题的中间件相比,就显得不足了;同时,在引入MySQL的存储时,由于多了一个中间件的存在,整个Nacos系统的整体可用性一定是会所有下降的。反观一下eureka,eureka集群下,eureka server是把互相之间的eureka模块来进行相互注册,不存在leader这一说,就是说你失败,ok我不认识你了,你突然又好了,那么欢迎你回来,这点和zookeeper有点像,但是zookeeper集群下是有它自己的算法来实现leader的。

  • 已经不想继续进行下去nacos了,因为其集群环境下基于数据库版本匹配太短缺,我这边满足不了,文档上说5.6+版本均可,而我mysql版本是5.7.2仍然给我抛了一天异常,懒得搞了,坐等nacos成熟之后,或许会再抽出时间研究一下,毕竟它的服务降级也还是可以研究一下的…


本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!