Spring Cloud on 小蜜蜂

Zuul

Wed, 07 May 2025 23:04:30 +0800

Zuul 的核心概念

（1）Zuul 是什么？

Zuul 是 Netflix 开源的 API 网关，用于微服务架构中的路由、过滤和负载均衡
主要功能：
- 路由：将客户端请求转发到后端服务
- 过滤：在请求和响应的生命周期中执行自定义逻辑
- 负载均衡：与 Ribbon 集成，实现客户端负载均衡

（2）Zuul 的工作流程

路由：根据配置请求转发到对应的微服务
过滤：在请求到达目标服务之前或之后执行过滤逻辑
负载均衡：通过 Ribbon 集成，实现客户端负载均衡

Zuul 的配置

（1）依赖配置

在 pom.xml 添加 Zuul 依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
</dependency>

（2）启用 Zuul

在启动类中添加 @EnableZuulProxy 注解：

@SpringBootApplication
@EnableZuulProxy
public class ZuulApplication {
    public static void main(String[] args) {
        SpringAppliction.run(ZuulApplication.class, args);
    }
}

（3）路由配置

在 application.yml 中配置路由规则：

zuul:
    routes:
        user-service: # 路径名称
            path: /user/** # 路径配置
            serviceId: user-service # 目标服务名称
        order-service:
            path: /order/**
            serviceId: order-service

解释：
- user-service 和 order-service 是路由的名称，可以自定义
- path 是匹配的 URL 路径
- serviceId 是 Eureka 中注册的服务名称
自定义路由
- 如果不想使用服务名称作为路由前缀，可以自定义路由：

zuul:
    routes:
        custom-user-service: # 路由策略
            path: /api/user/** # 匹配路径
            url: http://localhost:8081 # 目标服务地址

负载均衡配置

（1）集成 Ribbon

Zuul 默认集成了 Ribbon，可以通过服务名称实现负载均衡
在 application.yml 中配置 Ribbon：

zuul:
    routes:
        custom-user-service:
            path: /api/user/**
            serviceId: custom-user-service # 使用服务名称
custom-user-service:
    ribbon:
        listOfServers: http://localhost:8081,http://localhost:8082 # 目标服务实例列表
        NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 随机策略

实例：完整的 Zuul 配置

（1）application.yml

user-service:
    ribbon:
        listOfServers: http://localhost:8081,http://localhost:8082 # 目标服务实例列表

（2）启动类

@SpringBootApplication
@EnableZuulProxy
public class ZuulApplication {
    public static void main(String[] args) {
        SpringAppliction.run(ZuulApplication.class, args);
    }
}

Zuul 与 Spring Cloud Gateway对比

对比项	Spring Cloud Gateway	Spring Cloud Zuul 1.x
架构模型	异步非阻塞 (基于 WebFlux 和 Reactor)	同步阻塞 (基于 Servlet)
过滤器链	轻量高效	相对较重
路由匹配	高效的路由匹配算法	相对较慢
内存消耗	较低 (基于 Netty)	较高 (基于 Servlet 容器)
编程模型	响应式编程	传统同步模型
负载均衡	集成 Spring Cloud LoadBalancer	使用 Ribbon
线程切换	较少	较多
连接管理	使用 Netty 连接池	相对简单
协议支持	原生支持 HTTP/2	主要支持 HTTP/1.1
上下文切换	较少	较多
性能	更高	相对较低

Zipkin

Mon, 03 Mar 2025 22:19:24 +0800

Zipkin 是 Twitter 开源的分布式链路追踪系统，用于收集和查看微服务架构中的请求链路数据。它与 Spring Cloud Sleuth（或 Micrometer Tracing）配合使用——Sleuth 负责生成和传播 Trace 数据，Zipkin 负责存储和展示。

架构组成

+-----------+     +-----------+     +-----------+
| Collector | <-- | Reporter | <-- | Instrument|
+-----------+     +-----------+     +-----------+
      |                  |
      v                  v
+-----------+     +-----------+
| Storage   |     | UI        |
+-----------+     +-----------+

Instrument：应用中嵌入的追踪客户端（Brave / Sleuth），生成 Span 数据
Reporter：将 Span 数据异步发送到 Zipkin Server。支持 HTTP、Kafka、RabbitMQ
Collector：接收、验证、存储 Span 数据
Storage：持久化存储（内存/MySQL/ElasticSearch/Cassandra）
UI：Web 界面查询和可视化链路

数据模型

Span 数据结构

public final class Span implements Serializable {
    public static final class Builder {
        private String traceId;       // 全局唯一链路 ID
        private String parentId;      // 父 Span ID（根 Span 为 null）
        private String id;            // 当前 Span ID
        private String name;          // Span 名称（如 "get /user/{id}"）
        private long timestamp;       // 开始时间戳（微秒）
        private long duration;        // 持续时间（微秒）
        private List<Annotation> annotations;  // 关键事件标记
        private Map<String, String> tags;       // 自定义标签
        private Boolean shared;       // 是否被服务端和客户端共享
    }
}

关键 Annotation

标记	含义	用途
cs (Client Sent)	客户端发送请求	计算请求开始时间
cr (Client Received)	客户端收到响应	计算总耗时 = cr - cs
sr (Server Received)	服务端收到请求	计算网络延迟 = sr - cs
ss (Server Sent)	服务端发送响应	计算服务处理时间 = ss - sr
error	请求出错	标记异常链路

数据流

1. 应用通过 Reporter 发送 Span 数据
2. Collector 接收并校验数据完整性
3. 数据存储到 Storage（可选择 ES/Cassandra/MySQL）
4. UI 从 Storage 查询并展示

Reporter 发送方式对比

方式	优点	缺点	场景
HTTP（Web）	部署简单，无需额外组件	请求阻塞风险，吞吐量低	开发和低流量
Kafka	高吞吐，削峰填谷	需要维护 Kafka 集群	生产环境高流量
RabbitMQ	类似 Kafka，与 Spring 生态更适配	需要维护 RabbitMQ	已有 RabbitMQ 的基础设施
Scribe	日志收集	维护成本高	历史遗留系统

使用 Kafka 推荐配置：

spring:
  zipkin:
    sender:
      type: kafka
  kafka:
    bootstrap-servers: localhost:9092

Kafka 的优势：即使 Zipkin Server 短暂不可用，数据也不会丢失（Kafka 持久化缓冲）。

存储后端选择

存储	优势	劣势	推荐场景
内存	零配置，快速体验	重启后数据丢失，容量有限	开发测试
MySQL	运维成熟	查询性能差，数据量大时慢	低流量/小团队
ElasticSearch	查询快，适合全文搜索	运维复杂，资源消耗高	生产环境（推荐）
Cassandra	写入性能极高，天然支持水平扩展	查询功能有限，运维复杂	超大规模集群

生产环境选择建议：ElasticSearch 是最常用的选择，兼顾查询灵活性和写入性能。

数据采样策略

采样重要性

全量采样（probability: 1.0）在高并发下会产生大量数据——1000 QPS 的服务每天产生近亿条 Span。采样是必须的。

采样方式

固定比率采样：默认，按百分比采样

spring:
  sleuth:
    sampler:
      probability: 0.01  # 采样 1%

限速采样：保证每秒最多采样条数

spring:
  sleuth:
    sampler:
      rate: 10  # 每秒最多采样 10 条

自定义采样规则：对某些路径全量采样（如支付、订单相关接口），其他路径降低采样率。需实现 Sampler 接口。

集成示例

spring:
  zipkin:
    base-url: http://zipkin-server:9411
    sender:
      type: web
    enabled: true
  sleuth:
    sampler:
      probability: 0.1

# 启动 Zipkin Server（Docker）
docker run -d -p 9411:9411 openzipkin/zipkin:latest

排查思路

Zipkin UI 看不到数据
- 检查应用能否访问 Zipkin Server：telnet zipkin-server 9411
- 检查采样率是否为 0
- 检查应用日志中是否出现 ZipkinReporter 相关的异常
链路不完整
- 确认所有参与链路的服务都配置了 Zipkin
- 检查异步调用是否丢失 TraceContext——异步线程池中需要手动传播上下文
- 确认 Http Header 未被自定义过滤器清除（X-B3-TraceId 等）
Zipkin 存储满了
- ES：设置 ILM（Index Lifecycle Management）自动删除过期索引
- Cassandra：配置 TTL（Time To Live）
- MySQL：定期清理，或设置较短的数据保留期
性能问题
- Zipkin Collector 成为瓶颈：增加 Collector 实例数
- ES 写入过慢：降低采样率，或使用 Kafka 缓冲
- 使用 sender.type: kafka 将数据发送链路上的压力从应用线程转移到 Kafka

高可用部署

多个 Zipkin Server 实例
    ↑  (Nginx 负载均衡)
Kafka 集群（缓冲区）
    ↑
应用实例（Reporter 写入 Kafka）

部署多个 Collector 实例，使用 Nginx/ALB 负载均衡
使用 Kafka 作为 Reporter 和 Collector 之间的缓冲层
存储后端 ES 集群健康状态决定数据可靠性——使用 3 节点 + 副本策略
ES 使用 ILM 按天生成索引，设置保留天数自动清理

Spring Cloud Sleuth

Thu, 01 Aug 2024 13:54:50 +0800

注意：Spring Cloud Sleuth 已在 Spring Boot 3.x / Spring Cloud 2022.0.x 中被 Micrometer Tracing 取代。新项目直接使用 Micrometer Tracing，旧项目建议迁移。本文基于 Sleuth 2.x 版本。

分布式追踪核心概念

为什么需要链路追踪？

微服务架构中，一个请求可能需要经过多个服务。当请求变慢或报错时，没有链路追踪很难定位问题出在哪个服务、哪个环节。链路追踪通过 Trace ID 将一次请求跨服务的调用串联起来。

核心术语

Trace：一次完整的请求链路，用唯一的 Trace ID 标识
Span：一个工作单元（如一次 RPC 调用、一次数据库查询），包含开始和结束时间
Annotation：关键事件标记，记录请求在不同阶段的时间戳

Trace (traceId=abc)
├── Span 1 (id=1, parentId=null) —— 入口服务
│   ├── cs (Client Sent): 时间戳 T1
│   ├── sr (Server Received): 时间戳 T2 —— 下游服务收到
│   ├── ss (Server Sent): 时间戳 T3 —— 下游服务返回
│   └── cr (Client Received): 时间戳 T4
└── Span 2 (id=2, parentId=1) —— 下游服务调数据库
    ├── cs: 时间戳 T5
    └── cr: 时间戳 T6

通过这 4 个时间点可以计算出：

网络延迟：sr - cs（请求发送耗时）+ cr - ss（响应传输耗时）
服务处理时间：ss - sr（下游服务实际处理耗时）
总耗时：cr - cs

Sleuth 核心功能

自动生成并传播 Trace ID 和 Span ID（通过 HTTP Header 或消息头）
集成 Zipkin 等追踪后端
支持多种通信协议（HTTP、消息队列、gRPC）
日志自动关联——日志中自动添加 [appname, traceId, spanId, exportable]

2024-08-01 10:00:00.123 [http-nio-8080-exec-1] [myapp, 2485ec27856c56f4, 2485ec27856c56f4, true] INFO  - 请求开始

通过这个格式，可以按 traceId 筛选出某个请求在所有服务中的完整日志。

源码分析

Tracer 接口

public interface Tracer {
    Span nextSpan();
    Span nextSpan(Span parent);
    Span newTrace();
    void continueSpan(Span span);
    void close(Span span);
    Span currentSpan();
}

Tracer 负责 Span 的创建和管理。newTrace() 创建全新的 Trace（入口请求），nextSpan() 基于当前 Trace 创建子 Span。

TraceContext 传播

public interface Propagator {
    <C> void inject(TraceContext context, C carrier, Setter<C> setter);
    <C> Span.Builder extract(C carrier, Getter<C> getter);
}

inject 将 TraceContext 写入 HTTP Header（如 X-B3-TraceId），extract 从请求头中提取并恢复上下文。这是跨服务传播的核心接口。

自动配置

@Configuration
@ConditionalOnProperty(value = "spring.sleuth.enabled", matchIfMissing = true)
public class TraceAutoConfiguration {
    @Bean
    public Tracer tracer() {
        return new DefaultTracer();
    }

    @Bean
    public CurrentTraceContext currentTraceContext() {
        return ThreadLocalCurrentTraceContext.create();
    }

}

重要知识点

1. Sleuth 如何实现跨服务上下文传播？

Sleuth 通过 Brave（Zipkin 的 Java 客户端库）实现上下文传播。HTTP 请求经过 RestTemplate / Feign / WebClient 时，Sleuth 自动注入以下 Header：

X-B3-TraceId：全局唯一的 Trace ID
X-B3-SpanId：当前 Span ID
X-B3-ParentSpanId：父 Span ID
X-B3-Sampled：是否采样
X-B3-Flags：调试标记

下游服务收到请求后，从 Header 中提取 X-B3-TraceId，创建子 Span 并将自己作为当前 Trace 的一部分。

2. Trace 和 Span 的关系？

一个 Trace 由多个 Span 组成，形成树状结构
根 Span（第一个 Span）没有 parentId
子 Span 通过 parentId 引用父 Span
所有 Span 共享同一个 traceId

3. 如何自定义 Span？

@Autowired
private Tracer tracer;

public void customSpan() {
    Span span = tracer.nextSpan().name("custom-operation").start();
    try (Tracer.SpanInScope ws = tracer.withSpanInScope(span)) {
        // 业务逻辑
        span.tag("custom-key", "custom-value");
        span.annotate("custom-event");
    } finally {
        span.finish();
    }
}

注意：start() 只调用一次，finish() 会在 finally 中确保执行。使用 withSpanInScope 将当前 Span 绑定到线程上下文。

4. Sleuth 与 Zipkin 集成？

spring:
  zipkin:
    base-url: http://localhost:9411
    sender:
      type: web     # 发送方式: web/kafka/rabbitmq
  sleuth:
    sampler:
      probability: 1.0  # 采样率: 0~1，生产环境建议 0.1 以下

采样率说明：

1.0：100% 采样，开发和调试时使用
0.1：10% 采样，生产环境常用——追踪数据量大时存储和网络压力不可忽视
0.01：1% 采样，高流量系统的保守选择

5. Sleuth 对各种通信方式的支持？

通信方式	支持情况	说明
RestTemplate	自动	通过 ClientHttpRequestInterceptor
Feign	自动	通过 Feign 的 RequestInterceptor
WebClient	自动	通过 ExchangeFilterFunction
RabbitMQ	自动	通过消息头传播
Kafka	自动	通过消息头传播
gRPC	依赖扩展	需额外配置
线程池	需要手动	使用 `Tracer.withSpanInScope` 或 `LazyTraceExecutor`

6. Sleuth 的性能影响？

Sleuth 本身非常轻量，主要开销在：
- Trace ID 的生成和传播（极低）
- 数据发送到 Zipkin（异步，不阻塞请求线程）
- 采样率高时，Zipkin 存储可能成为瓶颈
生产环境建议：probability: 0.01~0.1 + 使用 Kafka 作为 Reporter（避免 HTTP 发送阻塞）

7. Sleuth 如何支持异步操作？

// 方法一：手动绑定上下文
Mono.just("value")
    .doOnNext(value -> {
        Span span = tracer.nextSpan().name("async-operation").start();
        try (Tracer.SpanInScope ws = tracer.withSpanInScope(span)) {
            // 异步逻辑
        } finally {
            span.finish();
        }
    });

// 方法二：使用 Sleuth 提供的 LazyTraceExecutor
@Bean
public Executor asyncExecutor() {
    return new LazyTraceExecutor(tracer, Executors.newFixedThreadPool(10));
}

排查思路

Trace ID 未在日志中出现
- 确认 spring.sleuth.enabled 未被设置为 false
- 确认日志格式正确（Sleuth 通过 MDC 注入 traceId）
- 检查是否使用了自定义 RestTemplate 或 Feign，可能覆盖了默认拦截器
调用链不完整
- 确认所有参与链路的服务都配置了 Sleuth
- 确认服务间的调用方式（HTTP/消息队列）被 Sleuth 支持
- 检查异步操作中是否丢失了上下文——使用 Tracer.withSpanInScope 或 LazyTraceExecutor
Zipkin 看不到数据
- 检查 spring.zipkin.base-url 是否正确
- 检查网络连通性（从应用程序到 Zipkin Server）
- 检查采样率设置：probability: 0 会导致不发送任何数据
迁移到 Micrometer Tracing 的注意点
- 配置从 spring.sleuth.* 变为 management.tracing.*
- Trace ID 格式从 64-bit（Sleuth 默认）变为 128-bit（Micrometer 默认）
- 依赖从 spring-cloud-starter-sleuth 变为 io.micrometer:micrometer-tracing-bridge-brave

Spring Cloud Gateway

Thu, 18 Jul 2024 23:13:45 +0800

Spring Cloud Gateway 核心原理

1. 为什么选择 Gateway 而非 Zuul？

Spring Cloud Gateway 基于 Spring WebFlux 和 Project Reactor，采用反应式编程模型（非阻塞 I/O）。与 Zuul 1.x（基于 Servlet API，同步阻塞）相比：

特性	Gateway	Zuul 1.x	Zuul 2.x
底层模型	Netty + WebFlux	Tomcat + Servlet	Netty
I/O 模型	异步非阻塞	同步阻塞	异步非阻塞
长连接	原生支持	不支持	支持
性能（吞吐量）	高	低（每个请求占用一个线程）	中
学习成本	较高（需了解 Reactor）	低	较高

Gateway 的异步模型意味着：一个请求从进入到返回不占用独立线程，处理过程中线程可以服务其他请求，因此在高并发场景下线程资源占用远少于 Zuul 1.x。

2. 架构组成

Client -> Gateway -> Route Predicate -> Gateway Filter -> Target Service

3. 核心概念

Route：路由，包含目标 URI、Predicate 集合和 Filter 集合
Predicate：断言，用于匹配 HTTP 请求（满足条件才走该路由）
Filter：过滤器，用于修改请求和响应（分为 GatewayFilter 和 GlobalFilter）

4. 工作流程

1. 客户端发起请求
2. Gateway Handler Mapping 查找匹配的路由（遍历所有 Route 的 Predicate 集合）
3. 执行 Gateway Filter 链（pre filters）
4. 代理请求到目标服务
5. 执行 Gateway Filter 链（post filters）
6. 返回响应给客户端

5. 关键组件

RouteLocator：路由定位器，定义路由规则
GatewayFilter：网关过滤器（按路由配置）
GlobalFilter：全局过滤器（所有路由生效）
RoutePredicateHandlerMapping：路由断言处理器映射
WebHandler：Web 请求处理器（底层由 WebFlux 的 DispatcherHandler 执行）

重要知识点

1. Gateway 和 Zuul 的区别？

见上方对比表。核心差异在于线程模型：Gateway 用少量线程处理大量请求（事件驱动），Zuul 1.x 每个请求对应一个线程（同步阻塞）。

2. Gateway 的核心组件？

Route、Predicate、Filter（GatewayFilter + GlobalFilter）、RouteLocator、GatewayFilterFactory

3. 如何自定义过滤器？

自定义 GatewayFilter 实现 GatewayFilter + Ordered 接口：

@Component
public class CustomFilter implements GatewayFilter, Ordered {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 前置处理
        String requestPath = exchange.getRequest().getURI().getPath();
        exchange.getAttributes().put("startTime", System.currentTimeMillis());

        return chain.filter(exchange).then(Mono.fromRunnable(() -> {
            // 后置处理
            Long startTime = exchange.getAttribute("startTime");
            if (startTime != null) {
                long cost = System.currentTimeMillis() - startTime;
                log.info("{} 耗时 {}ms", requestPath, cost);
            }
        }));
    }

    @Override
    public int getOrder() {
        return -1; // 越小越先执行
    }
}

注册方式：在 Route 定义中通过 .filters(f -> f.filter(new CustomFilter())) 注入。

4. Gateway 如何实现负载均衡？

集成 Spring Cloud LoadBalancer
使用 lb://service-id 格式的 URI（例如 lb://user-service）
Gateway 自动从注册中心（Nacos / Eureka）获取服务实例列表
默认负载均衡算法为轮询（支持自定义 ReactiveLoadBalancer）

5. 如何实现限流？

使用 RequestRateLimiter GatewayFilter，基于令牌桶算法：

spring:
  cloud:
    gateway:
      routes:
      - id: limit_route
        uri: http://example.org
        filters:
        - name: RequestRateLimiter
          args:
            redis-rate-limiter.replenishRate: 10  # 每秒填充的令牌数
            redis-rate-limiter.burstCapacity: 20   # 令牌桶容量

注意：GateWay 的限流需要集成 Redis（基于 Redis 的 lua 脚本实现令牌桶），因此必须引入 spring-boot-starter-data-redis-reactive。

6. Gateway 如何实现熔断？

spring:
  cloud:
    gateway:
      routes:
      - id: hystrix_route
        uri: lb://backing-service:8088
        filters:
        - name: Hystrix
          args:
            name: fallbackcmd
            fallbackUri: forward:/fallback

注意：Hystrix 已进入维护状态，新项目推荐使用 Spring Cloud CircuitBreaker（支持 Resilience4J）替代 Hystrix：

filters:
- name: CircuitBreaker
  args:
    name: myCircuitBreaker
    fallbackUri: forward:/fallback

7. 如何实现动态路由？

实现 RouteDefinitionRepository 接口，从数据库或配置中心加载路由：

@Component
public class DynamicRouteService implements ApplicationEventPublisherAware {
    @Autowired
    private RouteDefinitionWriter routeDefinitionWriter;

    public void addRoute(RouteDefinition definition) {
        routeDefinitionWriter.save(Mono.just(definition)).subscribe();
        publisher.publishEvent(new RefreshRoutesEvent(this)); // 刷新路由
    }
}

更新的关键：保存路由定义后必须发布 RefreshRoutesEvent，否则新路由不会生效。

8. Gateway 的安全机制？

集成 Spring Security + OAuth2 / JWT
支持 HTTPS
支持 IP 白名单（通过自定义 GlobalFilter 实现）
常见安全风险：Gateway 默认不校验重复路由、不限制请求体大小——生产环境需额外配置

9. Gateway 的监控？

集成 Actuator，management.endpoints.web.exposure.include=gateway
/actuator/gateway/routes：查看已加载的路由
/actuator/gateway/globalfilters：查看已注册的全局过滤器
结合 Micrometer + Prometheus + Grafana 采集请求延迟和错误率

10. Gateway 如何处理跨域？

spring:
  cloud:
    gateway:
      globalcors:
        cors-configurations:
          '[/**]':
            allowedOrigins: "*"
            allowedMethods:
            - GET
            - POST
            - PUT
            - DELETE
            allowedHeaders: "*"

注意：Gateway 的位置特殊——跨域配置在网关层处理即可，后端服务无需重复配置 CORS。

排查思路

路由不匹配
- 检查 Predicate 顺序（多个 Predicate 为 AND 关系）
- 查看日志：RoutePredicateHandlerMapping 会打印 “Mapping found” 或 “No route found”
转发失败
- 确认目标服务健康（直接访问目标服务接口验证）
- 检查负载均衡 URI 格式是否以 lb:// 开头
- 查看 Gateway 日志：ReadTimeoutException 表示后端响应过慢
过滤器不生效
- GlobalFilter 默认所有路由生效，GatewayFilter 须在路由配置中明确指定
- 检查 Ordered 排序（低 order 值的过滤器先执行前置后执行后置）
WebFlux 与旧版 Servlet 冲突
- 项目中不能同时存在 spring-boot-starter-web 和 spring-boot-starter-webflux，否则 Gateway 无法正常运行（Spring Boot 默认优先使用 Servlet 容器）。排查是否有其他模块引入了 web 依赖。

Spring Cloud Config

Tue, 11 Jun 2024 15:40:53 +0800

核心概念

（1）什么是 Spring Cloud Config？

Spring Cloud Config 是分布式配置管理工具，用于集中管理微服务的配置文件。它解决的核心问题：微服务数量增加后，配置文件散落在各个服务中，修改一个配置需要逐个修改、重启。

（2）组成部分

Config Server：配置中心服务器，从后端存储加载配置并通过 HTTP API 暴露
Config Client：配置客户端，启动时从 Config Server 拉取配置

（3）核心特性

集中化管理：所有微服务配置统一存储在 Git/SVN/本地等后端
动态刷新：通过 /actuator/refresh 或 Spring Cloud Bus 实现不重启更新配置
多环境支持：通过 spring.profiles.active 加载对应环境的配置（如 application-dev.yml）
安全性：支持配置内容的加密和解密（对称 AES 或非对称 RSA）
版本控制：Git 后端天然具备版本历史、回滚、分支管理能力
权限控制：通过 Git 仓库权限 + Config Server 的 Spring Security 双重控制
高可用：Config Server 可集群部署，通过注册中心实现负载均衡

工作原理

Config Server 配置解析路径

Config Server 根据客户端请求的 {application}/{profile}/{label} 路径解析配置。例如客户端请求 /my-app/dev/master，Config Server 会在 Git 仓库中查找：

my-app-dev.yml（应用名+环境）
my-app.yml（应用名级配置）
application-dev.yml（全局环境配置）
application.yml（全局默认配置）

优先级：1 > 2 > 3 > 4（后面覆盖前面）。

Bootstrap 上下文

Spring Cloud Config Client 使用 bootstrap context（由 bootstrap.yml 或 bootstrap.properties 配置），它在主应用上下文创建之前启动，负责：

从 Config Server 拉取配置
将拉取的配置设置为 Environment 属性源
然后才创建主应用上下文

这就是为什么 Config Server 地址必须在 bootstrap.yml 而非 application.yml 中配置——主上下文启动时必须已经有远程配置可用。

配置加载顺序

Config Client 的配置优先级：

bootstrap.yml（配置 Config Server 地址和应用名）
Config Server 返回的远程配置
本地的 application.yml（作用被远程配置覆盖）

配置详解

Config Server 配置

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

server:
  port: 8888

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/your-repo/config-repo.git
          search-paths: config-files
          default-label: master         # 默认分支
          timeout: 10                   # Git 连接超时（秒）
          force-pull: true              # 拉取失败时强制覆盖本地

@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

Config Client 配置

spring:
  application:
    name: my-app
  cloud:
    config:
      uri: http://localhost:8888
      profile: dev
      label: master
      # 失败快速响应（启动时连不上 Config Server 则直接启动失败）
      fail-fast: true
      retry:
        initial-interval: 1000
        multiplier: 1.5
        max-attempts: 5

加密配置

Config Server 支持对配置内容加密，有两种方式：

对称加密：设置 encrypt.key=your-secret-key，然后 POST 到 /encrypt 端点获取密文
非对称加密：配置 RSA 密钥对，将公钥给 Config Server，私钥用于解密

加密后的配置以 {cipher} 前缀存储在 Git 中：

spring:
  datasource:
    password: '{cipher}AQB...encrypted-string...'

动态刷新机制

手动刷新（逐台刷新）

curl -X POST http://localhost:8080/actuator/refresh

只刷新当前实例，其他实例需要逐一调用。适用于：

实例数量少
分批蓝绿部署

全局刷新（通过 Bus）

curl -X POST http://localhost:8888/actuator/bus-refresh

通过消息中间件广播刷新事件，所有订阅的客户端同时刷新。

graph TD;
    A[Config Server 接收到刷新请求] --> B[通过 RabbitMQ 发送刷新事件]
    B --> C[Config Client 接收到刷新事件]
    C --> D[RefreshScope.refreshAll]
    D --> E[销毁 @RefreshScope 标记的 Bean]
    E --> F[重新初始化 Bean]
    F --> G[配置更新完成]

@RefreshScope 的局限性

只对标注了 @RefreshScope 的 Bean 有效，引用了该 Bean 的其他 Bean 不会自动重建
@ConfigurationProperties 类必须同时标注 @RefreshScope 才能刷新
静态变量不会随刷新更新

排查思路

客户端连不上 Config Server
- 检查 bootstrap.yml 中的 spring.cloud.config.uri 是否正确
- 检查 Config Server 是否启动、网络是否可达
- 配置 fail-fast: true 和 retry 可以在连接失败时快速感知
配置未更新
- Config Client 未添加 @RefreshScope
- 调用 refresh 接口时请求体为空（应为 POST 而非 GET）
- 配置在 Git 中已修改但 Config Server 缓存未刷新——设置 spring.cloud.config.server.git.refresh-rate=0
环境加载错误
- 检查 Git 仓库中的文件名格式：必须为 {application}-{profile}.yml
- default-label 分支名需要与 Git 仓库匹配
加密配置无法解密
- 检查 encrypt.key 是否在 Config Server 端正确配置
- 加密的文本首尾是否有 {cipher} 前缀
- 非对称加密时，确保公钥已在环境变量或文件配置中正确设置
Config Server 性能问题
- Git 仓库过大会拖慢首次加载——使用 spring.cloud.config.server.git.clone-on-start=false（首次访问时才克隆）
- 每次请求都访问 Git 仓库有性能损耗——使用本地缓存或 basedir 指向预克隆仓库
- 高并发场景考虑配置强制 skip-ssl-validation 或使用 SSH 而非 HTTPS 避免证书验证开销

Spring Cloud Bus

Fri, 05 Jan 2024 13:42:22 +0800

Spring Cloud Bus 的核心概念

（1）什么是 Spring Cloud Bus？

Spring Cloud Bus 是一个分布式事件总线，用于在微服务之间传播状态变化（如配置更新）
它基于消息中间件（RabbitMQ、Kafka）实现，解决 Config Server 逐台通知的痛点——没有 Bus 时，配置变更后需要逐一重启或手动调用每个客户端端点的 refresh
与 Spring Cloud Config 配合使用是主流场景，但 Bus 本身不依赖 Config——任何需要广播的事件都可以通过 Bus 传播

（2）Spring Cloud Bus 的组成

消息中间件：RabbitMQ 或 Kafka，负责传递事件
事件生产者：Config Server 或其他微服务，发送事件
事件消费者：Config Client 或其他微服务，接收事件并执行相应操作

（3）Spring Cloud Bus 的特点

全局配置刷新：通过 /actuator/bus-refresh 端点触发全局配置刷新
服务状态同步：通过事件传播实现服务状态同步
多消息中间件支持：支持 RabbitMQ 和 Kafka
定点通知：支持指定某个或某几个服务实例刷新（/actuator/bus-refresh/{destination}），避免全量广播

Spring Cloud Bus 的工作原理

（1）事件传播流程

事件生产者（如 Config Server）发送事件到消息中间件
消息中间件将事件广播给所有订阅该队列的消费者
事件消费者接收到事件并执行相应操作

关键：每个 Bus 客户端启动时会在消息中间件中创建自己的唯一队列（基于 spring.cloud.bus.id），Bus 通过这个队列实现定点通知——/bus-refresh/user-service:** 只会发送给 service ID 为 user-service 的实例。

（2）全局配置刷新流程

管理员调用 POST /actuator/bus-refresh（向任意一个 Bus 客户端请求即可——它会通过消息中间件广播给所有实例）
该客户端发布 RefreshRemoteApplicationEvent
消息中间件广播该事件
所有 Config Client 监听到事件，调用 ContextRefresher.refresh() → RefreshScope.refreshAll()
标记了 @RefreshScope 的 Bean 被销毁并重新创建，加载新配置

Spring Cloud Bus 的配置

（1）RabbitMQ 配置

spring:
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest

（2）Kafka 配置

spring:
  kafka:
    bootstrap-servers: localhost:9092
    consumer:
      group-id: my-group

（3）添加依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId> <!-- RabbitMQ -->
    <!-- 或 -->
    <!-- <artifactId>spring-cloud-starter-bus-kafka</artifactId> --> <!-- Kafka -->
</dependency>

（4）暴露 Actuator 端点

management:
  endpoints:
    web:
      exposure:
        include: bus-refresh

Spring Cloud Bus 的使用场景

（1）全局配置刷新

# 全量刷新
curl -X POST http://localhost:8888/actuator/bus-refresh

# 定点刷新（只刷新 user-service）
curl -X POST http://localhost:8888/actuator/bus-refresh/user-service:**

（2）自定义事件

// 发送自定义事件
@Autowired
private ApplicationEventPublisher publisher;

public void sendCustomEvent() {
    publisher.publishEvent(new MyCustomEvent(this, "custom-data"));
}

// 接收自定义事件
@EventListener
public void handleCustomEvent(MyCustomEvent event) {
    // 处理事件
}

注意：自定义事件必须继承 RemoteApplicationEvent 才能通过 Bus 传播到其他服务节点，否则只会在本地发布。

（3）指定服务刷新的场景

当集群中不同服务配置不同时，全量刷新可能造成混乱。定点刷新适用于：

灰度配置发布：只刷新新版本的服务实例
分批部署：一组一组刷新，观察无问题后再继续

Spring Cloud Bus 源码概览

（1）BusRefreshEndpoint

@Endpoint(id = "bus-refresh")
public class BusRefreshEndpoint {

    private final ApplicationEventPublisher publisher;

    public BusRefreshEndpoint(ApplicationEventPublisher publisher) {
        this.publisher = publisher;
    }

    @WriteOperation
    public void refresh() {
        publisher.publishEvent(new RefreshRemoteApplicationEvent(this, null, null));
    }
}

（2）RefreshRemoteApplicationEvent

public class RefreshRemoteApplicationEvent extends RemoteApplicationEvent {
    public RefreshRemoteApplicationEvent(Object source, String originService, String destinationService) {
        super(source, originService, destinationService);
    }
}

destinationService 参数用于定点通知：null 表示广播给所有服务，指定值（如 user-service:**）则只发送给匹配的实例。

（3）RefreshListener

public class RefreshListener implements ApplicationListener<RefreshRemoteApplicationEvent> {

    private final RefreshScope refreshScope;

    public RefreshListener(RefreshScope refreshScope) {
        this.refreshScope = refreshScope;
    }

    @Override
    public void onApplicationEvent(RefreshRemoteApplicationEvent event) {
        refreshScope.refreshAll();
    }
}

常见问题排查

Bugs 刷新后配置未生效
- 检查 @RefreshScope 是否标注在使用配置的 Bean 上（注意：@RefreshScope 只对加了该注解的 Bean 有效，其依赖的其他 Bean 不会重建）
- @ConfigurationProperties 的类只需标注 @RefreshScope 即可刷新，但已经在使用的 Bean 不会自动重新注入——需要确保引用方也标注 @RefreshScope
- 检查 Control Bus 端口（spring.cloud.bus.id）是否在多个服务间唯一
事件未传播到其他服务
- 检查所有服务是否连接到同一个消息中间件实例（不同的 RabbitMQ vhost 或 Kafka topic 会导致隔离）
- 检查 spring.cloud.bus.destination 配置是否一致（默认 springCloudBus 即可）
Bus refresh 导致启动过慢
- Bus 客户端启动时会连接到消息中间件，如果中间件不可用，启动会卡住。可通过 spring.cloud.bus.enabled=false 禁用非必要实例的 Bus 功能
- 建议配置 spring.cloud.bus.env.enabled=true（默认开启），允许 Bus 端点只在特定 profile 下启用
RabbitMQ 配置正确但连接失败
- 检查防火墙和端口（5672 是 AMQP 端口，15672 是管理控制台——两者不要混淆）
- 验证 RabbitMQ 的 vhost 和用户权限

Ribbon

Wed, 19 Apr 2023 21:09:25 +0800

注意：Ribbon 已进入维护状态（Netflix 不再积极开发）。从 Spring Cloud 2020.0.x（Ilford）开始，官方推荐使用 Spring Cloud LoadBalancer 作为替代。新项目直接使用 LoadBalancer，旧项目建议逐步迁移。本文内容基于 Ribbon 2.x 版本。

核心概念

Ribbon 是 Netflix 开源的客户端负载均衡器，核心功能：

负载均衡：从多个服务实例中选择一个处理请求
故障转移：选择的实例不可用时自动重试其他实例
重试机制：支持配置重试次数和超时

关键设计点：Ribbon 是客户端负载均衡，与 Nginx 等服务端负载均衡不同：

特性	客户端负载均衡（Ribbon）	服务端负载均衡（Nginx）
位置	在应用内部运行	独立部署
实例感知	从注册中心获取列表	配置 upstream
故障转移	自动重试其他实例	需在 upstream 配置
部署复杂度	无需额外部署	需要独立部署和运维

工作原理

服务发现：Ribbon 从注册中心（如 Eureka）获取服务实例列表，并动态更新
负载均衡：根据配置的策略从列表中选择一个实例
故障转移：不可用时自动重试其他实例
请求分发：将请求分发到选定实例，处理响应

完整请求流程

Client Request
    → RestTemplate/Feign (URL: http://service-name/endpoint)
    → RibbonLoadBalancerClient.choose("service-name")
        → DynamicServerListLoadBalancer.getServerList()
            → EurekaClient.getInstancesByVipAddress()
        → IRule.choose(serverList)
            → 选择策略: 轮询/随机/加权...
    → 发送 HTTP 请求到选定实例
    → 失败时: RetryHandler 重试其他实例
    → 返回响应

负载均衡策略详解

Ribbon 提供 7 种内置策略：

策略类	说明	适用场景
RoundRobinRule	轮询	默认策略，各实例配置均衡
RandomRule	随机	无状态服务
WeightedResponseTimeRule	加权响应时间	实例性能不均
ZoneAvoidanceRule	区域感知	多数据中心部署
BestAvailableRule	最小并发	长连接场景
RetryRule	带重试的轮询	需要自动重试
AvailabilityFilteringRule	可用性过滤	剔除熔断实例

配置方式

全局配置

ribbon:
  ConnectTimeout: 1000
  ReadTimeout: 3000
  MaxAutoRetries: 0          # 同一实例重试次数
  MaxAutoRetriesNextServer: 1 # 切换实例重试次数
  OkToRetryOnAllOperations: false  # 是否所有操作都重试

服务级配置

service-name:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule
    MaxAutoRetries: 3
    MaxAutoRetriesNextServer: 1
    ConnectTimeout: 1000
    ReadTimeout: 3000

代码配置

@RibbonClient(name = "service-name", configuration = MyRibbonConfig.class)
public class MyRibbonConfig {
    @Bean
    public IRule ribbonRule() {
        return new RandomRule();
    }

    @Bean
    public RetryHandler retryHandler() {
        // 参数: maxRetriesOnSameServer, maxRetriesOnNextServer, okToRetryOnAllOperations
        return new DefaultLoadBalancerRetryHandler(3, 1, true);
    }
}

注意：使用 @RibbonClient 时，配置类不能被 @ComponentScan 扫描到（否则成为全局配置），建议放在启动类所在包之外。

使用场景

与 RestTemplate 集成

@Bean
@LoadBalanced
public RestTemplate restTemplate() {
    return new RestTemplate();
}

// 调用时直接用服务名，Ribbon 自动解析为实例 IP:PORT
String response = restTemplate.getForObject("http://service-name/endpoint", String.class);

与 Feign 集成

Feign 默认集成 Ribbon，无需额外配置：

@FeignClient(name = "service-name")
public interface MyFeignClient {
    @GetMapping("/endpoint")
    String getResponse();
}

底层原理

ILoadBalancer 接口

Ribbon 的核心接口是 ILoadBalancer，负责管理服务实例列表：

public interface ILoadBalancer {
    void addServers(List<Server> newServers);
    Server chooseServer(Object key);     // 选择一个实例
    void markServerDown(Server server);
    List<Server> getServerList(boolean availableOnly);
    void markServerDown(Server server);
}

默认实现 DynamicServerListLoadBalancer 通过 ServerListUpdater 定时从注册中心拉取最新实例：

public class DynamicServerListLoadBalancer<T extends Server> extends BaseLoadBalancer {
    private final ServerList<T> serverList;
    private final ServerListUpdater serverListUpdater;

    protected void updateListOfServers() {
        List<T> servers = serverList.getUpdatedListOfServers();
        setServersList(servers);
    }
}

IRule 负载均衡策略接口

public interface IRule {
    Server choose(Object key);
    void setLoadBalancer(ILoadBalancer lb);
    ILoadBalancer getLoadBalancer();
}

从 Eureka 获取实例

public class DiscoveryEnabledNIWSServerList extends AbstractServerList<DiscoveryEnabledServer> {
    private final EurekaClient eurekaClient;
    private final String serviceId;

    private List<DiscoveryEnabledServer> obtainServersViaDiscovery() {
        List<InstanceInfo> listOfInstanceInfo = eurekaClient.getInstancesByVipAddress(serviceId, false);
        for (InstanceInfo instanceInfo : listOfInstanceInfo) {
            if (instanceInfo.getStatus() == InstanceInfo.InstanceStatus.UP) {
                serverList.add(new DiscoveryEnabledServer(instanceInfo, false, true));
            }
        }
        return serverList;
    }
}

迁移到 Spring Cloud LoadBalancer

从 Spring Cloud 2020.0.x 开始，Ribbon 被 LoadBalancer 取代。迁移要点：

移除 Ribbon 依赖：删除 spring-cloud-starter-netflix-ribbon
添加 LoadBalancer 依赖：spring-cloud-starter-loadbalancer
接口变化：
- ILoadBalancer → ReactiveLoadBalancer / BlockingLoadBalancerClient
- IRule → ReactiveLoadBalancer 实现（如 RoundRobinLoadBalancer）
- @RibbonClient → 无直接等价，通过 LoadBalancerClient 配置
配置变化：service-name.ribbon.* → spring.cloud.loadbalancer.*

# LoadBalancer 配置示例
spring:
  cloud:
    loadbalancer:
      retry:
        enabled: true
      health-check:
        interval: 30s
      configurations: health-check # 启用健康检查

排查思路

负载均衡不生效（总是访问同一个实例）
- 确认 @LoadBalanced 注解已在 RestTemplate Bean 上
- 检查服务名解析：http://service-name/ 中的 service-name 是否与注册中心的服务名一致
- Ribbon 默认使用 ZoneAvoidanceRule，如果所有实例在同一 zone，行为类似轮询
实例列表未更新
- 检查 ServerListRefreshInterval（默认 30 秒）
- 检查 Eureka Client 的 eureka.client.registryFetchIntervalSeconds（默认 30 秒）
重试不生效
- Ribbon 本身不触发重试——需要配合 Spring Retry（需引入 spring-retry 依赖）
- 只有 @LoadBalanced 的 RestTemplate 或 Feign 客户端才会触发 Ribbon 重试
- 确保 MaxAutoRetries 和 MaxAutoRetriesNextServer 配置了正值
引入 LoadBalancer 后 Ribbon 失效
- Spring Cloud 2020.0.x 默认禁用了 Ribbon，如果仍想使用需要设置 spring.cloud.loadbalancer.ribbon.enabled=true（但已不推荐）

Nacos

Tue, 03 May 2022 20:54:29 +0800

一、Nacos 核心概念

是什么？

Nacos（Dynamic Naming and Configuration Server）是阿里开源的服务发现+配置管理+服务治理平台，核心功能：

服务发现与健康监测：服务注册、心跳机制、DNS 查询
动态配置管理：配置发布、监听、版本管理
动态 DNS：基于权重的路由、地域就近访问
服务元数据管理：支持应用/版本/环境等元数据

关键特性
- 双模式：支持 CP（强一致性、如配置管理）和 AP（高可用，如服务发现）
- 配置实时推送：基于长轮询（减少无效请求）
- 生态兼容：无缝集成 Spring Cloud、Dubbo、Kubernetes

二、核心架构与原理

服务注册与发现流程
- 注册：服务启动时向 Nacos Server 发送注册请求（HTTP/gRPC）
- 心跳：客户端定期发送心跳（默认5秒），超时（15秒）标记为不健康，30秒后剔除
- 发现：消费者通过订阅机制获取服务列表，本地缓存+增量更新
配置管理机制
- 发布配置：通过控制台/API发布配置，存储于 Derby 或 MySQL
- 监听配置：客户端长轮询（默认30秒），服务端 Hold 住请求，配置变更立即返回
- 历史版本：支持配置回滚和版本对比
一致性协议
- CP 模式：使用 Raft 协议（配置管理场景）
- AP 模式：自研 Distro 协议（服务发现场景，最终一致性）

三、重要知识点

Nacos vs Eureka vs Zookeeper？
- Eureka：AP 设计，适合服务发现，但功能单一
- Zookeeper：CP 设计，强一致性，但写性能低
- Nacos：AP/CP 可切换，集成服务发现+配置管理，生态更全面
长轮询如何实现配置实时推送？
- 客户端发起查询请求，若配置无变化，服务端 Hold 请求至超时（默认30秒）或期间配置变更立即返回
- 对比传统轮询：减少无效请求，提升实时性
- 对比 WebSocket：长轮询服务端实现更简单，但存在30秒最大延迟（非实时配置场景选长轮询即可，实时性要求极高场景考虑 gRPC 流式推送）
Nacos 集群如何保证数据一致性？
- Distro 模式（AP 模式）：每个节点负责部分数据，通过异步复制保证最终一致性。写入时先写本地，再异步复制到其他节点；读取时可能读到旧数据，但通常可接受（服务发现场景对一致性要求不高）。
- Raft 协议（CP 模式）：选举 Leader，多数节点写成功才返回。适用于配置管理——配置错了影响面大，宁可不更新也不能不一致。
Nacos 2.0 升级了哪些内容？
- 通信层优化：gRPC 替代 HTTP，减少连接数（1.x 每个客户端与 server 维持多个 HTTP 长连接，2.0 全复用为一条 gRPC 连接）
- 长连接增强：支持服务端主动推送，降低延迟
- 性能提升：支撑百万级服务实例
如何实现配置灰度发布？
- 通过 Data ID 或 Group 分组，结合 Spring Cloud 的 @RefreshScope 或监听 ConfigChangeEvent 实现部分实例更新
- 更优雅的方式：使用 Nacos 的 Beta 发布功能——指定目标 IP 列表，只有命中 IP 的客户端拉取到灰度配置。验证无误后再全量发布。

四、实战场景与排查思路

服务注册失败常见原因
- 网络不通：检查 Nacos Server 地址和端口（telnet 或 nc 测试连通性）
- 版本冲突：Spring Cloud Alibaba 与 Nacos 版本不兼容 → 参考官方版本对应表
- 命名空间/Group 配置错误：客户端 namespace 和 group 须与服务端一致，命名空间为空时默认使用 public
- 防火墙/安全组拦截：gRPC 端口（9848/9849）需额外开放
配置不生效排查步骤
- 检查控制台配置是否发布成功（Data ID、Group、命名空间与客户端代码匹配）
- 检查 @RefreshScope 是否加在正确的位置——标注在 @Configuration 类上可能导致整个类重新创建，注意副作用
- 查看日志：com.alibaba.nacos.client.config.listener 包日志是否有监听异常
- 长轮询超时确认：查看请求日志中 HTTP 状态码是否为 200（非 304 表示配置变更）
Nacos 集群部署注意事项
- 至少 3 个节点形成 Raft 选举（节点数建议奇数，避免脑裂）
- 使用 MySQL 作为外部存储（Derby 仅适合单机测试——集群模式下不使用 MySQL 会导致各节点数据不一致）
- 所有节点配置文件中的 cluster.conf 必须包含所有节点地址
- 通过 Nginx 做负载均衡时，gRPC 长连接需要配置 upstream 为 ip_hash 或使用 nginx-stream 模块

五、高级话题

Nacos-Sync 应用
- 跨注册中心同步（如 Kubernetes Service 到 Nacos、Eureka 迁移到 Nacos）
- 本质是事件监听+双向同步，注意循环同步问题（A→B→A 死循环），Nacos-Sync 通过记录同步来源避免
安全控制
- 开启鉴权：nacos.core.auth.enabled=true，配置自定义用户角色
- 重要：Nacos 2.2.3 之前默认鉴权不开启，且密钥为硬编码，务必修改 nacos.core.auth.plugin.nacos.token.secret.key
双活部署
- 多数据中心通过 Nacos-Sync 同步数据，结合 DNS 实现流量切换
- 注意：跨地域同步存在网络延迟，配置变更可能在数秒后才能传播到异地——不要依赖 Nacos 跨地域强一致

Hystrix

Wed, 22 May 2019 15:49:23 +0800

功能

服务熔断
服务降级
资源隔离
请求缓存
请求合并

核心思想

防止服务雪崩当一个服务发生故障时，避免故障扩散到整个系统
快速失败通过熔断机制快速失败。避免资源耗尽。
优雅降级在服务不可用的时候，提供备用方案（Fallback）

熔断器（Circuit Breaker）

原理
- 当服务的容错率超过阈值时，熔断器会被打开，后续请求会直接失败，不再调用目标服务
- 熔断器打开一段时间后，会进入半打开状态，尝试恢复服务
关键参数
- circuitBreaker.requestVolumeThreshold：触发熔断器需要最小请求数
- circuitBreaker.errorThresholdPercentage：错误率阈值（默认为50%）
- circuitBreaker.sleepWindowInMilliseconds：熔断器打开后的休眠时间（默认为5秒）

资源隔离

线程池隔离
- 每个服务调用使用独立的线程池，避免资源竞争
- 通过 HystrixThreadPoolKey 配置线程池
信号量隔离
- 使用信号量限制并发数，适用于轻量级调用（执行时间短的任务）

服务降级

原理
- 当服务调用失败或者熔断器打开时，执行降级逻辑
- 降级逻辑可以是返回默认值、调用备用服务等
实现
- 通过 HystrixCommand(fallbackMethod = “fallbackMethod”) 指定降级方法

请求缓存

原理
- 对相同请求参数，Hystrix 可以缓存结果，减少重复调用
实现
- 使用 @CacheResult 和 @CacheKey 注解

请求合并

原理
- 将多个请求合并为一个批量请求，减少网络开销
实现
- 使用 @HystrixCollapser 注解

工作流程

请求进入：
1. 请求被 Hystrix 拦截
检查熔断器状态
1. 如果熔断器打开，直接执行降级逻辑
资源隔离
1. 根据配置选择线程池隔离或信号量隔离
执行目标服务
1. 调用目标服务，记录成功或者失败
更新熔断器状态
1. 根据调用结果更新熔断器状态
执行降级逻辑
1. 如果调用失败或者熔断器打开，执行降级逻辑
返回结果
1. 返回调用结果或者降级结果

sequenceDiagram
    participant Client as 客户端
    participant Hystrix as Hystrix
    participant TargetService as 目标服务
    participant Fallback as 降级逻辑

    Client->>Hystrix: 1. 发起请求
    Hystrix->>Hystrix: 2. 检查熔断器状态
    alt 熔断器关闭
        Hystrix->>Hystrix: 3. 资源隔离（线程池/信号量）
        Hystrix->>TargetService: 4. 调用目标服务
        TargetService-->>Hystrix: 5. 返回结果
        Hystrix->>Hystrix: 6. 更新熔断器状态
        alt 调用成功
            Hystrix-->>Client: 7. 返回结果
        else 调用失败
            Hystrix->>Fallback: 8. 执行降级逻辑
            Fallback-->>Hystrix: 9. 返回降级结果
            Hystrix-->>Client: 10. 返回降级结果
        end
    else 熔断器打开
        Hystrix->>Fallback: 11. 执行降级逻辑
        Fallback-->>Hystrix: 12. 返回降级结果
        Hystrix-->>Client: 13. 返回降级结果
    end

底层原理

熔断器实现
1. 状态机
  1. 熔断器有三种状态：CLOSED （关闭）、OPEN（打开）、HALF_OPEN（半开）
  2. 状态转换基于容错率和请求量
2. 滑动窗口
  1. 使用滑动窗口统计最近一段时间的请求成功率和错误率
线程池隔离
1. 线程池管理
  1. 每个服务调用使用独立的线程池，避免资源竞争
  2. 线程池大小通过 **coreSize **和 **maxSize **配置。
2. 队列管理
  1. 使用有界队列（BlockingQueue）控制请求排队
信号量隔离
1. 信号量机制
  1. 使用 **Semaphore **控制并发请求书
  2. 适用于轻量级调用，减少线程切换开销
请求缓存
1. 缓存实现
  1. 使用 ConcurrentHashMap 存储缓存结果
  2. 通过 @CacheKey 指定缓存键
请求合并
1. 合并实现
  1. 使用 BatchCommand 将多个请求合并为一个批量请求
  2. 通过 @HystrixCollapser 配置合并规则

Feign

Fri, 15 Jun 2018 15:43:54 +0800

什么是Feign

Feign 是 Netflix 开源的声明式 HTTP 客户端，用于简化 RESTful 服务的调用
通过定义接口和注解，Feign 可以自动生成HTTP请求的实现

特点

声明式 API ：通过接口注解定义 HTTP 请求，无需手动编写 HTTP 客户端代码
集成 Ribbon ：默认集成 Ribbon ，支持客户端负载均衡
集成 Hystrix ：支持熔断和降级机制
可扩展性：支持自定义编码器、解码器和拦截器

工作原理

（1）接口定义

使用 @FeignClient 注解定义 Feign 客户端接口
通过方法注解（如 @GetMapping、@PostMapping）定义 HTTP 请求

（2）动态代理

Feign 通过动态代理技术生成接口的实现类
在运行时，Feign 会将方法调用转换为 Http 请求

（3）请求处理

Feign 根据接口定义生成 HTTP 请求，并通过 Ribbon 进行负载均衡
请求结果通过解码器为 Java 对象

（4）集成 Ribbon 和 Hystrix

Feign 默认集成了 Ribbon，支持客户端负载均衡
通过配置可以启用 Hystrix，实现熔断和降级

Feign 的配置

（1）基本配置

使用 @FeignClient 注解定义 Feign 客户端：

@FeignClient(name = "service-name", url = "http://localhost:8080")
public interface MyFeignClient {
    @GetMapping("/endpoint")
    String getResponse();
}

（2）负载均衡

* Feign 默认集成了 Ribbon，无需额外配置

* 可以通过配置文件自定义 Ribbon 的负载均衡策略：

service-name:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule

（3）熔断和降级

通过 @FeignClient 的** Fallback** 属性指定降级类：

@FeignClient(name = "service-name", fallback = MyFeignClientFallback.class)
public interface MyFeignClient {
    @GetMapping("/endpoint")
    String getResponse();
}

@Component
public class MyFeignClientFallback implements MyFeignClient {
    @Override
    public String getResponse() {
        return "Fallback response";
    }
}

（4）自定义配置

通过 **@Configuration **类自定义 Feign 的编码器、解码器和拦截器：

@Configuration
public class FeignConfig {
    @Bean
    public Encoder feignEncoder() {
        return new JacksonEncoder();
    }

    @Bean
    public Decoder feignDecoder() {
        return new JacksonDecoder();
    }

    @Bean
    public RequestInterceptor feignRequestInterceptor() {
        return template -> template.header("Authorization", "Bearer token");
    }
}

Feign 的使用场景

（1）微服务调用

在微服务架构中，Feign 常用于服务之间的调用
自定义接口和注解，简化 HTTP 请求的编写

（2）负载均衡

Feign 默认集成了 Ribbon，支持客户端负载均衡
可以根据配置选择不同的负载均衡策略

（3）熔断和降级

通过集成 Hystrix，Feign 支持熔断和降级机制
当服务不可用时，可以返回降级结果，避免系统崩溃

（4）自定义 HTTP 客户端

Feign 支持自定义编码器、解码器和拦截器，满足复杂的业务需求

Feign 的底层原理

（1）动态代理

Feign 通过 JDK 动态代理或者 CGLIB 生成接口的实现类
在运行时，Feign 会将方法调用转换为 HTTP 请求

（2）请求模版

Feign 使用 RequestTemplate 类表示 HTTP 请求模版
通过解析接口注解和方法参数，生成具体的 HTTP 请求

（3）编码器和解码器

Feign 使用编码器将 Java 对象转换为 HTTP 请求体
使用编码器将 HTTP 响应体转为 Java 对象

（4）拦截器

Feign 支持请求拦截器，可以在发送请求前修改请求头或者请求体

graph TD
    A[客户端调用 Feign 接口方法] --> B[ReflectiveFeign.newInstance 创建动态代理]
    B --> C[InvocationHandler.invoke 拦截方法调用]
    C --> D[SynchronousMethodHandler.invoke 处理请求]
    D --> E[RequestTemplate.Factory.create 生成请求模板]
    E --> F[RequestInterceptor.apply 应用拦截器]
    F --> G[Encoder.encode 编码请求体]
    G --> H[LoadBalancerFeignClient.execute 选择服务实例]
    H --> I[Client.execute 发送 HTTP 请求]
    I --> J[Decoder.decode 解析响应]
    J --> K[返回结果给客户端]

Eureka

Tue, 01 May 2018 13:16:53 +0800

Eureka

配置中心核心功能：

集中化管理
版本管理
动态更新
权限控制
环境隔离

基本功能：

服务发现 eureka客户端可以向eureka服务端获取服务实例列表
服务注册 eureka客户端启动的时候
三级缓存
- 读缓存 ReadOnlyCache
- 写缓存 WriteCache
- 注册表缓存
自我保护机制在网络通讯产生问题时，避免大量正常客服端实例被清除
- eureka 自我保护机制服务端相关影响配置

eureka:
  server:
    enable-self-preservation: true  # 默认true，开启自我保护
    renewal-percent-threshold: 0.85  # 续约百分比阈值，默认0.85
    renewal-threshold-update-interval-ms: 900000  # 更新阈值的时间间隔，默认15分钟

eureka 自我保护机制客户端相关影响配置

eureka:
  instance:
    lease-renewal-interval-in-seconds: 30  # 客户端续约间隔，默认30秒
    lease-expiration-duration-in-seconds: 90  # 服务过期时间，默认90秒

客户端服务注册流程

每当有客服端服务启动时，客户端会根据配置eureka服务端的地址，向服务端发起注册动作，服务端收到注册请求，会更新注册表缓冲信息，增加新的客户端信息到注册表缓冲，然后将注册表信息更新到写缓存。

客户端读取数据流程

客户端查看本地缓存是否存在
1. 存在：直接返回本地缓存中的数据
2. 不存在：请求服务端获取数据
  1. 获取读缓存，存在直接返回；不存在直接进入下一步
  2. 获取写缓存，存在直接返回，并且将数据更新到读缓存；不存在直接进入下一步
  3. 获取注册表缓存，存在直接返回，并且将数据更新到读缓存与写缓存

缓存更新场景

注册表更新场景：

服务实例注册
服务实例注销
服务实例续约（心跳）
服务实例状态变更

写缓存更新场景：

每当注册表发生变化时，写缓存会被同时更新到最新的注册表信息

读缓存更新场景：

每隔30s会同步写缓存数据

Eureka 中服务实例的状态主要包括以下几种：

UP：服务实例正常运行，可接收请求。
- 当eureka服务实例发起服务注册时
- 当eureka服务实例发起心跳，进行续期成功后，保持UP状态
- 当eureka服务实例启动成功后，将状态从STARTING更改为UP
DOWN：服务实例不可用。
- 当eureka服务实例主动注销
- 当eureka实例在规定的时间（默认90s）内没有发送心跳消息
STARTING：服务实例正在启动。
- 当服务器启动时
OUT_OF_SERVICE：服务实例被手动下线，不可用。
- 通过Eureka的管理接口或者UI，可以手动将状态从UP更改为OUT_OF_SERVICE
UNKNOWN：服务实例状态未知。
- 当网络分区时（网络问题导致服务之间无法通讯），Eureka服务端无法确认服务实例的状态时，就会将状态改为 UNKNOWN

Eureka各端缓存应用交互

sequenceDiagram
    participant Client as 客户端
    participant LocalCache as 本地缓存
    participant EurekaServer as Eureka 服务器
    participant ServiceInstance as 服务实例

    Client->>LocalCache: 1. 检查本地缓存
    alt 缓存有效
        LocalCache-->>Client: 返回缓存的服务实例
    else 缓存无效或过期
        Client->>EurekaServer: 2. 请求服务实例信息
        EurekaServer->>EurekaServer: 3. 检查读缓存
        alt 读缓存有效
            EurekaServer-->>Client: 返回读缓存的服务实例
        else 读缓存过期
            EurekaServer->>EurekaServer: 4. 从写缓存加载最新数据
            EurekaServer-->>Client: 返回最新的服务实例
        end
        Client->>LocalCache: 5. 更新本地缓存
    end
    Client->>ServiceInstance: 6. 调用目标服务实例
    Client->>EurekaServer: 7. 定时拉取最新服务实例
    EurekaServer-->>Client: 返回最新的服务实例
    Client->>LocalCache: 8. 更新本地缓存

ZooKeeper

Thu, 22 Mar 2018 22:21:04 +0800

ZooKeeper 核心原理

数据模型：
1. ZNode：树形结构中的节点，存储数据（<=1MB）
2. 节点类型
  1. 持久节点：手动删除
  2. 临时节点：会话结束自动删除
  3. 顺序节点：名称追加单调递增序号
3. 版本号：每个 ZNode 有版本号，用于 CAS操作
架构与角色：
1. Leader：处理写请求，发起提案
2. Follower：参与选举，处理读请求
3. Observer：拓展读性能，不参与选举
ZAB 协议（ZooKeeper Atomic Broadcast）
1. 恢复模式：选举 Leader （基于 zxid 和 myid，半数以上投票）
2. 广播模式：Leader 提出事物，半数以上 Follower 确认后提交
一致性保护：
1. 顺序一致性（客户端操作按顺序执行）
2. 原子性（事物要么全成功要么全失败）
3. 最终一致性（读请求可能返回旧值，但最终同步）
Watch 机制：
1. 客户端监听 ZNode 变化（如节点删除，数据更新）
2. 一次性触发，需要重新注册
3. 异步通知，可能存在延迟或丢失

典型应用场景

分布式锁：通过临时顺序节点实现，避免惊群效应
配置管理：集中存储配置，客户端监听变更
服务注册与发现：临时节点表示服务实例在线状态
选主（Leader Election）：最小序号节点成为 Master
分布式队列：顺序节点实现生产消费模型

重要知识点

ZooKeeper 如何保证数据一致性？
- 答：通过 ZAB 协议，写操作需要半数以上节点确认，保证顺序一致性和原子性。读请求可能来自任意节点（可能读到旧数据），但可通过 sync 操作强制读取最新值。
临时节点的作用时什么？
- 答：临时节点在会话结束后自动删除，常用于服务注册（服务下线自动清除）和分布式锁（客户端崩溃自动释放锁）。
如何处理脑裂问题？
- 答：ZAB 协议要求写操作必须由 Leader 发起，且需要半数以上节点确认。网络分区时，仅拥有多数节点的分区能选举 Leader，另一个分区无法写入，避免数据不一致。
Watcher 机制有哪些主要事项？
- 答：一次性触发、通知可能延迟、需要处理事件丢失（如 Watch 注册期间发生变更）。需在回调中重新注册 Watcher。
Leader 选举过程是怎样的？
- 答：节点启动时进入选举状态，投票优先给 zxid 最大的节点，zxid 相同则选 myid 更大的。获得半数以上投票的节点成为 Leader。
如何实现分布式锁？
- 答：客户端创建临时顺序节点，检查是否为最小序号节点。若是则获得锁；否则监听前一个节点的删除事件，使用 exists() +Watcher 避免轮询。

性能与优化

写性能：依赖半数以上节点确认，建议集群节点数为奇数（如3、5）。
读性能：可直接从本地节点读取，高吞吐。
快照与日志：定期生成快照（snapshot）和事务日志（txn log），加速恢复。

配置与运维

会话超时：tickTime 为基本时间单位，sessionTimeout 建议2-20倍tickTime 。
数据持久化：事务日志和快照存储于dataDir 和dataLogDir 。
ACL 控制：支持IP、Digest等多种认证方式，精细化权限管理。