11-06 5 views
1. 什么是etcd
A highly-available key value store for shared configuration and service discovery.
用于配置共享和服务发现的键值存储系统，其四个核心特点：
简单：基于HTTP+JSON的API让你用curl命令就可以轻松使用。
安全：可选SSL客户认证机制。
快速：每个实例每秒支持一千次写操作。
可信：使用Raft算法充分实现了分布式。
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节点以确认数据提交，最后进行数据的提交，再次同步
3. etcd服务
在默认设定下，etcd 通过主机的 2379 端口向 Client 提供服务。如下图：
每个主机上的应用程序都可以通过主机的 2379 以 HTTP + JSON 的方式向 etcd 读写数据。写入的数据会由 etcd 同步到集群的其它节点中。
4. Peers
在默认设定下，etcd 通过主机的 2380 端口在各个节点中同步 raft 状态及数据。
5. 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. 支持目录操作
6. 应用场景
场景一:
服务发现（Service Discovery）服务发现要解决的也是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听udp或tcp端口，并且通过名字就可以查找和连接。
微服务协同工作架构中，服务动态添加。随着Docker容器的流行，多种微服务共同协作，构成一个相对功能强大的架构的案例越来越多。透明化的动态添加这些服务的需求也日益强烈。通过服务发现机制，在etcd中注册某个服务名字的目录，在该目录下存储可用的服务节点的IP。在使用服务的过程中，只要从服务目录下查找可用的服务节点去使用即可。
场景二：消息发布与订阅
在分布式系统中，最适用的一种组件间通信方式就是消息发布与订阅。即构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者则订阅他们关心的主题，一旦主题有消息发布，就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。
场景三：分布式通知与协调
这里说到的分布式通知与协调，与消息发布和订阅有些相似。都用到了etcd中的Watcher机制，通过注册与异步通知机制，实现分布式环境下不同系统之间的通知与协调，从而对数据变更做到实时处理。实现方式通常是这样：不同系统都在etcd上对同一个目录进行注册，同时设置Watcher观测该目录的变化（如果对子目录的变化也有需要，可以设置递归模式），当某个系统更新了etcd的目录，那么设置了Watcher的系统就会收到通知，并作出相应处理。
场景四：分布式锁
因为etcd使用Raft算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。保持独占即所有获取锁的用户最终只有一个可以得到。etcd为此提供了一套实现分布式锁原子操作CAS（CompareAndSwap）的API。通过设置prevExist值，可以保证在多个节点同时去创建某个目录时，只有一个成功。而创建成功的用户就可以认为是获得了锁。控制时序，即所有想要获得锁的用户都会被安排执行，但是获得锁的顺序也是全局唯一的，同时决定了执行顺序。etcd为此也提供了一套API（自动创建有序键），对一个目录建值时指定为POST动作，这样etcd会自动在目录下生成一个当前最大的值为键，存储这个新的值（客户端编号）。同时还可以使用API按顺序列出所有当前目录下的键值。此时这些键的值就是客户端的时序，而这些键中存储的值可以是代表客户端的编号。
7. 对比其它key-value stores
etcd versus other key-value stores
8. etcd VS ZooKeeper
一致性协议： ETCD使用[Raft]协议， ZK使用ZAB（类PAXOS协议），前者容易理解，方便工程实现
运维方面：ETCD方便运维，ZK难以运维
项目活跃度：ETCD社区与开发活跃，ZK已经快死了
API：ETCD提供HTTP+JSON, gRPC接口，跨平台跨语言，ZK需要使用其客户端
访问安全方面：ETCD支持HTTPS访问，ZK在这方面缺失
9. 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来定位数据
作者：大象数据科学
链接：https://www.jianshu.com/p/3bd041807974
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
