微服务架构:注册中心 ZooKeeper、Eureka、Consul 、Nacos 对比!
程序员的成长之路
共 5143字,需浏览 11分钟
·
2020-12-11 13:33
阅读本文大概需要 2.8 分钟。
前言
CAP理论
一致性(Consistency) (所有节点在同一时间具有相同的数据) 可用性(Availability) (保证每个请求不管成功或者失败都有响应) 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
服务注册中心解决方案
应用内:直接集成到应用中,依赖于应用自身完成服务的注册与发现,最典型的是Netflix提供的Eureka 应用外:把应用当成黑盒,通过应用外的某种机制将服务注册到注册中心,最小化对应用的侵入性,比如Airbnb的SmartStack,HashiCorp的Consul DNS:将服务注册为DNS的SRV记录,严格来说,是一种特殊的应用外注册方式,SkyDNS是其中的代表
测活:服务注册之后,如何对服务进行测活以保证服务的可用性? 负载均衡:当存在多个服务提供者时,如何均衡各个提供者的负载? 集成:在服务提供端或者调用端,如何集成注册中心? 运行时依赖:引入注册中心之后,对应用的运行时环境有何影响? 可用性:如何保证注册中心本身的可用性,特别是消除单点故障?
主流注册中心产品
软件产品特性并非一成不变,如果发现功能特性有变更,欢迎评论指正
Consul是支持自动注销服务实例, 请见文档:https://www.consul.io/api-docs/agent/service,在check的 DeregisterCriticalServiceAfter 这个参数-- 感谢@超帅的菜鸟博主提供最新信息 新版本的Dubbo也扩展了对 Consul 的支持。参考: https://github.com/apache/dubbo/tree/master/dubbo-registry
Apache Zookeeper -> CP
Spring Cloud Eureka -> AP
Eureka不再从注册表中移除因为长时间没有收到心跳而过期的服务; Eureka仍然能够接受新服务注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用); 当网络稳定时,当前实例新注册的信息会被同步到其它节点中;
Consul
Consul Template
服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功 Leader挂掉时,重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
服务注册相对要快,因为不需要等注册信息replicate到其他节点,也不保证注册信息是否replicate成功 当数据出现不一致时,虽然A, B上的注册信息不完全相同,但每个Eureka节点依然能够正常对外提供服务,这会出现查询服务信息时如果请求A查不到,但请求B就能查到。如此保证了可用性但牺牲了一致性。
Nacos
推荐阅读:
记住看小电影前一定要检查一下域名是不是 HTTPS 的,不然……
广州蛋壳公寓18层租客跳楼身亡,室友:他刚毕业没工作,房东就赶我们走!微众银行紧急公告...
微信扫描二维码,关注我的公众号
朕已阅
评论