微服务通过注册中心实现动态寻址。服务启动时向eureka、Nacos等注册中心上报地址信息并定期发送心跳，注册中心维护实时服务列表；消费者调用前先查询注册中心获取可用实例，支持客户端或服务端发现模式。不同注册中心在一致性、性能上各有侧重，如Eureka为AP高可用，consul基于Raft强一致，Nacos融合配置管理且支持AP/CP切换。spring Cloud集成Nacos时只需引入依赖、配置地址并启用注解，即可实现自动注册与发现，关键在于结合技术栈选择合适方案，并关注健康检查与网络延迟影响。
微服务架构中，服务实例的数量和位置是动态变化的，因此需要一种机制让服务之间能够自动找到彼此。服务注册与发现就是解决这个问题的核心组件。
服务注册是如何工作的
当一个微服务启动后，它会主动向一个集中的服务注册中心（如 Eureka、Consul、zookeeper 或 Nacos）发送自己的网络信息，比如 IP 地址、端口、服务名称、健康状态等。这个过程叫做服务注册。
注册中心会维护一个实时的服务列表，记录当前所有可用的服务实例。服务提供者定期发送心跳来证明自己仍然存活。如果注册中心在一定时间内没有收到某个实例的心跳，就会将其从列表中移除，避免调用方访问到已下线的服务。
服务发现的实现方式
服务消费者在需要调用其他服务时，不会直接写死目标地址，而是向注册中心查询所需服务的可用实例列表。这个过程就是服务发现。
常见模式有两种：
- 客户端发现：消费者从注册中心获取服务列表，自行选择一个实例进行调用（例如使用 ribbon 做负载均衡）。
- 服务端发现：消费者将请求发给网关或负载均衡器，由它们向注册中心查询并转发请求（如 kubernetes 配合 Service 和 Ingress）。
常用的注册中心对比
不同注册中心在一致性模型、性能和功能上有所差异：
- Eureka（netflix）：AP 系统，强调高可用，适合云环境，自我保护机制可防止误删健康节点。
- Consul（HashiCorp）：支持多数据中心，强一致性（基于 Raft），提供健康检查和服务网格集成。
- Nacos（阿里巴巴）：兼具配置管理功能，支持 AP 和 CP 切换，国内生态友好。
- ZooKeeper：CP 系统，强一致性，常用于早期 hadoop 生态，但运维复杂度较高。
实际集成方式举例
- 引入 nacos-discovery 依赖。
- 在 application.yml 中配置 Nacos 服务器地址。
- 启动类添加 @EnableDiscoveryClient 注解（新版本可省略）。
- 服务提供者启动时自动注册，消费者通过 Feign 或 RestTemplate 结合 LoadBalancer 调用。
基本上就这些。关键是选型要结合团队技术栈和部署环境，同时注意健康检查机制和网络延迟对服务发现的影响。