04. Spring Cloud--客户端弹性模式

4.1 简介

在分布式系统中，当服务崩溃时，很容易检测到该服务已经不在了，因此应用程序可以绕过它。然而，当服务运行缓慢时，检测到这个服务性能不佳并绕过它是非常困难的，这是因为以下几个原因。

1. 服务的降级可以以间歇性问题开始，并形成不可逆转的势头 – 降级可能只发生在很小的爆发中。故障的第一个迹象可能是一小部分用户抱怨某个问题，直到突然间应用程序容器耗尽了线程池并彻底崩溃。
2. 对远程服务的调用通常是同步的，并且不会缩短长时间运行的调用 – 服务的调用者没有超时的概念来阻止服务调用的永久挂起。应用程序开发人员调用该服务来执行操作并等待服务返回。
3. 应用程序经常被设计为处理远程资源的彻底故障，而不是部分降级 – 通常，只要服务没有彻底失败，应用程序将继续调用这个服务，并且不会采取快速失败措施。该应用程序将继续调用表现不佳的服务。调用的应用程序或服务可能会优雅地降级，但更有可能因为资源耗尽而崩溃。资源耗尽是指有限的资源（如线程池或数据库连接）消耗殆尽，而调用客户端必须等待该资源变为可用。

性能不佳的远程服务所导致的潜在问题是，它们不仅难以检测，还会触发连锁效应，从而影响整个应用程序生态系统。如果没有适当的保护措施，一个性能不佳的服务可以迅速拖垮多个应用程序。

什么是客户端弹性模式？
客户端弹性软件模式的重点是，在远程服务发生错误或表现不佳时保护远程资源（另一个微服务调用或数据库查询）的客户端免于崩溃。这些模式的目标是让客户端“快速失败”，而不消耗诸如数据库连接和线程池之类的宝贵资源，并且可以防止远程服务的问题向客户端的消费者进行“上游”传播。

有4 种客户端弹性模式，它们分别是：

1. 客户端负载均衡（client load balance）模式
2. 断路器（circuit breaker）模式
3. 后备（fallback）模式
4. 舱壁（bulkhead）模式

4.2 客户端负载均衡模式

在讨论服务发现（01. Spring Cloud–服务发现）时，我们了解了客户端负载均衡模式。客户端负载均衡涉及让客户端从服务发现代理（如Netflix Eureka）查找服务的所有实例，然后缓存服务实例的物理位置。 每当服务消费者需要调用该服务实例时，客户端负载均衡器将从它维护的服务位置池返回一个位置。

因为客户端负载均衡器位于服务客户端和服务消费者之间，所以负载均衡器可以检测服务实例是否抛出错误或表现不佳。如果客户端负载均衡器检测到问题，它可以从可用服务位置池中移除该服务实例，并防止将来的服务调用访问该服务实例。

4.3 断路器模式

断路器模式是模仿电路断路器的客户端弹性模式。在电气系统中，断路器检测是否有过多电流流过电线。如果断路器检测到问题，它将断开与电气系统的其余部分的连接，并保护下游部件不被烧毁。

有了软件断路器，当远程服务被调用时，断路器将监视这个调用。如果调用时间太长，断路器将会介入并中断调用。此外，断路器将监视所有对远程资源的调用，如果对某一个远程资源的调用失败次数足够多，那么断路器实现就会出现并采取快速失败，阻止将来调用失败的远程资源。

4.3.1 在Spring Cloud中实现断路器模式

首先，要在pom.xml文件中添加依赖：

<dependency>
  <groupId>org.springframework.cloudgroupId>
  <artifactId>spring-cloud-starter-hystrixartifactId>
dependency>
<dependency>
  <groupId>com.netflix.hystrixgroupId>
  <artifactId>hystrix-javanicaartifactId>
dependency>

然后，要修改Spring入口文件，如下：

@SpringBootApplication
@EnableEurekaClient
@EnableCircuitBreaker   //告诉SpringCloud将要为服务使用Hystrix
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

最后，使用的时候，需要在要监视的方法上添加注解如下：

@HystrixCommand
public User getUserById(String id) {
    // 访问数据库处理...
}

使用@HystrixCommand注解，在任何时候调用getUserById方法时，Hystrix断路器都将包装这个调用。每当调用时间超过1000ms时，断路器将终端对getUserById方法的调用。

如果访问超时，则会返回如下信息：

{
    "timestamp": "2018-11-07T21:01:58.033+0000",
    "status": 504,
    "error": "Gateway Timeout",
    "message": "com.netflix.zuul.exception.ZuulException: Hystrix Readed time out"
}

4.3.2 定制断路器的超时时间

Hystrix 允许通过commandProperties 属性来定制断路器的行为。commandProperties属性接受一个HystrixProperty 对象数组，它可以传入自定义属性来配置Hystrix 断路器。在以下代码中,使用execution.isolation.thread.timeoutIn Milliseconds 属性设置Hystrix 调用的最大超时时间为 5s。

@HystrixCommand(commandProperties = {
	@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "5000")
})
public User getUserById(String id) {
    // 访问数据库处理...
}

4.4 后备模式

要使用Hystrix 实现一个的后备策略，开发人员必须做两件事情。第一件是，需要在@HystrixCommand 注解中添加一个名为fallbackMethod 的属性。该属性将包含一个方法的名称，当Hystrix 因为调用耗费时间太长而不得不中断该调用时，该方法将会被调用。

第二件是，需要定义一个待执行的后备方法。此后备方法必须与由@HystrixCommand 保护的原始方法位于同一个类中，并且必须具有与原始方法完全相同的方法签名，因为传递给由@HystrixCommand 保护的原始方法的所有参数都将传递给后备方法。

代码如下：

@HystrixCommand(fallbackMethod = "fallbackUser")
public String getUserById(String id) {
    // 访问数据库处理...
}

public String fallbackUser(String id){
    return "fall back user";
}

当getUserById方法在执行过程中抛出异常时，fallbackUser方法会作为备用方法被调用，也就是说调用者会得到fallbackUser方法的执行结果。

4.5 舱壁模式

在基于微服务的应用程序中，开发人员通常需要调用多个微服务来完成特定的任务。在不使用舱壁模式的情况下，这些调用默认是使用同一批线程来执行调用的，这些线程是为了处理整个Java容器的请求而预留的。在存在大量请求的情况下，一个服务出现性能问题会导致Java容器的所有线程被刷爆并等待处理工作，同时堵塞新请求，最终导致Java容器崩溃。舱壁模式将远程资源调用隔离在它们自己的线程池中，以便可以控制单个表现不佳的服务，而不会使该容器崩溃。

Hystrix使用线程池来委派所有对远程服务的请求。在默认情况下，所有的Hystrix命令都将共享一个线程池来处理请求。这个线程池将有10个线程来处理远程服务调用，而这些远程服务调用可以是任何东西，包括REST服务调用、数据库调用等。

在应用程序中访问少量的远程资源时，这种模型运行良好，并且各个服务的调用量分布相对均匀。问题是，如果某些服务具有比其他服务高得多的请求量或更长的完成时间，那么最终可能导致Hystrix线程池中的线程耗尽，因为一个服务最终会占据默认线程池中的所有线程。

Hystrix提供了一种易于使用的机制，在不同的远程资源调用之间创建舱壁。代码如下：

@HystrixCommand(
        fallbackMethod = "fallbackUser",
        threadPoolKey = "userThreadPool",
        threadPoolProperties = {
                @HystrixProperty(name = "coreSize", value = "30"),
                @HystrixProperty(name = "maxQueueSize", value = "10")
        }
)
public String getUserById(String id) {
    // 访问数据库处理
}

public String fallbackUser(String id){
    return "fall back user";
}

要注意的第一件事是， 我们在@HystrixCommand 注解中引入了一个新属性， 即threadPoolKey。这向 Hystrix 发出信号，我们想要建立一个新的线程池。如果在线程池中没有设置任何进一步的值，Hystrix 会使用threadPoolKey 属性中的名称搭建一个线程池，并使用所有的默认值来对线程池进行配置。

要定制线程池，应该使用@HystrixCommand 上的threadPoolProperties 属性。此属性使用HystrixProperty 对象的数组，这些HystrixProperty 对象用于控制线程池的行为。使用coreSize 属性可以设置线程池的大小。

开发人员还可以在线程池前创建一个队列，该队列将控制在线程池中线程繁忙时允许堵塞的请求数。此队列大小由maxQueueSize 属性设置。一旦请求数超过队列大小，对线程池的任何其他请求都将失败，直到队列中有空间。