企业官网建设流程全解析

• 云原生
• 后端
• 微服务
• DevOps
• AI 应用

etcd 是分布式系统中应用最广泛的强一致性键值存储，几乎每一个 Kubernetes 集群都以它作为主数据存储。本文以 Rainbond 仓库内嵌的 etcd（coreos/etcd v3.3.13）官方文档《Production users》为主体，系统梳理 etcd 在生产环境中的真实使用案例——从服务发现、配置管理、分布式锁到容器平台元数据存储，逐项还原各用户的集群规模、数据量级、运行环境与备份策略；同时结合仓库内 op-guide 运维文档与 Rainbond 对 etcd 的源码级应用，帮助读者在规划自建 etcd 集群时，直接对照真实案例选择合适的成员数量、硬件配置与维护节奏，并理解 etcd 在平台型系统中可以承担哪些核心职责。

文档定位：一份记录 etcd 生产用户的活档案

production-users.md 是 etcd 官方文档中一份特殊的档案：它不讲解 API 或配置，而是追踪并记录 etcd 在生产环境中的真实使用者与使用场景。文档开篇即说明其目的——通过积累生产用例清单，建立一个由 etcd 开发者与各类应用维护者组成的顾问社区，供 etcd 开发团队定期回访，了解 etcd 在真实业务中的运行情况、运维环境与集群规模，并持续更新这份清单。

这份文档的价值在于它的"实证性"：所有条目均来自真实运营方的一手信息，包含四个维度的事实：

• 应用类型（Application）：etcd 承载了什么业务，如服务发现、配置管理、分布式锁、容器编排元数据等；
• 集群规模（Cluster Size）：成员数量、集群数量、读写节点数；
• 数据规模（Order of Data Size）：从数百 KB 到数 GB 的量级分布；
• 运行环境与备份（Environment / Backups）：物理机、公有云、虚拟机等部署形态，以及是否/如何做数据备份。

文档从 2014 年记录至今，覆盖了 20 余个来自中国、美国、俄罗斯、新加坡等地的真实用户，是了解 etcd 生产形态最直接的一手资料。下文将先呈现这些案例全貌，再从中提炼出可复用的集群规划与运维原则。

etcd 的生态地位：所有 Kubernetes 集群的"数据库"

文档用一个专门的章节强调了一个在今天已成为行业常识的事实：所有 Kubernetes 集群都以 etcd 作为其主数据存储（primary data store）。Kubernetes 将 API 对象（Pod、Service、Deployment、ConfigMap 等）全部序列化后写入 etcd，因此 etcd 的可用性直接决定了整个集群的可用性。

文档将 Kubernetes 用户定义为"元用户（meta user）"，并鼓励各团队在清单中登记自己具体的 Kubernetes 集群。文档中列出的使用 Kubernetes 的公司包括 Niantic（Pokémon GO 背后的基础设施）、Box、CoreOS、Ticketmaster、Salesforce 等，此外 Tencent Games、Branch.io、Hyper.sh、Radius Intelligence、Vonage、Meitu 等条目也明确将 Kubernetes 列为 etcd 的重要承载对象。这意味着：任何一个运行在 Kubernetes 之上的平台（包括 Rainbond 这类 PaaS），其控制面稳定性在客观上就已经与底层 etcd 集群的稳定性深度绑定。

生产用户案例全景：20 余个真实部署逐一解析

以下是文档记录的全部生产用户条目。为便于对照，这里保留每个条目的原始字段（应用、启动时间、集群规模、数据规模、运营方、环境、备份策略），并按文档原始顺序呈现。

独立服务：discovery.etcd.io

discovery.etcd.io 是文档中已知运行时间最长的 etcd 后端服务，也是 etcd 自动集群引导（discovery bootstrap）机制的基础设施，于 2014 年 2 月随 etcd 0.3.0 发布上线。

OpenTable

CyCore Systems（cycoresys.com）

CyCore Systems 为多个客户提供微服务、虚拟机、数据库与存储集群，其集群构建在 CoreOS 机器之上，每台机器以 peer 或 proxy 模式运行 etcd。

Radius Intelligence

Radius Intelligence 使用运行在 CoreOS 上的 Kubernetes 来容器化并扩展内部工具集，例如 JetBrains TeamCity 以及内部 AWS 安全与成本报表工具。etcd 集群为这些 Kubernetes 集群提供支撑，同时保存环境引导配置键。

Vonage

Vonage 的 etcd 承担了 Kubernetes、vault 后端、微服务系统配置、调度与锁等职责，并以 SSL 与 SRV 方式做服务发现（未来规划），本地代理与微服务一一对应。

PD（PingCAP）

PD（Placement Driver）是 TiDB 集群中的中心控制器：保存集群元信息、调度数据、为分布式事务分配全局唯一时间戳。它内嵌（embed）etcd以获得高可用与自动故障转移能力。

Huawei

华为 Euler 部门将 etcd 用于 overlay 网络（Canal）的系统配置，运行于华为云 CCE 环境。

七牛云（Qiniu Cloud）

青云 QingCloud

青云在 appcenter 集群中，将 etcd 作为 metad（云元数据服务）的后端，实现服务发现。每个用户拥有一套独立的 3 成员 etcd 集群。

Yandex

腾讯游戏（Tencent Games）

腾讯游戏使用 Docker 与 Kubernetes 部署和运行应用，用 etcd 保存服务发现与 Kubernetes 等系统的元数据与配置数据。

Hyper.sh

Hyper.sh 的容器服务由 hypernetes（多租户 Kubernetes 发行版）支撑，同时用 etcd 协调多个管理服务并存储全局元数据。

美图（Meitu）

Grab

DaoCloud.io

DaoCloud 使用 Docker 与 Swarm 部署和运行应用，用 etcd 保存服务发现元数据；其容器管理平台承载了 1000+ 个部署，每个部署内含一套 3 节点 etcd 集群。

Branch.io

Branch 将 Kubernetes 重度用于 staging 与生产环境的微服务平台。

百度外卖（Baidu Waimai）

Salesforce.com

Hosted Graphite

Hosted Graphite 将 etcd 数据视为完全临时的，主要用于服务发现、锁与临时应用数据。

星环科技（Transwarp）

星环将 etcd 用于其数据云、操作系统、数据仓库与大数据分析平台 Sophon 等多个产品线。

从真实案例提炼的规律：集群规模、数据量级与备份策略

汇总上述 20 余个案例，可以提炼出几条具有普遍参考价值的实践规律。这些规律全部来自文档记录的真实运营数据，可作为自建 etcd 集群的规划基线。

集群规模：奇数成员是铁律，3/5/7 是主流

案例中的成员数量高度集中在3 成员、5 成员与 7 成员三种奇数配置：

• 3 成员是最常见形态：OpenTable、CyCore、Huawei、七牛、青云、Hyper.sh、美图、DaoCloud（每部署）、腾讯游戏（每集群）、Salesforce、Meitu、PD 等均采用；
• 5 成员用于更高可用性诉求：discovery.etcd.io、Vonage（每 DC）、Radius（其一）、Yandex（每集群）、百度外卖、PD（可选）；
• 7 成员是少数对一致性容忍度要求极高的场景：Grab、Hosted Graphite。

之所以必须是奇数，是因为 etcd 基于 Raft 共识协议，写入需要多数派（quorum）确认：3 成员容错 1 个节点故障，5 成员容错 2 个，7 成员容错 3 个。案例中未见偶数成员配置，这与 Raft 的多数派机制完全吻合。

另一个值得注意的规律是**"一个业务域一套小集群"而非"一个大集群吃天下"**：OpenTable 按业务拆 6 套 3 成员集群，腾讯游戏有数十套 3 成员集群，DaoCloud 甚至为每个部署单独创建 3 节点集群。将 etcd 故障域缩小、按租户或业务隔离，是大型平台普遍采用的做法，目的是避免单点大集群故障影响面过大。

数据量级：从 KB 到 GB 的跨度

案例中的数据规模跨度极大，但分布规律清晰：

• KB 级：CyCore、Radius、Vonage、Huawei、七牛、青云——这些场景只保存系统配置与少量服务发现元数据；
• MB 级：OpenTable、PD、美图、Grab、Hosted Graphite、星环、Hyper.sh、腾讯游戏——配置 + 服务发现 + 部分业务元数据；
• GB 级：Yandex、百度外卖——大规模服务发现与 CMDB 等系统数据。

对比 hardware.md 中"小集群存储不超过 100MB、中集群不超过 500MB、大集群不超过 1GB"的建议，可以看到绝大多数生产案例都落在中小规模区间。这也印证了 etcd 的设计哲学：它面向的是小而关键的强一致元数据，而非大容量数据存储——大对象应存放在数据库或对象存储中，etcd 只保存"丢了系统就转不起来"的那部分状态。

运行环境：裸金属与公有云并重

案例环境覆盖裸金属（CyCore、七牛、Yandex、腾讯游戏、Hyper.sh、美图、Grab、DaoCloud、Salesforce、Hosted Graphite、星环）、AWS（discovery.etcd.io、OpenTable、Radius、Vonage、Branch.io、Grab、PD）、VMWare（OpenTable、Vonage）以及各云厂商（华为云、青云、Azure、Google Cloud 等）。文档同时明确指出，Kubernetes 用户的运行环境还包括 OpenStack、Azure、Google Cloud、华为云、裸金属等。

对网络敏感的读者可以留意 hardware.md 中的建议：尽可能将 etcd 成员部署在单个数据中心内，以避免跨机房延迟与分区事件；若确需跨故障域，应选择距离较近的数据中心。

备份策略：两种流派泾渭分明

案例中的备份策略可以清晰地分为两派：

1. "无备份、数据可重建"派：OpenTable、Radius、Huawei、七牛、青云、Yandex、Hyper.sh、美图、Grab、DaoCloud、Salesforce、Hosted Graphite 均明确标注"无备份，所有数据在必要时可以重建/视为临时"。其前提是 etcd 中保存的数据要么可由业务系统重新生成，要么本身就是临时数据；
2. "有备份"派：discovery.etcd.io（异步备份至 S3）、CyCore（同步至 Ceph RadosGW 与 DigitalOcean VM）、Vonage（虚拟机每日快照）、腾讯游戏（同步至备份服务器）、Branch.io（EBS 卷备份）、百度外卖与星环（备份脚本）。

结合 maintenance.md 的说明：对 etcd 成员状态做周期性快照备份（snapshot），可以在发生误操作或数据损坏时恢复任何意外逻辑数据丢失。是否备份的关键判断标准是——etcd 里的数据能否被低成本重建：服务发现端点、调度元数据通常可以重建；而 CMDB、集群引导状态、长期积累的全局配置则强烈建议备份。

从案例到实践：etcd 生产部署的关键指标

文档中这些真实案例的运行参数，与仓库内 op-guide 下的运维文档相互印证。以下是部署 etcd 生产集群时必须关注的硬指标。

硬件选型：CPU / 内存 / 磁盘 / 网络

hardware.md 给出了官方硬件建议，可作为对标上述案例的基准：

• CPU：多数部署 2～4 核即可顺畅运行；承载数千客户端或每秒数万请求的重度部署趋于 CPU 密集（etcd 可从内存直接服务请求），通常需要 8～16 个专用核心；
• 内存：etcd 会激进缓存键值数据，其余大部分内存用于跟踪 watcher。通常 8GB 足够；数千 watcher、数百万 key 的重度部署建议 16～64GB；
• 磁盘（最关键）：etcd 的共识协议依赖将元数据持久化到日志，慢磁盘会拉高请求延迟并威胁集群稳定性。通常需要 50 顺序 IOPS（如 7200 转磁盘）；重度集群建议 500 顺序 IOPS（如本地 SSD 或高性能虚拟化块设备）。尽可能用 SSD 承载 etcd 存储，磁盘带宽上 10MB/s 可在 15 秒内恢复 100MB 数据，大集群建议 100MB/s 以上；
• 网络：1GbE 对常见部署足够，大型集群用 10GbE 可缩短故障成员恢复时间。

硬件文档还给出了与案例规模对应的参考配置表：50 节点 Kubernetes 集群对应 2 vCPU / 8GB / 3600 IOPS 级别；250 节点集群对应 4 vCPU / 16GB / 6000 IOPS；1000 节点集群对应 8 vCPU / 32GB / 8000 IOPS；3000 节点集群对应 16 vCPU / 64GB / 16000 IOPS。对照上文案例，绝大多数生产 etcd 都落在"小集群"与"中集群"档位——这也解释了为什么案例中的成员数普遍是 3 或 5。

集群引导：静态 / Discovery / DNS 三种方式

clustering.md 说明，启动 etcd 集群有三种引导机制，与生产案例的运营环境选择直接相关：

1. 静态引导（Static）：事先已知所有成员地址与集群规模时，通过--initial-cluster参数离线引导。例如三节点集群（infra0/infra1/infra2，地址 10.0.1.10/11/12）：

$ etcd --name infra0 --initial-advertise-peer-urls http://10.0.1.10:2380 \ --listen-peer-urls http://10.0.1.10:2380 \ --listen-client-urls http://10.0.1.10:2379,http://127.0.0.1:2379 \ --advertise-client-urls http://10.0.1.10:2379 \ --initial-cluster-token etcd-cluster-1 \ --initial-cluster infra0=http://10.0.1.10:2380,infra1=http://10.0.1.11:2380,infra2=http://10.0.1.12:2380 \ --initial-cluster-state new

其余两节点仅替换--name与 IP 即可。注意initial-cluster中的 URL 必须与各节点自身的initial-advertise-peer-urls一致，且多次创建同配置集群时务必使用唯一的initial-cluster-token，以避免跨集群交互损坏数据。

2. etcd Discovery 引导：成员 IP 无法预知时，借助发现服务自动引导——这正是 production-users 文档中discovery.etcd.io 服务的用武之地，它是这一机制的长期基础设施；
3. DNS Discovery 引导：通过 DNS SRV 记录发现集群成员。

集群运行后，扩容缩容则通过运行时重配置（runtime reconfiguration）完成，引导期专用的--initial-cluster-*参数在首次启动后即被忽略。

日常维护：压缩（compact）与碎片整理（defrag）

maintenance.md 强调，etcd 保存键空间的完整历史，因此必须周期性压缩历史版本，否则最终会耗尽存储空间并触发配额告警（quota alarm），使系统进入受限操作模式。两种方式：

• 手动压缩：etcdctl compact 3（压缩至 revision 3，之前的版本变为不可访问）；
• 自动压缩：--auto-compaction-mode=periodic --auto-compaction-retention=72h（保留 72 小时窗口）或--auto-compaction-mode=revision --auto-compaction-retention=1000（保留最近 1000 个 revision）。

压缩之后，后端数据库会出现内部碎片——已删除数据占用的空间对 etcd 可用但不会归还给文件系统，此时需要执行逐成员碎片整理：

$ etcdctl defrag Finished defragmenting etcd member[127.0.0.1:2379]

注意：defrag会阻塞该成员期间的读写，且请求不会被复制到整个集群，如需全集群整理应使用etcdctl defrag --cluster或在--endpoints中指定所有成员。另外--snapshot-count（v3.2 起默认 100,000）控制内存中保留的 Raft 条目数，是慢跟随者追赶时间与内存占用之间的权衡。

Rainbond 中的 etcd：从第三方依赖到平台核心组件

上述文档与案例描述的是"别人怎么用 etcd"，而 Rainbond 仓库本身就是一个完整的 etcd 生产使用者。从源码可以直接确认 etcd 在 Rainbond 平台中的具体落位。

内嵌版本与依赖关系

go.mod 中声明了github.com/coreos/etcd v3.3.13+incompatible，并通过 replace 指令将依赖指向仓库内./third_party/coreos-etcd（即本文关联文档所在目录）；version/version.go 中确认Version = "3.3.13"、MinClusterVersion = "3.0.0"。也就是说，Rainbond 将 etcd 以内嵌源码形式随仓库分发，官方文档（包括 production-users、op-guide 等）与客户端代码一并可见，方便开发者直接对照。

统一的客户端封装

util/etcd/client.go 提供了面向 Rainbond 全部模块的统一 etcd v3 客户端创建函数NewClient：

• 支持ClientArgs（Endpoints、DialTimeout、AutoSyncInterval、CaFile、CertFile、KeyFile）配置；
• 当三个 TLS 文件齐全时自动构建 TLS 客户端（transport.TLSInfo），用于加密通信；
• 具备健壮的重试逻辑：创建失败时每 10 秒重试并记录日志，直到成功；默认 DialTimeout 为 5 秒、AutoSyncInterval 为 10 秒。

util/etcd/etcd.go 则在 clientv3 之上封装了更上层的键操作原语：

• RemoteKV：通过事务比较（v3.Compare(v3.Version(key), "=", 0)）实现"仅当 key 不存在时创建"的原子语义，冲突时返回ErrKeyExists；
• newSequentialKV：生成<prefix>/0000000000000000N形式的顺序键，并借助__<prefix>记账键与修订版本比较保证并发下顺序键分配的原子性；
• EphemeralKV：将键绑定到会话租约（session lease），租约过期键自动消失，是典型的临时节点实现。

基于 etcd 的分布式主选举

util/etcd/etcdlock/master.go 实现了基于 etcd 的主节点选举（master election）机制：

• CreateMasterLock创建锁，默认端点http://127.0.0.1:2379；
• 内部使用concurrency.Session+concurrency.Election：先通过client.Lease.Grant申请租约，再以Campaign参与选举；
• Start()后异步执行竞选：通过Observe监听选举结果，当选后向事件通道推送MasterAdded，失势时推送MasterModified，会话过期推送MasterError；Stop()时执行Resign主动让位。

这套机制正是生产案例中"分布式锁、调度、主备选举"类场景的标准实现范式——利用 etcd 租约与选举 API 而非自研分布式协议，保证多实例服务只有一个活跃 leader。

etcd 键值命名空间承载消息队列

mq/api/mq/mq.go 中的队列实现命名为etcdQueue，其键模型直接沿用 etcd 键值命名空间：queueKey(topic) = KeyPrefix + "/" + topic，而 config/configs/rbdcomponent/mq_config.go 定义了--key-prefix标志，默认值为/mq。队列启动时注册 builder、worker、健康检查等主题（BuilderTopic、WorkerTopic、WorkerHealth 等），支持Enqueue/Dequeue/TopicIsExist/MessageQueueSize等操作。从源码结构看，该模块围绕"以 /mq 为根的键前缀 + 主题队列"这一 etcd 键值模型设计（当前etcdQueue内部使用内存版KeyValueStore实现队列语义，见 mq/api/mq/store.go），其命名与键组织方式仍是理解平台组件间异步通信的关键入口。

服务发现与第三方服务发现

etcd 在生产案例中最常见的用途——服务发现——在 Rainbond 中有两处直接实现：

• builder/parser/discovery/etcd.go：实现Discoverier接口的 etcd 版本，Connect建立 clientv3 客户端（支持 Username/Password），Fetch通过cli.Get(ctx, key, c.WithPrefix())拉取指定前缀下的全部键，将每个键值 JSON 反序列化为Endpoint，并以键名去除前缀后的部分作为端点标识；
• worker/appm/thirdparty/discovery/etcd.go：为第三方服务（third-party service）提供动态端点发现，支持Fetch之外还实现了Watch——基于cli.Watch(ctx, key, c.WithPrefix(), c.WithRev(version))监听键变化，将mvccpb.PUT/mvccpb.DELETE事件转换为 Create/Update/Delete 端点事件并推送到更新通道；端点数据为{"ip": "...", "port": N}格式，支持 IP 与域名两类端点。

这意味着在 Rainbond 中，注册到 etcd 的第三方服务实例可以自动、实时地同步进 Kubernetes 的端点体系，无需人工维护 Endpoints——这正是文档案例中"服务发现 + 系统配置"场景的平台化落地。

平台数据清理与 etcd 键约定

api/handler/etcd_handler.go 展示了 Rainbond 对 etcd 键空间的运维管理：定义了三类 etcd 键类型——ServiceCheckEtcdKey（源码检测）、ShareResultEtcdKey（应用分享结果）、BackupRestoreEtcdKey（备份恢复），分别对应/servicecheck/<key>、/rainbond/shareresult/<key>、/rainbond/backup_restore/<key>前缀，并提供按前缀批量删除（DeleteWithPrefix）的清理入口。从这些键前缀可以看出，Rainbond 将跨组件任务状态（源码检测、分享、备份恢复的中间结果）存放在 etcd 键空间中，供各组件异步读写。

小结

《Production users》这份档案虽短，却浓缩了 etcd 生产实践最宝贵的实证信息：3/5/7 奇数成员集群、KB～GB 的数据量级分布、裸金属与多云并行的环境选择、以及"可重建则不备份、不可重建必须备份"的策略分野。这些规律与仓库内 clustering.md、hardware.md、maintenance.md 等运维文档给出的引导方式、硬件基线、压缩与碎片整理手段一一呼应。

而在 Rainbond 中，etcd 的角色正是这些案例的高度浓缩：统一客户端封装（util/etcd/client.go）、租约临时节点与顺序键（util/etcd/etcd.go）、主选举（util/etcd/etcdlock/master.go）、消息队列键空间（mq/api/mq/mq.go）、构建期与第三方服务发现（builder/parser/discovery/etcd.go、worker/appm/thirdparty/discovery/etcd.go），以及平台任务状态的键约定与清理（api/handler/etcd_handler.go）。阅读本仓库时，可以沿着这条"官方文档 → 客户端封装 → 业务模块"的链路，把 etcd 的生产经验完整迁移到自己负责的分布式系统中。

• 云原生
• 后端
• 微服务
• DevOps
• AI 应用