Bulkhead

Паттерн bulkhead: изоляция пулов и квот, чтобы один сценарий или арендатор не устроил каскадный отказ соседям.

Bulkhead — паттерн надёжности: изоляция runtime (пулы, лимиты, очереди), чтобы один сценарий или арендатор не устроил каскадный отказ остальным.

На каком слое надёжности работает «Bulkhead»

Изоляция runtime: отсеки ресурсов (пулы, лимиты, очереди).

Какой отказ моделирует паттерн «Bulkhead»

один класс нагрузки или арендатор исчерпывает общий пул потоков, соединений, воркеров — соседние сценарии встают, хотя их зависимости живы.

Что изолирует «Bulkhead» и где кончается радиус взрыва

радиус взрыва внутри процесса или узла: отсек A может умереть по таймаутам, отсек B продолжает брать свою квоту. Не спасает от смерти всей машины — тогда смотрите запасной контур.

Когда паттерн «Bulkhead» применять нельзя

если отсеков столько, сколько методов API, получите простой и голодание мелких отсеков. Нельзя считать bulkhead «ещё одним ретраем». Не подменяет сагу.

Что записать в архитектурное решение (ADR) про «Bulkhead»

по какому признаку режете (зависимость, арендатор, критичность), чем измеряете ёмкость отсека, что видит клиент при отказе отсека (быстрый отказ, не очередь без конца).

Оценка качеств «Bulkhead»: масштабируемость, надёжность, сопровождение

Звёзды — ориентир автора сайта, не бенчмарк и не сравнение продуктов.

  • масштабируемость: ⭐⭐⭐ (3/5)
  • надежность: ⭐⭐⭐⭐⭐ (5/5)
  • сопровождение: ⭐⭐⭐⭐ (4/5)

Варианты протокола «Bulkhead» и как выбрать

  • Пул на зависимость: отдельный лимит исходящих вызовов к сервису платежей vs к каталогу.
  • Пул на арендатора / SLA: шумный сосед не забирает квоту критичного сценария.
  • Отсек на уровне исполнения (воркеры очереди, cgroup): тот же смысл, другой движок.

Схема взаимодействия: как работает «Bulkhead»

sequenceDiagram
    participant Клиент
    participant ОтсекА
    participant ОтсекБ
    Клиент->>ОтсекА: сценарий А
    Клиент->>ОтсекБ: сценарий Б
    ОтсекА--xОтсекА: пул исчерпан
    ОтсекБ-->>Клиент: ответ Б жив
взять_слот(отсек):
    если отсек.занято >= отсек.лимит:
        отказать_быстро()
    иначе:
        выполнить_в_отсеке()

Типичные ошибки при внедрении «Bulkhead»

  • Один общий пул на все исходящие вызовы — имя «bulkhead» в слайдах, каскад в проде.
  • Отсек без быстрого отказа: очередь растёт, изоляции нет.
  • Лимит скопирован с ретрая: «три потока и три повтора» без модели отказа.

С какими паттернами не путать «Bulkhead»

  • Sidecar — вынос прокси в соседний процесс; отсеки всё равно нужно задать, иначе sidecar делит ту же судьбу, но не квоты сценариев.
  • Ретрай с задержкой (Retry with delay) — пауза вызова; без отсека ретраи забивают общий runtime.
  • Резервирование — второй контур, когда отсек и узел уже не при чём.

Источники для сверки формулировок про «Bulkhead»

Именованной страницы Bulkhead у российских облаков нет. Сверка: Azure Architecture Center: Bulkhead.

Частые вопросы про «Bulkhead»

Что изолирует паттерн bulkhead?

Квоты runtime: пулы потоков, соединений, воркеров. Один сценарий или арендатор не должен исчерпать общий пул и уронить соседей.

Заменяет ли bulkhead sidecar?

Нет. Sidecar — соседний процесс. Без квот отсеков sidecar делит ту же судьбу, но не режет сценарии.

Какая типичная ошибка bulkhead?

Один общий пул на все исходящие вызовы или отсек без быстрого отказа, когда очередь растёт бесконечно.