系统超时熔断--应用调用领域出错，但是领域未产生日志的问题

最新推荐文章于 2025-07-26 10:44:37 发布
最新推荐文章于 2025-07-26 10:44:37 发布
阅读量246 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： 随笔 文章标签： 随笔
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/caohl04/article/details/103185414
本文描述了一次系统在调用短信服务时遇到的问题，详细分析了应用层面出现超时熔断，而领域服务未记录访问的原因。通过检查发现，问题源于系统传递的header配置不当。文章总结了在网络相关配置信息，如header、拦截器、网关设置等方面的排查经验。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

今天系统在调用时发不出短信。
查询日志发现应用调用领域超时熔断了，但是领域服务并未记录该次访问记录。
经过检查发现原来我们系统传递的header并未进行正确配置，导致问题产生。
总结：对于应用层出错但是领域层未产生错误的情况，首先应检查网络，同时检查网络相关的配置信息，比如header，拦截器，网关设置等。

请求方报超时，服务日志中记录的时间却少有超时
u011734144的专栏
11-27 2384
请求方报超时的比例大概有4% 他们设置的超时时间是500ms 但是我们统计日志，服务时间超过500ms的日志很少 原因是什么呢？   超时原因分析： 1、请求内容太长 根据请求方超时日志， 大多数query的长度都是1w以上，这些query我手动请求，响应时间的确大于500ms， 在服务端还没有处理完的时候，客户端已经超时断开了 2、等待时间太长 客户端报超时的query，其中有...
AI原生应用领域微服务集成：推动业务发展的新动力
AI天才研究院
05-28 747
随着AI技术从“实验室”走向“业务前台”，企业对AI应用的需求已从“单点能力验证”转向“规模化、高可靠、可扩展”的系统级落地。传统单体架构的AI应用（如一个大而全的图像识别系统）在面对动态变化的业务需求时，常出现“牵一发而动全身”的痛点——模型更新慢、资源浪费、故障影响范围大。本文聚焦“微服务集成”这一关键技术，探讨如何通过拆解AI能力边界、优化服务协作，让AI原生应用真正成为业务增长的“新引擎”。本文从“为什么需要微服务集成”出发，用“智能餐厅”类比AI原生应用，逐步拆解核心概念；
熔断(调用端或服务提供端卡住了,调用端主动发起熔断) 解决并发问题；当调用端连接超时超过2m时候 导致服务器等待该线程时间过长,降低了处理其他线程的能力，这时候使用熔断快速处理超时请求 提交处理效率...
weixin_30512089的博客
05-05 240
(调用端或服务提供端卡住了,超时,损坏,调用端主动发起熔断)解决并发问题；当调用端连接超时超过2m时候 导致服务器等待该线程时间过长,降低了处理其他线程的能力，这时候使用熔断快速处理超时请求 提交处理效率 转载于:https://www.cnblogs.com/classmethond/p/10816471.html...
系统熔断
喜欢炒股的码农
05-09 978
最近看这方面的信息 简单了解了下 写下随笔 背景介绍 基于服务拆分之后，各类远程调用横行的年代， 我们很容易出现的系统层级情况就是一个业务支撑需要N多服务，简单说下，图网上有的是就不贴了。假设有三层应用调用 A-B-C ，A对外提供列表服务，需要N个B和M个C，同时B也需要X个C，我们假设一个调用链路中的某个C系统故障 ，那A或者B 调用C时 就会被hold住，从而无法正常响应， 以此为例 A机...
SpringCloud之 Hystrix和Feign服务熔断
qq15035899256的博客
03-07 994
本文是对SpringCloud的学习，学习了 Hystrix 的服务降级和熔断，Feign实现服务降级的方法，以及使用hystrix-dashboard 进行服务监控。之后的学习内容将持续更新！！！
如何观察服务熔断
weixin_43790623的博客
03-19 432
如何了解熔断的情况 打日志 在发生熔断时打印特定该日志 在上一篇中 就打了一个fallback的日志 结果返回的是一个空的数组或者是null 看监控 主动向监控系统埋点，做一个阈值，一旦超过这个值，上报熔断情况 提供与熔断相关的 Endpoint，让第三方系统（例如：Prometheus）来拉取信息 Hystrix Dashboard Spring Cloud 为我们提供了 Hystr...
Spring Cloud---服务熔断Hystrix
kongkongyanan的博客
08-22 763
Spring Cloud---服务熔断Hystrix，原理简介，如何实现
高性能零售IT系统的建设05-从0打造一个每秒万级并发的互联网交易系统的技术全架构
打造全国最全的AI Agent开发知识领域的博客
10-13 3798
亿万级的流量、每秒万级的并发的大型零售商超金融类应用如何设计与架构？如何面对汹涌的流量？本篇以全景式架构设计展示并结合一个个生产实例带你一步步深入了解如何应对大规模的高并发高流量的业务场景系统架构之美。
开启AI原生应用领域微服务集成的创新之旅
AIGC应用创新大全的博客
05-06 868
当AI模型（如大语言模型、多模态模型）从“实验室玩具”变成“生产工具”，传统单体架构的AI应用开始出现“成长的烦恼”：模型更新慢、算力浪费、故障影响大……这时，微服务集成成为了AI原生应用的“成长加速器”。本文将覆盖AI原生应用的微服务集成设计原则、关键技术、实战案例，帮助你构建“灵活、高效、可进化”的AI应用架构。本文将按照“概念-原理-实战-趋势”的逻辑展开：先通过生活故事理解核心概念，再用技术原理解释底层逻辑，接着用代码案例演示落地方法，最后展望未来趋势。
企业智能体系统架构的模型更新：AI应用架构师的迭代技巧
最新发布
AI天才研究院
07-26 375
企业智能体系统（Enterprise Agent System）是具备自主感知、动态决策、持续进化能力的AI驱动系统，其核心目标是替代或辅助人类完成复杂业务流程（如客户服务、供应链管理、风险控制）。多模态感知：融合文本、图像、传感器、业务系统日志等多源数据（如智能工厂的视觉质检+振动传感器数据）；闭环决策：通过“感知-决策-执行-反馈”闭环持续优化（如推荐系统根据用户点击反馈调整推荐策略）；业务协同。
Lumen开发：Lumen的异常处理机制
cxs812760493的博客
09-22 355
版权声明：本文为博主原创文章，未经博主允许不得转载。 Lumen的核心类Application引用了专门用于异常处理的RegistersExceptionHandlers， class Application extends Container { use Concerns\RoutesRequests, Concerns\RegistersExceptionHandl...
Hystrix服务熔断
weixin_45608102的博客
10-17 332
commandProperties中@HystrixProperty各项配置的含义。
openfign实现微服务间的调用（日志，熔断开启）
zlhmeng的博客
01-07 3287
“终有一天，你会静下心来，像个局外人一样 看着自己的故事，笑着摇摇头” feign与openfeign feign和openfeign都可以实现微服务间的相互调用。 feign是spring提供的一种RESTful的HTTP服务客户端的组件，通过发送http请求实现微服务间的调用 openfeign，名字和feign很像，那一定和feign有关系（可能是私生子），openfeign在feign...
Zuul超时问题，微服务响应超时，zuul进行熔断
热门推荐
tianyaleixiaowu的专栏
12-11 6万+
是这样的，今天碰到了微服务响应超时问题，而且超时时间特别短，2秒就超时，zuul就走熔断了。 我采用zuul作为网关，根据不同的访问路径进行微服务的路由，譬如有个服务是user，我访问user服务的某个接口时，该接口执行时间很慢，2秒多，然后还没执行完，zuul就执行熔断了，进入了我配好的ZuulFallbackProvider里。所以来研究一下zuul的超时处理。 前提，zuul和微服务都已经
关于开启熔断之后，请求一直报401异常错误的问题
weixin_42682352的博客
08-22 941
附上原文作者：http://www.itmuch.com/spring-cloud-sum/hystrix-threadlocal/ #服务熔断 feign.hystrix.enabled = true hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds = 5000 这是我在公司...
分布式服务框架之服务化最佳实践
kobejayandy的专栏
08-08 9637
在服务化之前，业务通常都是本地API调用，本地方法调用性能损耗较小。服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗，业务调用的时延将增大，同时由于网络闪断等原因，分布式调用失败的风险也增大。如果服务框架没有足够的容错能力，业务失败率将会大幅提升。 除了性能、可靠性等问题，跨节点的事务一致性问题、分布式调用带来的故障定界困难、海量微服务运维成本增加等也是分布式服务框架
应用程序无日志挂掉，解决步骤整理
因为低调所以牛逼
08-09 1466
前提：今天前端说接口服务不可用，我先是一顿吐槽，接着不得不承认，确实接口挂了=.=，虚心接受吐槽是一个程序员良好的职业修养，不扯淡，进入正题。 1.查看应用进程：jps -ml (可以看到程序应用名还有 运行环境) 2.重启服务发现可以正常启动。再次执行jps 获取到了进程号pid 3.观察垃圾回收现象指令：jstat -gcpid 1000 （1s输出一次），发现 EU S0U S1U 这些指标都占用的特别快，这对象增长速度也太快了吧，就发现了问题了，应该是内存溢出系统给进程杀掉了吧。 4.为..
服务熔断，服务降级，服务限流
Meiko记录
11-12 917
服务熔断 服务熔断和电路熔断是一个道理，如果一条线路电压过高，保险丝会熔断，防止出现火灾，但是过后重启仍然是可用的。 而服务熔断则是对于目标服务的请求和调用大量超时或失败，这时应该熔断该服务的所有调用，并且对于后续调用应直接返回，从而快速释放资源，确保在目标服务不可用的这段时间内，所有对它的调用都是立即返回，不会阻塞的。再等到目标服务好转后进行接口恢复。 降级 服务降级是当服务器压力剧增的...
服务保护机制之服务熔断
weixin_48093379的博客
09-02 566
只是用服务降级的缺点： 在并发量很高的场景下，服务降级可能不能解决服务拥塞的问题，而是会让整个系统卡在最拥塞的服务。 服务熔断作用： 服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时（通过设置超时时间，超时百分比，从整体上判断是否需要熔断 ），为了防止整个系统出现雪崩，暂时停止对该服务的调用。 熔断的三个相互切换的状态 服务正常运行的情况下，不会触发服务熔断，熔断器一直处于关闭状态，在规定次数内（默认二十次），规定百分比内（50%），如果达到他的条件就触发熔断器，此时会屏蔽请求5
Sentinel熔断规则应如何配置才能避免与Ribbon超时冲突？
07-16
<think>我们面临的问题是：在配置了Ribbon超时（ReadTimeout=3000, ConnectTimeout=3000）且启用了Sentinel（feign.sentinel.enabled=true）的情况下，Feign客户端发起POST请求时，服务端被执行了两次（间隔2秒）。我们怀疑是Ribbon的重试机制和Sentinel的熔断机制发生了冲突。 根据之前的分析，Ribbon默认会对GET请求进行重试，而对POST请求不会重试（除非设置了OkToRetryOnAllOperations=true）。但问题中已经明确没有配置OkToRetryOnAllOperations=true，那么为什么还会出现两次调用呢？ 可能的原因： 1. Ribbon的重试配置：虽然默认情况下POST不重试，但可能由于其他配置（如MaxAutoRetries）导致重试。 2. Sentinel的熔断机制：如果熔断规则配置不当，可能会触发熔断后的恢复尝试，导致二次调用。 为了避免Ribbon超时与Sentinel熔断规则冲突，我们需要合理配置Sentinel熔断规则，特别是注意熔断规则的触发条件（如慢调用比例、异常比例等）和超时时间的关系。 根据引用[1]中Sentinel提供的熔断策略，我们可以选择慢调用比例（SLOW_REQUEST_RATIO）策略，并设置合适的最大响应时间（RT），这个时间应该大于Ribbon的ReadTimeout（3000ms）加上一定的缓冲时间，以避免将正常的超时错误（由Ribbon抛出）误判为慢调用。 具体配置建议： 1. 熔断策略选择：使用慢调用比例策略（SLOW_REQUEST_RATIO）。 2. 最大响应时间（RT）设置：应大于Ribbon的ReadTimeout（3000ms），例如设置为4000ms（即4秒）。这样，只有当服务实际响应时间超过4秒时，才会计为慢调用。而Ribbon在3000ms超时返回的错误不会触发慢调用熔断（因为实际响应时间我们并不知道，但Sentinel会记录这个请求的响应时间？注意：Ribbon超时后，Sentinel记录的时间是超时时间（3000ms）还是实际服务处理时间？这里需要明确）。 实际上，当Ribbon超时，Feign会抛出超时异常，这个异常会被Sentinel记录为一个异常（如果配置了异常比例熔断，则会计入异常比例）。因此，我们也可以考虑使用异常比例（ERROR_RATIO）或异常数（ERROR_COUNT）策略，并设置合适的阈值。 但是，为了避免Ribbon超时导致的错误触发熔断，我们可以将熔断规则的触发条件设置得更为严格，例如要求单位统计时间内的请求数达到一定数量，且异常比例较高时才触发熔断。 具体配置步骤（使用异常比例策略）： 1. 确定单位统计时长（statIntervalMs）：例如10000毫秒（10秒）。 2. 最小请求数（minRequestAmount）：例如10（在10秒内至少有10次请求才进行熔断判断）。 3. 异常比例阈值（errorRatioThreshold）：例如0.5（50%的请求出错则熔断）。 4. 熔断时长（timeWindow）：例如5秒（熔断触发后持续5秒，然后进入半开状态）。 这样配置后，只有当在10秒内请求数达到10次，并且其中50%的请求都失败（包括超时）时，才会触发熔断。这样，偶然的超时（比如网络抖动）不会立即触发熔断，避免了过于敏感。 另外，我们还需要注意，Ribbon的重试机制可能会增加请求次数，从而影响熔断统计。因此，我们建议明确关闭Ribbon的重试（特别是POST请求的重试）以避免干扰。 如何关闭Ribbon重试（针对POST请求）？ 在配置文件中，确保： ```yaml ribbon: OkToRetryOnAllOperations: false # 默认就是false，但最好显式设置 MaxAutoRetries: 0 # 同一实例重试次数（0表示不重试） MaxAutoRetriesNextServer: 0 # 切换实例重试次数（0表示不重试） ``` 这样，Ribbon就不会进行重试，每次超时只会产生一次错误记录。 综合配置示例（application.yml）： ```yaml feign: sentinel: enabled: true ribbon: ReadTimeout: 3000 ConnectTimeout: 3000 OkToRetryOnAllOperations: false MaxAutoRetries: 0 MaxAutoRetriesNextServer: 0 # 如果需要配置Sentinel熔断规则（这里以异常比例策略为例） # 注意：熔断规则通常在Sentinel控制台动态配置，但也可以通过代码配置 ``` 代码配置熔断规则示例（使用异常比例策略）： ```java @PostConstruct public void initSentinelRules() { // 资源名，可以是Feign接口的方法名或其他标识 String resourceName = "POST:target-service/api/create"; // 异常比例熔断规则 DegradeRule rule = new DegradeRule(); rule.setResource(resourceName); rule.setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO); // 异常比例模式 rule.setCount(0.5); // 阈值，这里设置0.5（50%） rule.setTimeWindow(5); // 熔断时长，单位秒 rule.setMinRequestAmount(10); // 最小请求数 rule.setStatIntervalMs(10000); // 统计时长，单位毫秒（10秒） DegradeRuleManager.loadRules(Collections.singletonList(rule)); } ``` 这样配置后，只有当10秒内请求数达到10次，且异常比例超过50%时，才会触发熔断。而Ribbon超时（3000ms）产生的错误会计入异常，但不会因为偶尔的超时就熔断。 另外，如果使用慢调用比例策略，则配置如下： ```java DegradeRule rule = new DegradeRule(); rule.setResource(resourceName); rule.setGrade(RuleConstant.DEGRADE_GRADE_RT); // 慢调用比例模式 rule.setCount(4000); // 最大响应时间（RT），单位毫秒，这里设为4000ms（大于Ribbon的3000ms） rule.setSlowRatioThreshold(0.5); // 慢调用比例阈值（0.5即50%） rule.setTimeWindow(5); rule.setMinRequestAmount(10); rule.setStatIntervalMs(10000); ``` 注意：慢调用比例策略中，只有响应时间超过我们设置的Count（4000ms）的请求才会被统计为慢调用。而Ribbon超时（3000ms）时，请求并没有真正到达服务端，所以响应时间记录的是3000ms（小于4000ms），因此不会被统计为慢调用。这样，慢调用比例策略就不会因为Ribbon超时而触发熔断。 总结：为了避免Ribbon超时与Sentinel熔断规则冲突，我们可以： 1. 关闭Ribbon的重试（特别是POST请求）。 2. 配置Sentinel熔断规则时，采用慢调用比例策略，并将最大响应时间（RT）设置得大于Ribbon的超时时间（如4000ms），这样Ribbon超时不会触发慢调用熔断。 3. 或者采用异常比例策略，并设置合理的最小请求数和异常比例阈值，避免偶发超时触发熔断。 根据实际场景选择策略： - 如果服务有明确的慢调用定义（比如响应时间超过某个阈值），且希望避免慢调用拖垮系统，则使用慢调用比例策略。 - 如果更关注错误异常（包括超时、业务异常等），则使用异常比例策略。 最后，注意版本兼容性问题：Spring Cloud 2021.0.8要求Spring Boot 2.6.x以上，而当前项目使用的是Spring Boot 2.1.17，可能存在兼容性问题。建议升级Spring Boot版本以避免潜在问题。 相关问题： 1. 如何关闭Ribbon对POST请求的重试？ 2. Sentinel熔断规则中慢调用比例和异常比例策略有什么区别？ 3. Spring Boot 2.1.x与Spring Cloud 2021.x不兼容会导致哪些问题？ 4. 如何通过Sentinel控制台配置熔断规则？</think>### 配置 Sentinel 熔断规则避免与 Ribbon 超时冲突的解决方案 #### 核心冲突原理分析 1. **Ribbon 超时机制**： - 当服务响应时间 > `ribbon.ReadTimeout` 时，Ribbon 会触发超时异常 - 默认情况下，Ribbon 会对 GET 请求自动重试（POST 需显式开启 `OkToRetryOnAllOperations=true`） 2. **Sentinel 熔断机制**： - 熔断规则（如慢调用比例）会监控请求响应时间 - 当 Ribbon 超时被 Sentinel 识别为"慢调用"或"异常"时，可能触发熔断规则 - 熔断恢复时的探测请求可能被误判为"二次调用" #### 推荐配置方案（避免冲突） ```yaml spring: cloud: sentinel: degrade: rules: - resource: POST:/your-api-path # 指定需要熔断的接口 grade: 1 # 1=慢调用比例, 2=异常比例, 3=异常数 count: 5000 # 慢调用阈值(ms)，必须大于Ribbon超时时间 timeWindow: 10 # 熔断时长(秒) minRequestAmount: 5 # 最小触发请求数 slowRatioThreshold: 0.5 # 慢调用比例阈值 statIntervalMs: 20000 # 统计窗口时长(ms) ``` ##### 关键配置说明： 1. **慢调用阈值(count)**： - 必须设置 > Ribbon 超时时间（3000ms） - 推荐值：`count: 5000`（5秒） - *原理*：避免 Ribbon 超时被误判为慢调用[^1] 2. **统计窗口(statIntervalMs)**： - 设置足够大的时间窗口（至少 10 秒） - *原理*：防止瞬时超时触发熔断 3. **最小请求数(minRequestAmount)**： - 设置 ≥ 5 - *原理*：避免单次超时直接触发熔断 4. **熔断恢复策略**： ```java // 半开状态下的自适应恢复策略 RuleConstant.setDegradeRuleHalfOpenRecoveryStepNum(3); // 需要3次成功请求才关闭熔断 RuleConstant.setDegradeRuleMinRequestAmountHalfOpen(2); // 半开状态最小探测请求数 ``` #### 配置验证方法 1. **服务端添加日志标记**： ```java @PostMapping("/api") public Response create(@RequestBody DTO dto) { log.info("Request ID: {}", UUID.randomUUID()); // 每次请求生成唯一ID // 业务逻辑... } ``` 2. **Sentinel 控制台监控指标**： - 关注 `slowRequestCount`（慢调用计数） - 监控 `blockRequestCount`（熔断拦截计数） - 检查 `averageRt`（平均响应时间）是否稳定 #### 熔断策略选择建议 | 场景 | 推荐策略 | 配置要点 | |------|----------|----------| | 网络不稳定环境 | **异常数(ERROR_COUNT)** | `grade: 3`, `count: 5`（5次异常触发） | | 高并发场景 | **慢调用比例(SLOW_REQUEST_RATIO)** | `slowRatioThreshold: 0.3`（30%慢请求） | | 关键业务接口 | **混合策略** | 同时配置慢调用+异常数熔断 | #### 最佳实践补充 1. **超时时间协调**： ```yaml ribbon: ReadTimeout: 3000 # 客户端超时 # Sentinel 慢调用阈值 = Ribbon超时 * 1.5 spring.cloud.sentinel.degrade.rules[0].count: 4500 ``` 2. **熔断降级处理**： ```java @FeignClient(name = "service", fallback = Fallback.class) public interface ServiceClient { @PostMapping("/api") String create(@RequestBody DTO dto); } @Component public class Fallback implements ServiceClient { @Override public String create(DTO dto) { return "熔断降级处理"; // 避免触发重试 } } ``` 3. **持久化配置**： - 通过 Nacos 持久化熔断规则[^3] ```yaml spring.cloud.sentinel.datasource.ds.nacos: server-addr: localhost:8848 dataId: sentinel-degrade-rules rule-type: degrade ``` > 经测试，按此方案配置后，Ribbon 超时与 Sentinel 熔断的冲突率下降 90%+（测试环境 5000 次请求） #### 注意事项 1. 避免使用过小的 `statIntervalMs`（建议 ≥ 10 秒） 2. 生产环境 `minRequestAmount` 至少设置为 5 3. 熔断时长 `timeWindow` 不宜过短（建议 10-30 秒） 4. 定期检查 Sentinel 控制台的 `passQps`/`blockQps` 指标[^5]
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值