相信大家伙学微服务的话,一般都是先学服务注册中心的吧。比如Eureka
、Zookeeper
、Consul
等等。
上面这三个的区别之前也介绍过,无非就是CAP理论中满足两个,Eureka
保证了可用性,但损失了一致性。而另外两个确保了一致性,但一定程度丢失了可用性。
其实服务注册中心远远不止这三个。前几年是这三位主流,但之后Eureka
停更了,Zookeeper
技术太过于“老旧”,社区活跃度很低而且还不支持可视化修改。对比而言consul
反而成为了我的最爱,社区活跃度高,学习阶段没有这么大流量访问需求,consul
满足CP保证了一致性完全够用了。最关键的是,它的可视化界面特别简洁,看着清爽舒服。
但是后面alibaba的nacos
出来了。这个货单看它的名字,
nacos=(na)naming+(co)config+(s)service
取自服务命名和配置的前两个字母加上service的第一个s。就是它可以拿来做服务注册中心和服务配置中心。扯远了,这一篇就记录一下它和其它几位的区别。
首先还是CAP理论的比较,先看个简单点的图:
可以看到默认情况下,Nacos
是支持AP的。这里说了特别情况,是因为它可以在CP和AP中来回切换。
这是直接在官网上拿来的nacos全景图,如 Nacos 全景图所示,Nacos 无缝支持一些主流的开源生态,也意味着可以和许多组件无缝对接。
这也意味着Nacos可以适应于多种应用场景。
一般来说,如果不需要储存服务级别的信息且服务实例是通过nacos-client注册,并能够保持心跳上报,那么就可以选择AP模式。当前主流的服务如Spring Cloud
和Dubbo服务,都适用于AP模式,AP模式为了服务的可能性而减弱了一致性,因此AP模式下只支持注册临时实例。
如果需要在服务级别编辑或者储存配置信息,那么CP是必须,K8S服务和DNS服务则适用于CP模式,该模式下支持注册持久化实例。
nacos
为我们提供了切换的接口:
curl -X PUT `$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'
后面的value表示要切换的模式,感谢观看🙏