服务发现：Consul与etcd

可视化演示

展示微服务注册中心的服务注册与发现流程、Raft共识协议Leader选举与日志复制、健康检查与watch通知机制，切换模式理解分布式服务发现核心原理。

1. 服务发现问题：会搬家的奶茶店

在“城市公告栏”出现之前，市民是怎么知道奶茶店地址的？答案是：街道办把店铺名单打印成册，发到每家每户。奶茶店一搬家，市民手里的小册子就废了。微服务架构也是这样：一个订单服务，为了扛住高峰流量会同时启动 6 个实例，每个实例都有独立的 IP 和端口；业务低峰时又缩回 2 个。如果调用方把地址写死在配置文件里，那么每一次弹性伸缩，都要人工去改一遍所有配置，再重启所有调用方。

这种“静态配置”的痛点，在实例数量变多后会急剧放大。假设有 M 个消费者都要调用同一个服务，而服务有 N 个动态实例，那么系统中需要维护的地址条目数就是两者的乘积。任何一个实例扩容、宕机或下线，M 条配置全部作废，改配置的速度永远追不上实例变化的速度。

所以，与其让每个市民都维护一份手抄名单，不如把名单集中到中央广场：消费者想喝奶茶时来查一次，改动只发生在一处。注册中心（Registry）就是这块公告栏，而“服务发现”就是“查公告栏找到该去哪家店”的整个过程。

2. 注册中心原理：公告栏的营业规则

公告栏要运转起来，需要一套明确的规则。首先，每家奶茶店开业时必须到中央广场登记地址，这叫“服务注册”；登记不是永久的——公告栏规定，每家店每 3 秒必须派人来报到一次，否则就视为倒闭并把告示撤下，这叫“心跳续约”；市民来查时，公告栏把当前所有在册地址交给他，这叫“服务发现”；如果一家店连续超过规定时间没来报到，公告栏就会把它的信息擦掉，这个过程由“租约”（Lease）机制完成。

租约本质上是一段“有效期”。每次心跳到达，注册中心就把该实例的过期时刻向后顺延一个 TTL（Time To Live）。当“当前时刻”减去“最后一次心跳到达时刻”大于 TTL 时，注册中心判定该实例失联，将其从在册名单中剔除。这套机制保证了公告栏上的信息总是“新鲜的”，而不是堆着一堆僵尸地址。

市民会问：如果公告栏自己坏了怎么办？这正是下一节两位主角分道扬镳的地方——Consul 和 etcd 用完全不同的方式保证公告栏本身的可靠。

3. Consul 架构：政务大厅加街坊情报员

Consul 的城市治理方案是“双轨制”。一方面，它在市中心建了一座政务大厅，所有店铺的开业、更名、关张等重大登记，都要由大厅里的办事员们集体表决通过后才生效，这就是 Raft 共识协议：一份变更只有获得多数办事员（quorum）盖章，才算正式写进总账簿。另一方面，Consul 在每个街区安插了情报员，情报员之间靠 gossip 协议快速传递“谁家新开了、谁家倒闭了”的消息，这样政务大厅的变更能在几百毫秒内传遍全城，而且某个街区网络不通时，本地依然能通过街坊口述获得大致的服务名单。

政务大厅的多数派决策有一个关键数字：quorum。假设大厅里有 N 个办事员，一次表决至少需要多少票才能通过？答案是超过一半：半数向下取整再加一。这个数字保证了任何两次表决的赞成人群一定有交集，从而不会出现“两个大厅各自为政”的分裂。

回到公告栏的比喻：Consul 的厉害之处在于，政务大厅（Raft）保证总账簿准确，而街坊情报员（gossip）让消息传播得又快又广。多数据中心场景下，每个城市都有自己的政务大厅和情报网络，城市之间各管各的，跨城调用时再互相通气——这就是 Consul 支持多数据中心的底气。

4. etcd 架构：唯一权威的政务大厅

与 Consul 的“双轨制”相反，etcd 的城市只有一座政务大厅里的一本总账簿，规则极其简单：任何变更（包括登记、变更、注销）都必须由大厅的多数办事员盖章才能生效，没有任何街坊情报员来帮忙传话。这就是“纯 Raft 强一致”模型——整个城市只有一个真相源，任何人读到任何信息，都跟总账簿完全一致，不存在“听说”和“传言”。

etcd 还引入了一个有趣的设计：总账簿的每一页都有递增的页码（revision）。每发生一次变更，页码加一，所有历史页面都保留，支持按版本查询。同时，etcd 把“店铺租约”做成了第一等公民：一家店可以领取一张长期租约，以租约 ID 关联自己的告示，只要租约不过期，告示就一直有效；续租时只需给租约续期，而不用一条条重新登记告示，这比逐个刷新地址高效得多。

为了保证读到的内容一定是新的，etcd 的读请求也要访问多数节点——读集合与写集合必须相交。读写多数派条件写作：

用公告栏比喻：etcd 没有街坊情报员，所有消息都以政务大厅盖章的版本为准，因此它的一致性最硬、也最容易推理。代价是：公告栏的每一次心跳、每一次读，都要折返大厅跑一趟，没有“顺路听街坊说一句”的便宜可占。

5. 健康检查：谁来决定一家店算不算活着

公告栏上挂着的地址，只有是健康店铺的才是可用的。两家城市用了不同的办法判断“这家店是否还活着”。Consul 的做法是“网格化巡检”：每个街区的情报员亲自上门探访，开店的人不用自己跑政务大厅报到，而是由情报员主动发起检查——可以是敲一下 HTTP 接口、拨一次 TCP 连接，甚至执行一段自定义脚本，连续失败一定次数就把店铺标记为“异常”，并立刻广播全城。

etcd 则沿用自己“一切以租约为准”的简洁逻辑：店铺自己定期向政务大厅续租，续租成功就代表活着；一旦租约在 TTL 内没有续期，大厅直接把与之关联的告示全部撤下。也就是说，Consul 的检查偏向“主动上门”（agent 执行检查），etcd 的检查偏向“本人报到”（客户端续租）。这也是为什么 Consul 能检查 MySQL 进程是否存活、磁盘是否满了这类“业务健康”，而 etcd 只能判断“这个节点还连不连得上”。

运维上，一个直观指标是服务健康可用率，即健康实例数占总实例数的百分比：

回到比喻：Consul 像是社区医生上门体检，能查出各种疑难杂症；etcd 像是定期在政务大厅签到，不签到就除名。前者信息丰富，后者逻辑极简——没有谁绝对更好，只看你想“体检”还是“点名”。

6. 通知机制：告示一贴出就喊你

市民不可能每秒钟都跑去公告栏盯着看，但新店开业的消息晚知道一分钟，就可能少做一单生意。于是两个城市都提供了“订阅”功能。etcd 的订阅叫 Watch：市民告诉公告栏“我想关注某某类型店铺”，然后挂起一个长轮询，公告栏一旦检测到相关页面版本号变化，立刻返回“有变化”，市民再快速拉取最新内容；如果很长时间没变化，请求也会超时返回，然后市民重新挂起，如此循环。

Consul 的订阅机制叫阻塞查询（blocking query）：名字不同，本质相似——消费者带着自己已知的最新 index 号来问，公告栏发现 index 没变化就一直“hold 住”请求不回复，直到有变更或超时才返回。两者的差异在版本化能力上：etcd 每次变更产生单调递增的 revision，消费者可以从任意版本号开始监听，不漏掉任何一次变更，即使中间离线了也能从断点续传。

Watch 的核心是“从哪个版本开始监听”。客户端记住自己已经处理到的版本号，下一次请求指定从该版本加一开始：

用市民的视角看：Watch 就像在公告栏旁边留了个“有新告示就拍我肩膀”的约定，而且每一张告示都编号，即使你打了个盹，醒来也知道该从哪张看起。Consul 的阻塞查询同样会拍你肩膀，但它的“编号”体系比 etcd 的版本化账本要轻量得多。

7. 选型决策：照着自己城市的样子挑

讲了这么多，最后的问题最实际：我该用哪一种？这里要引入分布式系统最著名的“不可能三角”——CAP 定理。当网络发生分区（P = 1，两片街区暂时失去联系）时，你必须在“一致性”（C，全城看到同一张公告）和“可用性”（A，尽量让市民能查到信息）之间二选一：

结合前几节的对比，选型套路已经很清晰：如果你的城市是 Kubernetes——etcd 就是唯一的官方登记处，深度绑定，直接使用；如果你的业务是 Spring Cloud 这类微服务，需要 HTTP 健康检查、DNS 接口、多数据中心容灾，Consul 更顺手；如果你对一致性极度敏感、不能容忍任何“街坊传言”造成的旧数据，etcd 的纯 Raft 更让人安心。而如果追求“查得到就行，稍微旧点无所谓”，Consul 的 gossip 加阻塞查询会让你更从容。

最终判断标准就一句话：你想要一个“永远准确、但偶尔要排队等大厅”的城市，还是一个“遍布情报员、消息稍慢半拍但始终能问到路”的城市？答案没有对错，只有适不适合。

AI 应用场景

Python 演示

import time  class Registry:    """迷你注册中心: 用内存字典维护地址与租约到期时间"""     def __init__(self, ttl=2.0):        self.ttl = ttl        self._addrs = {}        self._watchers = []     def register(self, name, addr):        self._addrs[name + '#' + addr] = time.time() + self.ttl        self._notify('register', name, addr)     def heartbeat(self, name, addr):        key = name + '#' + addr        if key in self._addrs:            self._addrs[key] = time.time() + self.ttl            return True        return False     def evict_expired(self):        now = time.time()        for key, expire in list(self._addrs.items()):            if expire < now:                del self._addrs[key]                name, addr = key.split('#')                self._notify('evict', name, addr)     def discover(self, name):        return sorted(k.split('#')[1] for k in self._addrs                      if k.startswith(name + '#'))     def watch(self, callback):        self._watchers.append(callback)     def _notify(self, event, name, addr):        for cb in self._watchers:            cb(event, name, addr)  def demo():    reg = Registry(ttl=2.0)    reg.watch(lambda e, n, a: print('[event]', e, n, a))    reg.register('payment', '10.0.0.1:8080')    reg.register('payment', '10.0.0.2:8080')    for i in range(6):        reg.heartbeat('payment', '10.0.0.1:8080')        time.sleep(0.7)        reg.evict_expired()        print('round', i + 1, 'visible:', reg.discover('payment'))    print('final table:', reg.discover('payment'))  if __name__ == '__main__':    demo()

1. self._addrs[name + '#' + addr] = time.time() + self.ttl注册时用“服务名#地址”作为键，值为租约过期时刻。
2. if key in self._addrs:心跳前必须确认该实例已注册，防止陌生实例混入。
3. self._addrs[key] = time.time() + self.ttl续约就是把过期时刻向后推 TTL 秒，相当于奶茶店续报到。
4. for key, expire in list(self._addrs.items()):用 list() 做快照遍历，避免边删边遍历报错。
5. if expire < now:过期判定：租约到期时刻早于当前时刻就剔除。
6. return sorted(k.split('#')[1] for k in self._addrs if k.startswith(name + '#'))发现服务就是按前缀筛选并排序返回地址列表。
7. reg.watch(lambda e, n, a: print('[event]', e, n, a))注册 watcher 回调，模拟订阅通知。
8. time.sleep(0.7)模拟实例心跳周期，周期小于 TTL 才能保持存活。

常见误区

面试题