PowerDotNet平台化软件架构设计与实现系列（05）：ETCD分布式键值存储平台

ETCD目前在PowerDotNet已经被用于注册中心和配置管理（常见的配置中心在PowerDotNet中仅仅是一个小小的模块而已）中，作为基础设施的重要组成部分，ETCD的重要性不言而喻。

本文简单总结介绍下个人开发使用和管理ETCD的一些经验。

ETCD诞生于CoreOS公司，它最初是用于解决集群管理系统中OS升级的分布式并发控制以及配置文件的存储与分发等问题。

按照官方解释（A distributed, reliable key-value store for the most critical data of a distributed system），ETCD是一个分布式的可靠的键值对存储系统，用于存储分布式系统中的关键数据。

对于熟悉ZooKeeper的人来说，ETCD提供的功能和ZooKeeper非常相似，比如都是通用的一致性元信息存储，都提供watch机制用于变更通知和分发，也都被分布式系统用来作为共享信息存储等。

实际上，据说ETCD就是受到ZooKeeper与doozerd启发而催生的一个项目，除了拥有与之类似的功能外，更专注于以下四点：

1、简单：基于 HTTP+JSON的API让你用curl就可以轻松使用

2、安全：可选 SSL 客户认证机制

3、快速：每个实例每秒支持一千次写操作

4、可信：使用 Raft 算法充分实现了分布式

下面两段介绍下ETCD基础概念和工作原理，主要抄书，特别鸣谢这篇文章作者，对个人理解提高非常有帮助。

一、ETCD构成

ETCD主要分为四个部分：

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

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

3、Raft：Raft强一致性算法的具体实现，是ETCD的核心。

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

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

ETCD作为一个高可用键值存储系统，天生就是为集群化而设计的。ETCD有三种集群化启动的配置方案，分别为静态配置启动、ETCD自身服务发现、通过DNS进行服务发现。

从图上我们能看到，一个 ETCD集群，通常会由 3 个或者 5 个节点组成（由于Raft算法在做决策时需要多数节点的投票，所以ETCD一般部署集群推荐奇数个节点，推荐的数量为3、5或者7个节点构成一个集群），多个节点之间通过 Raft 一致性算法的完成分布式一致性协同，算法会选举出一个主节点作为 leader，由 leader 负责数据的同步与数据的分发。当 leader 出现故障后系统会自动地选取另一个节点成为 leader，并重新完成数据的同步。客户端在多个节点中，仅需要选择其中的任意一个就可以完成数据的读写，内部的状态及数据协同由 ETCD 自身完成。

这里再小结下ETCD的重要概念：

Raft：Etcd 的核心，保证分布式系统强一致性的算法。

Node：一个 Raft 状态机实例。

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

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

Peer：对同一个 Etcd 集群中另外一个 Member 的称呼。

Client： 向 Etcd 集群发送 HTTP 请求的客户端。

WAL：预写式日志，Etcd 用于持久化存储的日志格式。

Snapshot：Etcd 防止 WAL 文件过多而设置的快照，存储 Etcd 数据状态。

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

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

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

Term：某个节点成为 Leader 到下一次竞选期间，称为一个 Term（任期）。

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

二、ETCD常见使用场景

1、服务发现（Service Discovery）

2、消息发布与订阅

3、负载均衡

4、分布式通知与协调

5、分布式锁

6、分布式队列

7、集群监控与Leader竞选

有这样多的常见应用场景，ETCD不可谓不强大，现在在绝大多数互联网应用中完全可以取代运维管理复杂的ZooKeeper。

三、ETCD管理

基础概念介绍结束，终于盼到了激动人心的实践环节^_^。

要复用ETCD功能，我们就要开发强大灵活的后台动态配置管理ETCD，当然我们也完全可以用现成的工具如etcd-manager进行ETCD管理。

1、ETCD集群

2、ETCD服务器

针对集群中的每台ETCD服务器，可以精准定位，进行统计、增删改数据等操作。

比如统计：

查看键值对：

比如配置中心的配置

查看键值对明细

或者API接口应用部署信息

再比如说一些常见工具

如集群：

用户角色和权限

动态工具等：

管理后台针对常见应用场景，有针对性的进行了开发改进和优化，为此还进行了ETCD客户端（Power.Etcd）的开发：

这个客户端项目有机会整理开源出来，主要是有部分PowerDotNet项目专用逻辑和依赖需要清理。

3、ETCD分组

对于大中型企业来说，ETCD的使用场景还是非常非常多的，必须进行统筹管理，否则迟早会有运维和管理难题。

PowerDotNet完美支持按照系统和应用进行ETCDRoute绑定，做到按组管理。

先定义ETCDRoute，一个ETCDRoute等同于一个分布式键值对分组：

将ETCDRoute绑定到具体应用，这样业务系统只要调用封装好的公共SDK（分布式分布式键值对客户端SDK命名为Power.Etcd）就能自动获取分布式键值对能力，甚至不用写任何配置，直接在配置中心，点点按钮搞定一切，实在是太省心了。

有了ETCD分布式键值对管理平台，能够最大程度的复用ETCD，接入的应用更加容易管理和运维，排查和定位问题更加方便简洁高效。

参考：

https://etcd.io/

https://github.com/etcd-io/etcd

https://www.infoq.cn/article/etcd-interpretation-application-scenario-implement-principle

https://www.cnblogs.com/alisystemsoftware/p/12016601.html

https://etcdmanager.io/

https://blog.csdn.net/shlazww/article/details/38736511

https://www.jianshu.com/p/5aed73b288f7

http://thesecretlivesofdata.com/raft