- 内容提要
- 译者序
- 前言
- 第 1 章 欢迎迈入云世界,Spring
- 第 2 章 使用 Spring Boot 构建微服务
- 第 3 章 使用 Spring Cloud 配置服务器控制配置
- 第 4 章 服务发现
- 第 5 章 使用 Spring Cloud 和 Netflix Hystrix 的客户端弹性模式
- 第 6 章 使用 Spring Cloud 和 Zuul 进行服务路由
- 第 7 章 保护微服务
- 第 8 章 使用 Spring Cloud Stream 的事件驱动架构
- 第 9 章 使用 Spring Cloud Sleuth 和 Zipkin 进行分布式跟踪
- 第 10 章 部署微服务
- 附录 A 在桌面运行云服务
- 附录 B OAuth2 授权类型
5.6 后备处理
断路器模式的一部分美妙之处在于,由于远程资源的消费者和资源本身之间存在“中间人”,因此开发人员有机会拦截服务故障,并选择替代方案。
在 Hystrix 中,这被称为后备策略(fallback strategy),并且很容易实现。让我们看看如何为许可数据库构建一个简单的后备策略,该后备策略简单地返回一个许可对象,这个许可对象表示当前没有可用的许可信息。代码清单 5-5 展示了上述讨论的内容。
代码清单 5-5 在 Hystrix 中实现一个后备
@HystrixCommand(fallbackMethod = "buildFallbackLicenseList") ⇽--- fallbackMethod 属性定义了类中的一个方法,如果来自 Hystrix 的调用失败,那么就会调用该方法
public List<License> getLicensesByOrg(String organizationId){
randomlyRunLong();
return licenseRepository.findByOrganizationId(organizationId);
}
private List<License> buildFallbackLicenseList(String organizationId){ ⇽--- 在后备方法中,返回了一个硬编码的值
List<License> fallbackList = new ArrayList<>();
License license = new License()
.withId("0000000-00-00000")
.withOrganizationId( organizationId )
.withProductName(
→ "Sorry no licensing information currently available");
fallbackList.add(license);
return fallbackList;
}
注意
在来自 GitHub 存储库的源代码中,我注释掉了
fallbackMethod
对应的行,以便读者可以看到服务调用的随机失败。要查看代码清单 5-5 中的后备代码,读者需要取消注释掉fallbackMethod
属性,否则,永远不会看到后备代码实际被调用。
要使用 Hystrix 实现一个的后备策略,开发人员必须做两件事情。第一件是,需要在 @HystrixCommand
注解中添加一个名为 fallbackMethod
的属性。该属性将包含一个方法的名称,当 Hystrix 因为调用耗费时间太长而不得不中断该调用时,该方法将会被调用。
第二件是,需要定义一个待执行的后备方法。此后备方法必须与由 @HystrixCommand
保护的原始方法位于同一个类中,并且必须具有与原始方法完全相同的方法签名,因为传递给由 @HystrixCommand
保护的原始方法的所有参数都将传递给后备方法。
在代码清单 5-5 所示的示例中,后备方法 buildFallbackLicenseList()
只是简单构建一个包含虚拟信息的单个 License
对象。读者可以使用后备方法从备用数据源读取这些数据,但出于演示的目的,我们将构建一个列表,该列表由原始的方法调用返回。
后备
在微服务检索数据并且调用失败的情况下,后备策略非常有效。在我工作过的一个组织中,我们将客户信息存储在操作型数据存储(Operational Data Store,ODS)中,并在数据仓库中进行汇总。
我们的愉快路径总是检索最新的数据,并为其动态计算摘要信息。然而,在一次特别严重的中断之后,由于数据库连接的速度慢,我们决定使用 Hystrix 后备实现来保护检索和汇总客户信息的服务调用。 如果由于性能问题或错误导致对 ODS 的调用失败,我们就使用后备来从数据仓库表中检索汇总数据。
我们的业务团队认为,提供旧数据给客户比让客户看到错误或整个应用程序崩溃更为可取。选择是否使用后备策略的关键是客户对数据“年龄”的宽容程度,以及永远不要让他们看到应用程序出现问题的重要程度。
在确定是否要实施后备策略时,要注意以下两点。
(1)后备是一种在资源超时或失败时提供行动方案的机制。如果发现自己使用后备来捕获超时异常,然后只做日志记录错误,就应该在服务调用周围使用标准的
try..catch
块,捕获HystrixRuntime Exception
异常,并将日志记录逻辑放在try..catch
块中。(2)注意使用后备方法所执行的操作。如果在后备服务中调用另一个分布式服务,就可能需要使用
@HystrixCommand
注解来包装后备方法。记住,在主要行动方案中经历的相同的失败有可能也会影响次要的后备方案。要进行防御性编码。我试过在使用后备的时候没有考虑到这个问题,最终吃了很大苦头。
现在我们拥有了后备方案,接下来继续访问端点。这一次,当我们访问这个端点并遇到一个超时错误(有 1/3 的机会)时,我们不会从服务调用中得到一个返回的异常,而是得到虚拟的许可证值。图 5-6 展示了上面讨论的内容。
图 5-6 使用 Hystrix 后备的服务调用
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论