深入浅出etcd系列第1部分——etcd架构和代码框架 - 行业资讯

1,绪论
etcd作为华为云PaaS的核心部件,实现了PaaS大多数组件的数据持久化,集群选举,状态同步等功能。如此重要的一个部件,我们只有深入地理解其架构设计和内部工作机制,才能更好地学习华为云Kubernetes容器技术,笑傲云原生的“江湖”。本系列将从整体框架再细化到内部流程,对etcd的代码和设计进行全方位解读。本文是《深入浅出etcd》系列的第一篇,重点解析etcd的架构和代码框架,下文所用到的代码均基于etcd v3.2.X版本。

另,由华为云容器服务团队倾情打造的《云原生分布式存储基石:etcd深入解析》一书已正式出版,各大平台均有发售,购书可了解更多关于分布式键-值存储和etcd的相关内容!

2, etcd简介
etcd是一个分布式的键值存储系统,底层通过筏协议进行领导选举和数据备份,对外提供高可用的数据存储,能有效应对网络问题和机器故障带来的数据丢失问题。同时它还可以提供服务发现,分布式锁,分布式数据队列,分布式通知和协调,集群选举等功能。为什么etcd如此重要吗?因为etcd是Kubernetes的后端唯一存储实现,毫不夸张地说,etcd就是Kubernetes的“心脏”。

2.1筏协议
要理解etcd分布式协同的工作原理,必须提到筏算法.Raft算法是斯坦福的迭戈Ongaro,约翰Ousterhout两人以易懂(可理解性)为目标设计的一致性共识算法。在此之前,提到共识算法(共识算法)必然会提到Paxos,但是Paxos的实现和理解起来都非常复杂,以至于筏算法提出者的博士论文中,作者提到,他们用了将近一年时间研究这个算法的各种解释,但还是没有完全理解这个算法.Paxos的算法原理和真正实现也有很大的距离,实现Paxos的系统,如胖乎乎的,对Paxos进行了很多的改进有优化,但是细节却是不为人所知的。筏协议采用分治的思想,把分布式协同的问题分为3个问题:

选举:一个新的集群启动时,或者老的领袖故障时,会选举出一个新的领袖;

日志同步:领袖必须接受客户端的日志条目并且将他们同步到集群的所有机器;

安全:保证任何节点只要在它的状态机中生效了一条日志条目,就不会在相同的关键上生效另一条日志条目。

一个木筏集群一般包含数个节点,典型的是5个,这样可以承受其中2个节点故障。每个节点实际上就是维护一个状态机,节点在任何时候都处于以下三种状态中的一个。

领袖:负责日志的同步管理,处理来自客户端的请求,与追随者保持这心跳的联系;

追随者:刚启动时所有节点为追随者状态,响应领导的日志同步请求,响应候选人的请求,把请求到跟随者的事务转发给领袖;

候选人:负责选举投票,筏刚启动时由一个节点从追随者转为候选人发起选举,选举出领袖后从候选人转为领袖状态。

节点启动以后,首先都是追随者状态,在追随者状态下,会有一个选举超时时间的计时器(这个时间是在配置的超时时间基础上加一个随机的时间得来的)。如果在这个时间内没有收到领导人发送的心跳包,则节点状态会变成候选人状态,也就是变成了候选人,候选人会循环广播选举请求,如果超过半数的节点同意选举请求,则节点转化为领袖状态。如果在选举过程中,发现已经有了领袖或者有更高的任期值的选举信息,则自动变成从动件状态。处于领袖状态的节点如果发现有更高任期值的领袖存在,则也是自动变成从动件状态。

筏把时间划分为任期(词)(如下图所示),任期是一个递增的整数,一个任期是从开始选举领袖到领袖失效的这段时间。有点类似于一届总统任期,只是它的时间是不一定的,也就是说只要领袖工作状态良好,它可能成为一个独裁者,一直不下台。

2.2 etcd的代码整体架构

从大体上可以将其划分为以下4个模块:

http:负责对外提供http访问接口和http客户机

筏状态机:根据接受的木筏消息进行状态转移,调用各状态下的动作。

细胞膜日志存储:持久化存储日志条目。

相对于v2, v3的主要改动点为:

使用grpc进行同行之间和与客户端之间通信;