Resilience4j — это легкая и простая в использовании отказоустойчивая библиотека, вдохновленная Netflix Hystrix, но разработанная для Java 8 и функционального программирования. Легкий, потому что библиотека использует только Vavr, у нее нет других зависимостей от внешних библиотек. Напротив, Netflix Hystrix имеет одну зависимость компиляции от Archaius, которая имеет больше зависимостей от внешних библиотек, таких как Guava и Apache Commons.
Resilience4j предоставляет функции более высокого порядка (декораторы) для улучшения любого функционального интерфейса, лямбда-выражения или ссылки на метод, включая автоматические выключатели, ограничители скорости, повторные попытки или переборки. Несколько декораторов можно использовать в любом функциональном интерфейсе, лямбда-выражении или ссылке на метод. Преимущество заключается в том, что вы можете выбрать нужный декоратор, не нуждаясь ни в чем другом.
С Resilience4j вам не нужно изо всех сил, вы можете выбрать то, что вам нужно.
resilience4 на .readme.IO/docs/повседневная физическая энергия…
Обзор
В этой статье будут представлены четыре отказоустойчивых механизма в resilience4j, но, ввиду общности принципов отказоустойчивых механизмов, эти отказоустойчивые механизмы, введенные позже, могут существовать и независимо от resilience4j (вы можете написать их сами или использовать другие аналогичные сторонние библиотеки, такие какNetflix Hystrix). Далее будет пояснена переборка с легендой (Bulkhead), выключатель (CircuitBreaker), ограничитель скорости (RateLimiter),Повторить(Retry) Понятие и принцип работы механизма.
Переборка
Resilience4j предоставляет реализации двух шаблонов переборок, которые можно использовать для ограничения количества одновременных выполнений:
- SemaphoreBulkhead (переборка семафора, по умолчанию), основанная на реализации семафора в библиотеке параллелизма Java.
- FixedThreadPoolBulkhead (фиксированная переборка пула потоков), которая использует ограниченную очередь и фиксированный пул потоков.
SemaphoreBulkhead должен хорошо работать с различными моделями многопоточности и ввода/вывода. Он основан на семафорах и, в отличие от Hystrix, не предлагает вариант «теневого» пула потоков. Клиент должен убедиться, что правильный размер пула потоков будет соответствовать конфигурации переборки.
Семафорная переборка
Как показано на рисунке выше, когда семафор оставлен, запрос, поступающий в систему, напрямую получит семафор и начнет бизнес-обработку. Когда семафор полностью занят, следующий запрос переходит в состояние блокировки.SemaphoreBulkhead предоставляет таймер блокировки.Если запрос в состоянии блокировки не может получить семафор в течение таймера блокировки, система отклонит эти запросы. Если запрос получает семафор в течение времени блокировки, он напрямую получает семафор и выполняет соответствующую бизнес-обработку.
Фиксированная переборка пула потоков (FixedThreadPoolBulkhead)
Функция FixedThreadPoolBulkhead, как и SemaphoreBulkhead, также используется для ограничения количества одновременных выполнений, но существуют различия в принципах реализации этих двух функций и незначительные различия в производительности. FixedThreadPoolBulkhead использует фиксированный пул потоков и очередь ожидания для реализации переборки. Когда в пуле потоков есть бездействие, запрос, поступающий в систему в это время, будет напрямую поступать в пул потоков, чтобы запустить новый поток, или использовать незанятый поток для обработки запроса. Когда пул потоков освободится, следующий запрос войдет в очередь ожидания. Если в очереди ожидания по-прежнему нет свободного места, следующий запрос будет отклонен напрямую. Когда запрос в очереди ожидает, пока пул потоков станет бездействующим, он войдет в пул потоков для бизнес-обработки.
Можно увидеть, что очевидная разница между FixedThreadPoolBulkhead и SemaphoreBulkhead заключается в том, что FixedThreadPoolBulkhead не имеет концепции блокировки, а SemaphoreBulkhead не имеет ограничения емкости очереди.
Ограничитель скорости
Функция ограничителя скорости (RateLimiter) состоит в том, чтобы предотвратить перегрузку системы внезапными чрезмерными запросами. RateLimiter использует концепцию цикла обновления, чтобы ограничить максимальное количество запросов, которые могут быть обработаны в фиксированном цикле обновления. Если количество запросов в определенном цикле обновления достигло максимума, следующий запрос в этом цикле перейдет в состояние блокировки.Если новый цикл обновления открыт в течение максимального времени блокировки, запросы в заблокированном состоянии перейдут в новое состояние. цикл, подлежащий обработке. Если новый цикл обновления не запускается в течение таймера максимальной блокировки, те запросы, которые превышают таймер блокировки, будут отклонены напрямую.
автоматический выключатель
CircuitBreaker более сложен, чем предыдущие механизмы плавких предохранителей. CircuitBreaker обычно имеет три состояния (CLOSE, OPEN, HALF_OPEN) и записывает текущий процент успешных или медленных запросов через окно времени или количества, чтобы основываться на этих показателях. сделать правильный отказоустойчивый ответ.
Когда CircuitBreaker находится в состоянии CLOSE, запрос, инициированный клиентом, будет поступать в систему сервера в обычном режиме. CircuitBreaker рассчитает аномальную частоту (частоту отказов или медленную скорость) всех запросов в окне перед текущим запросом. Если аномальная скорость ниже чем ожидаемое значение конфигурации, система будет продолжать нормально обрабатывать последующие запросы. Когда частота исключений не ниже ожидаемого значения конфигурации, сервер перейдет в состояние OPEN и временно отклонит все запросы. После некоторого времени охлаждения (пользовательская конфигурация) сервер автоматически перейдет в состояние HALF_OPEN. В полуоткрытом состоянии сервер попытается принять определенное количество запросов (пользовательская конфигурация). Если частота исключений этого определенного количества запросов меньше, чем ожидалось, то сервер снова вернется в состояние CLOSE и обработает запрос в обычном режиме. Если частота исключений все еще выше, чем ожидалось, он будет продолжать возвращаться в состояние OPEN.
Повторить попытку
Механизм повторных попыток относительно прост. Когда сервер обрабатывает аномальные клиентские запросы, он включает механизм повторных попыток. В течение периода повторных попыток сервер повторяет обработку бизнес-логики через регулярные промежутки времени. Если услуга успешно обработана в течение максимального количества повторных попыток, повторная попытка будет остановлена, и обработка будет считаться успешной. Если бизнес-логика обработки по-прежнему не работает в течение максимального количества повторных попыток, система отклонит запрос в это время.
Суммировать
В этой статье представлены несколько часто используемых механизмов отказоустойчивости.Лучше удалить resilience4j напрямую, чем механизм отказоустойчивости в resilience4j, потому что видно, что принципы этих механизмов не только получены из определенной библиотеки или связаны только с конкретной библиотекой, это больше философия дизайна, универсальность которой должна быть межъязыковой. Кроме того, хотя в этой статье только представлены эти механизмы отказоустойчивости, их использование полностью зависит от ваших бизнес-сценариев и архитектуры. Вы даже можете использовать их в любой комбинации, иполностью невидимыйНеважно, какой механизм эти комбинации показывают в итоге, как их использовать и как их комбинировать, полностью зависит от технической/бизнес-среды, в которой вы находитесь.
🌟🌟🌟🌟🌟🌟🌟🌟🌟🌟🌟🌟🌟🌟🌟🌟🌟🌟
Добро пожаловать в блог автора:blog.dongxishaonian.tech
Подписывайтесь на официальный аккаунт автора и публикуйте различные оригинальные/качественные технические статьи ⬇️