Паттерн Bulkhead

Продолжаю читать статьи про паттерны отказоустойчивых приложений. На очереди — Bulkhead.

В микросервисной архитектуре один сервис может посылать запросы к множеству других сервисов. При этом каждый такой запрос расходует ресурсы — и зачастую неравномерно: к одному сервису может быть гораздо больше обращений, чем к другому.

А теперь представим, что этот популярный сервис дал сбой и стал очень долго отвечать. При этом запросы продолжают поступать, расходуя ресурсы. В конечном счёте это может привести к полному истощению ресурсов (например, исчерпается пул сетевых соединений). Соответственно, сервис не сможет обеспечивать другие функции.

⭐️ Интересные идеи

➡️ Bulkhead предлагает разделить инстансы на разные группы в зависимости от загрузки и требований к доступности. В таком случае мы изолируем падение одного из сервисов его группой — все остальные группы продолжают функционировать корректно.

➡️ Bulkhead защищает сервис от каскадирования сбоя: если не функционирует всего лишь одна группа, остальная часть работы сервиса продолжит выполняться.

➡️ Одного Bulkhead недостаточно — рекомендуется применять его вместе с Retry, Rate Limiter и Circuit Breaker.

➡️ Для разделения асинхронной коммуникации можно использовать разные очереди и разные consumer groups (что уже реализовано в Kafka).

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи