Катим в прод | Александр Калыргин
21.12 · ред.
Как не добивать систему и дать ей восстановиться ⚡️
Представим кейс. У вас есть сервис «Погода», который предоставляет открытый внешний API. Наступает день Х и на сервис возрастает нагрузка в 100 раз. Он начинает потреблять больше ресурсов не успевая обрабатывать все запросы клиентов. Когда ресурсы заканчиваются — сервис «падает». Теперь он будет доступен только после полной перезагрузки. Резкий наплыв клиентов возник из-за рекламы, которую сделали ваши маркетологи у знаменитого блогера. Вас никто не предупредил, поэтому сервис не был готов к такой нагрузке. Этот простой стоил больших денег, ведь платные клиенты не могли пользоваться вашим сервисом. Как можно было избежать сбоя? Вариантов много: выполнять операции асинхронно; оповестить команду и добавить мощностей; установить меньше лимиты на запросы и т.д. Мы рассмотрим паттерн Circuit Breaker, который позволит не усугубить ситуацию, когда сервису стало резко хуже. Если переводить дословно Circuit Breaker — это «автоматический выключатель». Принцип действия аналогичный: если сервис сталкивается с проблемой, этот паттерн отключает его от остальной системы, предотвращая дальнейшие ошибки и перегрузку. Circuit Breaker постепенно подключает сервис обратно по мере его восстановления. Circuit Breaker работает в нескольких состояниях 1️⃣ Закрыт ✅ — всё работает нормально. Все запросы доходят до контролируемого сервиса. 2️⃣ Открыт 🚫 — если сервис даёт слишком много ошибок (например, больше 50% неудачных попыток), Circuit Breaker блокирует дальнейшие запросы к нему. 3️⃣ Полуоткрыт 🔄 — Circuit Breaker разрешает делать запросы снова, чтобы проверить, восстановился ли сервис. Почему это важно Когда ваша система зависит от внешних сервисов, сбой в одном из них может вызывать серьёзные проблемы для всего процесса. Circuit Breaker позволяет предотвратить такие проблемы, быстро отключая неработающие компоненты и давая им время на восстановление, пока остальная часть системы продолжает работать. Когда использовать 1️⃣ в микросервисах, чтобы избежать зависания системы при недоступности одного из сервисов; 2️⃣ при работе с внешними API, которые могут временно не отвечать; 3️⃣ в системах с высокой нагрузкой для контроля доступа к ресурсам; 4️⃣ при выполнении долгосрочных операций, чтобы избежать повторных вызовов; 5️⃣ при взаимодействии с ненадежными ресурсами. Всё это позволит минимизировать риск каскадных сбоев и увеличить общую надежность системы. Мой телеграм канал
еще контент в этом сообществе
еще контент в этом соообществе
Катим в прод | Александр Калыргин
21.12 · ред.
войдите, чтобы увидеть
и подписаться на интересных профи