分布式键值存储系统-etcd

各模块功能：

• HTTP Server：用于处理用户发送的API请求以及其他etcd节点的同步与心跳信息请求
• Store：用于处理etcd支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是etcd对用户提供的大多数API功能的具体实现
• Raft：Raft强一致性算法的具体实现，是etcd的核心
• WAL：Write Ahead Log（预写式日志），是etcd的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外，etcd就通过WAL进行持久化存储。WAL中，所有的数据提交都会事先记录日志。Snapshot是为了防止数据过多而进行的状态快照；Entry表示数据的具体日志内容。

 

一个协调服务应该满足以下五大目标：

1. 可用性角度：高可用
2. 数据一致性角度：提供读取“最新”数据的机制
3. 容量角度：低容量、仅存储关键元数据配置
4. 功能：增删改查、监听数据变化的机制
5. 运维复杂度：可维护性

 

为什么CoreOS团队不用ZooKeeper，而要从0到1开发一个新的协调服务呢？

从高可用、数据一致性、功能的角度来说，Zookeeper满足CoreOS的诉求。然而当时的ZooKeeper不支持通过API安全地变更成员，需要人工修改一个个节点地配置，并重启进程，若变更方式不对，则有可能出现脑裂等严重故障。适配云环境、可平滑调整集群规模、在线变更运行时配置是CoreOS的期望目标，而Zoomkeeper在这块的维护成本较高。

其次ZooKeeper用Java编写，部署较繁琐，占用较多的内存资源，同时ZooKeeper RPC的序列化机制用的是Jute，自己实现的RPC API。无法使用cur之类的常用工具与之互动，CoreOS期望使用比较简单的HTTP+JSON

etcd基础架构：

各层功能如下：

• Client 层：Client 层包括 client v2 和 v3 两个大版本 API 客户端库，提供了简洁易用的 API，同时支持负载均衡、节点间故障自动转移，可极大降低业务使用 etcd 复杂度，提升开发效率、服务可用性。
• API 网络层：API 网络层主要包括 client 访问 server 和 server 节点之间的通信协议。一方面，client 访问 etcd server 的 API 分为 v2 和 v3 两个大版本。v2 API 使用 HTTP/1.x 协议，v3 API 使用 gRPC 协议。同时 v3 通过 etcd grpc-gateway 组件也支持 HTTP/1.x 协议，便于各种语言的服务调用。另一方面，server 之间通信协议，是指节点间通过 Raft 算法实现数据复制和 Leader 选举等功能时使用的 HTTP 协议。
• Raft 算法层：Raft 算法层实现了 Leader 选举、日志复制、ReadIndex 等核心算法特性，用于保障 etcd 多个节点间的数据一致性、提升服务可用性等，是 etcd 的基石和亮点。
• 功能逻辑层：etcd 核心特性实现层，如典型的 KVServer 模块、MVCC 模块、Auth 鉴权模块、Lease 租约模块、Compactor 压缩模块等，其中 MVCC 模块主要由 treeIndex 模块和 boltdb 模块组成。
• 存储层：存储层包含预写日志 (WAL) 模块、快照 (Snapshot) 模块、boltdb 模块。其中 WAL 可保障 etcd crash 后数据不丢失，boltdb 则保存了集群元数据和用户写入的数据。