Учитывая, что Hystrix переходит в режим обслуживания, я работаю над переносом (довольно большой) кодовой базы на Resilience4j.
Я активно использую следующий шаблон с Hystrix:
new HystrixCommand<SomeReturnValue>(DependencyKeys.DEPENDENCY) {
@Override
protected SomeReturnValue run() {
return someExpensiveCall();
}
}
.observe()
И я хочу воспроизвести некоторые функции Hystrix с помощью Resilience4j.
Пока у меня есть следующий синтаксис для подключения внешнего вызова:
resilience.single(DependencyKeys.DEPENDENCY, this::someExpensiveCall);
Где класс Resilience предоставляет метод single:
public <T> Single<T> single(ResilienceKey key, Callable<T> callable) {
return Completable.complete()
.subscribeOn(Schedulers.computation())
.observeOn(configuration.scheduler(key))
.andThen(Single.defer(() -> Single.fromCallable(callable)
.lift(CircuitBreakerOperator.of(configuration.circuitBreaker(key)))
.lift(RateLimiterOperator.of(configuration.rateLimiter(key)))
.lift(BulkheadOperator.of(configuration.bulkhead(key)))
))
.observeOn(Schedulers.computation());
}
Как это может больше походить на то, что вы получаете с Hystrix с точки зрения разрыва цепи и запуска кода в разных пулах потоков, но более разумным образом. Мне действительно не нравится начинать цепочку с Completable.complete() только для того, чтобы я мог форсировать observeOn до того, как фактический вызываемый объект будет обернут.




Думаю прямой замены HystrixCommand в Resilience4j нет.
Наиболее похожей вещью будет CircuitBreaker.decorateCompletionStage или CircuitBreaker.executeCompletionStage. Используя эти методы, вы можете украсить любой тип на CompletableFuture поставщика.
Другой вариант — полагаться на нашу интеграцию с различными асинхронными модулями, такими как rxjava2 или reactor.
И, конечно же, если ни один из этих вариантов вам не подходит, пожалуйста, не забывайте, что Resilience4j — это очень беспристрастная, модульная и компонуемая библиотека. Вы можете разместить наш автоматический выключатель в любой библиотеке на парадигме параллелизма, используя наши 3 метода самого низкого уровня:
CircuitBreaker.isCallPermittedCircuitBreaker.onErrorCircuitBreaker.onSuccessТо же самое относится и к другим нашим основным компонентам. Я надеюсь, что этот ответ поможет хотя бы немного. Если у вас есть другие вопросы, я буду рад помочь. Удачного взлома ?
Я ценю ответ! Я использую интеграцию rxjava2, операторы
.lift(CircuitBreakerOperator.of(configuration.circuitBreaker(key)))эффективно оборачивают отложенную асинхронную функцию. Я предполагаю, что вопрос, который я действительно задаю, таков: если предположить, что это работает, является ли это лучшей практикой с точки зрения RxJava2 и Resilience4j.