Docs

Appearance

08纵览全局：etcd的架构是什么样的？ ​

从这一讲开始，我们将深入 etcd 组件的内部，进一步了解其架构以及核心功能实现的原理。了解 etcd 的实现原理，能够帮助我们日常使用etcd 时更加得心应手，遇到问题能更快地排查定位。

今天我们先从整体上介绍 etcd 组件的架构，了解etcd 内部各个模块之间的交互，总览 etcd。

etcd 项目结构 ​

在介绍 etcd 整体的架构之前，我们先来看一下 etcd 项目代码的目录结构：

java
$ tree
.
├── auth
├── build
├── client
├── clientv3
├── contrib
├── embed
├── etcdctl
├── etcdmain
├── etcdserver
├── functional
├── hack
├── integration
├── lease
├── logos
├── mvcc
├── pkg
├── proxy
├── raft
├── scripts
├── security
├── tests
├── tools
├── vendor
├── version
└── wal

可以看到，etcd 的包还是挺多的，有二十多个。接下来我们来具体分析下其中每一个包的职责定义，整理之后如下表所示：

etcd 核心的模块有 lease、mvcc、raft、etcdserver，其余都是辅助的功能。其中 etcdserver 是其他模块的整合。

etcd 整体架构 ​

接下来，我们看看etcd 的整体架构。我在上面的etcd 项目总览中提到了 etcd 中核心的几个模块，我们使用分层的方式来描绘 etcd 的架构图，如下所示：

  • 客户端层 ：包括 clientv3 和 etcdctl 等客户端。用户通过命令行或者客户端调用提供了 RESTful 风格的API，降低了 etcd的使用复杂度。除此之外，客户端层的负载均衡（etcd V3.4 版本的客户端默认使用的是 Round-robin，即轮询调度）和节点间故障转移等特性，提升了etcd 服务端的高可用性。需要注意的是，etcd V3.4之前版本的客户端存在负载均衡的 Bug，如果第一个节点出现异常，访问服务端时也可能会出现异常，建议进行升级。

  • API 接口层 ：API 接口层提供了客户端访问服务端的通信协议和接口定义，以及服务端节点之间相互通信的协议，我将会在下一讲重点讲解 etcd的通信接口。etcd 有 V3和V2 两个版本。etcd V3 使用gRPC 作为消息传输协议；对于之前的V2 版本，etcd 默认使用HTTP/1.x 协议。对于不支持 gRPC的客户端语言，etcd 提供 JSON的grpc-gateway。通过 grpc-gateway 提供 RESTful 代理，转换 HTTP/JSON 请求为 gRPC 的 Protocol Buffer 格式的消息。这部分内容我们在 05 讲"gRPC 代理模式：实现可伸缩的 etcd API"具体做了讲解，这里我们就不再展开了。

  • etcd Raft 层 ：负责 Leader 选举和日志复制等功能，除了与本节点的 etcd Server 通信之外，还与集群中的其他 etcd 节点进行交互，实现分布式一致性数据同步的关键工作。

  • 逻辑层：etcd 的业务逻辑层，包括鉴权、租约、KVServer、MVCC 和 Compactor 压缩等核心功能特性。

  • etcd 存储：实现了快照、预写式日志 WAL（Write Ahead Log）。etcd V3 版本中，使用 BoltDB 来持久化存储集群元数据和用户写入的数据。

下面我们看一下 etcd 各个模块之间的交互过程。

etcd 交互总览 ​

我们通过学习 etcd 服务端处理客户端的写请求的过程，展示 etcd 内部各个模块之间的交互。首先通过命令行工具 etcdctl 写入键值对：

java
etcdctl --endpoints http://127.0.0.1:2379 put foo bar

下图中展示了 etcd 处理一个客户端请求涉及的模块和流程。

从上至下依次为客户端 → API 接口层 → etcd Server → etcd raft 算法库。我们根据请求处理的过程，将 etcd Server 和 etcd raft 算法库单独说明。

  • etcd Server：接收客户端的请求，在上述的etcd 项目代码中对应etcdserver 包。请求到达 etcd Server 之后，经过 KVServer 拦截，实现诸如日志、Metrics 监控、请求校验等功能。etcd Server 中的raft模块，用于与 etcd-raft 库进行通信。applierV3 模块封装了 etcd V3 版本的数据存储；WAL 用于写数据日志，WAL中保存了任期号、投票信息、已提交索引、提案内容等，etcd 根据 WAL 中的内容在启动时恢复，以此实现集群的数据一致性。

  • etcdraft：etcd 的raft 库。raftLog 用于管理 raft 协议中单个节点的日志，都处于内存中。raftLog 中还有两种结构体 unstable和storage，unsable 中存储不稳定的数据，表示还没有 commit，而 storage中都是已经被 commit 了的数据。这两种结构体分别用于不同步骤的存储，我们将在下面的交互流程中介绍。除此之外，raft 库更重要的是负责与集群中的其他 etcd Server进行交互，实现分布式一致性。

在上图中，客户端请求与 etcd 集群交互包括如下两个步骤：

  • 首先是写数据到 etcd 节点中；

  • 其次是当前的 etcd 节点与集群中的其他 etcd 节点之间进行通信，确认存储数据成功之后回复客户端。

请求流程可划分为以下的子步骤：

  • 客户端通过负载均衡算法选择一个 etcd 节点，发起 gRPC 调用；

  • etcd Server 收到客户端请求；

  • 经过 gRPC 拦截、Quota 校验，Quota 模块用于校验 etcd db 文件大小是否超过了配额；

  • 接着 KVServer 模块将请求发送给本模块中的raft，这里负责与 etcd raft模块进行通信；

  • 发起一个提案，命令为put foo bar，即使用put 方法将 foo 更新为 bar；

  • 在raft 中会将数据封装成 raft 日志的形式提交给 raft模块；

  • raft模块会首先保存到 raftLog 的 unstable 存储部分；

  • raft模块通过raft 协议与集群中其他 etcd 节点进行交互。

需要注意的是，在 raft 协议中写入数据的 etcd 必定是 leader 节点，如果客户端提交数据到非 leader 节点时，该节点需要将请求转发到 etcd leader 节点处理。

我们继续来看相应的应答步骤，流程如下：

  • 提案通过 RaftHTTP 网络模块转发，集群中的其他节点接收到该提案；

  • 在收到提案之后，集群中其他节点向 leader 节点应答"我已经接收这条日志数据"；

  • Leader收到应答之后，统计应答的数量，当满足超过集群半数以上节点，应答接收成功；

  • etcd raft算法模块构造 Ready 结构体，用来通知 etcd Server 模块，该日志数据已经被 commit；

  • etcd Server 中的 raft 模块（交互图中有标识），收到 Ready 消息后，会将这条日志数据写入到 WAL 模块中；

  • 正式通知 etcd Server 该提案已经被 commit；

  • etcd Server 调用 applierV3 模块，将日志写入持久化存储中；

  • etcd Server 应答客户端该数据写入成功；

  • etcd Server 调用 etcd raft 库，将这条日志写入到 raftLog 模块中的 storage。

上述过程中，提案经过网络转发，当多数etcd 节点持久化日志数据成功并进行应答，提案的状态会变成已提交。

在应答某条日志数据是否已经 commit 时，为什么 etcd raft 模块首先写入到 WAL 模块中？这是因为该过程仅仅添加一条日志，一方面开销小，速度会很快；另一方面，如果在后面 applierV3 写入失败，etcd 服务端在重启的时候也可以根据 WAL 模块中的日志数据进行恢复。etcd Server 从 raft 模块获取已提交的日志条目，由 applierV3 模块通过 MVCC 模块执行提案内容，更新状态机。

整个过程中，etcd raft 模块中的 raftLog 数据在内存中存储，在服务重启后失效；客户端请求的数据则被持久化保存到 WAL 和 applierV3 中，不会在重启之后丢失。

小结 ​

这一讲我们主要介绍了 etcd 整体的架构。首先通过 etcd 项目结构，介绍了各个包的用途，并介绍了其中核心的包；接着基于分层的方式，绘制了 etcd 分层架构图，结合图介绍了各个模块的作用；最后通过客户端写入 etcd 服务端的请求，理解 etcd 各个模块交互的过程。

本讲内容总结如下：

本课时通过总览 etcd 的架构，将其重要的模块标识出来，如 etcd raft 模块、WAL、applierV3、Quota 等模块，也为我们下面具体介绍 etcd 的原理做一个铺垫。

学习完本课时，从上述 etcd 各个模块的交互过程，你知道有哪些方式保证了 etcd 写请求保证分布式一致性？欢迎你在留言区和我分享你的学习收获。

下一讲，我们将开始学习 etcd 的 API 接口层，看看 etcd 定义了哪些 API 接口并进行实践。