服务注册选型比较:Consul vs Zookeeper vs Etcd vs Eureka

zookeeper基于paxos的化简版zab,etcd基于raft算法、consul也是基于raft算法。etcd和consul作为后起之秀,并没有因为已经有了zookeeper而放弃自己,而是采用更为直接的raft算法。

原文  http://luyiisme.github.io/2017/04/22/spring-cloud-service-discovery-products/

主题 ConsuletcdZooKeeper

这里就平时经常用到的服务发现的产品进行下特性的对比,首先看下结论:

Feature Consul zookeeper etcd euerka
服务健康检查 服务状态,内存,硬盘等 (弱)长连接,keepalive 连接心跳 可配支持
多数据中心 支持
kv存储服务 支持 支持 支持
一致性 raft paxos raft
cap ca cp cp ap
使用接口(多语言能力) 支持http和dns 客户端 http/grpc http(sidecar)
watch支持 全量/支持long polling 支持 支持 long polling 支持 long polling/大部分增量
自身监控 metrics metrics metrics
安全 acl /https acl https支持(弱)
spring cloud集成 已支持 已支持 已支持 已支持
  • 服务的健康检查

Euraka 使用时需要显式配置健康检查支持;Zookeeper,Etcd 则在失去了和服务进程的连接情况下任务不健康,而 Consul 相对更为详细点,比如内存是否已使用了90%,文件系统的空间是不是快不足了。

  • 多数据中心支持

Consul 通过 WAN 的 Gossip 协议,完成跨数据中心的同步;而且其他的产品则需要额外的开发工作来实现;

  • KV 存储服务

除了 Eureka ,其他几款都能够对外支持 k-v 的存储服务,所以后面会讲到这几款产品追求高一致性的重要原因。而提供存储服务,也能够较好的转化为动态配置服务哦。

  • 产品设计中 CAP 理论的取舍

Eureka 典型的 AP,作为分布式场景下的服务发现的产品较为合适,服务发现场景的可用性优先级较高,一致性并不是特别致命。其次 CA 类型的场景 Consul,也能提供较高的可用性,并能 k-v store 服务保证一致性。 而Zookeeper,Etcd则是CP类型 牺牲可用性,在服务发现场景并没太大优势;

  • 多语言能力与对外提供服务的接入协议

Zookeeper的跨语言支持较弱,其他几款支持 http11 提供接入的可能。Euraka 一般通过 sidecar的方式提供多语言客户端的接入支持。Etcd 还提供了Grpc的支持。 Consul除了标准的Rest服务api,还提供了DNS的支持。

  • Watch的支持(客户端观察到服务提供者变化)

Zookeeper 支持服务器端推送变化,Eureka 2.0(正在开发中)也计划支持。 Eureka 1,Consul,Etcd则都通过长轮询的方式来实现变化的感知;

  • 自身集群的监控

除了 Zookeeper ,其他几款都默认支持 metrics,运维者可以搜集并报警这些度量信息达到监控目的;

  • 安全

Consul,Zookeeper 支持ACL,另外 Consul,Etcd 支持安全通道https.

  • Spring Cloud的集成

目前都有相对应的 boot starter,提供了集成能力。

总的来看,目前Consul 自身功能,和 spring cloud 对其集成的支持都相对较为完善,而且运维的复杂度较为简单(没有详细列出讨论),Eureka 设计上比较符合场景,但还需持续的完善。

Etcd 和 Zookeeper 提供的能力非常相似,在软件生态中所处的位置也几乎是一样的,可以互相替代的。

都是通用的一致性元信息存储,

都提供watch机制用于变更通知和分发,

也都被分布式系统用来作为共享信息存储,

二者除了实现细节,语言,一致性协议上的区别,最大的区别在周边生态圈。

Zookeeper 是apache下的,用java写的,提供rpc接口,最早从hadoop项目中孵化出来,在分布式系统中得到广泛使用(hadoop, solr, kafka, mesos 等)。

Etcd 是coreos公司旗下的开源产品,比较新,以其简单好用的rest接口以及活跃的社区俘获了一批用户,在新的一些集群中得到使用(比如kubernetes)。

虽然v3为了性能也改成二进制rpc接口了,但其易用性上比 Zookeeper 还是好一些。

而 Consul 的目标则更为具体一些,Etcd 和 Zookeeper 提供的是分布式一致性存储能力,具体的业务场景需要用户自己实现,比如服务发现,比如配置变更。

而Consul 则以服务发现和配置变更为主要目标,同时附带了kv存储。

在软件生态中,越抽象的组件适用范围越广,但同时对具体业务场景需求的满足上肯定有不足之处。

原文地址:https://www.cnblogs.com/doit8791/p/9246594.html

时间: 2024-08-28 05:50:37

服务注册选型比较:Consul vs Zookeeper vs Etcd vs Eureka的相关文章

常用的服务发现对比(Consul、zookeeper、etcd、eureka)

这里就平时经常用到的服务发现的产品进行下特性的对比,首先看下结论:   Feature Consul Zookeeper Etcd Eureka 服务健康检查  服务状态,内存,硬盘等  (弱)长连接,keepalive  连接心跳  可配支持 多数据中心  支持  -  -  - kv存储服务  支持  支持  支持  - 一致性  raft  paxos  raft  - CAP定理  CA  CP  CP  AP 使用接口(多语言能力)  支持http和dns  客户端  http/grp

服务发现框架选型,Consul还是Zookeeper还是etcd

本文并不介绍服务发现的基本原理.除了一致性算法之外,其他并没有太多高深的算法,网上的资料很容易让大家明白上面是服务发现. 想直接查看结论的同学,请直接跳到文末. 目前,市面上有非常多的服务发现工具,<Open-Source Service Discovery>一文中列举了如下开源的服务发现工具.(http://jasonwilder.com/blog/2014/02/04/service-discovery-in-the-cloud/) 上面表格中,前三个是通用的,后面都是各大公司自己造的轮子

服务发现比较:Consul vs Zookeeper vs Etcd vs Eureka

这里就平时经常用到的服务发现的产品进行下特性的对比,首先看下结论: Feature Consul zookeeper etcd euerka 服务健康检查 服务状态,内存,硬盘等 (弱)长连接,keepalive 连接心跳 可配支持 多数据中心 支持 — — — kv存储服务 支持 支持 支持 — 一致性 raft paxos raft — cap ca cp cp ap 使用接口(多语言能力) 支持http和dns 客户端 http/grpc http(sidecar) watch支持 全量/

分布式服务注册和发现consul 简要介绍

Consul是HashiCorp公司推出的开源工具,用于实现分布式系统的服务发现与配置.与其他分布式服务注册与发现的方案,Consul的方案更"一站式",内置了服务注册与发现框 架.分布一致性协议实现.健康检查.Key/Value存储.多数据中心方案,不再需要依赖其他工具(比如ZooKeeper等).使用起来也较 为简单.Consul用Golang实现,因此具有天然可移植性(支持Linux.windows和Mac OS X):安装包仅包含一个可执行文件,方便部署,与Docker等轻量级

5.服务注册与发现Consul,简学API,手动注册和删除服务

package main import ( httptransport "github.com/go-kit/kit/transport/http" mymux "github.com/gorilla/mux" "gomicro/Services" "net/http" ) func main() { user := Services.UserService{} endp := Services.GenUserEnPoint(

【转帖】基于Zookeeper的服务注册与发现

http://www.techweb.com.cn/network/hardware/2015-12-25/2246973.shtml 背景 大多数系统都是从一个单一系统开始起步的,随着公司业务的快速发展,这个单一系统变得越来越庞大,带来几个问题: 1. 随着访问量的不断攀升,纯粹通过提升机器的性能来已经不能解决问题,系统无法进行有效的水平扩展 2. 维护这个单一系统,变得越来越复杂 3. 同时,随着业务场景的不同以及大研发的招兵买马带来了不同技术背景的工程师,在原有达达Python技术栈的基础

SpringCloud:Eureka服务注册与发现

1.Eureka简介 Spring Cloud 封装了 Netflix 公司开发的 Eureka 模块来实现服务注册和发现(请对比Zookeeper). Eureka 采用了 C-S 的设计架构.Eureka Server 作为服务注册功能的服务器,它是服务注册中心. 而系统中的其他微服务,使用 Eureka 的客户端连接到 Eureka Server并维持心跳连接. 这样系统的维护人员就可以通过 Eureka Server 来监控系统中各个微服务是否正常运行. SpringCloud 的一些其

SpringCloud 服务注册中心 服务提供者 服务消费者

1. 建立"服务注册中心" 创建一个基础的Spring Boot工程,并在pom.xml中引入需要的依赖内容: <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka-server</artifactId> </dependency> 在主类中通过@EnableEurekaSe

SpringCloud构建微服务 | 服务注册与发现(一)提供Demo

Eureka介绍: Eureka是Netflix开发的服务发现框架,本身是一个基于REST的服务,主要用于定位运行在AWS域中的中间层服务,以达到负载均衡和中间层服务故障转移的目的. SpringCloud将它集成在其子项目spring-cloud-netflix中,以实现SpringCloud的服务发现功能. Eureka包含两个组件:Eureka Server和Eureka Client. Eureka Server提供服务注册服务,各个节点启动后,会在Eureka Server中进行注册,