Spring Cloud 系列 #01：Spring Cloud 微服务

本文系统梳理 Spring Cloud 微服务全家桶的核心组件——注册中心、配置中心、网关、熔断限流、负载均衡、声明式调用、链路追踪，帮助你快速掌握微服务架构的工程实践。

目录

微服务核心组件全景

Spring Cloud 是专为微服务架构设计的"全家桶"框架，与 Spring Boot 分工协作：

• Spring Boot：主内，处理底层柴米油盐（数据访问、RESTful、日志、容器）
• Spring Cloud：主外，提供分布式系统支持（服务发现、配置管理、网关、熔断）

核心组件一览

选型建议：新项目优先选用 Spring Cloud Alibaba 组件（Nacos + Sentinel）+ Spring 原生组件（Gateway + LoadBalancer + OpenFeign），避开已进入维护状态的 Netflix 组件（Hystrix、Ribbon）。

注册中心：Eureka vs Nacos

为什么需要注册中心

微服务集群中服务实例的 IP 动态变化，调用方需要通过注册中心实时获取可用节点列表。

核心机制：

Provider 启动 → 向注册中心注册（服务名 + IP:Port + 健康状态）
Consumer 启动 → 订阅注册中心 → 缓存节点列表到本地
节点变更      → 注册中心推送变更给所有订阅方

Eureka vs Nacos 对比

Nacos 注册示例

# application.yml
spring:
  application:
    name: user-service
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848
        namespace: dev          # 命名空间隔离
        group: DEFAULT_GROUP

// 启动类开启服务发现
@SpringBootApplication
@EnableDiscoveryClient
public class UserServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(UserServiceApplication.class, args);
    }
}

负载均衡：Ribbon vs LoadBalancer

Spring Cloud 的负载均衡是客户端负载均衡：Consumer 从注册中心获取所有 Provider 节点列表，在本地自主选择节点发起调用，不依赖外部负载均衡设备。

Ribbon vs Spring Cloud LoadBalancer

自定义负载均衡策略（金丝雀测试示例）

// com.example — 自定义负载均衡策略，将带有 canary=true 标签的请求路由到灰度节点
@Bean
public ReactorLoadBalancer<ServiceInstance> canaryLoadBalancer(
        Environment environment,
        LoadBalancerClientFactory factory) {
    String name = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);
    return new CanaryLoadBalancer(
        factory.getLazyProvider(name, ServiceInstanceListSupplier.class), name);
}

public class CanaryLoadBalancer implements ReactorServiceInstanceLoadBalancer {
    @Override
    public Mono<Response<ServiceInstance>> choose(Request request) {
        // 检查请求头中是否有 canary 标记
        HttpHeaders headers = ((RequestDataContext) request.getContext())
            .getClientRequest().getHeaders();
        boolean isCanary = "true".equals(headers.getFirst("X-Canary"));

        return serviceInstanceListSupplierProvider.getIfAvailable()
            .get(request)
            .next()
            .map(instances -> selectInstance(instances, isCanary));
    }

    private Response<ServiceInstance> selectInstance(
            List<ServiceInstance> instances, boolean isCanary) {
        List<ServiceInstance> targets = instances.stream()
            .filter(i -> isCanary == "true".equals(i.getMetadata().get("canary")))
            .collect(Collectors.toList());

        if (targets.isEmpty()) targets = instances;
        return new DefaultResponse(targets.get(ThreadLocalRandom.current()
            .nextInt(targets.size())));
    }
}

OpenFeign 声明式客户端

OpenFeign 通过动态代理将接口调用转化为远程 HTTP 调用，让服务间调用像调用本地方法一样简单。

动态代理原理

启动阶段：
  @EnableFeignClients → 扫包加载所有 @FeignClient 接口
  FeignClientsRegistrar → 构造 FeignClientFactoryBean
  ReflectiveFeign → 解析注解元数据，生成 MethodHandler
  → 创建实现 InvocationHandler 的动态代理对象，注入 Spring 容器

运行阶段：
  业务代码调用 FeignClient 接口方法
  → 动态代理拦截
  → 根据 MethodHandler 中的元数据构建 HTTP Request
  → 通过 LoadBalancer 选择目标节点
  → 发起远程 HTTP 调用
  → 反序列化响应，返回结果

基础使用

// 定义 FeignClient 接口（com.example）
@FeignClient(
    value = "order-service",          // 服务名（与注册中心一致）
    fallback = OrderServiceFallback.class  // 降级实现
)
public interface OrderServiceClient {

    @GetMapping("/orders/{orderId}")
    OrderResponse getOrder(@PathVariable("orderId") Long orderId);

    @PostMapping("/orders")
    OrderResponse createOrder(@RequestBody CreateOrderRequest request);

    @GetMapping("/orders")
    List<OrderResponse> listOrders(
        @RequestParam("userId") Long userId,
        @RequestParam(value = "page", defaultValue = "0") int page
    );
}

// 降级实现
@Component
public class OrderServiceFallback implements OrderServiceClient {
    @Override
    public OrderResponse getOrder(Long orderId) {
        return OrderResponse.empty();  // 返回默认值
    }

    @Override
    public OrderResponse createOrder(CreateOrderRequest request) {
        throw new ServiceUnavailableException("订单服务暂不可用");
    }

    @Override
    public List<OrderResponse> listOrders(Long userId, int page) {
        return Collections.emptyList();
    }
}

高级配置

# application.yml
feign:
  client:
    config:
      order-service:           # 针对特定服务的配置
        connect-timeout: 1000  # 连接超时（ms）
        read-timeout: 5000     # 读取超时（ms）
        logger-level: FULL     # 日志级别：NONE/BASIC/HEADERS/FULL
  compression:
    request:
      enabled: true            # 开启请求压缩
      min-request-size: 2048
    response:
      enabled: true            # 开启响应压缩

// 自定义 FeignClient 配置
@Configuration
public class FeignConfig {
    // 自定义请求拦截器（如添加认证 Token）
    @Bean
    public RequestInterceptor authInterceptor() {
        return template -> {
            String token = SecurityContextHolder.getToken();
            template.header("Authorization", "Bearer " + token);
        };
    }

    // 自定义重试策略
    @Bean
    public Retryer feignRetryer() {
        // 初始间隔 100ms，最大间隔 1s，最多重试 3 次
        return new Retryer.Default(100, 1000, 3);
    }
}

配置中心：Spring Cloud Config vs Nacos Config

为什么需要配置中心

微服务数量多，配置分散在各服务中，难以统一管理；配置变更需要重启服务，影响可用性。

配置中心解决：

• 配置集中管理（一处修改，全局生效）
• 动态刷新（不重启服务即可更新配置）
• 环境隔离（dev/test/prod 不同配置）
• 版本管理和回滚

Spring Cloud Config vs Nacos Config

Nacos Config 使用示例

# bootstrap.yml（必须在 bootstrap 中配置，先于 application.yml 加载）
spring:
  application:
    name: user-service
  cloud:
    nacos:
      config:
        server-addr: localhost:8848
        namespace: dev
        group: DEFAULT_GROUP
        file-extension: yaml     # 配置文件格式
        # 加载多个配置文件
        extension-configs:
          - data-id: common.yaml
            group: COMMON_GROUP
            refresh: true

// 动态刷新配置（com.example）
@RestController
@RefreshScope  // 标注此注解，配置变更后自动刷新
public class UserController {

    @Value("${user.max-page-size:20}")
    private int maxPageSize;

    @GetMapping("/users")
    public List<User> listUsers(@RequestParam int size) {
        int actualSize = Math.min(size, maxPageSize);
        return userService.list(actualSize);
    }
}

熔断降级：Sentinel

服务雪崩与容错思路

服务雪崩：下游服务故障（如慢 SQL 导致响应超时），请求积压，依赖该服务的所有上游服务被拖垮，整个集群崩溃。

Sentinel 的"内外兼修"容错思路：

外部流量控制（限流）
  ↓ 拦截超量请求，保护服务入口
内部异常治理（降级 + 熔断）
  ↓ 隔离下游故障，防止级联传播

降级 vs 熔断

熔断状态机：

关闭（Closed）
  ↓ 异常比例超阈值
打开（Open）—— 所有请求直接降级
  ↓ 休眠时间窗口结束
半开（Half-Open）—— 放行少量探测请求
  ↓ 探测成功 → 关闭；探测失败 → 重新打开

Sentinel 流控规则

// 编程方式定义流控规则（com.example）
@PostConstruct
public void initSentinelRules() {
    // 限流规则：QPS 不超过 100
    List<FlowRule> flowRules = new ArrayList<>();
    FlowRule rule = new FlowRule();
    rule.setResource("getUserById");    // 资源名（接口/方法名）
    rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
    rule.setCount(100);                 // QPS 阈值
    rule.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_DEFAULT); // 快速失败
    flowRules.add(rule);
    FlowRuleManager.loadRules(flowRules);

    // 熔断规则：慢调用比例超过 50% 触发熔断
    List<DegradeRule> degradeRules = new ArrayList<>();
    DegradeRule degradeRule = new DegradeRule();
    degradeRule.setResource("getUserById");
    degradeRule.setGrade(CircuitBreakerStrategy.SLOW_REQUEST_RATIO.getType());
    degradeRule.setCount(0.5);          // 慢调用比例阈值 50%
    degradeRule.setSlowRatioThreshold(0.5);
    degradeRule.setTimeWindow(10);      // 熔断时长 10s
    degradeRules.add(degradeRule);
    DegradeRuleManager.loadRules(degradeRules);
}

与 OpenFeign 集成

feign:
  sentinel:
    enabled: true

@FeignClient(value = "order-service", fallbackFactory = OrderFallbackFactory.class)
public interface OrderServiceClient {
    @GetMapping("/orders/{id}")
    OrderResponse getOrder(@PathVariable Long id);
}

@Component
public class OrderFallbackFactory implements FallbackFactory<OrderServiceClient> {
    @Override
    public OrderServiceClient create(Throwable cause) {
        return orderId -> {
            log.error("调用订单服务失败: {}", cause.getMessage());
            return OrderResponse.builder().status("UNAVAILABLE").build();
        };
    }
}

Resilience4j（Spring 原生替代方案）

// com.example — Resilience4j 熔断器示例
@Service
public class UserService {

    @CircuitBreaker(name = "userService", fallbackMethod = "getUserFallback")
    @RateLimiter(name = "userService")
    @Retry(name = "userService")
    public UserResponse getUser(Long userId) {
        return externalUserApi.getUser(userId);
    }

    public UserResponse getUserFallback(Long userId, Exception e) {
        log.warn("熔断触发，返回默认用户: userId={}", userId);
        return UserResponse.defaultUser(userId);
    }
}

resilience4j:
  circuitbreaker:
    instances:
      userService:
        failure-rate-threshold: 50        # 失败率 50% 触发熔断
        wait-duration-in-open-state: 10s  # 熔断持续 10s
        sliding-window-size: 10           # 滑动窗口大小

微服务网关：Gateway vs Zuul

Gateway vs Zuul 对比

结论：新项目统一使用 Spring Cloud Gateway，Zuul 仅用于维护旧系统。

Gateway 核心概念

Route（路由）
  ├── ID：路由唯一标识
  ├── URI：目标服务地址（可以是服务名，如 lb://order-service）
  ├── Predicate（谓词）：路由匹配规则，满足所有谓词才转发
  └── Filter（过滤器）：请求/响应处理链

路由配置示例

# application.yml
spring:
  cloud:
    gateway:
      routes:
        # 路由到用户服务
        - id: user-service-route
          uri: lb://user-service        # lb:// 表示通过注册中心做负载均衡
          predicates:
            - Path=/api/users/**        # 路径匹配
            - Method=GET,POST           # 方法匹配
            - Header=X-Version, v2      # Header 匹配
          filters:
            - StripPrefix=1             # 去掉路径前缀 /api
            - AddRequestHeader=X-Gateway-Source, gateway
            - name: RequestRateLimiter  # 限流过滤器
              args:
                redis-rate-limiter.replenishRate: 10
                redis-rate-limiter.burstCapacity: 20

        # 限时秒杀路由（只在特定时间段生效）
        - id: flash-sale-route
          uri: lb://order-service
          predicates:
            - Path=/api/flash-sale/**
            - Between=2024-11-11T00:00:00+08:00, 2024-11-11T23:59:59+08:00
          order: 1                      # 优先级（数字越小优先级越高）

自定义全局过滤器

// com.example — 全局鉴权过滤器
@Component
public class AuthGlobalFilter implements GlobalFilter, Ordered {

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        ServerHttpRequest request = exchange.getRequest();
        String token = request.getHeaders().getFirst("Authorization");

        if (isPublicPath(request.getPath().value())) {
            return chain.filter(exchange);  // 白名单路径直接放行
        }

        if (token == null || !jwtUtils.validate(token)) {
            exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
            return exchange.getResponse().setComplete();
        }

        // 将用户信息传递给下游服务
        String userId = jwtUtils.getUserId(token);
        ServerHttpRequest mutatedRequest = request.mutate()
            .header("X-User-Id", userId)
            .build();
        return chain.filter(exchange.mutate().request(mutatedRequest).build());
    }

    @Override
    public int getOrder() {
        return -100;  // 负数表示高优先级，在其他过滤器之前执行
    }
}

全局跨域配置

// com.example — 全局 CORS 配置
@Configuration
public class CorsConfig {
    @Bean
    public CorsWebFilter corsWebFilter() {
        CorsConfiguration config = new CorsConfiguration();
        config.addAllowedOriginPattern("*");
        config.addAllowedMethod("*");
        config.addAllowedHeader("*");
        config.setAllowCredentials(true);

        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", config);
        return new CorsWebFilter(source);
    }
}

链路追踪：Sleuth + Zipkin

为什么需要链路追踪

微服务架构中，一次用户请求会经过多个服务，出现 Bug 时难以定位是哪个服务出了问题。链路追踪通过为每次请求生成全局唯一 ID，将所有相关日志串联起来。

Sleuth 核心概念

日志示例：

# 格式：[服务名, TraceId, SpanId, 是否上报Zipkin]
INFO [user-service, a1b2c3d4e5f6, a1b2c3d4e5f6, true] 收到请求 GET /users/123
INFO [order-service, a1b2c3d4e5f6, f1e2d3c4b5a6, true] 查询用户订单
INFO [payment-service, a1b2c3d4e5f6, 1a2b3c4d5e6f, true] 处理支付

调用链示意：

用户请求
  │ Trace ID: a1b2c3
  │
  ├── user-service (Span: A1, Parent: null)
  │     │
  │     ├── order-service (Span: B2, Parent: A1)
  │     │     │
  │     │     └── payment-service (Span: C3, Parent: B2)
  │     │
  │     └── inventory-service (Span: B3, Parent: A1)

Sleuth 四种事件（Annotation）

时延计算：

• 服务端处理时间 = ss - sr
• 网络延迟 = sr - cs（或 cr - ss）
• 总耗时 = cr - cs

集成配置

<!-- pom.xml -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-sleuth-zipkin</artifactId>
</dependency>

# application.yml
spring:
  zipkin:
    base-url: http://localhost:9411  # Zipkin Server 地址
    sender:
      type: web                      # 通过 HTTP 上报（也可用 Kafka/RabbitMQ）
  sleuth:
    sampler:
      probability: 1.0               # 采样率：1.0 = 100%（生产环境建议 0.1）

完整链路追踪方案

微服务日志（含 TraceId/SpanId）
  ↓ Logback/Log4j2 输出
  ↓
ELK Stack（日志收集与检索）
  ├── Logstash：收集和解析日志
  ├── Elasticsearch：存储和索引日志
  └── Kibana：日志查询 UI

Zipkin（调用链可视化）
  ├── 收集 Span 数据
  ├── 展示调用链瀑布图
  └── 统计各服务耗时

排查流程：

1. 用户反馈报错 → 从前端日志/用户行为获取大致时间范围
2. 在 Kibana 中搜索该时间段的 ERROR 日志 → 获取 Trace ID
3. 在 Zipkin 中输入 Trace ID → 查看完整调用链和各节点耗时
4. 定位到出错的服务和 Span → 在 Kibana 中搜索该服务的详细日志

参考资料

• 《Spring Cloud 微服务项目实战》— 极客时间，姚秋辰
• Spring Cloud 官方文档：https://spring.io/projects/spring-cloud
• Spring Cloud Alibaba：https://github.com/alibaba/spring-cloud-alibaba
• Sentinel 官方文档：https://sentinelguard.io/zh-cn/
• Zipkin 官方文档：https://zipkin.io/