简体中文 繁體中文 English 日本語 Deutsch 한국 사람 بالعربية TÜRKÇE português คนไทย Français

开启辅助访问 切换到宽版

站内搜索

搜索

活动公告

通知：周六15点在线即可领取科技点！（持续一小时）
10-31 22:15
通知：Telegram 推送频道https://t.me/+2tB3a7aKXlw2YjA1 及时接收第一手论坛帖子信息～
10-23 09:32
通知：本站资源由网友上传分享，如有违规等问题请到版务模块进行投诉，将及时处理！
10-23 09:31
通知：加入QQ社群吧 https://qm.qq.com/q/QZibQd1hiq
10-23 09:28
通知：签到时间调整为每日4:00（东八区）
10-23 09:26
>社区 > 科技 > 经验交流 >帖子
本版发帖返回

微服务架构中服务熔断与降级机制实战指南 提升系统稳定性的关键技术解析 从原理到实现全面掌握 避免级联故障的必备技能

威震华夏关云长

3万

主题

308

科技点

3万

积分

大区版主

木柜子打湿

积分
31891

财Doro三倍冰淇淋无人之境【一阶】立华奏小樱（小丑装）⑨的冰沙以外的星空【二阶】
发表于 2025-10-8 11:30:00 | 显示全部楼层 |阅读模式

马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。

您需要 登录 才可以下载或查看，没有账号？立即注册

x
引言

在当今的软件开发领域，微服务架构已经成为构建大型复杂系统的主流选择。微服务架构通过将应用拆分为一组小型、自治的服务，每个服务负责特定的业务功能，从而提高了系统的可维护性、可扩展性和团队开发效率。然而，随着服务数量的增加和相互依赖关系的复杂化，系统稳定性面临着前所未有的挑战。

在分布式系统中，一个服务的故障可能会引发连锁反应，导致整个系统崩溃，这种现象被称为”级联故障”或”雪崩效应”。为了应对这种挑战，服务熔断与降级机制应运而生，它们是保障微服务系统稳定性的关键技术。

本文将深入探讨服务熔断与降级机制的原理、实现方式以及最佳实践，帮助读者全面掌握这些技术，从而构建更加健壮、可靠的微服务系统。

微服务架构的挑战

微服务架构虽然带来了诸多好处，但也引入了一系列新的挑战：

1. 服务依赖复杂性：在微服务架构中，一个业务流程通常需要多个服务协同完成，服务之间形成了复杂的依赖网络。当某个服务出现故障或延迟时，可能会影响到依赖它的所有服务。
2. 网络不可靠性：服务之间的通信通过网络进行，网络延迟、丢包、带宽限制等问题都可能导致服务调用失败。
3. 资源限制：每个服务都有其资源限制，如线程池、数据库连接池等。当请求量激增时，资源可能被耗尽，导致服务无法响应新的请求。
4. 故障传播：在分布式系统中，一个服务的故障可能会沿着调用链向上游传播，引发连锁反应，最终导致整个系统不可用。
5. 服务响应时间变长：当某个服务响应变慢时，会导致调用方服务的线程被长时间占用，进而影响调用方服务的处理能力。

服务依赖复杂性：在微服务架构中，一个业务流程通常需要多个服务协同完成，服务之间形成了复杂的依赖网络。当某个服务出现故障或延迟时，可能会影响到依赖它的所有服务。

网络不可靠性：服务之间的通信通过网络进行，网络延迟、丢包、带宽限制等问题都可能导致服务调用失败。

资源限制：每个服务都有其资源限制，如线程池、数据库连接池等。当请求量激增时，资源可能被耗尽，导致服务无法响应新的请求。

故障传播：在分布式系统中，一个服务的故障可能会沿着调用链向上游传播，引发连锁反应，最终导致整个系统不可用。

服务响应时间变长：当某个服务响应变慢时，会导致调用方服务的线程被长时间占用，进而影响调用方服务的处理能力。

这些挑战都可能导致系统稳定性下降，甚至引发级联故障。为了应对这些挑战，我们需要引入服务熔断与降级机制。

服务熔断机制详解

原理与概念

服务熔断机制源于电子工程中的”熔断器”概念。在电路中，当电流超过额定值时，熔断器会自动断开，以保护电路免受损坏。在微服务架构中，服务熔断机制的作用类似：当检测到某个服务持续出现故障或响应时间过长时，熔断器会”断开”，暂时阻止对该服务的调用，从而保护系统免受故障服务的影响。

服务熔断机制的核心思想是”快速失败”（Fail Fast），即当检测到服务异常时，立即失败并返回错误，而不是等待超时。这样可以避免资源被长时间占用，提高系统的响应能力和整体稳定性。

熔断状态机

服务熔断通常通过一个状态机来实现，包含三种状态：关闭（Closed）、打开（Open）和半开（Half-Open）。

1. 关闭状态（Closed）：初始状态，熔断器允许请求通过。在此状态下，熔断器会统计请求的成功、失败和超时情况。当失败率达到预设阈值时，熔断器从关闭状态转换为打开状态。
2. 初始状态，熔断器允许请求通过。
3. 在此状态下，熔断器会统计请求的成功、失败和超时情况。
4. 当失败率达到预设阈值时，熔断器从关闭状态转换为打开状态。
5. 打开状态（Open）：当熔断器处于打开状态时，所有对该服务的请求都会被立即拒绝，抛出异常或返回预设的错误响应。熔断器会设置一个计时器，在经过一段时间后，熔断器从打开状态转换为半开状态，以检测服务是否已经恢复。
6. 当熔断器处于打开状态时，所有对该服务的请求都会被立即拒绝，抛出异常或返回预设的错误响应。
7. 熔断器会设置一个计时器，在经过一段时间后，熔断器从打开状态转换为半开状态，以检测服务是否已经恢复。
8. 半开状态（Half-Open）：在半开状态下，熔断器会允许有限数量的请求通过。如果这些请求都成功，熔断器会认为服务已经恢复，转换回关闭状态。如果这些请求中有任何一个失败，熔断器会立即转换回打开状态，并重置计时器。
9. 在半开状态下，熔断器会允许有限数量的请求通过。
10. 如果这些请求都成功，熔断器会认为服务已经恢复，转换回关闭状态。
11. 如果这些请求中有任何一个失败，熔断器会立即转换回打开状态，并重置计时器。

关闭状态（Closed）：

• 初始状态，熔断器允许请求通过。
• 在此状态下，熔断器会统计请求的成功、失败和超时情况。
• 当失败率达到预设阈值时，熔断器从关闭状态转换为打开状态。

打开状态（Open）：

• 当熔断器处于打开状态时，所有对该服务的请求都会被立即拒绝，抛出异常或返回预设的错误响应。
• 熔断器会设置一个计时器，在经过一段时间后，熔断器从打开状态转换为半开状态，以检测服务是否已经恢复。

半开状态（Half-Open）：

• 在半开状态下，熔断器会允许有限数量的请求通过。
• 如果这些请求都成功，熔断器会认为服务已经恢复，转换回关闭状态。
• 如果这些请求中有任何一个失败，熔断器会立即转换回打开状态，并重置计时器。

这种状态机设计使得熔断器能够在服务故障时快速断开，在服务恢复时自动重连，从而在保护系统的同时，最大限度地减少对服务可用性的影响。

熔断策略与配置

服务熔断机制通常支持多种策略和配置参数，以适应不同的业务场景和需求：

1. 失败率阈值：当请求的失败率达到此阈值时，熔断器打开。例如，设置为50%表示在10个请求中有5个失败时触发熔断。
2. 请求量阈值：在统计失败率之前，必须达到的最小请求数量。例如，设置为20表示只有在20个请求内才会计算失败率，避免在请求量少时误触发熔断。
3. 熔断器打开后的等待时间：熔断器从打开状态转换为半开状态需要等待的时间。例如，设置为5秒表示熔断器打开后5秒才会尝试恢复。
4. 半开状态下的最大请求数：在半开状态下允许通过的最大请求数量。例如，设置为5表示在半开状态下只允许5个请求通过，用于检测服务是否恢复。
5. 慢调用阈值：当请求的响应时间超过此阈值时，被视为慢调用。慢调用可以计入失败率统计，也可以单独作为熔断的触发条件。
6. 慢调用比例阈值：当慢调用比例达到此阈值时，熔断器打开。例如，设置为80%表示在10个请求中有8个是慢调用时触发熔断。

失败率阈值：当请求的失败率达到此阈值时，熔断器打开。例如，设置为50%表示在10个请求中有5个失败时触发熔断。

请求量阈值：在统计失败率之前，必须达到的最小请求数量。例如，设置为20表示只有在20个请求内才会计算失败率，避免在请求量少时误触发熔断。

熔断器打开后的等待时间：熔断器从打开状态转换为半开状态需要等待的时间。例如，设置为5秒表示熔断器打开后5秒才会尝试恢复。

半开状态下的最大请求数：在半开状态下允许通过的最大请求数量。例如，设置为5表示在半开状态下只允许5个请求通过，用于检测服务是否恢复。

慢调用阈值：当请求的响应时间超过此阈值时，被视为慢调用。慢调用可以计入失败率统计，也可以单独作为熔断的触发条件。

慢调用比例阈值：当慢调用比例达到此阈值时，熔断器打开。例如，设置为80%表示在10个请求中有8个是慢调用时触发熔断。

通过合理配置这些参数，可以使熔断机制更好地适应不同的业务场景和需求。

服务降级机制详解

原理与概念

服务降级是指当系统面临压力或某些服务不可用时，有选择地降低一些非核心功能的质量或暂时关闭这些功能，以保证核心功能的正常运行。服务降级是一种”舍车保帅”的策略，通过牺牲部分功能来换取整体系统的可用性和稳定性。

服务降级与服务熔断密切相关，但侧重点不同：

• 服务熔断关注的是保护系统免受故障服务的影响，是一种自动触发的保护机制。
• 服务降级关注的是在资源有限或服务不可用时，如何保证核心功能的可用性，通常是一种主动的策略。

在实际应用中，服务熔断通常会配合服务降级一起使用：当熔断器打开时，可以触发服务降级逻辑，返回预设的降级结果或执行降级操作。

降级策略与实现方式

服务降级可以采用多种策略和实现方式，根据业务需求和场景选择合适的方案：

1. 返回默认值：当服务不可用时，返回一个预设的默认值。例如，在获取用户信息的服务不可用时，返回一个默认的用户信息。
2. 返回缓存数据：使用缓存中的旧数据代替实时数据。例如，在商品价格服务不可用时，返回缓存中的价格数据。
3. 异步处理：将非关键操作转为异步处理，降低主流程的响应时间。例如，在订单创建成功后，发送通知邮件的操作可以转为异步处理。
4. 功能开关：通过开关控制某些功能的开启或关闭。例如，在系统压力大时，关闭非核心功能如推荐、评论等。
5. 限流：限制请求的速率，防止系统过载。例如，对某些接口设置每秒最大请求数。
6. 静态化处理：将动态内容转为静态内容。例如，在首页服务压力大时，使用预生成的静态页面代替动态生成的页面。
7. 简化业务逻辑：简化某些复杂业务逻辑，减少资源消耗。例如，在报表生成服务压力大时，只生成简化版的报表。

返回默认值：当服务不可用时，返回一个预设的默认值。例如，在获取用户信息的服务不可用时，返回一个默认的用户信息。

返回缓存数据：使用缓存中的旧数据代替实时数据。例如，在商品价格服务不可用时，返回缓存中的价格数据。

异步处理：将非关键操作转为异步处理，降低主流程的响应时间。例如，在订单创建成功后，发送通知邮件的操作可以转为异步处理。

功能开关：通过开关控制某些功能的开启或关闭。例如，在系统压力大时，关闭非核心功能如推荐、评论等。

限流：限制请求的速率，防止系统过载。例如，对某些接口设置每秒最大请求数。

静态化处理：将动态内容转为静态内容。例如，在首页服务压力大时，使用预生成的静态页面代替动态生成的页面。

简化业务逻辑：简化某些复杂业务逻辑，减少资源消耗。例如，在报表生成服务压力大时，只生成简化版的报表。

降级粒度控制

服务降级的粒度是指降级操作的作用范围，合理的降级粒度控制可以在保证系统稳定性的同时，最大限度地减少对用户体验的影响。常见的降级粒度包括：

1. 方法级降级：针对单个方法或接口进行降级。这是最细粒度的降级，可以实现精确控制。
2. 服务级降级：针对整个服务进行降级。当服务整体不可用时，可以快速切换到降级逻辑。
3. 用户级降级：针对特定用户或用户群体进行降级。例如，对免费用户降级，而保证付费用户的体验。
4. 业务级降级：针对特定业务流程进行降级。例如，在促销活动期间，对非促销相关的业务进行降级。
5. 全局降级：对整个系统进行降级。这是最粗粒度的降级，通常在系统面临严重压力时使用。

方法级降级：针对单个方法或接口进行降级。这是最细粒度的降级，可以实现精确控制。

服务级降级：针对整个服务进行降级。当服务整体不可用时，可以快速切换到降级逻辑。

用户级降级：针对特定用户或用户群体进行降级。例如，对免费用户降级，而保证付费用户的体验。

业务级降级：针对特定业务流程进行降级。例如，在促销活动期间，对非促销相关的业务进行降级。

全局降级：对整个系统进行降级。这是最粗粒度的降级，通常在系统面临严重压力时使用。

在实际应用中，通常需要结合多种降级粒度，根据业务重要性和系统状态灵活调整降级策略。

常见熔断与降级框架介绍

在微服务架构中，有多种成熟的框架可以实现服务熔断与降级机制。下面介绍几种常用的框架：

Hystrix

Hystrix是Netflix开源的一款用于处理分布式系统的延迟和容错的库。它通过隔离服务间的访问点、阻止级联故障并提供回退选项，提高系统的整体弹性。

主要特性：

1. 资源隔离：通过线程池或信号量隔离依赖服务，限制并发访问量。
2. 熔断机制：实现了完整的熔断状态机，支持自动熔断和恢复。
3. 降级回退：提供优雅的降级机制，当服务调用失败时执行预设的降级逻辑。
4. 实时监控：提供实时的监控面板，展示熔断器的状态和指标。

示例代码：
  2. // 使用Hystrix实现服务熔断与降级
  3. public class UserServiceCommand extends HystrixCommand<User> {
  4.     private final UserService userService;
  5.     private final Long userId;
  6.    
  7.     public UserServiceCommand(UserService userService, Long userId) {
  8.         super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("UserServiceGroup"))
  9.                 .andCommandKey(HystrixCommandKey.Factory.asKey("GetUserById"))
  10.                 .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
  11.                         .withCircuitBreakerEnabled(true)
  12.                         .withCircuitBreakerRequestVolumeThreshold(20)
  13.                         .withCircuitBreakerErrorThresholdPercentage(50)
  14.                         .withCircuitBreakerSleepWindowInMilliseconds(5000)
  15.                         .withExecutionTimeoutInMilliseconds(1000)));
  16.         this.userService = userService;
  17.         this.userId = userId;
  18.     }
  19.    
  20.     @Override
  21.     protected User run() throws Exception {
  22.         return userService.getUserById(userId);
  23.     }
  24.    
  25.     @Override
  26.     protected User getFallback() {
  27.         // 降级逻辑：返回默认用户
  28.         User defaultUser = new User();
  29.         defaultUser.setId(-1L);
  30.         defaultUser.setName("Default User");
  31.         return defaultUser;
  32.     }
  33. }
  35. // 使用方式
  36. UserService userService = new UserServiceImpl();
  37. UserServiceCommand command = new UserServiceCommand(userService, 123L);
  38. User user = command.execute();
复制代码

Sentinel

Sentinel是阿里巴巴开源的一款面向分布式服务架构的流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

主要特性：

1. 丰富的流量控制规则：支持基于QPS、线程数、关系链等多种维度的流量控制。
2. 熔断降级：支持基于响应时间、异常比例等多种熔断策略。
3. 系统自适应保护：通过系统负载、CPU使用率等指标自动调整流量控制规则。
4. 实时监控：提供实时的监控和控制台，支持规则动态配置。

示例代码：
  2. // 使用Sentinel实现服务熔断与降级
  3. public class UserService {
  4.     public User getUserById(Long userId) {
  5.         try (Entry entry = SphU.entry("getUserById")) {
  6.             // 被保护的业务逻辑
  7.             return userDao.getUserById(userId);
  8.         } catch (BlockException ex) {
  9.             // 熔断或限流导致的阻塞，执行降级逻辑
  10.             User defaultUser = new User();
  11.             defaultUser.setId(-1L);
  12.             defaultUser.setName("Default User");
  13.             return defaultUser;
  14.         } catch (Exception ex) {
  15.             // 业务异常
  16.             Tracer.traceEntry(ex, entry);
  17.             throw ex;
  18.         }
  19.     }
  20. }
  22. // 定义熔断规则
  23. private static void initDegradeRule() {
  24.     List<DegradeRule> rules = new ArrayList<>();
  25.     DegradeRule rule = new DegradeRule();
  26.     rule.setResource("getUserById");
  27.     // 熔断策略：基于异常比例
  28.     rule.setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO);
  29.     // 异常比例阈值：50%
  30.     rule.setCount(0.5);
  31.     // 熔断时长：10秒
  32.     rule.setTimeWindow(10);
  33.     // 最小请求数：20
  34.     rule.setMinRequestAmount(20);
  35.     // 慢调用比例阈值：80%
  36.     rule.setSlowRatioThreshold(0.8);
  37.     rules.add(rule);
  38.     DegradeRuleManager.loadRules(rules);
  39. }
复制代码

Resilience4j

Resilience4j是一款轻量级的容错库，受Netflix Hystrix启发，但设计更轻量、更模块化。它提供了多种容错模式，包括熔断器、限流器、重试、隔离等。

主要特性：

1. 模块化设计：各功能模块独立，可以按需引入。
2. 轻量级：无外部依赖，只依赖Vavr库。
3. 响应式编程支持：支持CompletableFuture、Reactive Streams等。
4. 丰富的熔断策略：支持基于失败率、异常数量等多种熔断策略。

示例代码：
  2. // 使用Resilience4j实现服务熔断与降级
  3. public class UserService {
  4.     private final CircuitBreaker circuitBreaker;
  5.    
  6.     public UserService() {
  7.         // 配置熔断器
  8.         CircuitBreakerConfig config = CircuitBreakerConfig.custom()
  9.                 .failureRateThreshold(50)
  10.                 .waitDurationInOpenState(Duration.ofMillis(5000))
  11.                 .ringBufferSizeInHalfOpenState(10)
  12.                 .ringBufferSizeInClosedState(100)
  13.                 .build();
  14.         
  15.         circuitBreaker = CircuitBreaker.of("userService", config);
  16.     }
  17.    
  18.     public User getUserById(Long userId) {
  19.         // 使用熔断器包装业务逻辑
  20.         Supplier<User> supplier = CircuitBreaker.decorateSupplier(circuitBreaker,
  21.             () -> userDao.getUserById(userId));
  22.         
  23.         // 定义降级逻辑
  24.         Supplier<User> fallbackSupplier = SupplierUtils.recover(supplier,
  25.             throwable -> {
  26.                 User defaultUser = new User();
  27.                 defaultUser.setId(-1L);
  28.                 defaultUser.setName("Default User");
  29.                 return defaultUser;
  30.             });
  31.         
  32.         return fallbackSupplier.get();
  33.     }
  34. }
复制代码

Spring Cloud Circuit Breaker

Spring Cloud Circuit Breaker是Spring Cloud提供的统一熔断器抽象，支持多种熔断器实现，包括Hystrix、Resilience4j、Sentinel等。它提供了一致的API，使得在不同熔断器实现之间切换变得更加容易。

主要特性：

1. 统一API：提供一致的熔断器API，隐藏具体实现的差异。
2. 多实现支持：支持Hystrix、Resilience4j、Sentinel等多种熔断器实现。
3. Spring生态集成：与Spring Boot、Spring Cloud等无缝集成。
4. 响应式支持：支持Spring WebFlux等响应式编程模型。

示例代码：
  2. // 使用Spring Cloud Circuit Breaker实现服务熔断与降级
  3. @Service
  4. public class UserService {
  5.     private final UserDao userDao;
  6.     private final CircuitBreakerFactory circuitBreakerFactory;
  7.    
  8.     public UserService(UserDao userDao, CircuitBreakerFactory circuitBreakerFactory) {
  9.         this.userDao = userDao;
  10.         this.circuitBreakerFactory = circuitBreakerFactory;
  11.     }
  12.    
  13.     public User getUserById(Long userId) {
  14.         // 创建熔断器
  15.         CircuitBreaker circuitBreaker = circuitBreakerFactory.create("userService");
  16.         
  17.         // 使用熔断器包装业务逻辑
  18.         Supplier<User> supplier = () -> userDao.getUserById(userId);
  19.         
  20.         // 定义降级逻辑
  21.         Supplier<User> fallback = () -> {
  22.             User defaultUser = new User();
  23.             defaultUser.setId(-1L);
  24.             defaultUser.setName("Default User");
  25.             return defaultUser;
  26.         };
  27.         
  28.         // 执行调用
  29.         return circuitBreaker.run(supplier, fallback);
  30.     }
  31. }
  33. // 配置文件（application.yml）
  34. resilience4j:
  35.   circuitbreaker:
  36.     configs:
  37.       default:
  38.         failureRateThreshold: 50%
  39.         waitDurationInOpenState: 5s
  40.         slidingWindowSize: 100
  41.         slidingWindowType: COUNT_BASED
  42.     instances:
  43.       userService:
  44.         baseConfig: default
复制代码

实战案例：使用具体框架实现熔断与降级

在本节中，我们将通过两个实战案例，分别使用Hystrix和Sentinel框架实现服务熔断与降级机制。

基于Hystrix的实现

假设我们有一个电商系统，包含订单服务、库存服务和用户服务。当库存服务不可用时，我们希望能够进行服务降级，返回预设的库存信息，而不是让整个订单创建流程失败。

步骤1：添加依赖

首先，在项目的pom.xml文件中添加Hystrix相关依赖：
  2. <dependency>
  3.     <groupId>org.springframework.cloud</groupId>
  4.     <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
  5. </dependency>
  6. <dependency>
  7.     <groupId>org.springframework.cloud</groupId>
  8.     <artifactId>spring-cloud-starter-openfeign</artifactId>
  9. </dependency>
复制代码

步骤2：启用Hystrix

在Spring Boot应用的主类上添加@EnableHystrix和@EnableFeignClients注解：
  2. @SpringBootApplication
  3. @EnableHystrix
  4. @EnableFeignClients
  5. public class OrderServiceApplication {
  6.     public static void main(String[] args) {
  7.         SpringApplication.run(OrderServiceApplication.class, args);
  8.     }
  9. }
复制代码

步骤3：定义Feign客户端

创建一个Feign客户端，用于调用库存服务：
  2. @FeignClient(name = "inventory-service", fallback = InventoryServiceFallback.class)
  3. public interface InventoryServiceClient {
  4.    
  5.     @GetMapping("/inventory/check")
  6.     Inventory checkInventory(@RequestParam("productId") Long productId,
  7.                            @RequestParam("quantity") Integer quantity);
  8. }
复制代码

步骤4：实现降级逻辑

创建InventoryServiceFallback类，实现降级逻辑：
  2. @Component
  3. public class InventoryServiceFallback implements InventoryServiceClient {
  4.    
  5.     @Override
  6.     public Inventory checkInventory(Long productId, Integer quantity) {
  7.         // 降级逻辑：返回一个预设的库存对象
  8.         Inventory fallbackInventory = new Inventory();
  9.         fallbackInventory.setProductId(productId);
  10.         fallbackInventory.setQuantity(-1); // -1表示库存服务不可用
  11.         fallbackInventory.setAvailable(false);
  12.         return fallbackInventory;
  13.     }
  14. }
复制代码

步骤5：使用Hystrix Command

在订单服务中，使用Hystrix Command调用库存服务：
  2. @Service
  3. public class OrderService {
  4.    
  5.     @Autowired
  6.     private InventoryServiceClient inventoryServiceClient;
  7.    
  8.     @HystrixCommand(fallbackMethod = "createOrderFallback",
  9.             commandProperties = {
  10.                     @HystrixProperty(name = "circuitBreaker.enabled", value = "true"),
  11.                     @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "20"),
  12.                     @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "50"),
  13.                     @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "5000"),
  14.                     @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000")
  15.             })
  16.     public Order createOrder(OrderRequest orderRequest) {
  17.         // 检查库存
  18.         Inventory inventory = inventoryServiceClient.checkInventory(
  19.             orderRequest.getProductId(), orderRequest.getQuantity());
  20.         
  21.         if (!inventory.isAvailable()) {
  22.             throw new BusinessException("库存不足");
  23.         }
  24.         
  25.         // 创建订单
  26.         Order order = new Order();
  27.         order.setProductId(orderRequest.getProductId());
  28.         order.setQuantity(orderRequest.getQuantity());
  29.         order.setUserId(orderRequest.getUserId());
  30.         order.setCreateTime(new Date());
  31.         order.setStatus("CREATED");
  32.         
  33.         return orderRepository.save(order);
  34.     }
  35.    
  36.     public Order createOrderFallback(OrderRequest orderRequest, Throwable e) {
  37.         // 降级逻辑：创建一个标记为失败的订单
  38.         Order fallbackOrder = new Order();
  39.         fallbackOrder.setProductId(orderRequest.getProductId());
  40.         fallbackOrder.setQuantity(orderRequest.getQuantity());
  41.         fallbackOrder.setUserId(orderRequest.getUserId());
  42.         fallbackOrder.setCreateTime(new Date());
  43.         fallbackOrder.setStatus("FAILED");
  44.         fallbackOrder.setRemark("库存服务不可用，订单创建失败");
  45.         
  46.         return orderRepository.save(fallbackOrder);
  47.     }
  48. }
复制代码

步骤6：配置Hystrix

在application.yml文件中配置Hystrix：
  2. hystrix:
  3.   command:
  4.     default:
  5.       execution:
  6.         isolation:
  7.           thread:
  8.             timeoutInMilliseconds: 1000
  9.       circuitBreaker:
  10.         requestVolumeThreshold: 20
  11.         errorThresholdPercentage: 50
  12.         sleepWindowInMilliseconds: 5000
复制代码

步骤7：监控Hystrix

添加Hystrix Dashboard和Turbine依赖，用于监控Hystrix的状态：
  2. <dependency>
  3.     <groupId>org.springframework.cloud</groupId>
  4.     <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
  5. </dependency>
  6. <dependency>
  7.     <groupId>org.springframework.cloud</groupId>
  8.     <artifactId>spring-cloud-starter-netflix-turbine</artifactId>
  9. </dependency>
复制代码

在应用主类上添加@EnableHystrixDashboard和@EnableTurbine注解：
  2. @SpringBootApplication
  3. @EnableHystrix
  4. @EnableFeignClients
  5. @EnableHystrixDashboard
  6. @EnableTurbine
  7. public class OrderServiceApplication {
  8.     public static void main(String[] args) {
  9.         SpringApplication.run(OrderServiceApplication.class, args);
  10.     }
  11. }
复制代码

配置Turbine：
  2. turbine:
  3.   app-config: order-service
  4.   cluster-name-expression: "'default'"
复制代码

访问Hystrix Dashboard（http://localhost:8080/hystrix），输入Turbine流地址（http://localhost:8080/turbine.stream），即可监控Hystrix的状态。

基于Sentinel的实现

现在，我们使用Sentinel框架来实现同样的功能。

步骤1：添加依赖

在项目的pom.xml文件中添加Sentinel相关依赖：
  2. <dependency>
  3.     <groupId>com.alibaba.cloud</groupId>
  4.     <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
  5. </dependency>
  6. <dependency>
  7.     <groupId>com.alibaba.cloud</groupId>
  8.     <artifactId>spring-cloud-starter-alibaba-sentinel-datasource</artifactId>
  9. </dependency>
  10. <dependency>
  11.     <groupId>com.alibaba.csp</groupId>
  12.     <artifactId>sentinel-datasource-nacos</artifactId>
  13. </dependency>
复制代码

步骤2：配置Sentinel

在application.yml文件中配置Sentinel：
  2. spring:
  3.   cloud:
  4.     sentinel:
  5.       transport:
  6.         dashboard: localhost:8080
  7.         port: 8719
  8.       datasource:
  9.         ds1:
  10.           nacos:
  11.             server-addr: localhost:8848
  12.             dataId: ${spring.application.name}-sentinel
  13.             groupId: DEFAULT_GROUP
  14.             rule-type: flow
复制代码

步骤3：定义Feign客户端

创建一个Feign客户端，用于调用库存服务：
  2. @FeignClient(name = "inventory-service", fallback = InventoryServiceFallback.class)
  3. public interface InventoryServiceClient {
  4.    
  5.     @GetMapping("/inventory/check")
  6.     @SentinelResource(value = "checkInventory", fallback = "checkInventoryFallback")
  7.     Inventory checkInventory(@RequestParam("productId") Long productId,
  8.                            @RequestParam("quantity") Integer quantity);
  9.    
  10.     default Inventory checkInventoryFallback(Long productId, Integer quantity, Throwable e) {
  11.         // 降级逻辑：返回一个预设的库存对象
  12.         Inventory fallbackInventory = new Inventory();
  13.         fallbackInventory.setProductId(productId);
  14.         fallbackInventory.setQuantity(-1); // -1表示库存服务不可用
  15.         fallbackInventory.setAvailable(false);
  16.         return fallbackInventory;
  17.     }
  18. }
复制代码

步骤4：实现降级逻辑

创建InventoryServiceFallback类，实现降级逻辑：
  2. @Component
  3. public class InventoryServiceFallback implements InventoryServiceClient {
  4.    
  5.     @Override
  6.     public Inventory checkInventory(Long productId, Integer quantity) {
  7.         // 降级逻辑：返回一个预设的库存对象
  8.         Inventory fallbackInventory = new Inventory();
  9.         fallbackInventory.setProductId(productId);
  10.         fallbackInventory.setQuantity(-1); // -1表示库存服务不可用
  11.         fallbackInventory.setAvailable(false);
  12.         return fallbackInventory;
  13.     }
  14. }
复制代码

步骤5：使用Sentinel保护订单创建服务

在订单服务中，使用Sentinel保护订单创建服务：
  2. @Service
  3. public class OrderService {
  4.    
  5.     @Autowired
  6.     private InventoryServiceClient inventoryServiceClient;
  7.    
  8.     @SentinelResource(value = "createOrder", fallback = "createOrderFallback")
  9.     public Order createOrder(OrderRequest orderRequest) {
  10.         // 检查库存
  11.         Inventory inventory = inventoryServiceClient.checkInventory(
  12.             orderRequest.getProductId(), orderRequest.getQuantity());
  13.         
  14.         if (!inventory.isAvailable()) {
  15.             throw new BusinessException("库存不足");
  16.         }
  17.         
  18.         // 创建订单
  19.         Order order = new Order();
  20.         order.setProductId(orderRequest.getProductId());
  21.         order.setQuantity(orderRequest.getQuantity());
  22.         order.setUserId(orderRequest.getUserId());
  23.         order.setCreateTime(new Date());
  24.         order.setStatus("CREATED");
  25.         
  26.         return orderRepository.save(order);
  27.     }
  28.    
  29.     public Order createOrderFallback(OrderRequest orderRequest, Throwable e) {
  30.         // 降级逻辑：创建一个标记为失败的订单
  31.         Order fallbackOrder = new Order();
  32.         fallbackOrder.setProductId(orderRequest.getProductId());
  33.         fallbackOrder.setQuantity(orderRequest.getQuantity());
  34.         fallbackOrder.setUserId(orderRequest.getUserId());
  35.         fallbackOrder.setCreateTime(new Date());
  36.         fallbackOrder.setStatus("FAILED");
  37.         fallbackOrder.setRemark("库存服务不可用，订单创建失败");
  38.         
  39.         return orderRepository.save(fallbackOrder);
  40.     }
  41. }
复制代码

步骤6：初始化熔断规则

创建一个配置类，初始化熔断规则：
  2. @Configuration
  3. public class SentinelConfig {
  4.    
  5.     @PostConstruct
  6.     private void initDegradeRules() {
  7.         List<DegradeRule> rules = new ArrayList<>();
  8.         
  9.         // 创建订单服务的熔断规则
  10.         DegradeRule createOrderRule = new DegradeRule();
  11.         createOrderRule.setResource("createOrder");
  12.         createOrderRule.setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO);
  13.         createOrderRule.setCount(0.5); // 异常比例阈值：50%
  14.         createOrderRule.setTimeWindow(10); // 熔断时长：10秒
  15.         createOrderRule.setMinRequestAmount(20); // 最小请求数：20
  16.         createOrderRule.setSlowRatioThreshold(0.8); // 慢调用比例阈值：80%
  17.         rules.add(createOrderRule);
  18.         
  19.         // 检查库存服务的熔断规则
  20.         DegradeRule checkInventoryRule = new DegradeRule();
  21.         checkInventoryRule.setResource("checkInventory");
  22.         checkInventoryRule.setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO);
  23.         checkInventoryRule.setCount(0.5); // 异常比例阈值：50%
  24.         checkInventoryRule.setTimeWindow(10); // 熔断时长：10秒
  25.         checkInventoryRule.setMinRequestAmount(20); // 最小请求数：20
  26.         checkInventoryRule.setSlowRatioThreshold(0.8); // 慢调用比例阈值：80%
  27.         rules.add(checkInventoryRule);
  28.         
  29.         DegradeRuleManager.loadRules(rules);
  30.     }
  31. }
复制代码

步骤7：监控Sentinel

启动Sentinel Dashboard（默认地址为http://localhost:8080），在Dashboard中可以实时监控服务的状态、配置规则等。

通过以上步骤，我们分别使用Hystrix和Sentinel实现了服务熔断与降级机制。当库存服务不可用时，系统会自动触发降级逻辑，返回预设的库存信息，保证订单创建流程的可用性。

熔断与降级的最佳实践

在实际应用中，熔断与降级机制的有效性取决于合理的设计和配置。以下是一些最佳实践，可以帮助我们更好地使用这些机制：

如何设计合理的熔断策略

1. 根据业务特点设置熔断参数：对于关键业务，可以设置较高的熔断阈值，避免过早熔断影响业务。对于非关键业务，可以设置较低的熔断阈值，优先保护系统整体稳定性。根据服务的响应时间分布，合理设置超时时间，避免因网络抖动导致误熔断。
2. 对于关键业务，可以设置较高的熔断阈值，避免过早熔断影响业务。
3. 对于非关键业务，可以设置较低的熔断阈值，优先保护系统整体稳定性。
4. 根据服务的响应时间分布，合理设置超时时间，避免因网络抖动导致误熔断。
5. 分级别熔断：对不同级别的服务采用不同的熔断策略。例如，核心服务可以采用较严格的熔断策略，而边缘服务可以采用较宽松的熔断策略。对同一服务的不同接口采用不同的熔断策略，根据接口的重要性和调用频率进行差异化配置。
6. 对不同级别的服务采用不同的熔断策略。例如，核心服务可以采用较严格的熔断策略，而边缘服务可以采用较宽松的熔断策略。
7. 对同一服务的不同接口采用不同的熔断策略，根据接口的重要性和调用频率进行差异化配置。
8. 动态调整熔断参数：根据系统的负载情况动态调整熔断参数。例如，在系统高负载时，可以降低熔断阈值，更早地触发熔断。根据服务的健康状态动态调整熔断参数。例如，当服务响应时间变长时，可以自动降低熔断阈值。
9. 根据系统的负载情况动态调整熔断参数。例如，在系统高负载时，可以降低熔断阈值，更早地触发熔断。
10. 根据服务的健康状态动态调整熔断参数。例如，当服务响应时间变长时，可以自动降低熔断阈值。
11. 熔断策略的测试与验证：在生产环境之前，充分测试熔断策略的有效性。可以使用混沌工程工具模拟服务故障，验证熔断机制是否按预期工作。定期回顾和调整熔断策略，根据实际运行情况优化参数。
12. 在生产环境之前，充分测试熔断策略的有效性。可以使用混沌工程工具模拟服务故障，验证熔断机制是否按预期工作。
13. 定期回顾和调整熔断策略，根据实际运行情况优化参数。

根据业务特点设置熔断参数：

• 对于关键业务，可以设置较高的熔断阈值，避免过早熔断影响业务。
• 对于非关键业务，可以设置较低的熔断阈值，优先保护系统整体稳定性。
• 根据服务的响应时间分布，合理设置超时时间，避免因网络抖动导致误熔断。

分级别熔断：

• 对不同级别的服务采用不同的熔断策略。例如，核心服务可以采用较严格的熔断策略，而边缘服务可以采用较宽松的熔断策略。
• 对同一服务的不同接口采用不同的熔断策略，根据接口的重要性和调用频率进行差异化配置。

动态调整熔断参数：

• 根据系统的负载情况动态调整熔断参数。例如，在系统高负载时，可以降低熔断阈值，更早地触发熔断。
• 根据服务的健康状态动态调整熔断参数。例如，当服务响应时间变长时，可以自动降低熔断阈值。

熔断策略的测试与验证：

• 在生产环境之前，充分测试熔断策略的有效性。可以使用混沌工程工具模拟服务故障，验证熔断机制是否按预期工作。
• 定期回顾和调整熔断策略，根据实际运行情况优化参数。

如何优雅地实现服务降级

1. 明确降级目标和范围：在设计降级策略时，明确降级的目标和范围。哪些功能可以降级，哪些功能必须保证。根据业务重要性划分降级级别，例如：核心功能、重要功能、一般功能、次要功能。
2. 在设计降级策略时，明确降级的目标和范围。哪些功能可以降级，哪些功能必须保证。
3. 根据业务重要性划分降级级别，例如：核心功能、重要功能、一般功能、次要功能。
4. 设计合理的降级逻辑：降级逻辑应该简单、可靠，避免引入新的复杂性。降级逻辑本身不应该成为新的故障点。降级逻辑应该有明确的标识，方便后续的数据修复和问题排查。
5. 降级逻辑应该简单、可靠，避免引入新的复杂性。降级逻辑本身不应该成为新的故障点。
6. 降级逻辑应该有明确的标识，方便后续的数据修复和问题排查。
7. 提供有意义的降级响应：降级响应应该对用户友好，避免暴露系统内部错误。例如，可以使用”系统繁忙，请稍后再试”等友好的提示信息。降级响应应该包含足够的信息，方便后续的数据修复和问题排查。
8. 降级响应应该对用户友好，避免暴露系统内部错误。例如，可以使用”系统繁忙，请稍后再试”等友好的提示信息。
9. 降级响应应该包含足够的信息，方便后续的数据修复和问题排查。
10. 支持手动降级：除了自动降级外，还应该支持手动降级。在系统维护或特殊情况下，运维人员可以手动触发降级。手动降级应该有明确的操作界面和操作日志，方便管理和审计。
11. 除了自动降级外，还应该支持手动降级。在系统维护或特殊情况下，运维人员可以手动触发降级。
12. 手动降级应该有明确的操作界面和操作日志，方便管理和审计。
13. 降级后的恢复策略：设计降级后的恢复策略，包括自动恢复和手动恢复。自动恢复应该在服务正常后自动切换回正常逻辑。恢复过程应该是渐进的，避免大量请求同时涌入导致服务再次崩溃。
14. 设计降级后的恢复策略，包括自动恢复和手动恢复。自动恢复应该在服务正常后自动切换回正常逻辑。
15. 恢复过程应该是渐进的，避免大量请求同时涌入导致服务再次崩溃。

明确降级目标和范围：

• 在设计降级策略时，明确降级的目标和范围。哪些功能可以降级，哪些功能必须保证。
• 根据业务重要性划分降级级别，例如：核心功能、重要功能、一般功能、次要功能。

设计合理的降级逻辑：

• 降级逻辑应该简单、可靠，避免引入新的复杂性。降级逻辑本身不应该成为新的故障点。
• 降级逻辑应该有明确的标识，方便后续的数据修复和问题排查。

提供有意义的降级响应：

• 降级响应应该对用户友好，避免暴露系统内部错误。例如，可以使用”系统繁忙，请稍后再试”等友好的提示信息。
• 降级响应应该包含足够的信息，方便后续的数据修复和问题排查。

支持手动降级：

• 除了自动降级外，还应该支持手动降级。在系统维护或特殊情况下，运维人员可以手动触发降级。
• 手动降级应该有明确的操作界面和操作日志，方便管理和审计。

降级后的恢复策略：

• 设计降级后的恢复策略，包括自动恢复和手动恢复。自动恢复应该在服务正常后自动切换回正常逻辑。
• 恢复过程应该是渐进的，避免大量请求同时涌入导致服务再次崩溃。

监控与告警

1. 全面监控熔断状态：监控熔断器的状态变化，包括熔断器打开、关闭、半开状态的转换次数和持续时间。监控熔断器的指标，包括请求量、成功量、失败量、超时量、失败率等。
2. 监控熔断器的状态变化，包括熔断器打开、关闭、半开状态的转换次数和持续时间。
3. 监控熔断器的指标，包括请求量、成功量、失败量、超时量、失败率等。
4. 监控降级情况：监控降级触发的次数和频率，了解系统的稳定性和可靠性。监控降级逻辑的执行情况，确保降级逻辑本身没有问题。
5. 监控降级触发的次数和频率，了解系统的稳定性和可靠性。
6. 监控降级逻辑的执行情况，确保降级逻辑本身没有问题。
7. 设置合理的告警规则：当熔断器频繁打开时，应该触发告警，提醒运维人员关注相关服务。当降级逻辑频繁执行时，应该触发告警，提醒开发人员优化相关服务。
8. 当熔断器频繁打开时，应该触发告警，提醒运维人员关注相关服务。
9. 当降级逻辑频繁执行时，应该触发告警，提醒开发人员优化相关服务。
10. 建立熔断与降级事件的处理流程：建立熔断与降级事件的处理流程，包括事件发现、原因分析、解决方案、效果验证等环节。定期回顾熔断与降级事件，总结经验教训，持续改进系统的稳定性。
11. 建立熔断与降级事件的处理流程，包括事件发现、原因分析、解决方案、效果验证等环节。
12. 定期回顾熔断与降级事件，总结经验教训，持续改进系统的稳定性。

全面监控熔断状态：

• 监控熔断器的状态变化，包括熔断器打开、关闭、半开状态的转换次数和持续时间。
• 监控熔断器的指标，包括请求量、成功量、失败量、超时量、失败率等。

监控降级情况：

• 监控降级触发的次数和频率，了解系统的稳定性和可靠性。
• 监控降级逻辑的执行情况，确保降级逻辑本身没有问题。

设置合理的告警规则：

• 当熔断器频繁打开时，应该触发告警，提醒运维人员关注相关服务。
• 当降级逻辑频繁执行时，应该触发告警，提醒开发人员优化相关服务。

建立熔断与降级事件的处理流程：

• 建立熔断与降级事件的处理流程，包括事件发现、原因分析、解决方案、效果验证等环节。
• 定期回顾熔断与降级事件，总结经验教训，持续改进系统的稳定性。

熔断与降级在系统稳定性保障中的作用

服务熔断与降级机制在系统稳定性保障中扮演着至关重要的角色，它们通过以下方式提升系统的整体稳定性：

1. 防止级联故障：当某个服务出现故障时，熔断机制可以快速断开对该服务的调用，防止故障向上游传播，避免级联故障。通过限制对故障服务的访问量，保护系统整体资源不被耗尽。
2. 当某个服务出现故障时，熔断机制可以快速断开对该服务的调用，防止故障向上游传播，避免级联故障。
3. 通过限制对故障服务的访问量，保护系统整体资源不被耗尽。
4. 提高系统弹性：熔断与降级机制使系统能够在面对部分故障时继续提供服务，提高了系统的弹性。通过自动恢复机制，系统能够在服务恢复正常后自动重连，减少人工干预。
5. 熔断与降级机制使系统能够在面对部分故障时继续提供服务，提高了系统的弹性。
6. 通过自动恢复机制，系统能够在服务恢复正常后自动重连，减少人工干预。
7. 优化资源利用：通过熔断机制，避免将资源浪费在不可用的服务上，提高资源利用效率。通过降级机制，在资源紧张时优先保障核心功能的资源需求。
8. 通过熔断机制，避免将资源浪费在不可用的服务上，提高资源利用效率。
9. 通过降级机制，在资源紧张时优先保障核心功能的资源需求。
10. 提升用户体验：通过降级机制，即使在系统压力大的情况下，也能为用户提供基本的服务，避免完全不可用的情况。通过友好的降级响应，减少用户因系统问题而产生的不良体验。
11. 通过降级机制，即使在系统压力大的情况下，也能为用户提供基本的服务，避免完全不可用的情况。
12. 通过友好的降级响应，减少用户因系统问题而产生的不良体验。
13. 支持系统演进：熔断与降级机制为系统的渐进式演进提供了保障。在系统升级、迁移等过程中，可以通过熔断与降级机制控制风险。通过灰度发布和蓝绿部署等策略，结合熔断与降级机制，可以降低系统变更的风险。
14. 熔断与降级机制为系统的渐进式演进提供了保障。在系统升级、迁移等过程中，可以通过熔断与降级机制控制风险。
15. 通过灰度发布和蓝绿部署等策略，结合熔断与降级机制，可以降低系统变更的风险。

防止级联故障：

• 当某个服务出现故障时，熔断机制可以快速断开对该服务的调用，防止故障向上游传播，避免级联故障。
• 通过限制对故障服务的访问量，保护系统整体资源不被耗尽。

提高系统弹性：

• 熔断与降级机制使系统能够在面对部分故障时继续提供服务，提高了系统的弹性。
• 通过自动恢复机制，系统能够在服务恢复正常后自动重连，减少人工干预。

优化资源利用：

• 通过熔断机制，避免将资源浪费在不可用的服务上，提高资源利用效率。
• 通过降级机制，在资源紧张时优先保障核心功能的资源需求。

提升用户体验：

• 通过降级机制，即使在系统压力大的情况下，也能为用户提供基本的服务，避免完全不可用的情况。
• 通过友好的降级响应，减少用户因系统问题而产生的不良体验。

支持系统演进：

• 熔断与降级机制为系统的渐进式演进提供了保障。在系统升级、迁移等过程中，可以通过熔断与降级机制控制风险。
• 通过灰度发布和蓝绿部署等策略，结合熔断与降级机制，可以降低系统变更的风险。

总结与展望

服务熔断与降级是微服务架构中保障系统稳定性的关键技术。通过合理设计和实现这些机制，我们可以有效防止级联故障，提高系统的弹性和可靠性。

本文从原理到实现，全面介绍了服务熔断与降级机制，包括熔断状态机、熔断策略、降级策略、常见框架等内容，并通过实战案例展示了如何使用Hystrix和Sentinel实现这些机制。

随着云原生技术的发展，服务熔断与降级机制也在不断演进。未来，我们可以期待以下发展趋势：

1. 智能化：通过机器学习和人工智能技术，实现更智能的熔断与降级策略，自动适应不同的业务场景和系统状态。
2. 自动化：通过AIOps技术，实现熔断与降级策略的自动配置和优化，减少人工干预。
3. 可视化：提供更直观的可视化界面，帮助运维人员更好地理解和控制熔断与降级机制。
4. 标准化：推动熔断与降级机制的标准化，实现不同框架和平台之间的互操作性。
5. 生态集成：与云原生生态中的其他组件（如服务网格、API网关等）深度集成，提供更全面的稳定性保障。

智能化：通过机器学习和人工智能技术，实现更智能的熔断与降级策略，自动适应不同的业务场景和系统状态。

自动化：通过AIOps技术，实现熔断与降级策略的自动配置和优化，减少人工干预。

可视化：提供更直观的可视化界面，帮助运维人员更好地理解和控制熔断与降级机制。

标准化：推动熔断与降级机制的标准化，实现不同框架和平台之间的互操作性。

生态集成：与云原生生态中的其他组件（如服务网格、API网关等）深度集成，提供更全面的稳定性保障。

总之，服务熔断与降级机制是构建高可用、高弹性微服务系统的必备技能。通过深入理解这些机制的原理和实现方式，并结合实际业务场景进行合理设计和配置，我们可以构建更加稳定、可靠的微服务系统，为用户提供更好的服务体验。
熔断, 级联, 服务, 降级, 必备
回复

使用道具 举报

返回列表 发新帖
您需要登录后才可以回帖 登录 | 立即注册
高级模式
B Color Image Link Quote Code Smilies

本版积分规则

友情链接

keba
磕巴白菜
别管 别听 就是玩
二次元论坛
二次元论坛
按下F逃离世界！
次元宅社
次元宅社
开放、共创，CHANGE SEKAI！
频道订阅

频道订阅

加入社群

加入社群

联系我们|TG频道|RSS

Powered by Pixtech

© 2025 Pixtech Team.