一、为什么需要服务注册与发现？—— 从单体到分布式的痛点解决
在单体架构中，所有功能模块部署在同一进程内，模块间调用通过本地方法直接实现，不存在 “服务位置” 的问题。但微服务架构下，一个业务系统被拆分为数十甚至数百个独立服务，每个服务可能部署在不同的服务器、容器或云实例中，且会根据流量动态扩缩容，服务的 IP 地址、端口号时刻变化。
此时若采用传统的 “硬编码配置” 方式管理服务地址，会面临三大致命问题：
地址动态变化导致不可用：服务扩容 / 缩容、故障迁移后，旧配置中的地址失效，会引发大量调用失败；
配置维护成本爆炸：当服务数量超过 10 个时，手动更新所有调用方的配置文件会成为运维噩梦，且极易出错；
无法实现负载均衡与故障隔离：硬编码无法动态感知服务健康状态，无法将请求分发到健康节点，也无法避免将流量路由到故障服务。
服务注册与发现机制的核心价值，就是通过一个 “中间协调者”（服务注册中心），自动管理服务地址、感知服务状态，让调用方无需关心服务的具体部署位置，即可实现可靠调用。
666
xxxx
go
