使用Resilience4J实现断路器模式

19-06-22 banq
                   

断路器是一种模式,可以防止整个架构中单个微服务的故障级联,从而确保系统具有弹性。该模式可以通过像Hystrix或Resilience4j这样的代码库实现,或者通过底层基础设施来实现,例如使用Istio。

Hystrix vs. Resilience4j简介

Hystrix是Netflix提供的一个开源库,旨在提高分布式系统的弹性,使HTTP请求在其分布式组件之间进行通信。它通过实现断路器模式实现。

Resilience4J是一个受Hystrix启发的独立库,它建立在功能编程的原理之上。两者之间最显着的区别在于,虽然Hystrix采用面向对象的设计,其中对外部系统的调用必须包含在HystrixCommand提供多种功能中,但Resilience4J依赖于函数组合来让您堆叠所需的特定装饰器。

那些装饰器当然包括断路器,还包括速率限制器,重试和隔板。这些装饰器可以同步或异步执行,充分利用Java 8中引入的lambda。

Resilience4J的其他优点包括更精细的配置选项(例如,关闭断路器模式所需的成功执行次数)和更轻的依赖性足迹。

Java中的函数编程简介

函数组合背后的想法是:

  • 如果函数f被定义为Function<X, Y>- 将类型X作为输入并返回类型的函数Y
  • 如果函数g定义为Function<Y, Z>
  • 然后可以将新函数h定义为Function<X, Z>组成函数f和g

Java 8在其API中引入了函数编程(FP)的一些方面。上面的函数组合可以在Java中翻译:

public class F implements Function<Integer, Integer> {

    @Override
    public Integer apply(Integer x) {
        return x + 1;
    }
}

public class G implements Function<Integer, Integer> {

    @Override
    public Integer apply(Integer y) {
        return 2 * y;
    }
}

public class H implements  Function<Integer, Integer> {

    @Override
    public Integer apply(Integer x) {
        var f = new F();
        var g = new G();
        Integer y = f.apply(x);
        return g.apply(y);
    }
}

这非常麻烦,因为Java最初设计时考虑了面向对象编程(OOP)。

一切都需要属于一个类,即使这没有多大意义。因此,为了弥合OOP和FP之间的这种差距,并使FP代码更容易编写,Java 8带来了函数接口的概念:功能接口是一个带有单个抽象方法的接口,并且可选择带注释@FunctionalInterface。

可以使用lambda表示法以简化的方式编写任何功能接口。例如,Function<T, V>是一个函数接口,因为它有一个抽象方法 - apply()。因此,可以使用lambdas重写上面的代码:

Function<Integer, Integer> h = x -> {
    Function<Integer, Integer> f = y -> y + 1;
    Function<Integer, Integer> g = y -> y + 1;
    return g.apply(f.apply(x));
};

FP的另一个基础是高阶函数。这只意味着函数是类似于任何其他类型的函数,并且可以作为函数中的参数传递,并作为结果返回。

例如,Functioninterface定义以下方法:

default <V> Function<T, V> andThen(Function<? super R, ? extends V> after) {
    Objects.requireNonNull(after);
    return (T t) -> after.apply(apply(t));
}

使用这种方法,我们可以简单地重写h函数:

var h = f.compose(g);

Resilience4J完全基于函数式编程,并且使用了很多公开的概念。重要的是要记住从Hystrix迁移,因为与通常的Java思维方式相比,这需要进行更改。

Resilience4J入门

HTTP调用可以被认为是一个函数:它接受HTTP请求作为输入,并返回HTTP响应。

同样,Circuit Breaker可以被认为是一个函数,输入相同的HTTP请求,返回值如果调用成功则返回HTTP响应,如果失败则返回默认HTTP响应。

因此,使用断路器就像用第二个“断路器”函数组成第一个“调用”函数。

这是一个示例,用于说明如何使用它:

public class Command {
    public Long run() {
        // Does the actual job of making the HTTP request
    }
}

var cb = CircuitBreaker.ofDefaults("circuit-breaker");
var result = cb.executeSupplier(new Command()::run);

因为Resilience4J中的每个特征都被建模为一个函数,所以组合这些特征只需要应用上述的函数组合原理。

这相当于面向对象编程中的Decorator模式:目标被“包装”到装饰器对象中。

在这里,我们应用此设计来组成三个函数调用。第一个调用HTTP端点,第二个调用Circuit Breaker,第三个调用,如果调用失败则重试。

var cb = CircuitBreaker.ofDefaults("circuit-breaker");
var retry = Retry.ofDefaults("retry");
var cbSupplier = CircuitBreaker.decorateSupplier(cb, new Command()::run);
var retrySupplier = Retry.decorateSupplier(retry, cbSupplier);
var result = retrySupplier.get();

自定义缓存装饰器

使用Resilience4J实现缓存功能,我们的要求是:只有在修饰函数调用失败时才应从缓存返回。设计我们自己的缓存实现功能非常简单。“函数”这个词很重要,因为根据Resilience4J的设计原则,状态 - 缓存 - 应该是外部的并传递给函数以保持其纯净。为了简化实现,缓存将保留一个值,当装饰函数成功返回时,可能会替换该值:

public class Cache<T> {

    private T value;

    static <T> Supplier<T> decorateSupplier(Cache<T> cache, Supplier<T> supplier) {
        return Try.ofSupplier(supplier)
                .fold(
                        throwable -> () -> cache.value,
                        value -> {
                            cache.value = value;
                            return () -> value;
                        });
    }
}

本Try类来自于Vavr库,函数编程API的Java语言和Resilience4J唯一的依赖。它需要两个lambdas:

  • 第一个接受一个 Throwable并返回一个返回结果的函数
  • 第二个接受该值,并返回一个返回结果的函数

请注意,两者都是惰性的:它们不直接返回结果,而是返回Supplier结果。使用此自定义缓存,现在可以装饰Circuit Breaker调用,以便在电路打开时返回缓存值:

var cb = CircuitBreaker.ofDefaults("circuit-breaker");
var cache = new Cache<Long>();
var cbDecorated = CircuitBreaker.decorateSupplier(cb, new Command()::run);
var cacheDecorated = Cache.decorateSupplier(cache, cbDecorated);
cacheDecorated.get();