2. 注册中心核心原理：服务注册、服务续约、服务剔除、服务下线、服务发现的完整生命周期

好，咱们今天聊点实在的。注册中心这东西，说白了就是个「通讯录」。服务启动时把自己登记上去，挂了就划掉，别人要找你就来查这个本子。听起来简单？嗯，但里面的门道可不少。

我当年刚接触微服务时，觉得注册中心不就是个存地址的KV存储吗？后来线上出了几次事故，才明白这五个环节——注册、续约、剔除、下线、发现——每一个都藏着坑。今天我把它们掰开揉碎了讲给你听。

2.1 服务注册：服务实例的「上户口」

服务启动时，第一件事就是去注册中心报到。这就像你搬到新城市，先去派出所登记一样。

注册的核心信息有哪些？

• 服务名：比如 order-service，这是唯一标识
• 实例ID：通常是 IP + 端口 + 时间戳，保证全局唯一
• IP和端口：别人要调你，总得知道门牌号吧
• 元数据：版本号、权重、机房信息等，方便做灰度或路由
• 健康状态：刚注册时一般是 UP

我个人习惯用自注册模式。为什么？因为可控。我在项目中遇到过第三方代理漏注册的情况，排查起来特别痛苦。自注册虽然代码侵入性强一点，但出了问题你能立刻定位到是哪个服务没注册上。

// 伪代码：服务注册的核心逻辑
public void register(ServiceInstance instance) {
    // 1. 检查实例是否已存在
    if (registry.containsKey(instance.getId())) {
        // 续约逻辑，后面讲
        renew(instance);
        return;
    }
    // 2. 写入注册表
    registry.put(instance.getId(), instance);
    // 3. 设置过期时间（默认30秒）
    instance.setExpireAt(System.currentTimeMillis() + 30000);
    // 4. 通知订阅者
    notifyListeners(instance, EventType.REGISTERED);
}

2.2 服务续约：心跳保活机制

注册不是一劳永逸的。服务可能挂掉、网络可能闪断，注册中心怎么知道你还活着？靠的就是心跳续约。

续约机制其实很简单：服务每隔一段时间（比如30秒）给注册中心发个心跳，说「我还活着」。注册中心收到后，就把这个实例的过期时间往后推。

续约的关键参数：

参数	默认值	说明
心跳间隔	30秒	服务发心跳的频率
续约超时	90秒	超过这个时间没收到心跳，就认为服务挂了
剔除周期	60秒	注册中心扫描过期实例的频率

你想想看，为什么心跳间隔和超时时间要设置成1:3的比例？这是为了容忍网络抖动。偶尔丢一两个心跳没关系，只要在超时前续上就行。

// 伪代码：续约逻辑
public boolean renew(String instanceId) {
    ServiceInstance instance = registry.get(instanceId);
    if (instance == null) {
        return false; // 实例不存在，需要重新注册
    }
    // 更新过期时间
    instance.setExpireAt(System.currentTimeMillis() + 30000);
    return true;
}

2.3 服务剔除：清理「僵尸实例」

服务可能突然崩溃，连最后的心跳都没来得及发。这时候注册中心里就留下了「僵尸实例」——地址还在，但服务已经不在了。

剔除机制就是注册中心的「清洁工」。它会定期扫描所有实例，把那些过期没续约的实例从注册表中移除。

剔除的触发条件：

• 实例的过期时间 < 当前时间
• 连续N次心跳失败（不同实现策略不同）

我记得有一次线上事故，就是因为剔除机制没生效。某个服务节点内存泄漏，进程还在但已经无法处理请求了。心跳还在发，但业务请求全部超时。后来我加了个「健康检查探针」——不只是看心跳，还要真正去探测服务端口是否可达、业务接口是否正常响应。

// 伪代码：剔除逻辑（简化版）
public void evict() {
    long now = System.currentTimeMillis();
    for (ServiceInstance instance : registry.values()) {
        if (instance.getExpireAt() < now) {
            // 超过续约时间，标记为待剔除
            evictionQueue.add(instance);
        }
    }
    // 批量剔除
    for (ServiceInstance instance : evictionQueue) {
        registry.remove(instance.getId());
        notifyListeners(instance, EventType.EVICTED);
    }
}

2.4 服务下线：优雅地退出

服务剔除是被动的，服务下线是主动的。当你要发布新版本、缩容或者维护时，应该让服务优雅地下线，而不是直接kill进程。

优雅下线的流程：

1. 服务收到停止信号（比如SIGTERM）
2. 向注册中心发送下线请求
3. 注册中心立即移除该实例，并通知所有订阅者
4. 服务等待一段时间（比如30秒），让正在处理的请求完成
5. 服务进程退出

// 伪代码：优雅下线
public void deregister(String instanceId) {
    // 1. 从注册表移除
    ServiceInstance instance = registry.remove(instanceId);
    if (instance != null) {
        // 2. 通知所有订阅者
        notifyListeners(instance, EventType.DEREGISTERED);
        // 3. 标记实例为下线状态
        instance.setStatus(Status.DOWN);
    }
}

2.5 服务发现：调用方如何找到目标服务

前面四个环节都是为了服务发现服务的。服务发现就是调用方去注册中心查询目标服务的可用实例列表。

两种发现模式：

模式	原理	优点	缺点
客户端发现	调用方直接查询注册中心，获取实例列表后自行负载均衡	架构简单，少一次网络跳转	每个客户端都要集成发现逻辑
服务端发现	通过负载均衡器（如Nginx、Kong）查询注册中心，转发请求	客户端无感知，统一管理	多了一次网络跳转，负载均衡器可能成为瓶颈

我个人更倾向客户端发现模式。为什么？因为少一次代理转发，延迟更低。而且现在像Spring Cloud、Dubbo这些框架都内置了客户端发现能力，用起来很方便。

发现的缓存策略：

• 定时拉取：每隔30秒从注册中心拉一次全量实例列表。简单，但数据可能滞后。
• 长轮询：客户端发起一个长连接，注册中心有变更时主动推送。实时性好，但连接数多时压力大。
• WebSocket：双向通信，实时推送。比长轮询更高效，但实现复杂一些。

// 伪代码：服务发现（客户端缓存版）
public List<ServiceInstance> getInstances(String serviceName) {
    // 1. 先从本地缓存查
    List<ServiceInstance> cached = localCache.get(serviceName);
    if (cached != null && !cached.isEmpty()) {
        return cached;
    }
    // 2. 缓存没有，去注册中心查
    List<ServiceInstance> instances = registryClient.getInstances(serviceName);
    // 3. 写入本地缓存
    localCache.put(serviceName, instances);
    return instances;
}

2.6 完整生命周期总结

咱们把五个环节串起来看：

1. 服务启动 → 向注册中心发起注册请求，登记自己的地址和元数据
2. 运行期间 → 每隔30秒发送续约心跳，告诉注册中心「我还活着」
3. 异常宕机 → 注册中心检测到心跳超时，触发剔除机制，清理僵尸实例
4. 正常停止 → 服务主动发起下线请求，优雅地退出
5. 调用方 → 通过发现机制获取可用实例列表，发起远程调用