概述

服务发现（Service Discovery）是微服务架构中的核心基础设施。在动态的分布式环境中，服务实例的IP地址和端口会随部署、扩缩容、故障恢复等不断变化。服务发现机制使得消费方能够动态获取服务提供方的网络位置。本文对比分析主流的服务发现方案及其适用场景。

两种发现模式

客户端发现（Client-Side Discovery）

客户端从注册中心获取服务实例列表，由客户端自行选择实例进行调用。

代表： Eureka、Nacos（可选模式）、ZooKeeper + 自定义SDK

服务端发现（Server-Side Discovery）

客户端通过负载均衡器（或DNS）调用服务，由服务端组件负责路由到具体实例。

代表： Kubernetes Service、AWS ELB + Cloud Map、Consul Connect

对比

特性	客户端发现	服务端发现
客户端复杂度	高（需集成SDK）	低（只需知道LB地址）
性能	高（直连）	中（多一跳）
语言无关性	低（需各语言SDK）	高（透明代理）
服务治理能力	强（客户端可定制）	依赖LB能力
运维复杂度	低	中（需维护LB）

DNS-Based服务发现

最简单的服务发现方式，通过DNS解析获取服务地址。

; DNS A记录
order-service.internal.example.com. IN A 10.0.1.1
order-service.internal.example.com. IN A 10.0.1.2
order-service.internal.example.com. IN A 10.0.1.3

; DNS SRV记录（携带端口和权重信息）
_grpc._tcp.order-service.internal.example.com. IN SRV 10 60 8080 s1.example.com.
_grpc._tcp.order-service.internal.example.com. IN SRV 10 40 8080 s2.example.com.

优点： 通用性极强，所有语言和框架都支持DNS 缺点： DNS缓存导致更新延迟（TTL），无法携带丰富的元数据，健康检查能力弱

主流方案对比

Consul

HashiCorp出品，基于Raft协议的CP系统，支持多数据中心。

// Consul服务注册（Go SDK）
import "github.com/hashicorp/consul/api"

client, _ := api.NewClient(api.DefaultConfig())

registration := &api.AgentServiceRegistration{
    ID:      "order-service-1",
    Name:    "order-service",
    Port:    8080,
    Address: "10.0.1.1",
    Tags:    []string{"v2", "primary"},
    Meta:    map[string]string{"version": "2.1.0"},
    Check: &api.AgentServiceCheck{
        HTTP:     "http://10.0.1.1:8080/health",
        Interval: "10s",
        Timeout:  "3s",
        DeregisterCriticalServiceAfter: "30s",
    },
}
client.Agent().ServiceRegister(registration)

// 服务发现
services, _, _ := client.Health().Service("order-service", "", true, nil)
for _, entry := range services {
    fmt.Printf("Address: %s:%d\n",
        entry.Service.Address, entry.Service.Port)
}

etcd

CoreOS开发的分布式键值存储，基于Raft的CP系统。需要配合客户端实现服务发现逻辑。

// etcd服务注册
import clientv3 "go.etcd.io/etcd/client/v3"

client, _ := clientv3.New(clientv3.Config{
    Endpoints: []string{"etcd1:2379", "etcd2:2379"},
})

// 创建租约（自动续期，类似心跳）
lease, _ := client.Grant(context.Background(), 10) // 10秒TTL

// 注册服务（带租约）
key := "/services/order-service/10.0.1.1:8080"
value := `{"address":"10.0.1.1","port":8080,"version":"2.1.0"}`
client.Put(context.Background(), key, value, clientv3.WithLease(lease.ID))

// 保持租约存活
ch, _ := client.KeepAlive(context.Background(), lease.ID)
go func() {
    for range ch {
        // 自动续租
    }
}()

// 服务发现（Watch机制）
watchCh := client.Watch(context.Background(), "/services/order-service/",
    clientv3.WithPrefix())
for resp := range watchCh {
    for _, ev := range resp.Events {
        switch ev.Type {
        case clientv3.EventTypePut:
            fmt.Printf("Service UP: %s\n", ev.Kv.Key)
        case clientv3.EventTypeDelete:
            fmt.Printf("Service DOWN: %s\n", ev.Kv.Key)
        }
    }
}

ZooKeeper

Apache基金会项目，基于ZAB协议的CP系统。使用临时节点（Ephemeral Node）实现服务注册，节点断开连接后临时节点自动删除。

Nacos

阿里巴巴开源，同时支持AP和CP模式。

// Nacos服务注册
NamingService naming = NamingFactory.createNamingService("nacos-server:8848");

// 注册实例
Instance instance = new Instance();
instance.setIp("10.0.1.1");
instance.setPort(8080);
instance.setWeight(1.0);
instance.setHealthy(true);
instance.setMetadata(Map.of("version", "2.1.0", "env", "prod"));

naming.registerInstance("order-service", "DEFAULT_GROUP", instance);

// 服务发现（带订阅）
naming.subscribe("order-service", event -> {
    List<Instance> instances = ((NamingEvent) event).getInstances();
    // 更新本地服务列表
    updateLocalServiceList(instances);
});

// 主动查询
List<Instance> instances = naming.selectInstances("order-service", true);
// true: 只返回健康实例

Eureka

Netflix开源的AP系统，Spring Cloud生态的默认选择。

// Eureka客户端配置（Spring Boot）
// application.yml
// eureka:
//   client:
//     service-url:
//       defaultZone: http://eureka1:8761/eureka,http://eureka2:8761/eureka
//   instance:
//     instance-id: ${spring.application.name}:${server.port}
//     prefer-ip-address: true

@FeignClient(name = "order-service")
public interface OrderClient {
    @GetMapping("/orders/{id}")
    Order getOrder(@PathVariable String id);
}

综合对比表

特性	Consul	etcd	ZooKeeper	Nacos	Eureka
一致性模型	CP (Raft)	CP (Raft)	CP (ZAB)	AP/CP可切换	AP
健康检查	HTTP/TCP/gRPC/Script	需自实现	Session	HTTP/TCP/MySQL	客户端心跳
多数据中心	原生支持	需额外方案	不支持	支持	不支持
配置管理	KV存储	KV存储	ZNode	原生支持	不支持
Watch/Push	长轮询 + Blocking Query	gRPC Stream	Watcher	长轮询 + gRPC推送	客户端轮询
语言支持	多语言SDK + DNS/HTTP API	多语言SDK	Java为主	Java为主	Java (Spring)
维护活跃度	高	高	中	高	低（维护模式）

Kubernetes服务发现

Kubernetes内置了服务发现机制，是云原生环境下的首选方案。

# Kubernetes Service
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  selector:
    app: order
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP
---
# 通过DNS访问: order-service.default.svc.cluster.local
# 或简写: order-service (同命名空间)

选型建议

总结

服务发现是微服务架构的基础设施。客户端发现模式提供了更好的性能和灵活性，服务端发现模式则更加语言无关和易于管理。在具体方案选择上，Kubernetes环境优先使用内置的Service机制；Java/Spring Cloud生态优先考虑Nacos；Go/多语言环境推荐Consul或etcd。选择时需要综合考虑一致性需求、健康检查能力、多数据中心支持和团队技术栈等因素。

贡献者

withesse

更新日志

2026/3/14 13:09

查看所有更新日志

• 9f6c2-feat: organize wiki content and refresh site setup于 2026/3/14

编辑此页