k8s etcd简介

etcd简介

etcd是一个非常可靠的kv存储系统，常在分布式系统中存储着关键的数据。它是由coreos团队开发并开源的分布式键值存储系统，具备以下特点：

• 简单：提供定义明确且面向用户的API
• 安全：支持SSL证书验证
• 性能：基准压测支持1w+/sec写入
• 可靠：采用Raft协议保证分布式系统数据的可用性和一致性。

etcd的这些特性，使得它常常出现在分布式设计场景下的工具集中。它在现代化的集群运行中能够起到关键性的作用。

etcd项目地址：https://github.com/coreos/etcd/

etcd常见功能

• 键值存储、查询功能：支持精准查询、range操作、ttl机制、key版本等。
• 一致性机制：采用raft协议保证强一致性。
• 可用性机制：提供集群和leader选举机制。
• SSL认证机制。
• watch机制。

 etcd常见应用场景

1. 配置中心

etcd是一个分布式的键值存储系统，其优秀的读写性能、一致性和可用性的机制，非常适合用来做配置中心角色。

2. 分布式锁

etcd 使用 Raft 算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。

• 保持独占即所有获取锁的用户最终只有一个可以得到。etcd 为此提供了一套实现分布式锁原子操作 CAS（CompareAndSwap）的 API。通过设置prevExist值，可以保证在多个节点同时去创建某个目录时，只有一个成功。而创建成功的用户就可以认为是获得了锁。
• 控制时序，即所有想要获得锁的用户都会被安排执行，但是获得锁的顺序也是全局唯一的，同时决定了执行顺序。etcd 为此也提供了一套 API（自动创建有序键），对一个目录建值时指定为POST动作，这样 etcd 会自动在目录下生成一个当前最大的值为键，存储这个新的值（客户端编号）。同时还可以使用 API 按顺序列出所有当前目录下的键值。此时这些键的值就是客户端的时序，而这些键中存储的值可以是代表客户端的编号。

3. leader选举组件

通过 etcd 来进行监控实现起来非常简单并且实时性强。

• 前面几个场景已经提到 Watcher 机制，当某个节点消失或有变动时，Watcher 会第一时间发现并告知用户。
• 节点可以设置TTL key，比如每隔 30s 发送一次心跳使代表该机器存活的节点继续存在，否则节点消失。

这样就可以第一时间检测到各节点的健康状态，以完成集群的监控要求。

另外，使用分布式锁，可以完成 Leader 竞选。这种场景通常是一些长时间 CPU 计算或者使用 IO 操作的机器，只需要竞选出的 Leader 计算或处理一次，就可以把结果复制给其他的 Follower。从而避免重复劳动，节省计算资源。

这个的经典场景是搜索系统中建立全量索引。如果每个机器都进行一遍索引的建立，不但耗时而且建立索引的一致性不能保证。通过在 etcd 的 CAS 机制同时创建一个节点，创建成功的机器作为 Leader，进行索引计算，然后把计算结果分发到其它节点。

分布式场景下，常采用leader-follower模式来保证有状态服务的高可用（即使leader挂掉，其他follower立马补上），比如k8s和kafka partition高可用机制。可以很方便的借助etcd来实现leader选举机制，这里有个leader election实现：https://github.com/willstudy/leaderelection

4. 服务注册与服务发现

为了解决微服务场景下，服务地址的注册和发现问题。和配置中心功能类似，不同之处在于服务注册和服务发现，还伴随着状态检测。

在同一个分布式集群中的进程或服务如何才能找到对方并建立连接。从本质上说，服务发现就是要了解集群中是否有进程在监听udp或者tcp端口，并且通过名字就可以进行查找和链接。

要解决服务发现的问题，需要下面三大支柱，缺一不可。

• 一个强一致性、高可用的服务存储目录。

基于Ralf算法的etcd天生就是这样一个强一致性、高可用的服务存储目录。

• 一种注册服务和健康服务健康状况的机制。

用户可以在etcd中注册服务，并且对注册的服务配置key TTL，定时保持服务的心跳以达到监控健康状态的效果。

• 一种查找和连接服务的机制。

通过在etcd指定的主题下注册的服务业能在对应的主题下查找到。为了确保连接，我们可以在每个服务机器上都部署一个proxy模式的etcd，这样就可以确保访问etcd集群的服务都能够互相连接。

5. 消息订阅和发布

etcd内置watch机制，完全可以实现一个小型的消息订阅和发布组件。

在分布式系统中，最适用的一种组件间通信方式就是消息发布与订阅。即构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者则订阅他们关心的主题，一旦主题有消息发布，就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。

• 应用中用到的一些配置信息放到 etcd 上进行集中管理。这类场景的使用方式通常是这样：应用在启动的时候主动从 etcd 获取一次配置信息，同时，在 etcd 节点上注册一个 Watcher 并等待，以后每次配置有更新的时候，etcd 都会实时通知订阅者，以此达到获取最新配置信息的目的。
• 分布式搜索服务中，索引的元信息和服务器集群机器的节点状态存放在 etcd 中，供各个客户端订阅使用。使用 etcd 的key TTL功能可以确保机器状态是实时更新的。
• 分布式日志收集系统。这个系统的核心工作是收集分布在不同机器的日志。收集器通常是按照应用（或主题）来分配收集任务单元，因此可以在 etcd 上创建一个以应用（主题）命名的目录 P，并将这个应用（主题相关）的所有机器 ip，以子目录的形式存储到目录 P 上，然后设置一个 etcd 递归的 Watcher，递归式的监控应用（主题）目录下所有信息的变动。这样就实现了机器 IP（消息）变动的时候，能够实时通知到收集器调整任务分配。
• 系统中信息需要动态自动获取与人工干预修改信息请求内容的情况。通常是暴露出接口，例如 JMX 接口，来获取一些运行时的信息。引入 etcd 之后，就不用自己实现一套方案了，只要将这些信息存放到指定的 etcd 目录中即可，etcd 的这些目录就可以通过 HTTP 的接口在外部访问。

 

6.分布式队列

分布式队列的常规用法与场景五中所描述的分布式锁的控制时序用法类似，即创建一个先进先出的队列，保证顺序。

另一种比较有意思的实现是在保证队列达到某个条件时再统一按顺序执行。这种方法的实现可以在 /queue 这个目录中另外建立一个 /queue/condition 节点。

• condition 可以表示队列大小。比如一个大的任务需要很多小任务就绪的情况下才能执行，每次有一个小任务就绪，就给这个 condition 数字加 1，直到达到大任务规定的数字，再开始执行队列里的一系列小任务，最终执行大任务。
• condition 可以表示某个任务在不在队列。这个任务可以是所有排序任务的首个执行程序，也可以是拓扑结构中没有依赖的点。通常，必须执行这些任务后才能执行队列中的其他任务。
• condition 还可以表示其它的一类开始执行任务的通知。可以由控制程序指定，当 condition 出现变化时，开始执行队列任务。

7.负载均衡

在场景一中也提到了负载均衡，本文所指的负载均衡均为软负载均衡。分布式系统中，为了保证服务的高可用以及数据的一致性，通常都会把数据和服务部署多份，以此达到对等服务，即使其中的某一个服务失效了，也不影响使用。由此带来的坏处是数据写入性能下降，而好处则是数据访问时的负载均衡。因为每个对等服务节点上都存有完整的数据，所以用户的访问流量就可以分流到不同的机器上。

• etcd 本身分布式架构存储的信息访问支持负载均衡。etcd 集群化以后，每个 etcd 的核心节点都可以处理用户的请求。所以，把数据量小但是访问频繁的消息数据直接存储到 etcd 中也是个不错的选择，如业务系统中常用的二级代码表（在表中存储代码，在 etcd 中存储代码所代表的具体含义，业务系统调用查表的过程，就需要查找表中代码的含义）。
• 利用 etcd 维护一个负载均衡节点表。etcd 可以监控一个集群中多个节点的状态，当有一个请求发过来后，可以轮询式的把请求转发给存活着的多个状态。类似 KafkaMQ，通过ZooKeeper来维护生产者和消费者的负载均衡。同样也可以用 etcd 来做ZooKeeper的工作。

• 

etcd和同类型产品的对比

2.1 etcd vs redis

etcd诞生之日起，就定位成一种分布式存储系统，并在k8s 服务注册和服务发现中，为大家所认识。它偏重的是节点之间的通信和一致性的机制保证，并不强调单节点的读写性能。

而redis最早作为缓存系统出现在大众视野，也注定了redis需要更加侧重于读写性能和支持更多的存储模式，它不需要care一致性，也不需要侧重事务，因此可以达到很高的读写性能。

总结一下，redis常用来做缓存系统，etcd常用来做分布式系统中一些关键数据的存储服务，比如服务注册和服务发现。

2.2 etcd vs consul

consul定位是一个端到端的服务框架，提供了内置的监控检查、DNS服务等，除此之外，还提供了HTTP API和Web UI，如果要实现简单的服务发现，基本上可以开箱即用。

但是缺点同样也存在，封装有利有弊，就导致灵活性弱了不少。除此之外，consul还比较年轻，暂未在大型项目中实践，可靠性还未可知。

2.3 etcd vs zookeeper

etcd站在了巨人的肩膀上

3. etcd性能表现

来自于官网介绍：https://etcd.io/docs/v3.4.0/op-guide/performance/ 大致总结一下：

• 读：1w ~ 10w 之间
• 写：1w左右

建议：

• etcd需要部署到ssd盘（强烈建议）
• 多个写采用batch操作。
• 非必要情况下，避免range操作。

etcd集群更偏重一致性和稳定性，并不强调高性能，在绝大部分场景下均不会到达etcd性能瓶颈，如果出现瓶颈的话，需要重新review架构设计，比如拆分或者优化流程。