github:https://github.com/etcd-io/etcd
官方:https://etcd.io/
etcd是CoreOS团队于2013年6月发起的开源项目,授权协议为Apache。etcd是用于共享配置和服务发现的分布式,一致性的KV存储系统。etcd内部采用raft协议作为一致性算法,etcd基于Go语言实现
提供配置共享和服务发现的系统比较多,其中最为大家熟知的是[Zookeeper](后文简称ZK),而ETCD可以算得上是后起之秀了。在项目实现,一致性协议易理解性,运维,安全等多个维度上,ETCD相比Zookeeper都占据优势。
在分布式系统中,如何管理节点间的状态一直是一个难题,etcd像是专门为集群环境的服务发现和注册而涉及,它提供了数据TTL失效、数据改变监视、多值、目录监听、分布式锁原子操作等功能,可以方便的跟踪并管理集群节点的状态。
etcd作为一个受到ZooKeeper与doozer启发而催生的项目,除了拥有与之类似的功能外,更专注于以下四点。
按照官网给出的[Benchmark], 在2CPU,1.8G内存,SSD磁盘这样的配置下,单节点的写性能可以达到16K QPS, 而先写后读也能达到12K QPS。这个性能还是相当可观的。
本文选取ZK作为典型代表与ETCD进行比较,而不考虑[Consul]项目作为比较对象,原因为Consul的可靠性和稳定性还需要时间来验证(项目发起方自身服务并未使用Consul, 自己都不用)。
一致性协议: ETCD使用[Raft]协议, ZK使用ZAB(类PAXOS协议),前者容易理解,方便工程实现;
运维方面:ETCD方便运维,ZK难以运维;
项目活跃度:ETCD社区与开发活跃,ZK已经快死了;
API:ETCD提供HTTP+JSON, gRPC接口,跨平台跨语言,ZK需要使用其客户端;
访问安全方面:ETCD支持HTTPS访问,ZK在这方面缺失;
【推荐】】etcd学习(1)-etcd的使用场景
参考URL: https://www.cnblogs.com/ricklz/p/15033193.html
etcd应用场景
参考URL: https://www.hi-linux.com/posts/40915.html
应用场景有如下几类:
举个最简单的例子,如果你需要一个分布式存储仓库来存储配置信息,并且希望这个仓库读写速度快、支持高可用、部署简单、支持http接口,那么就可以使用etcd。
目前,cloudfoundry使用etcd作为hm9000的应用状态信息存储,kubernetes用etcd来存储docker集群的配置信息等。
在微服务或者组件设计,特别是最为大家熟知的就是 Kubernetes (k8s),其底层就依赖于 etcd 实现集群状态和配置的管理,会把etcd作为状态持有者,如果etcd出了问题,会导致整个集群都出现问题,可见etcd的重要性。
etcd是一个非常可靠的kv存储系统,常在分布式系统中存储着关键的数据。etcd常用来做分布式系统中一些关键数据的存储服务,比如服务注册和服务发现。
总结:etcd 在微服务和 Kubernates 集群中不仅可以作为服务注册于发现,还可以作为 key-value 存储的中间件。
通俗的讲就是:etcd 最常用于服务注册与发现,作为集群管理的组件使用;也可以用于K-V存储,作为数据库使用
一个用户的api请求,可能调用多个微服务资源,这些服务我们可以使用etcd进行服务注册和服务发现,当每个服务启动的时候就注册到etcd中,当我们需要使用的时候,直接在etcd中寻找,调用即可。
服务注册发现解决的是分布式系统中最常见的问题之一,即在同一个分布式系统中,找到我们需要的目标服务。
etcd非常适合用于服务注册与发现。主要原因有:
etcd是一个优秀的开源项目,它高效、可靠、安全的特性非常符合服务注册与发现的需求。