使用SpringBoot实现微服务超时重试模式的示例

使用resilience4j的库和Spring Boot设计高弹性的微服务。

微服务本质上是分布式的。当您使用分布式系统时,请始终记住这一第一法则- 网络中可能发生任何事情。处理任何此类意外故障可能很难解决。故障可能是任何东西-应用程序,硬件或网络等。

系统从故障中恢复并保持正常运行的能力使系统更具 弹性。它还避免了下游服务的任何级联故障。

重试模式:

在微服务体系结构中,当有多个服务(A,B,C和D)时,一个服务(A)可能依赖于另一服务(B),而另一服务(B)又可能依赖于C,依此类推。有时由于某些问题,服务D可能无法按预期响应。服务D可能引发了某些异常,例如内存不足 错误或内部服务器错误。此类异常被级联到下游服务,这可能导致不良的用户体验,如下所示。

有时,当google.com对我们不起作用时,我们只是不放弃。我们假设页面下次可以正常工作,并且大多数情况下都会刷新页面,因此只需刷新页面即可。间歇性网络问题非常普遍。在微服务领域,我们可能正在运行同一服务D的多个实例,以实现高可用性和负载平衡。如果其中一个实例可能有问题,并且无法正确响应我们的请求,则如果我们重试该请求,则负载均衡器可以将请求发送到运行状况良好的节点并正确获得响应。因此,使用“重试”选项,我们有更多机会获得正确的响应。

让我们考虑这个简单的应用程序来解释此重试模式。

  • 如上所述,我们有多个微服务
  • 产品服务充当产品目录并负责提供产品信息
  • 产品服务取决于评级服务。
  • 评分服务维护产品评论和评分。 由于拥有大量数据而速度慢是众所周知的。
  • 每当我们查看产品详细信息时,产品服务就会将请求发送到评分服务,以获取该产品的评论。
  • 我们还有其他服务,例如帐户服务,订单服务和付款服务等,与本文的讨论无关。
  • 产品服务是一项核心服务,没有它,用户将无法启动订单工作流程。

设置:

<dependency>
    <groupId>io.github.resilience4j</groupId>
    <artifactId>resilience4j-spring-boot2</artifactId>
    <version>1.6.1</version>
</dependency>

产品服务负责根据用户搜索条件提供产品列表。它是即使在关键负载下也应该启动和响应的核心服务之一。如果下降,将严重影响收入。由于此服务取决于评级服务,因此我们不希望任何网络问题或评级服务不可用性影响此产品服务。这就是使用 resilience4j 库的目的。

  • 我首先为resilience4j创建一个配置,  如下所示。在这里,我们将超时明确设置为3秒。我们可以在特定的超时时间内添加多个服务。
  • 我们可以有多种服务配置,如下所示。
  • 对于ratingService,我们将最多进行3次重试,延迟5秒。
  • retryExceptions:这些是我们将重试的异常。这是一个数组字段。您可以配置多个例外。
  • ignoreExceptions:有些异常我们可能不想重试。例如,一个错误的请求就是一个错误的请求。重试没有意义。因此,我们忽略了这一点。
resilience4j.retry:
  instances:
    ratingService:
      maxRetryAttempts: 3
      waitDuration: 5s
      retryExceptions:
        - org.springframework.web.client.HttpServerErrorException
      ignoreExceptions:
        - org.springframework.web.client.HttpClientErrorException
    someOtherService:
      maxRetryAttempts: 3
      waitDuration: 10s
      retryExceptions:
        - org.springframework.web.client.HttpServerErrorException
        - java.io.IOException

代码:

@Service
public class RatingServiceClient {

    private final RestTemplate restTemplate = new RestTemplate();

    @Value("${rating.service.endpoint}")
    private String ratingService;

    @Retry(name = "ratingService", fallbackMethod = "getDefault")
    public CompletionStage<ProductRatingDto> getProductRatingDto(int productId){
        Supplier<ProductRatingDto> supplier = () ->
            this.restTemplate.getForEntity(this.ratingService + productId, ProductRatingDto.class)
                    .getBody();
        return CompletableFuture.supplyAsync(supplier);
    }

    private CompletionStage<ProductRatingDto> getDefault(int productId, HttpClientErrorException throwable){
        return CompletableFuture.supplyAsync(() -> ProductRatingDto.of(0, Collections.emptyList()));
    }

}

代码解释:

  • @Retry表示resilience4j将对该方法执行应用重试逻辑。
  • name = ratingService 表示 resilience4j 将使用yaml中的ratingService配置。
  • 当main方法由于某种原因失败时,将使用fallbackMethod。

总结

重试模式 是用于设计弹性微服务的最简单的微服务 设计模式之一。引入重试可以解决与网络相关的问题。

源代码可 在此处获得。

超时模式源码可在此处获得。

以上就是使用SpringBoot实现微服务超时重试模式的示例的详细内容,更多关于SpringBoot实现微服务超时的资料请关注我们其它相关文章!

(0)

相关推荐

  • Idea springboot如何实现批量启动微服务

    概要 在使用IDEA开发微服务的时候,微服务比较多,启动起来比较麻烦,下面介绍一下使用批量启动微服务的方法. 方法 编辑当前项目根目录下的 .idea\workspace.xml 文件. 找到 <component name="RunDashboard"> 在这个标签下增加: <option name="configurationTypes"> <set> <option value="SpringBootAppl

  • SpringBoot+Eureka实现微服务负载均衡的示例代码

    1,什么是Eureka,什么是服务注册与发现 Spring Boot作为目前最火爆的web框架.那么它与Eureka又有什么关联呢? Eureka是Netflix开源的一个RESTful服务,主要用于服务的注册发现. Eureka由两个组件组成:Eureka服务器和Eureka客户端.Eureka服务器用作服务注册服务器. Eureka客户端是一个java客户端,用来简化与服务器的交互.作为轮询负载均衡器,并提供服务的故障切换支持. Netflix在其生产环境中使用的是另外的客户端,它提供基于流

  • Springboot微服务打包Docker镜像流程解析

    1.构建springboot项目 2.打包应用 3.编写dockerfile 4.构建镜像 5.发布运行! [root@localhost demo]# ls demo02-0.0.1-SNAPSHOT.jar Dockerfile # Dockerfile文件 [root@localhost demo]# cat Dockerfile FROM java:8 COPY *.jar /app.jar CMD ["--server.port=8080"] EXPOSE 8080 ENTR

  • springboot 打包部署 共享依赖包(分布式开发集中式部署微服务)

    1.此文初衷 平常我们在进行微服务开发完毕后,单个微服务理应部署单个虚机上(docker也可),然后服务集中发布到服务注册中心上,但是有些小的项目,这样做未免太过繁杂增加了部署难度,这里主要讲述的是如何在单机上通过共享jar包的方式来部署多个微服务,解决以上部署难度同时在带宽不够或者网速慢的情况下如何快速的发布部署. 2.部署目录结构   部署目录解答-> 各个微服务与依赖包(lib文件夹下)在同一级目录下,此为图1内容.图二内容展示的是单个微服务内的文件结构,部署配置文件以及所打的jar包,这

  • SpringBoot+SpringCloud用户信息微服务传递实现解析

    这篇文章主要介绍了SpringBoot+SpringCloud实现登录用户信息在微服务之间的传递,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 实现思路: 1:准备一个ThreadLocal变量,供线程之间共享. 2:每个微服务对所有过来的Feign调用进行过滤,然后从请求头中获取User用户信息,并存在ThreadLocal变量中. 3:每个微服务在使用FeignClient调用别的微服务时,先从ThreadLocal里面取出user信息,并

  • SpringBoot集成gRPC微服务工程搭建实践的方法

    前言 本文将使用Maven.gRPC.Protocol buffers.Docker.Envoy等工具构建一个简单微服务工程,笔者所使用的示例工程是以前写的一个Java后端工程,因为最近都在 学习微服务相关的知识,所以利用起来慢慢的把这个工程做成微服务化应用.在实践过程踩过很多坑,主要是经验不足对微服务还是停留在萌新阶段,通过本文 记录创建微服务工程碰到一些问题,此次实践主要是解决以下问题: 如何解决.统一服务工程依赖管理 SpringBoot集成gRPC 管理Protocol buffers文

  • 使用SpringBoot实现微服务超时重试模式的示例

    使用resilience4j的库和Spring Boot设计高弹性的微服务. 微服务本质上是分布式的.当您使用分布式系统时,请始终记住这一第一法则- 网络中可能发生任何事情.处理任何此类意外故障可能很难解决.故障可能是任何东西-应用程序,硬件或网络等. 系统从故障中恢复并保持正常运行的能力使系统更具 弹性.它还避免了下游服务的任何级联故障. 重试模式: 在微服务体系结构中,当有多个服务(A,B,C和D)时,一个服务(A)可能依赖于另一服务(B),而另一服务(B)又可能依赖于C,依此类推.有时由于

  • Rancher+Docker+SpringBoot实现微服务部署、扩容、环境监控

    目录 前言 一.前置需求 1.linux虚拟机或系统 2.创建好docker环境 3.写一个简单的微服务并创建为docker镜像 二.安装Rancher 1.拉取rancher镜像 2.启动rancher容器 3.访问rancher 三.配置rancher 1.把语言改为中文 2.创建rancher环境 3.添加一个主机 4.为主机添加应用 5.为应用添加服务 四.扩容 五.状态监控 1.查看 cpu.内存.网络.存储 状态 2.查看日志 六.访问控制 七.补充 前言 Rancher 是一套容器

  • Docker安装jenkins实现微服务多模块打包的示例代码

    目录 1.安装 2.初始化 3.配置jenkins 3.1 安装Maven 3.2 配置Maven插件 3.3 安装svn插件 4. 创建自动化部署任务 4.1 配置清理旧的构建 4.2 创建svn账密凭证 4.3 填写build命令 4.4 首次构建 5. 配置maven运行命令及shell脚本 5.1 maven父子项目依赖指令配置 5.2打包完成之后shell命令 废话不多说,直接讲正事 1.安装 # 1.pull jenkins(若使用jdk11则可pull最新版jenkins,否则最新

  • SpringBoot整合RabbitMQ实现六种工作模式的示例

    目录 前提概念 生产者 队列 消费者 SpringBoot整合RabbitMQ基本配置添加maven依赖 1. 简单(simple)模式 2. 工作模式 生产消息: 3. 发布订阅模式 特点 创建队列.交换机以及绑定: 4. 路由模式 特点 创建队列.交换机以及绑定: 5. 主题模式 特点 创建交换机和队列: 6. RPC模式 特点 消费端添加返回值: 交换机类型 Direct Exchange(直连) Fanout Exchange(扇形) Topic Exchange(主题) 总结 源码示例

  • 如何用Springboot Admin监控你的微服务应用

    1 简介 目前,微服务大行其道,各大小公司争相学习模仿,把单体应用拆得七零八落.服务多了,运行的实例多了,给运维人员的压力就更大了.如果有十几个应用,单单做Health Check就已经够费时间的了.聪明的Springboot提供了Actuator接口,可以非常好获得应用的内部信息,然而针对数量庞大的服务却无能为力. 得益于开源社区的力量,我们有了Springboot Admin.它能对注册于服务发现的所有应用监控起来,功能包括健康检查.JVM内存.INFO信息.获得线程栈和堆栈信息.提醒(邮件

  • 浅谈架构模式变迁之从分层架构到微服务架构

    前言 谈到软件系统设计的方法论,在代码层面,有我们熟悉的23种设计模式(design pattern),对应到架构层面,则有所谓的架构模式(architecture pattern).它们分别从微观和宏观的角度指导着我们设计出良好的软件系统,因此,作为一个软件工程师,我们不仅要熟悉设计模式,对常见的架构模式也要熟稔于心.正如看到一个设计模式的名字脑里就能浮现出大致的结构图,当我们看到一个架构模式的名字时,也要马上想到对应的架构图及其基本特点.比如,当谈到分层架构时,我们就应该想起它的架构图是怎样

  • .Net Core微服务网关Ocelot超时、熔断、限流

    基本概念 超时.熔断.限流听起来好像很远,但实际上用在方方面面.很多人可能还搞不懂熔断是做什么,其实可以把熔断理解为一种防护措施.做个假设,在微服务体系下,某个下游服务响应很慢,然后随着时间推移,会有越来越多的请求堆积,从而会导致各种严重后果,单说连接池大量被占用就很要命.更不用说服务之间还要相互调用,你等我10秒,我等你5秒,不仅毫无体验感,高可用也就成了空谈.不如换个思路:与其等10秒返回一个请求失败,不如马上就返回请求失败.这样一来,请求堆不起来,资源也有时间释放或者恢复.这个动作就叫熔断

随机推荐