ETCD高可用架构涉及常用功能整理

探讨etcd的系统架构以及以及整体常用的命令和系统分析，本文主要探讨高可用版本的etcd集群，并基于日常工作中的沉淀进行思考和整理。更多关于分布式系统的架构思考请参考文档关于常见分布式组件高可用设计原理的理解和思考

---

1. etcd的高可用系统架构和相关组件

etcd在产品设计上，面对的存储数据量比较小，一台etcd机器就能够满足数据的存储需求，因此在集群的架构设计上，使用镜像模式进行数据高可用，通过Raft 协议进行选举leader，从而满足集群的高可用和数据一致性要求。

etcd的系统架构如下

相关核心的组件和角色作用如下

角色	数量	角色作用	备注
Leader	有且必须只有1个	它会发起并维护与各Follwer及Observer间的心跳，所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器	通过内部选举选择出leader
Follower	多个	会响应Leader的心跳，可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理，并且负责在Leader处理写请求时对请求进行投票	和Observer统称为Learner
Learner	多个	作用跟Follow相同，但是没有投票权	和Follower统称为Learner

etcd的数据模型，是k-v结构，但etcd的key可以是任意字符串同时在存储上实现了key有序排列，所以仍旧可以模拟出父子目录关系，例如：key=/a/b/c、/a/b、/a

1.1 Quorum机制

Quorum机制（有效个数）模式：指分布式系统的每一次修改都要在大多数（超过半数）实例上通过来确定修改通过。

产生Quorum机制（有效个数）的背景如下：

分布式系统的LC矛盾
在一个分布式存储系统中，用户请求会发到一个实例上。通常在一个实例上面执行的修改，需要复制到其他的实例上，这样可以保证在原实例挂了的情况下，用户依然可以看到这个修改。这就涉及到一个问题，究竟复制到多少个其他实例上之后，用户请求才会返回成功呢？如果复制的实例个数过多，那么请求响应时间就会更长；如果复制的实例过少，则这个修改可能会丢失。取得这个平衡性很重要，这也是分布式 PACELC 中的 L（Latency） 与 C（Consistency） 的取舍。

解决方案
当一个修改，被集群中的大部分节点（假设个数为N）通过之后，这个修改也就被这个集群所接受。这个 N 就是有效个数。假设集群数量为 n，那么 N = n/2 + 1.例如 n = 5，则 N = 3，从而应运而生Quorum机制（有效个数）

1.2 Raft协议

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

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

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

2. etcd的核心参数

2.1 常规配置

etcd常用配置

    - --advertise-client-urls=https://xx.xx.xx.xx:2379
    - --cert-file=/etc/kubernetes/pki/etcd/server.crt
    - --client-cert-auth=true
    - --data-dir=/data/var/lib/etcd
    - --initial-advertise-peer-urls=https://xx.xx.xx.xx:2380
    # 所有集群节点
    - --initial-cluster=xx.xx.xx.xx=https://xx.xx.xx.xx:2380,xx.xx.xx.xx=https://xx.xx.xx.xx:2380,xx.xx.xx.xx=https://xx.xx.xx.xx:2380,xx.xx.xx.xx=https://xx.xx.xx.xx:2380,xx.xx.xx.xx=https://xx.xx.xx.xx:2380
    - --initial-cluster-state=new
    - --key-file=/etc/kubernetes/pki/etcd/server.key
    - --listen-client-urls=https://127.0.0.1:2379,https://xx.xx.xx.xx:2379
    - --listen-metrics-urls=http://0.0.0.0:2381
    - --listen-peer-urls=https://xx.xx.xx.xx:2380
    - --name=xx.xx.xx.xx
    - --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
    - --peer-client-cert-auth=true
    - --peer-key-file=/etc/kubernetes/pki/etcd/peer.key
    - --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
    - --snapshot-count=10000
    - --quota-backend-bytes=8589934592
    - --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
    - --cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA38