在单体服务里，模块之间调用通常只是函数调用。你知道它在哪个包、哪个文件、哪个接口，引用过来就能用。但当系统开始拆分成多个服务以后，问题一下子就变了：一个服务如果想调用另一个服务，它首先要知道对方在哪里。
表面上看，这只是“拿到一个地址”的问题，实际上它背后牵扯的是服务实例变化、扩缩容、故障摘除、流量切换等一整套运行机制。
服务注册与发现，本质上是在解决分布式系统里最基础也最现实的问题：服务不是固定写死在某台机器上的，那调用方到底该如何动态找到它。
为什么不能把服务地址直接写死
在最简单的场景里，很多人会想：既然服务 A 要调服务 B，那我直接把 B 的 IP 和端口写到配置里不就行了。
这个办法在极小规模场景下也许能短期工作，但很快就会暴露问题。
- 服务实例会重启，IP 可能变化
- 服务会扩容缩容，实例数量不是固定的
- 某些实例可能故障，需要被临时摘除
- 不同环境下的地址配置完全不同
也就是说，服务地址不是一个稳定不变的常量，而是一个会随着运行状态动态变化的信息。
注册与发现分别在做什么
“注册”解决的是服务提供方怎么把自己的可用信息上报出去。
“发现”解决的是服务消费方怎么拿到当前可用的实例列表，并从中选择一个目标去发起调用。
这个过程背后通常包含几个角色。
- 服务提供者：把自己的地址、端口、健康状态等信息上报
- 注册中心：负责存储和维护可用实例信息
- 服务消费者：从注册中心获取可用节点并选择目标实例
这样一来，调用方就不需要关心具体哪台机器在跑，只需要依赖“这个服务名”所对应的当前可用实例集合。
注册中心为什么不能只是个静态表
因为它维护的不是“配置”，而是“运行时状态”。
一个真正有用的注册中心，往往不仅要记录实例信息，还要配合健康检查、心跳机制、实例摘除和变更通知。否则表面上你拿到了一个地址，但这个地址可能对应的是已经挂掉的实例，那服务发现的价值就会大打折扣。
所以注册中心本质上是一层动态的运行时目录，而不是简单的地址簿。
服务发现之后还差哪一步
很多人以为发现到实例列表就结束了，实际上还差非常关键的一步：选择。
如果某个服务有多个实例，消费者不可能同时请求全部节点，它必须根据某种策略选一个目标。于是负载均衡就自然接进来了。也正因为如此，服务发现和负载均衡通常是连在一起理解的。
前者解决“有哪些可用节点”，后者解决“本次该调哪个节点”。
常见问题通常出在哪里
注册与发现最容易出问题的地方，往往不是功能没有，而是边界条件没处理好。
例如。
- 实例已经不可用了，但消费者侧缓存还没更新
- 注册中心里有节点，但健康状态其实异常
- 服务名配置不一致，导致调用方根本找不到目标
- 节点刚扩容出来，流量立刻打满，启动预热还没完成
这些问题会让你意识到：服务发现看起来只是拿地址，实际上它深度参与了系统稳定性。
一个值得自己做的小练习
假设你有一个用户服务，原来只有一个实例。现在把它扩成三个实例，并思考下面几个问题。
- 如果某个实例重启了，调用方如何知道它的地址变了
- 如果某个实例健康检查失败，谁负责把它移出可用列表
- 如果实例数量变化，调用方需要不要重新发版
只要你认真回答这些问题，就会明白为什么服务注册与发现会是微服务治理里最基础的能力之一。
小结
服务注册与发现，解决的并不是一个抽象的“分布式概念”，而是多服务系统里最基础的现实问题：服务实例是动态变化的，调用方不能靠写死地址生存。注册中心负责维护运行时可用实例信息，消费者通过发现机制拿到可用节点，再交给后续的负载均衡和调用治理继续处理。理解这一点，后面很多服务治理能力就都更容易串起来了。