Резервирование в архитектуре решений — это failover, заранее подготовленный запасной контур. Страница разбирает паттерн надёжности: когда основной путь умер, а не когда зависимость «моргнула» на секунду.
На каком слое надёжности работает «Резервирование»
Запасной контур (failover). Речь про заранее подготовленный резервный путь, не про повтор того же вызова.
Какой отказ моделирует паттерн «Резервирование»
основной инстанс, зона или зависимость больше не может обслужить запрос (процесс умер, health check красный, зона недоступна). Это не краткий 503 «попробуйте ещё раз».
Что изолирует «Резервирование» и где кончается радиус взрыва
радиус простоя основного пути. Резерв принимает ту же работу. Соседние сценарии не обязаны знать, какой контур ответил, если контракт тот же.
Когда паттерн «Резервирование» применять нельзя
если отказ временный и тот же узел через секунду жив — это слой вызова (Ретрай с задержкой (Retry with delay)). Если «резерв» — ещё одна реплика для роста чтения, это масштабируемость, не этот ящик. Нельзя включать резерв, у которого нет своей ёмкости и проверки готовности: получите двойной отказ на холодном стенде.
Что записать в архитектурное решение (ADR) про «Резервирование»
зафиксируйте, что считается смертью основного пути, кто переключает (балансировщик, клиент, человек), RTO и что происходит с in-flight запросами.
Оценка качеств «Резервирование»: масштабируемость, надёжность, сопровождение
Звёзды — ориентир автора сайта, не бенчмарк и не сравнение продуктов.
- масштабируемость: ⭐⭐⭐ (3/5)
- надежность: ⭐⭐⭐⭐⭐ (5/5)
- сопровождение: ⭐⭐⭐⭐ (4/5)
Варианты протокола «Резервирование» и как выбрать
- Active-passive: резерв горячий или тёплый, трафик идёт на основной, пока проверка готовности не снимет его.
- Active-active с ручным/автоматическим выводом: оба контура принимают нагрузку; «резервирование» здесь — способность вывести контур, а не секретный второй сервер.
- Клиентский failover: клиент знает два адреса. Имеет смысл только если клиент умеет отличить смерть пути от прикладной ошибки.
Общее: переключение по состоянию цели, не по таймеру повторной попытки.
Схема взаимодействия: как работает «Резервирование»
sequenceDiagram
participant Клиент
participant Основной
participant Резерв
Клиент->>Основной: запрос
Основной--xКлиент: инстанс недоступен
Клиент->>Резерв: тот же запрос
Резерв-->>Клиент: ответесли цель_не готова(основной):
направить(запрос, резерв)
иначе:
направить(запрос, основной)Типичные ошибки при внедрении «Резервирование»
- Резерв никогда не прогревают и не проверяют — переключение в день аварии на пустой контур.
- Смешать failover и retry: долбить мёртвый инстанс «с задержкой», вместо того чтобы снять его из пула целей.
- Два контура без общего контракта: резерв отвечает «почти тем же» и ломает идемпотентность клиента.
С какими паттернами не путать «Резервирование»
- Ретрай с задержкой (Retry with delay) — тот же вызов к тому же (или любому живому) экземпляру после временного сбоя, без смены контура.
- Bulkhead — режет пулы, чтобы один сценарий не сожрал runtime; не поднимает второй контур.
- Сага (SAGA) — согласованность шагов бизнес-процесса, не доступность узла.
Источники для сверки формулировок про «Резервирование»
Пересказ своими словами, не цитата: в облачной практике отказ зоны и цели снимают с балансировки через health check, а не через надежду на повтор. Yandex Cloud — рекомендации по отказоустойчивости.
Частые вопросы про «Резервирование (failover)»
Когда нельзя применять резервирование (failover)?
Если отказ временный и тот же узел скоро снова жив — это слой вызова (retry). Если «резерв» — реплика для роста чтения, это масштабируемость. Нельзя включать контур без своей ёмкости и health check.
Чем failover отличается от retry with delay?
Failover меняет контур после смерти цели. Retry повторяет тот же запрос к живой (или той же) цели после короткого сбоя, без смены контура.
Что записать в ADR про резервирование?
Что считается смертью основного пути, кто переключает, RTO и что происходит с запросами in-flight.