硬编码地址为什么走不通

两个服务互相调用时，如果把对方地址写死在配置里，问题马上就来了：服务扩容加了三台机器，调用方配置就得跟着改；某台机器挂了，调用方还一直往死地址发请求。服务实例数量是动态的、地址是会变的，靠人工维护地址清单在微服务规模下根本不可行。

解决办法是引入一个"登记簿"：服务启动时把自己的地址报到登记簿，调用方不问具体地址，而是问登记簿"某某服务现在有哪些健康实例"。这个登记簿就是注册中心，顺带还能统一管理配置。

本文核心知识点
  • 注册发现服务上报地址、消费方按名寻址。
  • Nacos同时当注册中心与配置中心。
  • EurekaAP 优先的经典注册中心。
  • 配置中心配置改动后动态推送、免重启。
注册中心配图：蓝色渐变背景底部一个中央发光方块基座，向上以树状白色发光连线分叉连接多个悬浮圆角服务方块，右侧一个空白配置面板，扁平科技插画
中央基座向上树状连接各服务实例，右侧独立配置面板，正是注册中心加配置中心的拓扑。

注册与发现的基本流程

流程分三步：服务提供者启动时，把自己的 服务名 + IP:端口 + 元数据 注册到注册中心；消费者从注册中心拉到一份该服务的实例列表，并在本地做负载均衡；注册中心定期探测实例健康，把宕机的实例剔除。这样扩容、缩容、故障摘除对调用方都是透明的。

Nacos：注册中心上手

Nacos 是国内最常用的选择，一个组件同时承担注册中心和配置中心。Spring Cloud 接入很简单：引入依赖、配置 Nacos 地址、启动类加注解，服务就自动注册上去了。

spring:
  cloud:
    nacos:
      discovery:
        server-addr: nacos:8848   # 注册中心地址

在 Nacos 控制台能直接看到所有服务的实例列表、健康状态，并能手动下线某个实例用于灰度发布。

Eureka 与 AP 优先

Eureka 是 Spring Cloud 原生的注册中心，设计上AP 优先：注册中心节点之间互相复制，哪怕某个节点网络分区了，它依然能响应注册和查询请求，宁可返回稍旧的实例列表，也不让整个注册服务不可用。Nacos 则可在 CP/AP 间切换。对可用性要求高、能容忍短暂脏数据的场景，AP 优先往往更稳。