服务发现失败怎么办？
在部署微服务时，经常会遇到某个服务启动后无法被其他服务发现的情况。比如订单服务调用库存服务时，提示“服务不可达”。这通常是因为注册中心配置有误，或者服务实例没有正确上报心跳。
检查 Consul、Nacos 或 Eureka 的地址是否填写正确，确保网络互通。例如，在 Nacos 中，如果 application.yml 里注册地址写成了本地回环地址 127.0.0.1，那其他节点自然找不到它。
spring:
cloud:
nacos:
discovery:
server-addr: 192.168.1.100:8848另外，防火墙也可能拦截了注册中心的端口，尤其是生产环境跨服务器通信时，得确认相关端口已开放。
负载均衡策略不生效
明明配置了轮询策略，但请求还是集中在某一台实例上。这种情况多出现在使用 Ribbon 或 Spring Cloud LoadBalancer 的项目中。
先确认是否启用了正确的负载均衡客户端。有些老项目引入了多个负载组件，导致实际运行的是默认的随机策略。可以在配置文件中显式指定：
spring:
cloud:
loadbalancer:
ribbon:
enabled: false同时检查目标服务的实例权重设置。如果某个实例被人为调高权重，流量自然会倾斜。这在灰度发布中是正常操作，但在排查问题时容易被忽略。
链路追踪数据缺失
接入了 SkyWalking 或 Zipkin 后，发现部分接口的调用链断掉了。最常见的原因是某些中间件未适配，比如用了原生的 RestTemplate 却忘了加上 @LoadBalanced 注解，导致上下文传递失败。
另一个典型场景是异步任务脱离主线程。比如在订单创建后通过线程池发送通知，这时候 Span 信息不会自动传递。需要手动将 traceId 从主线程传入子线程，否则追踪系统里就看不到完整的调用路径。
熔断器状态一直打开
Hystrix 或 Sentinel 配置完之后，偶尔出现服务恢复了但熔断器还没闭合的情况。用户访问依然被拒绝，页面显示降级内容。
这通常是熔断恢复时间没设好。比如设置了 30 秒冷却期，但实际服务重启花了 40 秒，等新实例准备好时熔断还没尝试半开状态。可以适当缩短 timeout 窗口，或调整失败率阈值。
还有一种情况是健康检查接口返回异常。即使应用本身正常，但如果 /actuator/health 被网关频繁探测并记录为失败，也会触发持续熔断。建议细化健康检查逻辑，避免因次要依赖影响整体判断。
配置中心更新不生效
改了 Nacos 上的配置，点了发布，但服务日志里参数还是旧的。这时候别急着重启，先看有没有加 @RefreshScope 注解。
Spring Cloud 中，只有标注了 @RefreshScope 的 Bean 才会响应配置刷新。普通 @Component 类即使注入了 @Value，也不会动态更新。另外，静态字段也无法被刷新，这类陷阱在开发中很常见。
如果用了自定义配置类，记得确认监听的 dataId 和 group 是否匹配。有时候测试环境和生产环境的命名习惯不同，比如一个用 hyphen 分隔，一个用下划线，结果监听错了配置项。