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

发布于 2022年 01月 24日 00:50

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

推荐文章