1. 什么是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 提供服务。如下图：

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

2.2 Peers

在预设设定下，etcd 通过主机的 2380 埠在各个节点中同步 raft 状态及资料。

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. 应用场景

服务发现要解决的也是分散式系统中最常见的问题之一，即在同一个分散式丛集中的程序或服务，要如何才能找到对方并建立连线。本质上来说，服务发现就是想要了解丛集中是否有程序在监听udp或tcp埠，并且通过名字就可以查询和连线。

微服务协同工作架构中，服务动态新增。随着Docker容器的流行，多种微服务共同协作，构成一个相对功能强大的架构的案例越来越多。透明化的动态新增这些服务的需求也日益强烈。通过服务发现机制，在etcd中注册某个服务名字的目录，在该目录下储存可用的服务节点的IP。在使用服务的过程中，只要从服务目录下查询可用的服务节点去使用即可。

场景二：讯息释出与订阅

在分散式系统中，最适用的一种元件间通讯方式就是讯息释出与订阅。即构建一个配置共享中心，资料提供者在这个配置中心释出讯息，而讯息使用者则订阅他们关心的主题，一旦主题有讯息释出，就会实时通知订阅者。通过这种方式可以做到分散式系统配置的集中式管理与动态更新。

场景三：分散式通知与协调

这里说到的分散式通知与协调，与讯息释出和订阅有些相似。都用到了etcd中的Watcher机制，通过注册与异步通知机制，实现分散式环境下不同系统之间的通知与协调，从而对资料变更做到实时处理。实现方式通常是这样：不同系统都在etcd上对同一个目录进行注册，同时设定Watcher观测该目录的变化（如果对子目录的变化也有需要，可以设定递回模式），当某个系统更新了etcd的目录，那么设定了Watcher的系统就会收到通知，并作出相应处理。

场景四：分散式锁

因为etcd使用Raft算法保持了资料的强一致性，某次操作储存到丛集中的值必然是全域性一致的，所以很容易实现分散式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。

保持独占即所有获取锁的使用者最终只有一个可以得到。etcd为此提供了一套实现分散式锁原子操作CAS（CompareAndSwap）的API。通过设定prevExist值，可以保证在多个节点同时去建立某个目录时，只有一个成功。而建立成功的使用者就可以认为是获得了锁。

控制时序，即所有想要获得锁的使用者都会被安排执行，但是获得锁的顺序也是全域性唯一的，同时决定了执行顺序。etcd为此也提供了一套API（自动建立有序键），对一个目录建值时指定为POST动作，这样etcd会自动在目录下生成一个当前最大的值为键，储存这个新的值（客户端编号）。同时还可以使用API按顺序列出所有当前目录下的键值。此时这些键的值就是客户端的时序，而这些键中储存的值可以是代表客户端的编号。

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来定位资料。