服务注册与发现原理，解决的是一个很实际的问题：微服务实例会扩容、缩容、重启、迁移和故障下线，调用方不能再写死IP和端口，而要通过服务名和健康状态找到当前可用的实例。
前置条件：适合已经了解微服务基础概念，正在学习服务治理、Kubernetes Service、注册中心或应用交付平台的技术读者和平台团队。
为什么微服务不能依赖固定地址
在单体或少量服务场景中，系统之间可以通过固定地址互相调用。但在微服务和容器环境中，服务实例数量经常变化。一个服务可能有多个副本，实例可能因为发布、扩容、故障或调度迁移而改变地址。
如果调用方写死地址，就会遇到几个问题：新增实例无法自动接收流量，故障实例仍然被调用，发布期间地址变化导致调用失败，跨环境迁移需要大量修改配置。服务注册与发现就是为了解决这种动态寻址问题。
服务发现的核心不是保存地址列表，而是让调用方始终拿到当前健康、可用、符合策略的服务实例。地址只是结果，健康状态和治理策略才决定能否被调用。
服务注册负责把实例放进服务目录
服务实例启动后，会把自己的服务名、实例地址、端口、版本、元数据和健康状态注册到注册中心或平台服务目录。这样调用方不需要知道具体实例在哪里，只需要知道要访问哪个服务。
注册信息不能只包含地址。更完整的信息还包括实例所属环境、版本、可用区、权重、协议、标签和健康状态。这样平台才能支持灰度、就近访问、故障摘除和不同环境隔离。
在Kubernetes中，Service和EndpointSlice承担了类似服务发现的基础能力。Pod可以变化，但Service提供稳定访问入口；EndpointSlice记录后端可用Pod集合，kube-proxy或其他网络组件负责把流量转发到具体实例。
服务发现负责把服务名解析成可用实例
调用方发起请求时，不应直接关心某个实例IP，而是通过服务名查询可用实例。服务发现可以发生在客户端，也可以由代理、网关、Service Mesh或Kubernetes网络层完成。
客户端发现模式下，调用方自己从注册中心获取实例列表，并根据负载均衡策略选择目标实例。服务端发现模式下，调用方只访问一个稳定入口，由代理或负载均衡组件在后端选择实例。
| 发现模式 | 调用方职责 | 适用边界 |
| 客户端发现 | 获取实例列表并选择目标实例 | 应用框架能力强，团队能统一SDK |
| 服务端发现 | 访问稳定入口，由中间层转发 | 需要降低应用侵入，统一治理入口 |
| K8s Service | 访问服务名或ClusterIP | 容器平台内服务通信 |
| Service Mesh | 流量经过代理执行策略 | 复杂微服务治理和观测场景 |
不同模式没有绝对优劣。企业更需要判断调用治理应该放在应用代码、平台网络、网关还是服务网格中，避免同一系统里多套发现机制互相叠加。
健康检查决定哪些实例可以被发现
服务注册后并不代表一定可以接收流量。一个实例可能刚启动但还未初始化完成，也可能线程池耗尽、依赖不可用或即将下线。健康检查就是为了判断实例是否应该留在可调用列表中。
健康检查至少要区分存活和就绪。存活检查关注进程是否还活着，就绪检查关注实例是否已经可以处理请求。对Kubernetes应用来说，livenessProbe和readinessProbe的设计会直接影响服务发现结果。
如果就绪检查过于简单，只检查进程存在，流量可能被送到还没有准备好的实例；如果检查过于严格，短暂依赖波动又可能导致实例频繁摘除。健康检查需要结合业务启动流程和依赖关系设计。
负载均衡让流量分配到多个实例
服务发现拿到实例列表后，还需要决定请求发往哪个实例。常见策略包括轮询、随机、最少连接、权重、就近访问和基于标签的路由。微服务系统越复杂，负载均衡策略越需要和灰度、版本、地域和容量配合。
例如灰度发布时，新版本实例可能只接收少量流量；多可用区部署时，请求可以优先访问同区实例；某些实例容量更高时，可以配置更大权重。服务发现和负载均衡结合后，才能从“找到服务”进一步变成“按策略调用服务”。
这也是为什么服务注册与发现常常和API网关、Service Mesh、Kubernetes Service一起讨论。它们都在不同层次参与流量路由和服务治理。
注册发现机制失效时会出现哪些问题
第一类问题是调用到不健康实例。原因可能是健康检查缺失、状态同步延迟、实例下线没有及时摘除，或者调用方缓存了过期实例列表。表现为间歇性失败、连接超时或错误率上升。
第二类问题是服务找不到。原因可能是服务名错误、命名空间不一致、DNS解析异常、注册中心不可用或网络策略阻断。排查时要从服务名、实例列表、DNS、网络和应用日志逐层确认。
第三类问题是流量分配不均。原因可能是负载均衡策略不合理、实例权重配置错误、部分实例就绪状态不稳定，或者长连接导致请求集中。此时不能只看注册成功，还要看请求实际到达了哪些实例。
企业平台应把注册发现纳入服务治理
服务注册与发现不应只是框架内部机制。平台团队需要统一服务命名、环境隔离、健康检查模板、发布摘流、实例状态观测和故障排查入口。否则服务数量增加后，调用关系会变得难以理解。
在Kubernetes场景中，可以从Service、EndpointSlice、Ingress、Gateway API、Service Mesh和可观测平台之间建立统一视图。这样团队既能看到服务入口，也能看到后端实例、调用链路、错误率和延迟。
如果读者正在梳理微服务治理体系，可以结合 应用交付分类 的服务网格、灰度发布和应用生命周期内容，补齐服务从发布到运行的完整治理链条。
最后建议：先统一服务命名和健康检查
服务注册与发现原理并不复杂，但在生产环境中很容易因为命名混乱、健康检查不准、状态同步延迟和多套治理入口叠加而出问题。
建议团队先统一服务命名、命名空间、健康检查和下线流程，再逐步引入更复杂的路由、灰度和服务网格能力。只有基础目录可信，后续流量治理和可观测分析才有稳定依据。
常见问题
服务注册中心和DNS有什么区别？
DNS可以把服务名解析到地址，但传统DNS通常不直接承载丰富的实例元数据、版本、权重、健康状态和治理策略。服务注册中心更关注动态实例管理，能记录实例上线、下线、健康变化和服务元信息。
在Kubernetes中，DNS和Service机制会配合工作：调用方通过服务名访问稳定入口，背后由Service和EndpointSlice维护可用Pod集合。企业理解时不必把DNS和注册中心完全对立，而应看它们在当前平台中分别承担解析、目录和流量转发的哪一部分职责。
服务发现失败应该先查什么？
建议先确认服务名和命名空间是否正确，再检查目标服务是否有健康实例。随后检查DNS解析、Endpoint或实例列表、网络策略、代理配置和应用日志。不要一开始就假设是注册中心故障，很多问题来自命名、健康检查或网络隔离。
如果是在Kubernetes环境中，可以按Service、EndpointSlice、Pod readiness、网络策略和调用方日志逐层排查。关键是把“服务是否存在”“实例是否健康”“调用方是否能解析”“网络是否允许访问”拆开验证。
K8s Service是否已经解决所有服务发现问题？
K8s Service解决了集群内服务稳定访问入口和后端Pod动态变化的问题，是服务发现的重要基础。但它不等于完整服务治理。灰度发布、细粒度流量控制、跨集群发现、mTLS、复杂观测和策略审计，通常还需要网关、服务网格或平台能力补充。
因此，企业可以把K8s Service看作服务发现底座，把API网关、Gateway API、Service Mesh和可观测平台看作不同层次的治理增强。是否需要增强能力，要看服务规模、调用复杂度和治理要求，而不是默认全部引入。
原创声明：本文为 Alauda 原创技术内容，非商业转载须注明出处：https://www.alauda.cn/blog/850/。
文中图示和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
