go语言服务注册与发现 golang consul服务发现和注册( 六 )


当 Eureka Server 节点在短时间内丢失过多的心跳时,那么这个节点就会进入自我保护模式 。
Eureka的集群中 , 只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性) 。除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
Eureka不再从注册表中移除因为长时间没有收到心跳而过期的服务;
Eureka仍然能够接受新服务注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用);
当网络稳定时,当前实例新注册的信息会被同步到其它节点中;
因此,Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使得整个注册服务瘫痪 。
Consul 是 HashiCorp 公司推出的开源工具,用于实现分布式系统的服务发现与配置 。Consul 使用 Go 语言编写 , 因此具有天然可移植性(支持Linux、windows和Mac OS X) 。
Consul采用主从模式的设计,使得集群的数量可以大规模扩展 , 集群间通过RPC的方式调用(HTTP和DNS) 。
Consul 内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案,不再需要依赖其他工具(比如 ZooKeeper 等),使用起来也较为简单 。
Consul 遵循CAP原理中的CP原则,保证了强一致性和分区容错性,且使用的是Raft算法,比zookeeper使用的Paxos算法更加简单 。虽然保证了强一致性,但是可用性就相应下降了,例如服务注册的时间会稍长一些 , 因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 ;在leader挂掉了之后,重新选举出leader之前会导致Consul 服务不可用 。
默认依赖于SDK
Consul本质上属于应用外的注册方式,但可以通过SDK简化注册流程 。而服务发现恰好相反,默认依赖于SDK,但可以通过Consul Template(下文会提到)去除SDK依赖 。
Consul Template
Consul,默认服务调用者需要依赖Consul SDK来发现服务,这就无法保证对应用的零侵入性 。
所幸通过Consul Template,可以定时从Consul集群获取最新的服务提供者列表并刷新LB配置(比如nginx的upstream),这样对于服务调用者而言,只需要配置一个统一的服务调用地址即可 。
Consul强一致性(C)带来的是:
Eureka保证高可用(A)和最终一致性:
其他方面,eureka就是个servlet程序,跑在servlet容器中; Consul则是go编写而成 。
etcd是一个采用http协议的分布式键值对存储系统,因其易用,简单 。很多系统都采用或支持etcd作为服务发现的一部分,比如kubernetes 。但正事因为其只是一个存储系统 , 如果想要提供完整的服务发现功能,必须搭配一些第三方的工具 。
比如配合etcd、Registrator、confd组合 , 就能搭建一个非常简单而强大的服务发现框架 。但这种搭建操作就稍微麻烦了点,尤其是相对consul来说 。所以etcd大部分场景都是被用来做kv存储,比如kubernetes 。
etcd 比较多的应用场景是用于服务发现,服务发现 (Service Discovery) 要解决的是分布式系统中最常见的问题之一,即在同一个分布式集群中的进程或服务如何才能找到对方并建立连接 。和 Zookeeper 类似,etcd 有很多使用场景,包括:
配置管理
服务注册发现
选主
应用调度
分布式队列
分布式锁
按照给出的数据,在 2CPU,1.8G 内存,SSD 磁盘这样的配置下,单节点的写性能可以达到 16K QPS, 而先写后读也能达到12K QPS 。这个性能还是相当可观 。

推荐阅读