第 15 章 服务容错保护(1)
丁雪丰
本章内容
几种常见的服务容错模式
Resilience4j 的基本用法
Spring Cloud CircuitBreaker 的抽象与应用
在微服务系统中，业务操作由多个服务协作完成，在这个过程中涉及的服务多了，出问题的概率自然也就变高了。如果下游服务出问题了，上游又不设防，就会被拖累；如果请求量陡增，超过服务的承受能力，也会引发问题……当我们遇到的问题多了，自然就会沉淀出不少经验，本章就让我们来看看如何基于常见的容错模式，使用一些框架来保护我们的系统。
15.1 常见的服务容错模式
一开始，我们不急于去介绍和使用那些帮助处理故障的工具，在知道如何借助外部力量之前，先来了解一下：为什么要实现服务容错，别人都是怎么做的，没有工具时我们又能怎么办。
请注意 本章所涉及的故障都是微服务链路中依赖的上下游之间发生的故障，系统本身内部的代码问题不在我们讨论的范畴内。
15.1.1 几种常见的容错模式
在编写代码时，我们会用设计模式，最知名的就是 GoF 23。在故障处理方面其实也有模式可以遵循（或者通俗一点说，也有自己的“套路”），我们把这些模式搬出来就能应付不少问题了。
重试模式
最简单粗暴的容错模式，可能就是重试（Retry）了。重试，简单而言就是出错后再试一次。但重试不是万灵药，系统支持重试有很多先决条件，例如，我们的下游服务要能保证幂等性，否则很容易造成一些重复请求的问题，而如果这笔请求是转账操作，调用一次转一笔钱，无脑重试可能会给不支持幂等的下游系统带来无穷无尽的问题。由此就不难理解，为什么在很多支持重试的框架（例如 HTTP Client）中，我们要关闭重试功能。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了微服务系统中常见的服务容错模式，包括重试模式、断路器模式、舱壁模式和限流器模式。这些模式可以帮助处理上下游服务之间的故障，确保系统的稳定性和可靠性。重试模式通过重复尝试操作来应对可能的失败，需要注意幂等性和设计合理的重试策略。断路器模式避免执行可能失败的操作，通过监控报错情况来切换断路器状态，以保护系统免受故障影响。舱壁模式将系统的线程池或客户端分隔开来，保证一个业务的故障不会影响其他业务的正常运行。限流器模式通过控制上游请求的数量，避免服务资源被滥用，保护服务提供方的安全。文章还介绍了在二进制奶茶店场景下实现服务容错模式的需求描述和业务逻辑调整，以及通过AOP实现简单的容错功能。同时，文章还提到了如何测试容错功能，使用单元测试验证AOP拦截器的效果。通过这些内容，读者可以快速了解微服务系统中常见的服务容错模式及其实现方式，为构建稳定可靠的微服务系统提供了有益的参考。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《学透 Spring：从入门到项目实战》
《学透 Spring：从入门到项目实战》
立即购买
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论