Spring Boot微服务治理实战：从服务注册发现到熔断限流的完整方案

微服务治理的核心问题

微服务架构拆分了单体应用后，服务间调用的可靠性保障成为最大的工程挑战。一个包含20个微服务的系统，一次用户请求可能经过5-8次服务间调用，任意一环故障都可能引发级联失败。治理不是锦上添花，而是微服务架构的生存基础。

治理体系包含四个核心模块：服务注册与发现、负载均衡与流量控制、熔断与限流、可观测性。这四个模块协同工作，缺一则系统在异常场景下的表现会急剧恶化。

服务注册发现：Nacos实战配置

Nacos同时支持CP和AP模式，临时实例（ephemeral=true）走AP模式用心跳保活，持久实例走CP模式用Raft协议保证一致性。大多数微服务场景使用临时实例即可。

# application.yml
spring:
  application:
    name: order-service
  cloud:
    nacos:
      discovery:
        server-addr: nacos-cluster:8848
        namespace: production
        group: DEFAULT_GROUP
        cluster-name: BJ-CLUSTER
        weight: 1.0
        ephemeral: true
      config:
        server-addr: nacos-cluster:8848
        namespace: production
        file-extension: yaml
        shared-configs:
          - data-id: common-redis.yaml
            group: SHARED
            refresh: true

cluster-name用于同机房亲和路由。跨地域部署时，优先路由到同集群的实例，减少跨机房延迟。这个策略需要在负载均衡层配合实现。

Nacos集群部署至少3个节点，使用MySQL持久化数据。节点数量建议奇数（3或5），Raft选举需要多数派同意。

负载均衡与流量控制：Spring Cloud LoadBalancer

Spring Cloud 2020+版本移除了Ribbon，使用Spring Cloud LoadBalancer作为默认负载均衡器。自定义负载均衡策略实现同机房优先路由：

@Configuration
public class ZoneAwareLoadBalancerConfig {
    
    @Bean
    ReactorLoadBalancer<ServiceInstance> zoneAwareLoadBalancer(
            Environment environment,
            LoadBalancerClientFactory factory) {
        String serviceId = environment.getProperty(
            LoadBalancerClientFactory.PROPERTY_NAME);
        return new ZoneAwareLoadBalancer(
            factory.getLazyProvider(serviceId, ServiceInstanceListSupplier.class),
            environment.getProperty("spring.cloud.nacos.discovery.cluster-name", "DEFAULT")
        );
    }
}

流量灰度发布通过Metadata实现。给新版本实例打上version=v2标签，负载均衡器根据请求头中的版本标记路由到对应实例。

熔断降级：Resilience4j配置实战

Resilience4j是Spring Cloud推荐的熔断组件，替代了已停止维护的Hystrix。核心配置：

# Resilience4j配置
resilience4j:
  circuitbreaker:
    configs:
      default:
        slidingWindowSize: 10
        failureRateThreshold: 50
        waitDurationInOpenState: 30s
        permittedNumberOfCallsInHalfOpenState: 5
        slowCallRateThreshold: 80
        slowCallDurationThreshold: 3s
    instances:
      orderService:
        baseConfig: default
      paymentService:
        slidingWindowSize: 5
        failureRateThreshold: 30
        waitDurationInOpenState: 60s
  
  ratelimiter:
    configs:
      default:
        limitForPeriod: 100
        limitRefreshPeriod: 1s
        timeoutDuration: 0
    instances:
      orderApi:
        baseConfig: default
      paymentApi:
        limitForPeriod: 50

在代码中使用注解方式：

@Service
public class OrderService {
    
    @CircuitBreaker(name = "orderService", fallbackMethod = "getOrderFallback")
    @RateLimiter(name = "orderApi")
    @Retry(name = "orderService", fallbackMethod = "getOrderFallback")
    @Timed(value = "order.service", description = "订单查询耗时")
    public Order getOrder(Long orderId) {
        return orderClient.getOrder(orderId);
    }
    
    public Order getOrderFallback(Long orderId, Exception e) {
        log.warn("订单查询降级, orderId={}, error={}", orderId, e.getMessage());
        return Order.builder()
            .id(orderId)
            .status(OrderStatus.UNKNOWN)
            .fallback(true)
            .build();
    }
}

降级方法的签名必须与原方法一致（参数 + 额外的Throwable参数），返回类型相同。降级策略不是返回空数据，而是返回安全的默认值，上层业务可以据此判断走降级流程。

分布式限流：Redis + Lua脚本

单机限流无法应对分布式场景。基于Redis的滑动窗口限流方案：

-- Redis Lua限流脚本
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local now = tonumber(ARGV[3])

redis.call('zremrangebyscore', key, 0, now - window)
local count = redis.call('zcard', key)

if count < limit then
    redis.call('zadd', key, now, now .. '-' .. math.random(1000000))
    redis.call('expire', key, math.ceil(window / 1000))
    return 1
else
    return 0
end

Spring Boot集成时通过DefaultRedisScript加载Lua脚本，执行返回1表示放行、0表示拒绝。Lua脚本在Redis中原子执行，避免了并发竞态问题。

可观测性：链路追踪与指标监控

Micrometer + Prometheus + Grafana构成Spring Boot微服务的可观测性基础设施：

# application.yml - Actuator + Prometheus配置
management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus,metrics
  metrics:
    export:
      prometheus:
        enabled: true
    tags:
      application: ${spring.application.name}
    distribution:
      percentiles-histogram:
        http.server.requests: true
      slo:
        http.server.requests: 100ms,200ms,500ms,1s

SLO配置让Prometheus直方图按照关键延迟阈值分桶，Grafana面板可以展示P50/P95/P99延迟。

分布式链路追踪使用Micrometer Tracing + Zipkin/Jaeger，生产环境采样率设置为10%，核心业务链路可强制采样。

治理配置清单

1. Nacos集群至少3节点，使用MySQL持久化，临时实例+心跳保活
2. 负载均衡配置同集群优先，灰度发布用Metadata路由
3. 熔断器参数根据服务重要性分级：核心服务failureRateThreshold=30%，非核心服务50%
4. 限流分两级：API网关全局限流 + 服务级精细限流
5. 降级方法返回安全默认值而非null，上层可感知降级状态
6. 分布式限流用Redis+Lua原子操作，避免竞态
7. 链路追踪采样率按QPS分级，核心链路强制采样
8. SLO延迟分桶配置100ms/200ms/500ms/1s四档