Question

本章主要内容

• 实现断路器模式、后备模式和舱壁模式
• 使用断路器模式来保护微服务客户端资源
• 当远程服务失败时使用 Hystrix
• 实施 Hystrix 的舱壁模式来隔离远程资源调用
• 调节 Hystrix 的断路器和舱壁的实现
• 定制 Hystrix 的并发策略

所有的系统，特别是分布式系统，都会遇到故障。如何构建应用程序来应对这种故障，是每个软件开发人员工作的关键部分。然而，当涉及构建弹性系统时，大多数软件工程师只考虑到基础设施或关键服务彻底发生故障。他们专注于在应用程序的每一层构建冗余，使用诸如集群关键服务器、服务间的负载均衡以及将基础设施分离到多个位置的技术。

尽管这些方法考虑到系统组件的彻底（通常是惊人的）损失，但它们只解决了构建弹性系统的一小部分问题。当服务崩溃时，很容易检测到该服务已经不在了，因此应用程序可以绕过它。然而，当服务运行缓慢时，检测到这个服务性能不佳并绕过它是非常困难的，这是因为以下几个原因。

（1） 服务的降级可以以间歇性问题开始，并形成不可逆转的势头 ——降级可能只发生在很小的爆发中。故障的第一个迹象可能是一小部分用户抱怨某个问题，直到突然间应用程序容器耗尽了线程池并彻底崩溃。

（2） 对远程服务的调用通常是同步的，并且不会缩短长时间运行的调用 ——服务的调用者没有超时的概念来阻止服务调用的永久挂起。应用程序开发人员调用该服务来执行操作并等待服务返回。

（3） 应用程序经常被设计为处理远程资源的彻底故障，而不是部分降级 ——通常，只要服务没有彻底失败，应用程序将继续调用这个服务，并且不会采取快速失败措施。该应用程序将继续调用表现不佳的服务。调用的应用程序或服务可能会优雅地降级，但更有可能因为资源耗尽而崩溃。资源耗尽是指有限的资源（如线程池或数据库连接）消耗殆尽，而调用客户端必须等待该资源变为可用。

性能不佳的远程服务所导致的潜在问题是，它们不仅难以检测，还会触发连锁效应，从而影响整个应用程序生态系统。如果没有适当的保护措施，一个性能不佳的服务可以迅速拖垮多个应用程序。基于云、基于微服务的应用程序特别容易受到这些类型的中断的影响，因为这些应用程序由大量细粒度的分布式服务组成，这些服务在完成用户的事务时涉及不同的基础设施。