ETCD 与 服务发现

96
大象数据科学
0.6 2018.05.22 09:12* 字数 2123

1. 什么是ETCD

A highly-available key value store for shared configuration and service discovery.

用于配置共享和服务发现的键值存储系统,其四个核心特点:

简单:基于HTTP+JSON的API让你用curl命令就可以轻松使用。

安全:可选SSL客户认证机制。

快速:每个实例每秒支持一千次写操作。

可信:使用Raft算法充分实现了分布式。

2.  ETCD架构


图-2 ETCD组成结构图

HTTP Server:用于处理用户发送的API请求以及其它etcd节点的同步与心跳信息请求。

Store:用于处理etcd支持的各类功能的事务,包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等,是etcd对用户提供的大多数API功能的具体实现。

Raft:Raft强一致性算法的具体实现,是etcd的核心。

WAL:Write Ahead Log(预写式日志),是etcd的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外,etcd就通过WAL进行持久化存储。WAL中,所有的数据提交前都会事先记录日志。Snapshot是为了防止数据过多而进行的状态快照;Entry表示存储的具体日志内容。

通常,一个用户的请求发送过来,会经由HTTP Server转发给Store进行具体的事务处理,如果涉及到节点的修改,则交给Raft模块进行状态的变更、日志的记录,然后再同步给别的etcd节点以确认数据提交,最后进行数据的提交,再次同步。

2.1 ETCD 服务

在默认设定下,etcd 通过主机的 2379 端口向 Client 提供服务。如下图:

图3 ETCD服务示意图

每个主机上的应用程序都可以通过主机的 2379 以 HTTP + JSON 的方式向 etcd 读写数据。写入的数据会由 etcd 同步到集群的其它节点中。

2.2 Peers

在默认设定下,etcd 通过主机的 2380 端口在各个节点中同步 raft 状态及数据。

图4 peers同步

2.3 ETCD接口

ETCD提供HTTP协议,在最新版本中支持Google gRPC方式访问。具体支持接口情况如下:

    a. ETCD是一个高可靠的KV存储系统,支持PUT/GET/DELETE接口;

    b. 为了支持服务注册与发现,支持WATCH接口(通过http long poll实现);

    c. 支持KEY持有TTL属性;

    d. CAS(compare and swap)操作;

    e. 支持多key的事务操作;

    f.  支持目录操作

3. 应用场景

场景一:服务发现(Service Discovery)

服务发现要解决的也是分布式系统中最常见的问题之一,即在同一个分布式集群中的进程或服务,要如何才能找到对方并建立连接。本质上来说,服务发现就是想要了解集群中是否有进程在监听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 分布式锁

4. ETCD VS ZooKeeper

一致性协议: ETCD使用[Raft]协议, ZK使用ZAB(类PAXOS协议),前者容易理解,方便工程实现;

运维方面:ETCD方便运维,ZK难以运维;

项目活跃度:ETCD社区与开发活跃,ZK已经快死了;

API:ETCD提供HTTP+JSON, gRPC接口,跨平台跨语言,ZK需要使用其客户端;

访问安全方面:ETCD支持HTTPS访问,ZK在这方面缺失。

5. ETCD 词汇表

Raft:etcd所采用的保证分布式系统强一致性的算法。

Node:一个Raft状态机实例。

Member: 一个etcd实例。它管理着一个Node,并且可以为客户端请求提供服务。

Cluster:由多个Member构成可以协同工作的etcd集群。

Peer:对同一个etcd集群中另外一个Member的称呼。

Client: 向etcd集群发送HTTP请求的客户端。

WAL:预写式日志,etcd用于持久化存储的日志格式。

snapshot:etcd防止WAL文件过多而设置的快照,存储etcd数据状态。

Proxy:etcd的一种模式,为etcd集群提供反向代理服务。

Leader:Raft算法中通过竞选而产生的处理所有数据提交的节点。

Follower:竞选失败的节点作为Raft中的从属节点,为算法提供强一致性保证。

Candidate:当Follower超过一定时间接收不到Leader的心跳时转变为Candidate开始Leader竞选。

Term:某个节点成为Leader到下一次竞选开始的时间周期,称为一个Term。

Index:数据项编号。Raft中通过Term和Index来定位数据。


日记本