微服务架构中的服务发现机制详解：从DNS到注册中心的选择与实践

为什么需要服务发现？

当你的单体应用拆分成十几个微服务后，突然发现一个致命问题——服务之间怎么互相找到对方？硬编码IP？每次上线改配置？服务扩容时手动维护地址列表？别闹了！服务发现就是来解决这个核心痛点的。

基础方案：基于DNS的服务发现

工作原理

DNS轮询是最原始的服务发现方式，通过域名解析返回多个IP地址。我三年前在电商项目就用过这招，结果大促时踩了三个坑：

1. TTL缓存导致服务下线延迟
2. 缺乏健康检查机制
3. 无法实现动态权重分配

适用场景

• 服务变更频率极低的环境
• 对服务发现实时性要求不高的场景
• 预算有限的初期项目（毕竟不用额外组件）

注册中心方案深度对比

Eureka：Spring Cloud的默认选择

架构特点：

• AP设计（保证可用性牺牲一致性）
• 客户端缓存机制
• 自我保护模式（网络分区时的救命稻草）

去年我们迁移到Eureka 2.0时发现个隐藏功能：多级缓存机制使得注册信息获取速度比1.0快3倍。但要注意它的集群同步是异步的，金融级业务慎用。

Consul：全能选手

核心优势：

1. 内置健康检查（支持HTTP/TCP/脚本）
2. 多数据中心支持
3. KV存储功能（能当配置中心用）

实测Consul的WAN gossip协议跨机房同步延迟在200ms内，特别适合我们的跨境业务。但内存消耗比Eureka高30%，小团队要注意成本。

etcd：K8s的御用选择

技术亮点：

• 基于Raft强一致性协议
• 监听机制（watch）响应速度<100ms
• 原生支持TLS加密

有个反直觉的设计：etcd的读写性能随着集群规模增大会下降，3节点是最佳实践。我们压力测试时5节点比3节点QPS反而降了40%。

选型决策树

1. 是否需要强一致性？
   • 是 → etcd
   • 否 → 下一步
2. 是否需要多数据中心？
   • 是 → Consul
   • 否 → 下一步
3. 是否Java技术栈？
   • 是 → Eureka
   • 否 → Consul

实战避坑指南

服务注销的死亡30秒

我们曾因没处理好服务关闭时的注销逻辑，导致线上出现"僵尸服务"调用失败。正确姿势应该是：

1. 先发送SIGTERM信号
2. 等待10秒处理剩余请求
3. 执行注销操作
4. 再等待20秒确保注销完成
5. 最后强制终止

注册中心的高可用设计

千万别把注册中心做成单点！我们的三机房部署方案：

[机房A] 3节点etcd集群
      ↑ 专线同步
[机房B] 3节点etcd集群
      ↑ VPN备份通道
[机房C] 2节点灾备集群

未来演进方向

最近在测试Proxyless Service Mesh方案，用xDS协议直接对接Envoy，注册中心只做最终存储。测试数据显示：

• 服务调用延迟降低15%
• 资源消耗减少20%
• 但复杂度直线上升

要不要尝鲜？我的建议是：等你的微服务超过50个再考虑。