ETCD服务发现.docx
- 文档编号:4748276
- 上传时间:2022-12-08
- 格式:DOCX
- 页数:9
- 大小:3.44MB
ETCD服务发现.docx
《ETCD服务发现.docx》由会员分享,可在线阅读,更多相关《ETCD服务发现.docx(9页珍藏版)》请在冰豆网上搜索。
ETCD服务发现
ETCD服务发现
开始
1、Etcd 介绍
Etcdisadistributed,consistent key-value storefor sharedconfiguration and servicediscovery
是一个分布式的,一致的key-value存储,主要用途是共享配置和服务发现。
Etcd已经在很多分布式系统中得到广泛的使用。
2、为什么需要Etcd
所有的分布式系统,都面临的一个问题是多个节点之间的数据共享问题,这个和团队协作的道理是一样的,成员可以分头干活,但总是需要共享一些必须的信息,比如谁是leader,都有哪些成员,依赖任务之间的顺序协调等。
所以分布式系统要么自己实现一个可靠的共享存储来同步信息(比如Elasticsearch),要么依赖一个可靠的共享存储服务,而Etcd就是这样一个服务。
3、Etcd提供什么能力
Etcd主要提供以下能力,已经熟悉Etcd的读者可以略过本段。
1.提供存储以及获取数据的接口,它通过协议保证Etcd集群中的多个节点数据的强一致性。
用于存储元信息以及共享配置。
2.提供监听机制,客户端可以监听某个key或者某些key的变更(v2和v3的机制不同,参看后面文章)。
用于监听和推送变更。
3.提供key的过期以及续约机制,客户端通过定时刷新来实现续约(v2和v3的实现机制也不一样)。
用于集群监控以及服务注册发现。
4.提供原子的CAS(Compare-and-Swap)和CAD(Compare-and-Delete)支持(v2通过接口参数实现,v3通过批量事务实现)。
用于分布式锁以及leader选举。
更详细的使用场景不在这里描述,有兴趣的可以参看文末infoq的一篇文章。
4、Etcd如何实现一致性的
说到这个就不得不说起raft协议。
但这篇文章不是专门分析raft的,篇幅所限,不能详细分析,有兴趣的建议看文末原始论文地址以及raft协议的一个动画。
便于看后面的文章,我这里简单做个总结:
1.raft通过对不同的场景(选主,日志复制)设计不同的机制,虽然降低了通用性(相对paxos),但同时也降低了复杂度,便于理解和实现。
2.raft内置的选主协议是给自己用的,用于选出主节点,理解raft的选主机制的关键在于理解raft的时钟周期以及超时机制。
3.理解Etcd的数据同步的关键在于理解raft的日志同步机制。
Etcd实现raft的时候,充分利用了go语言CSP并发模型和chan的魔法,想更进行一步了解的可以去看源码,这里只简单分析下它的wal日志。
wal日志是二进制的,解析出来后是以上数据结构LogEntry。
其中第一个字段type,只有两种,一种是0表示Normal,1表示ConfChange(ConfChange表示Etcd本身的配置变更同步,比如有新的节点加入等)。
第二个字段是term,每个term代表一个主节点的任期,每次主节点变更term就会变化。
第三个字段是index,这个序号是严格有序递增的,代表变更序号。
第四个字段是二进制的data,将raftrequest对象的pb结构整个保存下。
Etcd源码下有个tools/etcd-dump-logs,可以将wal日志dump成文本查看,可以协助分析raft协议。
raft协议本身不关心应用数据,也就是data中的部分,一致性都通过同步wal日志来实现,每个节点将从主节点收到的dataapply到本地的存储,raft只关心日志的同步状态,如果本地存储实现的有bug,比如没有正确的将dataapply到本地,也可能会导致数据不一致。
5、Etcdv2与v3
Etcdv2和v3本质上是共享同一套raft协议代码的两个独立的应用,接口不一样,存储不一样,数据互相隔离。
也就是说如果从Etcdv2升级到Etcdv3,原来v2的数据还是只能用v2的接口访问,v3的接口创建的数据也只能访问通过v3的接口访问。
所以我们按照v2和v3分别分析。
Etcdv2存储,Watch以及过期机制
Etcdv2是个纯内存的实现,并未实时将数据写入到磁盘,持久化机制很简单,就是将store整合序列化成json写入文件。
数据在内存中是一个简单的树结构。
比如以下数据存储到Etcd中的结构就如图所示。
/nodes/1/namenode1
/nodes/1/ip192.168.1.1
store中有一个全局的currentIndex,每次变更,index会加1.然后每个event都会关联到currentIndex.
当客户端调用watch接口(参数中增加wait参数)时,如果请求参数中有waitIndex,并且waitIndex小于currentIndex,则从EventHistroy表中查询index小于等于waitIndex,并且和watchkey匹配的event,如果有数据,则直接返回。
如果历史表中没有或者请求没有带waitIndex,则放入WatchHub中,每个key会关联一个watcher列表。
当有变更操作时,变更生成的event会放入EventHistroy表中,同时通知和该key相关的watcher。
这里有几个影响使用的细节问题:
1.EventHistroy是有长度限制的,最长1000。
也就是说,如果你的客户端停了许久,然后重新watch的时候,可能和该waitIndex相关的event已经被淘汰了,这种情况下会丢失变更。
2.如果通知watch的时候,出现了阻塞(每个watch的channel有100个缓冲空间),Etcd会直接把watcher删除,也就是会导致wait请求的连接中断,客户端需要重新连接。
3.Etcdstore的每个node中都保存了过期时间,通过定时机制进行清理。
从而可以看出,Etcdv2的一些限制:
1.过期时间只能设置到每个key上,如果多个key要保证生命周期一致则比较困难。
2.watch只能watch某一个key以及其子节点(通过参数recursive),不能进行多个watch。
3.很难通过watch机制来实现完整的数据同步(有丢失变更的风险),所以当前的大多数使用方式是通过watch得知变更,然后通过get重新获取数据,并不完全依赖于watch的变更event。
5、Etcdv3存储,Watch以及过期机制
Etcdv3将watch和store拆开实现,我们先分析下store的实现。
Etcdv3store分为两部分,一部分是内存中的索引,kvindex,是基于google开源的一个golang的btree实现的,另外一部分是后端存储。
按照它的设计,backend可以对接多种存储,当前使用的boltdb。
boltdb是一个单机的支持事务的kv存储,Etcd的事务是基于boltdb的事务实现的。
Etcd在boltdb中存储的key是reversion,value是Etcd自己的key-value组合,也就是说Etcd会在boltdb中把每个版本都保存下,从而实现了多版本机制。
举个例子:
用etcdctl通过批量接口写入两条记录:
etcdctltxn<<<'
putkey1"v1"
putkey2"v2"
'
再通过批量接口更新这两条记录:
etcdctltxn<<<'
putkey1"v12"
putkey2"v22"
'
boltdb中其实有了4条数据:
rev={30},key=key1,value="v1"
rev={31},key=key2,value="v2"
rev={40},key=key1,value="v12"
rev={41},key=key2,value="v22"
reversion主要由两部分组成,第一部分mainrev,每次事务进行加一,第二部分subrev,同一个事务中的每次操作加一。
如上示例,第一次操作的mainrev是3,第二次是4。
当然这种机制大家想到的第一个问题就是空间问题,所以Etcd提供了命令和设置选项来控制compact,同时支持put操作的参数来精确控制某个key的历史版本数。
了解了Etcd的磁盘存储,可以看出如果要从boltdb中查询数据,必须通过reversion,但客户端都是通过key来查询value,所以Etcd的内存kvindex保存的就是key和reversion之前的映射关系,用来加速查询。
然后我们再分析下watch机制的实现。
Etcdv3的watch机制支持watch某个固定的key,也支持watch一个范围(可以用于模拟目录的结构的watch),所以watchGroup包含两种watcher,一种是keywatchers,数据结构是每个key对应一组watcher,另外一种是rangewatchers,数据结构是一个IntervalTree(不熟悉的参看文文末链接),方便通过区间查找到对应的watcher。
同时,每个WatchableStore包含两种watcherGroup,一种是synced,一种是unsynced,前者表示该group的watcher数据都已经同步完毕,在等待新的变更,后者表示该group的watcher数据同步落后于当前最新变更,还在追赶。
当Etcd收到客户端的watch请求,如果请求携带了revision参数,则比较请求的revision和store当前的revision,如果大于当前revision,则放入synced组中,否则放入unsynced组。
同时Etcd会启动一个后台的goroutine持续同步unsynced的watcher,然后将其迁移到synced组。
也就是这种机制下,Etcdv3支持从任意版本开始watch,没有v2的1000条历史event表限制的问题(当然这是指没有compact的情况下)。
另外我们前面提到的,Etcdv2在通知客户端时,如果网络不好或者客户端读取比较慢,发生了阻塞,则会直接关闭当前连接,客户端需要重新发起请求。
Etcdv3为了解决这个问题,专门维护了一个推送时阻塞的watcher队列,在另外的goroutine里进行重试。
Etcdv3对过期机制也做了改进,过期时间设置在lease上,然后key和lease关联。
这样可以实现多个key关联同一个leaseid,方便设置统一的过期时间,以及实现批量续约。
相比Etcdv2,Etcdv3的一些主要变化:
1.接口通过grpc提供rpc接口,放弃了v2的http接口。
优势是长连接效率提升明显,缺点是使用不如以前方便,尤其对不方便维护长连接的场景。
2.废弃了原来的目录结构,变成了纯粹的kv,用户可以通过前缀匹配模式模拟目录。
3.内存中不再保存value,同样的内存可以支持存储更多的key。
4.watch机制更稳定,基本上可以通过watch机制实现数据的完全同步。
5.提供了批量操作以及事务机制,用户可以通过批量事务请求来实现Etcdv2的CAS机制(批量事务支持if条件判断)。
7、Etcd,Zookeeper,Consul比较
这三个产品是经常被人拿来做选型比较的。
Etcd和Zookeeper提供的能力非常相似,都是通用的一致性元信息存储,都提供watch机制用于变更通知和分发,也都被分布式系统用来作为共享信息存储,在软件生态中所处的位置也几乎是一样的,可以互相替代的。
二者除了实现细节,语言,一致性协议上的区别,最大的区别在周边生态圈。
Zookeeper是apache下的,用java写的,提供rpc接口,最早从hadoop项目中孵化出来,在分布式系统中得到广泛使用(hadoop,solr,kafka,mesos等)。
Etcd是coreos公司旗下的开源产品,比较新,以其简单好用的rest接口以及活跃的社区俘获了一批用户,在新的一些集群中得到使用(比如kubernetes)。
虽然v3为了性能也改成二进制rpc接口了,但其易用性上比Zookeeper还是好一些。
而Consul的目标则更为具体一些,Etcd和Zookeeper提供的是分布式一致性存储能力,具体的业务场景需要用户自己实现,比如服务发现,比如配置变更。
而Consul则以服务发现和配置变更为主要目标,同时附带了kv存储。
在软件生态中,越抽象的组件适用范围越广,但同时对具体业务场景需求的满足上肯定有不足之处。
服务发现
场景一:
服务发现(ServiceDiscovery)
服务发现要解决的也是分布式系统中最常见的问题之一,即在同一个分布式集群中的进程或服务,要如何才能找到对方并建立连接。
本质上来说,服务发现就是想要了解集群中是否有进程在监听udp或tcp端口,并且通过名字就可以查找和连接。
图1服务发现示意图
微服务协同工作架构中,服务动态添加。
随着Docker容器的流行,多种微服务共同协作,构成一个相对功能强大的架构的案例越来越多。
透明化的动态添加这些服务的需求也日益强烈。
通过服务发现机制,在etcd中注册某个服务名字的目录,在该目录下存储可用的服务节点的IP。
在使用服务的过程中,只要从服务目录下查找可用的服务节点去使用即可。
图2微服务协同工作
场景二:
消息发布与订阅
在分布式系统中,最适用的一种组件间通信方式就是消息发布与订阅。
即构建一个配置共享中心,数据提供者在这个配置中心发布消息,而消息使用者则订阅他们关心的主题,一旦主题有消息发布,就会实时通知订阅者。
通过这种方式可以做到分布式系统配置的集中式管理与动态更新。
图3消息发布与订阅
场景三:
分布式通知与协调
这里说到的分布式通知与协调,与消息发布和订阅有些相似。
都用到了etcd中的Watcher机制,通过注册与异步通知机制,实现分布式环境下不同系统之间的通知与协调,从而对数据变更做到实时处理。
实现方式通常是这样:
不同系统都在etcd上对同一个目录进行注册,同时设置Watcher观测该目录的变化(如果对子目录的变化也有需要,可以设置递归模式),当某个系统更新了etcd的目录,那么设置了Watcher的系统就会收到通知,并作出相应处理。
场景四:
分布式锁
因为etcd使用Raft算法保持了数据的强一致性,某次操作存储到集群中的值必然是全局一致的,所以很容易实现分布式锁。
锁服务有两种使用方式,一是保持独占,二是控制时序。
∙保持独占即所有获取锁的用户最终只有一个可以得到。
etcd为此提供了一套实现分布式锁原子操作CAS(CompareAndSwap)的API。
通过设置prevExist值,可以保证在多个节点同时去创建某个目录时,只有一个成功。
而创建成功的用户就可以认为是获得了锁。
∙控制时序,即所有想要获得锁的用户都会被安排执行,但是获得锁的顺序也是全局唯一的,同时决定了执行顺序。
etcd为此也提供了一套API(自动创建有序键),对一个目录建值时指定为POST动作,这样etcd会自动在目录下生成一个当前最大的值为键,存储这个新的值(客户端编号)。
同时还可以使用API按顺序列出所有当前目录下的键值。
此时这些键的值就是客户端的时序,而这些键中存储的值可以是代表客户端的编号。
∙
图4分布式锁
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ETCD 服务 发现