企业官网建设流程全解析

etcd 3.3 全系列演进深度解析：从 bbolt 存储升级到可观测性体系的版本变革

【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcd

本篇文章以 etcd 仓库官方变更记录 CHANGELOG-3.3 为主线，系统梳理 etcd 3.3 主版本与后续 27 个补丁版本的核心变更脉络——涵盖存储引擎迁移、mvcc 事务能力扩展、WAL 数据一致性修复、选举时序调优、认证安全加固以及一套成规模的 Prometheus 指标体系。读者读完将掌握 3.3.x 各阶段的重点能力、新增服务端/客户端命令行参数及其语义、已知数据损坏风险点，以及升级时的破坏性变更注意事项，可作为排查历史行为与做版本升级决策的参考索引。

版本范围与总览

etcd 3.3 是 etcd 3.x 系列中生命周期极长的一个大版本：主版本v3.3.0于 2018-02-01 发布，末代补丁v3.3.27于 2021-10-15 发布。其变更记录覆盖从 2017-12-20 的v3.3.0-rc.0到 2021-10-15 的v3.3.27，包含 rc.0～rc.4 五个候选版本与 27 个正式补丁版本。

需要注意一个特殊发布：v3.3.16因go mod依赖哈希不一致被标记为bad release，官方明确警告不要使用（见仓库中相关 issue 编号 #11241），并建议直接采用v3.3.17替代——该补丁即是为替换 3.3.16 而发布。

对照仓库现状可知，3.3 之后的演进路径清晰可循：当前主分支的 api/version/version.go 中Version已演进到3.8.0-alpha.0，本变更记录中大量以experimental-前缀引入的能力（如初始损坏检查、v2v3 模拟）后续版本已陆续转正或移除，阅读时可结合 CHANGELOG-3.4 与 CHANGELOG-3.5 追溯后续走势。

3.3.0：一次触及内核的基础设施升级

存储引擎迁移：boltdb 退场，coreos/bbolt 登场

3.3.0 最重要的一项底层变更是用coreos/bbolt替换了原boltdb/bolt（依赖从v1.3.0升级到v1.3.1-coreos.6，后续 3.3.16 再次升级到v1.3.3）。变更记录明确指出其动机是修复"etcd 数据库大小无限增长直至mvcc: database space exceeded"的问题（issue #8009），并由此支持了大于 8GiB 的数据库（变更记录同时注明：8GiB 在当时只是普通环境的建议上限，并非硬限制）。

存储引擎层面的连带优化还包括：

• Range 操作大幅减少内存分配；
• 在重启或领导者选举期间对租约撤销（lease revoke）做限速与随机化，避免 Raft proposal 速率尖峰（issue #8096）——这一点在 server/storage/ 的 mvcc、lease 实现目录中均有对应模块可佐证。

服务端新增配置项：数据生命周期与请求上限治理

3.3.0 集中引入了多个至今仍在使用、且源码里依然可见的关键服务端 flag。当前这些 flag 的解析与默认值统一收敛在 server/embed/config.go，例如auto-compaction-mode默认值为"periodic"、auto-compaction-retention默认值为"0"（0 表示禁用自动压缩），可视为 3.3 时代的直接延续。

其中--auto-compaction-retention从整数到字符串的转变是破坏性变更：YAML 配置文件里原来的auto-compaction-retention: 24必须写成auto-compaction-retention: "24"或auto-compaction-retention: "24h"（字符串类型），periodic模式下该值必须是 Gotime.ParseDuration可解析的合法时长。仓库根目录的 etcd.conf.yml.sample 给出了 YAML 形态的完整字段示范。

额外几个行为改进同样值得关注：

• 当集群存在告警（如NOSPACE）或没有 leader 时，/health端点会如实返回 unhealthy，且返回体中的"health"字段被定义为string 类型（{"health":"true"}/{"health":"false"}），并非 bool；
• --advertise-client-urls出现空 host（如http://:2379）或环境变量被遮蔽时仅输出警告（v3.4 起才升级为报错退出）；
• gRPC 服务端 info 级日志默认关闭，需要--debug打开。

API 层扩展：事务、租约、fragment 分片 watch 的雏形

3.3.0 的 API 新增集中于事务与租约组合能力，很多在今天clientv3里司空见惯的用法都起源于此：

• 事务比较（Compare）支持范围比较（ranges in transaction comparisons），用于实现"断连的线性化读"；
• 支持嵌套事务（nested transactions），主要面向 proxy 场景；
• 事务比较新增租约目标（Compare_LEASE/LeaseValue辅助函数），可在Txn中直接比较LeaseID；
• 新增租约列表能力（lease list）；
• 新增按修订号哈希（hash by revision，即HashKV），用于对 boltdb 做更强的损坏校验。

运维能力方面新增了MoveLeader（主动迁移领导者）与Leases（枚举租约）维护接口。对应现代源码中 server/etcdserver/server.go 的MoveLeader方法（约第 1228 行起）即承担领导者转移逻辑。

客户端、etcdctl 与 gRPC Proxy

3.3.0 客户端侧引入"健康感知 balancer"以修复 watch API 挂起，并为clientv3.Config增加MaxCallSendMsgSize（默认 2 MiB）与MaxCallRecvMsgSize（默认math.MaxInt32）字段，解决此前客户端响应被限死在 4 MiB 的问题（曾影响 Kubernetes #51099）。

etcdctl v3新增了一大批实用命令与 flag：

• etcdctl --discovery-srv：基于 DNS SRV 的服务发现；
• etcdctl --keepalive-time / --keepalive-timeout：客户端连接级 keepalive；
• etcdctl lease list、etcdctl lease keep-alive --once；
• etcdctl move-leader、etcdctl endpoint hashkv、etcdctl endpoint --cluster（对标 v2 的cluster-health）；
• etcdctl snapshot restore --wal-dir、etcdctl defrag --data-dir；
• etcdctl lock --ttl；
• etcdctl watch [key] [range_end] -- [exec-command…]：支持执行外部命令，并为每次事件注入ETCD_WATCH_REVISION、ETCD_WATCH_EVENT_TYPE、ETCD_WATCH_KEY、ETCD_WATCH_VALUE环境变量；
• etcdctl endpoint health --write-out修复了 JSON 输出不生效的问题，同时统一错误信息格式为"<endpoint> is unhealthy: failed to commit proposal: ..."。

gRPC Proxy 层新增--metrics-addr、--max-send-bytes、--max-recv-bytes、--debug等 flag，并支持/health端点；实验性 flag 包括--experimental-leasing-prefix（断连线性化读）与--experimental-serializable-ordering（跨端点单调递增的 serializable read）。

Raft 层引入了**非投票成员（Learner）**能力，用来实现 Raft 论文 4.2.1 中"追赶新服务器"的策略——Learner 不参与投票、不会自我提升为 leader，可安全地先行追赶日志。

最后是 grpc-gateway 端点的重大更名：/v3alpha被替换为/v3beta。3.3 中两个路径均可用（curl -L http://localhost:2379/v3beta/kv/put -X POST -d '{"key": "Zm9v", "value": "YmFy"}'），但 3.4 起/v3alpha彻底失效，这是 API 消费方需要提前适配的破坏性变更。

自动压缩：跨补丁版本演进最剧烈的子系统

自动压缩（auto compaction）是 3.3 系列中语义调整最频繁、最容易因理解偏差踩坑的能力，其实现源码现位于 server/etcdserver/api/v3compactor/compactor.go，并配有同目录的 compactor_test.go 做行为验证。

3.3.0定义了两个核心参数组合的语义：

• --auto-compaction-mode=revision --auto-compaction-retention=1000：每 5 分钟触发一次Compact，目标为"最新修订号" - 1000（最新修订号为 30000 时压缩到 29000）；
• --auto-compaction-mode=periodic --auto-compaction-retention=72h：以 72 小时为保留窗口、每 7.2 小时压缩一次；
• --auto-compaction-mode=periodic --auto-compaction-retention=30m：以 30 分钟为保留窗口、每 3 分钟压缩一次。

也就是说，3.3.0 的 periodic 压缩按"保留时长的 1/10"作为压缩周期推进保留窗口。

3.3.2修复了 revision 模式解析 bug：此前--auto-compaction-mode revision --auto-compaction-retention 1会被错误翻译成 3600000000000（一个时间量），修复后被正确解析为修订号保留 1（issue #9337）。

3.3.3进一步调整了 periodic 压缩的保留窗口推进节奏，核心变化是"不再按 1/10 周期、而是按完整保留时长推进"：

• retention=72h：此前每 7.2 小时压缩一次；此后每 1 小时执行一次，保留窗口仍为 72 小时；
• retention=30m：此前每 3 分钟压缩；此后每 30 分钟压缩一次，保留窗口仍为 30 分钟；
• 对于超过 1 小时的保留时长，压缩器按小时为单位推进窗口并丢弃窗口之前的历史数据。

变更记录给出了量化示例：每小时写入 100 条且retention=24h时，v3.2.x / v3.3.0~v3.3.2 每 2.4 小时压缩修订号 2400、2640、2880，而 v3.3.3 及以后每 1 小时压缩 2400、2500、2600。这意味着升级补丁版本后压缩执行频率可能显著改变，运维上应以实际修订号增长速率来设定 retention，避免窗口内数据量过大或压缩过于频繁。

慢请求告警：从 3.3.0 到 3.3.8 持续打磨

3.3.1 引入"请求耗时过长"告警，示例输出形如：

etcdserver: read-only range request "key:\"\000\" range_end:\"\000\" " took too long [3.389041388s] to execute

3.3.8 对这条告警做了三点增强：在日志中抹除请求 value 字段（防敏感信息泄漏）、补上响应大小信息、并统一了慢请求 apply 日志格式，示例：

read-only range request "key:\"/a\" range_end:\"/b\" " with result "range_response_count:3 size:96" took too long (97.966µs) to execute

这一系列告警正是如今--warning-apply-duration、--warning-unary-request-duration等慢路径告警配置（见 server/embed/config.go 的 flag 注册）的前身，排查慢读/慢写时可优先借助它们定位是 apply 慢还是网络慢。

可观测性：一批成建制的 Prometheus 指标

3.3 系列在指标体系建设上投入巨大，且明确了重要约定：所有etcd_debugging_*前缀指标都是实验性的，可能随版本变化。逐版本梳理如下：

• 3.3.0：新增etcd --listen-metrics-urls（可额外用https://localhost:2378,http://localhost:9379形式同时提供 TLS 与明文指标端口，便于监控绕过关键 API 端口）；新增etcd_server_version、etcd_debugging_mvcc_db_compaction_keys_total、etcd_debugging_server_lease_expired_total；修复etcd_debugging_mvcc_range/put/delete/txn_total四类操作指标在事务场景下的统计。
• 3.3.4：新增etcd_server_is_leader；修复etcd_debugging_server_lease_expired_total。
• 3.3.9：新增容量治理三件套——etcd_server_quota_backend_bytes、etcd_mvcc_db_total_size_in_bytes、etcd_mvcc_db_total_size_in_use_in_bytes。变更记录给出了精确的判读示例：etcd_server_quota_backend_bytes 2.147483648e+09表示当前配额 2 GB；etcd_mvcc_db_total_size_in_bytes 20480表示物理占用 20 KB；etcd_mvcc_db_total_size_in_use_in_bytes 16384表示 defrag 完成后可回收到的目标大小；两者之差即为磁盘上可通过 defrag 节省的字节数。
• 3.3.10：etcd_network_peer_round_trip_time_seconds改进为跟踪 leader 心跳（此前仅采样快照连接的 TCP）；新增快照收发全套指标（etcd_network_snapshot_send/receive_success/failures、etcd_snap_db_fsync_duration_seconds_count、etcd_snap_db_save_total_duration_seconds_bucket）、etcd_server_id、etcd_server_health_success/failures、etcd_server_read_indexes_failed_total。
• 3.3.13：修复db_compaction_total_duration_milliseconds指标错误地恒为 0 的问题。
• 3.3.18：新增etcd_cluster_version与etcd_debugging_mvcc_total_put_size_in_bytes。
• 3.3.19：新增带"type"、"client_api_version"label 的etcd_server_client_requests_total，便于按 API 类型与客户端版本拆分请求量。
• 3.3.20：新增etcd_wal_write_bytes_total（WAL 写入字节总量）。
• 3.3.21：新增etcd_debugging_auth_revision，用于监控 auth 存储的修订号。
• 3.3.24：新增os_fd_used与os_fd_limit，把当前操作系统文件描述符使用量纳入可观测范围（对应 pkg/runtime/ 的 FD 统计能力，同时优化了runtime.FDUsage的内存分配）。

选举时序：从"快速启动"到"防打断式重启"

etcd 3.3 在 leader 选举时序上经历了从激进到保守的反复权衡，这一过程深刻反映了集群可用性与启动速度之间的矛盾。

3.3.0 前身：etcd 在节点启动时快速推进（fast-forward）选举 tick，仅留 1 个 tick 就触发选举，用以加速启动阶段，尤其利好选举超时配置较长（如跨数据中心 10 秒）的部署。

3.3.3首次修正：重启时调整选举 tick，确保留下不止 1 个 tick，给现任 leader 更多时间联系重启节点，以减少"破坏性重加入"（disruptive rejoining）对集群可用性的冲击（issue #9333）。

3.3.4将控制权交给用户：新增etcd --initial-election-tick-advance与embed.Config.InitialElectionTickAdvance。默认true时本地成员会推进选举 tick 加速首次选举——例如 10 秒选举超时下推进到 8 秒、只留 2 秒余量；当 leader 到重加入节点的网络拥塞、剩余 tick 内收不到心跳时，就可能发生破坏性选举。通过--initial-election-tick-advance=false可以禁用该推进（代价是跨数据中心场景下初始引导变慢），且单节点集群无论设置如何都会推进 tick。对应的现代配置字段仍保留在 server/embed/config.go 中。

3.3.0 还改进了--initial-cluster不匹配时的报错质量：v3.2 只提示etcd --initial-cluster must include s1=...，v3.3 会把 DNS 解析失败原因一并输出（如failed to resolve https://s1.test:2380 to match --initial-cluster=...），显著降低跨数据中心误配排查成本。

认证、TLS 与安全加固时间线

3.3 系列在认证安全上积累了从"可用"到"健壮"的完整路径：

• 3.3.0：引入基于 CRL 的连接拒绝（--client-crl-file/--peer-crl-file）；新增--peer-cert-allowed-cn支持节点间的 CN 认证；证书中同时含 IP 与 DNS 时，只要远端 IP 匹配即放行、不再强制校验 DNS；服务端支持对通配符 DNS SAN 做反查/正查匹配；认证失败时返回用户所拥有的角色信息；并修复了auth store在 token 被禁用时的 panic。
• 3.3.2：空 auth token 不再导致初始化失败（修复auth: invalid auth options报错）；修复 JWT token 下租约撤销例行任务的 auth 存储 panic；防止超大 TTL 的 Lease Grant 溢出（超过 9,000,000,000 秒即约 285 年的 TTL 将返回rpctypes.ErrLeaseTTLTooLarge），并明确建议"Lease 只应服务于秒/分钟级的短周期保活或会话，而不是小时/天级"。
• 3.3.3：--auto-compaction-mode=revision解析修复（见上文）。
• 3.3.4：修复 TLS 证书热加载在"证书 SAN 只含 IP 不含域名"场景下不触发GetCertificate的问题——此前的实现要求客户端必须携带有效 SNI 才能触发证书重载，导致纯 IP 证书过期后无法在线轮换。
• 3.3.7：新增etcd --cipher-suites支持 TLS 密码套件白名单，握手请求携带白名单外套件时直接失败（空列表时交给 Go 自动填充），用于阻断弱密码套件。
• 3.3.9：使用 Go 1.10.3 编译以支持crypto/x509的 "Name Constraints" 扩展。
• 3.3.11：gRPC-gateway 代理请求禁用 CommonName 认证，规避证书 CN 导致的权限提升风险。
• 3.3.14 之后：客户端 balancer 重写后提升了对安全端点（TLS）的 failover 能力。
• 3.3.23：对已存在的数据目录与自动生成自签名证书所用目录新增权限检查——Linux 上要求 700、Windows 上要求 777；不满足时 3.3.23 起行为变更（不再静默放行）。
• 3.3.25：若检测到使用权限不同于 700(Linux)/777(Windows) 的既有目录，服务启动时输出日志警告。

数据一致性：WAL、快照与 mvcc 的关键修复清单

3.3 系列后期补丁大量聚焦"进程崩溃/网络分区后的一致性恢复"，这类修复通常只改几行代码，却决定生产数据的生死，值得逐一记录：

• 3.3.6：修复 mvcc 在快照恢复时的服务端 panic——当一个 watcher 以未来修订号 X 被请求到网络分区节点，分区恢复后 leader 下发快照，若快照最新修订号仍低于 X，旧版本会直接 panic（该场景同时关联 3.3.1 的 unsynced watcher 恢复 bug，可能导致客户端漏事件）。
• 3.3.21：修复 WAL 与服务器快照不一致——此前若节点在持久化 raft hard state 之后、保存快照之前崩溃，restore将失败（issue #10219）；auth 模块通过保存一致索引（consistent index）修复了一个数据损坏 bug；mvcc 修复了一个死锁；并增加了 apply 失败与快照收发日志。
• 3.3.22：为 WALValidate方法补上缺失的 CRC 校验，避免校验过程本身 panic（issue #11918）。
• 3.3.13：新增Verify函数对 WAL 内容做损坏检查，对应 server/storage/wal/ 的 WAL 实现。
• 3.3.19：修复 defrag 中的数据损坏 bug（issue #11613）。
• 3.3.18：修复 shutdown 期间的 WAL purge 时序——此前 etcd 在关闭时可能误删仍需要的 wal 文件，导致启动时出现灾难性错误etcdserver: open wal error: wal: file not found.；现在会确保 purge 循环先于 raft 节点停止信号退出。
• 3.3.10：快照 status 增加一致性校验，校验失败时返回"snapshot file integrity check failed..."。
• 3.3.16：为跳过对等节点客户端地址校验新增实验性 flag--experimental-peer-skip-client-san-verification。
• 3.3.0：修复 restore 时后端数据库内存索引损坏问题（仅影响 3.2.0），以及 watch 从快照恢复的问题。

这些修复共同指向一个运维事实：3.3 后期版本的一致性保障强度远高于早期版本，长期停留在 3.3.0~3.3.5 的集群应尽快评估升级到 3.3 末代补丁。

3.3.14：client balancer 重写与模块化

3.3.14 是本系列中风险最高、也最值得单独说明的补丁——它把一些 3.4 的新特性反向移植了进来，以最小化与新版客户端 balancer 的差异。核心变更：

• 用 gRPC v1.23.0 的新 balancer 接口重写客户端 balancer（PR #9860），采用异步 resolver 把端点交给 gRPC dial；如需阻塞到底层连接就绪，应在clientv3.Config.DialOptions中传入grpc.WithBlock()；
• 修复了 Kubernetes 1.13.x 在首个 etcd server 不可用时拒绝工作的故障（kubernetes#72102）；
• 依赖管理从glide切换到 Go module（随后 3.3.15 又回退到 glide，详见下文"升级注意事项"）；
• 新增rpctypes.ErrLeaderChanged：读索引的线性化请求在发生领导变更时快速失败，而非干等到 context 超时；
• 弃用latest容器标签及 minor 版本标签：docker pull gcr.io/etcd-development/etcd:latest不再保证最新，v3.3标签可能陈旧，建议使用带精确 patch 版本的docker pull gcr.io/etcd-development/etcd:v3.3.14；
• 官方发布不再提供 ACI 制品（AppC 规范已停摆，acbuild不再维护）。

**API 扩展（fragment 分片 watch 与手动进度通知）**同样在 3.3.14 落地：

• WatchCreateRequest新增watch_id字段，允许客户端为 watch 指定 ID；
• 新增fragment字段：当单次 watch 响应总大小超过--max-request-bytes（服务端默认embed.DefaultMaxRequestBytes= 1.5 MiB + 512 字节 gRPC 开销）时，服务端会把事件拆成多个小于上限的分片下发。文档给出两个极限示例：10 个各 1 MiB 的事件在 1 MiB 限额下会拆成 10 个分片下发；而若事件本身 2 MiB、客户端MaxCallRecvMsgSize又只有 1 MiB，则客户端会收到"code = ResourceExhausted desc = grpc: received message larger than max"。客户端侧的事件合并逻辑需要自行实现（官方clientv3在 v3.4 中内置）；
• 新增WatchRequest.WatchProgressRequest，可手动触发向所有关联 watch 流广播进度事件（相当于可手动触发的WithProgressNotify）。

另外pkg/adt的区间树在 3.3.14 从struct重构为interface（见 pkg/adt/adt.go 与 pkg/adt/README.md 的红黑树性质说明），并修复了删除操作破坏红黑树 black-height 性质的问题。

3.3 后期：库使用治理与镜像安全

• 3.3.13将github.com/ugorji/go/codec迁移到github.com/json-iterator/go、github.com/ghodss/yaml迁移到sigs.k8s.io/yaml，是面向长期维护的依赖收敛。
• 3.3.15又临时回退到glide依赖管理（因为 3.3.14 引入的 Go module 与部分下游组件不兼容，见 kubernetes#81434），所以 v3.3.15~v3.3.27 使用的是glide。
• 3.3.23修复了 clientv3 作为库引入时错误的包依赖问题。
• 3.3.26修复 watch 重连后 auth token 失效问题——clientConn就绪时自动重新获取AuthToken。
• 3.3.27将容器基础镜像从debian:buster-v1.4.0升级到debian:bullseye-20210927，一次性修复 openssl（CVE-2021-3711）、glibc（CVE-2021-35942）、libseccomp（CVE-2019-9893）与 apk-tools（CVE-2021-36159）的四个 CVE——这是 3.3 系列的收尾版本，也提醒仍在运行 3.3 的集群应至少更新到含镜像修复的末代版本。

升级注意事项与破坏性变更汇总

综合全系列变更，升级到任意 3.3.x 或在不同补丁版本间迁移前应重点核对以下破坏性变更（变更记录正文反复强调：升级前务必通读各版本记录与 upgrade guide）：

1. YAML 字段类型变化：auto-compaction-retention从整数变为字符串，需写作"24"或"24h"；auto-compaction-mode需显式声明为periodic或revision。
2. gRPC gateway 端点更名：/v3alpha→/v3beta，3.4 起旧路径彻底不可用。
3. 客户端 balancer 语义变化（3.3.14 起）：异步 resolver 使 dial 不再阻塞等待连接，依赖"连接即就绪"语义的调用方需自行加grpc.WithBlock()；gRPC 依赖需 >= v1.7.4/1.7.5（3.3.0 起），v3.3.14 起为 v1.23.0。
4. 容器镜像标签策略：不要依赖latest或 minor 版本标签，改用精确 patch 版本。
5. 目录权限检查（3.3.23 行为变更）：既有数据目录与自签名证书生成目录必须为 700(Linux)/777(Windows)，否则启动报错。
6. etcdctl endpoint health输出与退出码：3.3.14 起统一错误文案；3.3.0 起健康检查失败返回非零退出码。
7. 过期租约的lease timetolive输出：由"lease LEASE_ID granted with TTL(0s), remaining(-1s)"变为"lease LEASE_ID already expired"。
8. 避雷 3.3.16：该版本go mod哈希存在仓库间不一致，为官方标记的 bad release，请直接使用 3.3.17。
9. Go 编译工具链：3.3.0 要求 Go 1.9+（以 Go 1.9.3 编译），3.3.13/3.3.12 编译工具链为 Go 1.10.8，3.3.14 起要求 Go 1.12+，3.3.15~3.3.27 以 Go 1.12.9/1.12.17 编译——若以源码方式构建历史版本，需匹配相应 Go 工具链。

结语：如何从本变更记录中获益

etcd 3.3 系列用近四年的补丁周期，把"运行稳定"与"能力扩展"两条线并行推进：主版本 3.3.0 定调了 bbolt 存储、事务扩展与大体量指标体系；3.3.1~3.3.13 重在修复 mvcc/watcher/选举的稳定性和数据一致性；3.3.14 完成客户端 balancer 重写并预告 3.4 的 fragment watch；3.3.21~3.3.27 则专注库治理、权限校验与容器镜像安全。对仍在维护 3.3 集群的团队而言，本文可作为快速定位"某个行为/flag/metric 从哪个版本起生效"的索引；对希望理解 etcd 现代版本（3.4 及之后）演进动机的读者，这份记录则是追踪特性出生脉络的原始素材。如需验证各项 flag 在当代代码中的落点，可继续查阅 server/embed/config.go 的默认值定义、server/etcdserver/api/v3compactor/compactor.go 的压缩实现，以及 CHANGELOG 目录下相邻大版本的变更记录。

【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcd