[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-mikroservisy-chto-takoe-pattern-bulkhead":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":16,"progress":17,"seo":18},835,"chto-takoe-pattern-bulkhead",23,"mikroservisy","Микросервисы","🔗","Что такое паттерн Bulkhead?","Bulkhead (переборка) — это паттерн отказоустойчивости, изолирующий ресурсы для разных внешних вызовов, чтобы сбой одного компонента не исчерпал ресурсы для других.\n\n> Аналогия из жизни: корабль разделён на водонепроницаемые отсеки (bulkheads). Если один отсек затоплен, другие остаются сухими и корабль не тонет.\n\n### Проблема без Bulkhead\n\n```\nБез Bulkhead:\n┌──────────────────────────────────┐\n│ Thread Pool (20 потоков)         │\n│ [customer] [customer] [customer] │ ← все потоки заняты зависшим\n│ [customer] ... нет потоков для   │   customer-service\n│ payment или notification!        │\n└──────────────────────────────────┘\n\nС Bulkhead:\n┌──────────────┐ ┌──────────────┐ ┌──────────────┐\n│ Customer Pool│ │ Payment Pool │ │ Notif. Pool  │\n│ (5 потоков)  │ │ (10 потоков) │ │ (5 потоков)  │\n│ [зависли]    │ │ [работают]   │ │ [работают]   │\n└──────────────┘ └──────────────┘ └──────────────┘\n```\n\n### Два типа Bulkhead\n\n| Критерий | Thread Pool | Semaphore |\n|---|---|---|\n| Изоляция | Полная (отдельные потоки) | Частичная (общий пул) |\n| Overhead | Выше (переключение контекста) | Ниже |\n| Таймаут | Можно прервать поток | Нет контроля |\n| Подходит для | Медленные вызовы | Быстрые вызовы |\n\n\u003Cdetails>\u003Csummary>Thread Pool Bulkhead\u003C\u002Fsummary>\n\n```java\n@Service\npublic class PaymentService {\n\n    @Bulkhead(name = \"customerService\", type = Bulkhead.Type.THREADPOOL,\n              fallbackMethod = \"getCustomerFallback\")\n    public CompletableFuture\u003CCustomerDto> getCustomer(Long id) {\n        return CompletableFuture.supplyAsync(() -> customerClient.getCustomer(id));\n    }\n\n    private CompletableFuture\u003CCustomerDto> getCustomerFallback(Long id, Throwable t) {\n        log.warn(\"Bulkhead для customer-service полон: {}\", t.getMessage());\n        return CompletableFuture.completedFuture(CustomerDto.unknown(id));\n    }\n}\n```\n\n```yaml\nresilience4j:\n  thread-pool-bulkhead:\n    instances:\n      customerService:\n        maxThreadPoolSize: 5\n        coreThreadPoolSize: 3\n        queueCapacity: 10\n        keepAliveDuration: 60s\n      paymentGateway:\n        maxThreadPoolSize: 10\n        coreThreadPoolSize: 5\n        queueCapacity: 20\n```\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\u003Csummary>Semaphore Bulkhead\u003C\u002Fsummary>\n\n```java\n@Bulkhead(name = \"customerService\", type = Bulkhead.Type.SEMAPHORE)\npublic CustomerDto getCustomer(Long id) {\n    return customerClient.getCustomer(id);\n}\n```\n\n```yaml\nresilience4j:\n  bulkhead:\n    instances:\n      customerService:\n        maxConcurrentCalls: 5\n        maxWaitDuration: 500ms\n```\n\n\u003C\u002Fdetails>\n\n### Комбинация паттернов отказоустойчивости (порядок имеет значение!)\n\n```\nЗапрос → Bulkhead → CircuitBreaker → Retry → Timeout → Вызов сервиса\n```\n\n> **На собеседовании:** объясните через аналогию с кораблём и покажите, что понимаете разницу между Thread Pool и Semaphore Bulkhead. Ключевой вопрос: почему Bulkhead стоит перед Circuit Breaker в цепочке — потому что он ограничивает количество одновременных вызовов ещё до проверки circuit breaker.","","middle",[15],"microservices",[],null,{"title":19,"description":20,"ogTitle":19,"ogDescription":21,"keywords":22,"schemaAnswer":23,"featuredSnippetReady":24},"Что такое паттерн Sidecar? — Gymterview","Sidecar — это паттерн развёртывания, при котором вспомогательный контейнер работает рядом с основным сервисом в одном pod'е (в Kubernetes) и берёт на себя сквоз","Sidecar — это паттерн развёртывания, при котором вспомогательный контейнер работает рядом с основным сервисом в одном po",[15,13],"Sidecar — это паттерн развёртывания, при котором вспомогательный контейнер работает рядом с основным сервисом в одном pod'е (в Kubernetes) и берёт на себя сквозные задачи: проксирование трафика, логирование, мониторинг, безопасность.",true]