likes
comments
collection
share

「容器管理系统」开发篇：7. 初识 ETCD

作者站长头像
站长
· 阅读数 29

回顾

项目已开源：基于 Golang 的 容器管理系统

什么是 ETCD ？

etcd是一个强一致的分布式键值存储，它提供了一种可靠的方式来存储需要由分布式系统或机器集群访问的数据。通过分布式锁，leader选举和写屏障(write barriers)来实现可靠的分布式协作。etcd集群是为高可用，持久性数据存储和检索而准备。

Etcd 本身是 CoreOS 基于 Raft 协议开发的分布式 key-value 存储，可用于服务发现、共享配置以及一致性保障（如数据库选主、分布式锁等）

「容器管理系统」开发篇：7. 初识 ETCD

ETCD 的历史背景

etcd这个名字源于两个想法，即　unix "/etc" 文件夹和分布式系统"d"istibuted。 "/etc" 文件夹为单个系统存储配置数据的地方，而 etcd 存储大规模分布式系统的配置信息。因此，"d"istibuted　的 "/etc" ，是为 "etcd"。

etcd 是 CoreOS 团队于 2013 年 6 月发起的开源项目，它的目标是构建一个高可用的分布式键值（key-value）数据库，基于 Go 语言实现。

  • 2013年6月，由CoreOS团队于发布的开源。
  • 2014年6月，作为Kubernetes核心元数据的存储服务一起发布，自此ETCD社区得到飞速发展。
  • 2015年2月，发布了第一个正式稳定版本2.0，重构了Raft一致性算法，提供了用户树形数据视图，支持每秒超过1000次的写入性能。
  • 2017年1月，发布了3.1版本，提供了一套全新的API，同时提供了gRPC接口，通过gRPC的proxy扩展并极大地提高ETCD的读取性能，支持每秒超过10000次的写入。
  • 2018年11月，项目进入CNCF的孵化项目。
  • 2019年8月，发布了3.4版本，该版本由Google、Alibaba等公司联合打造，进一步改进etcd的性能及稳定性。
  • 2021年7月，发布了3.5版本，支持Go Module版本号语义及模块化，提升了性能及稳定性，增强了集群运维能力。

为什么要用 ETCD ？

所有的分布式系统，都面临的一个问题是多个节点之间的数据共享问题，这个和团队协作的道理是一样的，成员可以分头干活，但总是需要共享一些必须的信息，比如谁是 leader， 都有哪些成员，依赖任务之间的顺序协调等。

所以分布式系统要么自己实现一个可靠的共享存储来同步信息（比如 Elasticsearch ），要么依赖一个可靠的共享存储服务，而 Etcd 就是这样一个服务。

ETCD 有什么能力？

Etcd 主要提供以下能力：

  1. 提供存储以及获取数据的接口，它通过协议保证 Etcd 集群中的多个节点数据的强一致性。用于存储元信息以及共享配置。
  2. 提供监听机制，客户端可以监听某个key或者某些key的变更（v2和v3的机制不同，参看后面文章）。用于监听和推送变更。
  3. 提供key的过期以及续约机制，客户端通过定时刷新来实现续约（v2和v3的实现机制也不一样）。用于集群监控以及服务注册发现。
  4. 提供原子的CAS（Compare-and-Swap）和 CAD（Compare-and-Delete）支持（v2通过接口参数实现，v3通过批量事务实现）。用于分布式锁以及leader选举。

etcd可以扮演两大角色：

  1. 持久化的键值存储系统
  2. 分布式系统数据一致性服务提供者

ETCD 如何实现一致性？

etcd 集群使用 Raft 协议保障多节点集群状态下的数据一致性。etcd 是使用 Go 语言对 Raft 协议一种实现方式。

在 Raft 体系中，有一个强 leader，由它全权负责接收客户端的请求命令，并将命令作为日志条目复制给其他服务器，在确认安全的时候，将日志命令提交执行。当 leader 故障时，会选举产生一个新的 leader。在强 leader 的帮助下，Raft将一致性问题分解为了三个子问题：

  • Leader 选举： 当已有的leader故障时必须选出一个新的leader。
  • 日志复制： leader接受来自客户端的命令，记录为日志，并复制给集群中的其他服务器，并强制其他节点的日志与leader保持一致。
  • 安全 safety 措施： 通过一些措施确保系统的安全性，如确保所有状态机按照相同顺序执行相同命令的措施。

解这三个子问题的过程，保障了数据的一致。

etcd 只是 Raft 协议的一种实现机制，如果对协议理解足够深，也可以自己用其他语言实现。

ETCD V2 和 V3 的区别

Etcd v2 和 v3 本质上是共享同一套 raft 协议代码的两个独立的应用，接口不一样，存储不一样，数据互相隔离。

也就是说如果从 Etcd v2 升级到 Etcd v3，原来v2 的数据还是只能用 v2 的接口访问，v3 的接口创建的数据也只能访问通过 v3 的接口访问。

  • Etcd v2 存储，Watch 以及过期机制

「容器管理系统」开发篇：7. 初识 ETCD

  • Etcd v3 存储，Watch 以及过期机制

「容器管理系统」开发篇：7. 初识 ETCD

ETCD 的核心竞争力

etcd 的核心优势是使用简洁的方式实现 Raft 协议。

etc 在设计的时候重点考虑了如下的四个要素：

  1. 简单

    • 支持RESTful风格的HTTP+JSON的API
    • v3版本增加了对gRPC的支持 同时也提供rest gateway进行转化
    • Go语言编写，跨平台，部署和维护简单
    • 使用Raft算法保证强一致性，Raft算法可理解性好

  2. 安全

    • 支持TLS客户端安全认证

  3. 性能

    • 单实例(V3)支持每秒10KQps

  4. 可靠

    • 使用 Raft 算法充分保证了分布式系统数据的强一致性 etcd 集群是一个分布式系统，由多个节点相互通信构成整体的对外服务，每个节点都存储了完整的数据，并且通过 Raft 协议保证了每个节点维护的数据都是一致的。

Etcd，Zookeeper，Consul 比较

这三个产品是经常被人拿来做选型比较的。

  • Etcd
    • Etcd 和 Zookeeper 提供的能力非常相似，都是通用的一致性元信息存储，都提供watch机制用于变更通知和分发，也都被分布式系统用来作为共享信息存储，在软件生态中所处的位置也几乎是一样的，可以互相替代的。二者除了实现细节，语言，一致性协议上的区别，最大的区别在周边生态圈。
  • Zookeeper
    • Zookeeper 是apache下的，用java写的，提供rpc接口，最早从hadoop项目中孵化出来，在分布式系统中得到广泛使用（hadoop, solr, kafka, mesos 等）。Etcd 是coreos公司旗下的开源产品，比较新，以其简单好用的rest接口以及活跃的社区俘获了一批用户，在新的一些集群中得到使用（比如kubernetes）。虽然v3为了性能也改成二进制rpc接口了，但其易用性上比 Zookeeper 还是好一些。
  • Consul
    • Consul 的目标则更为具体一些，Etcd 和 Zookeeper 提供的是分布式一致性存储能力，具体的业务场景需要用户自己实现，比如服务发现，比如配置变更。而Consul 则以服务发现和配置变更为主要目标，同时附带了kv存储。 在软件生态中，越抽象的组件适用范围越广，但同时对具体业务场景需求的满足上肯定有不足之处。

结束语

本节主要讲述了：

  • ETCD 的由来，历史背景
  • 为什么要用ETCD？
  • ETCD 的核心竞争力
  • ETCD V2 和 V3 版本的区别
  • ETCD 与其他同类型产品的优缺点