Ремень ГРМ спасет вашу архитектуру

Знаете, почему ремень ГРМ в автомобиле рвётся и причем тут наша архитектура? Ремень ГРМ специально сделан слабым звеном во всей работе двигателя. Его главная задача синхронизировать работу двигателя, чтобы клапаны открывались/закрывались в нужный момент. Если вдруг что-то заклинит, то порвется ремень, который стоит около $100, а не сломается двигатель за $10000. Это принцип "заранее подложенной подушки" из ТРИЗ, и ремень ГРМ в этом принципе называют "Жертвенный элемент". В проектировании архитектуры есть очень похожий паттерн, который называется Circuit Breaker. Его идея заключается в том, что он берет на себя эту самую роль "ГРМ ремня" в двигателе. Например: Представим, что наш сервис ходит в какой-то другой сервис (например, в API платёжки). Если платежный API начинает тупить или упал, что будет делать наш сервис: - Ждать ответа (timeout) - Блокировать потоки - Копить запросы - В итоге тоже упадет Circuit Breaker решает это так: Он следит за запросами и их успешностью.

Схема работы функции Circuit Breaker Наш сервис -> [Circuit Breaker] -> Платежный API

Circuit Breaker работает в 3 состояниях: 1. CLOSED (закрыт) - когда все ок - Запросы идут как обычно - Считаем количество ошибок 2. OPEN (открыт) - когда сервис сломался - Когда ошибок становится слишком много (например, 50% за минуту) - Circuit Breaker "размыкается" - перестает слать запросы - Сразу возвращается ошибка пользователю, не дожидаясь таймаута - Даёт внешнему сервису время восстановиться 3. HALF-OPEN (полуоткрыт) - проверка внешнего сервиса - Через N секунд пробует отправить пару запросов - Если успешно -> переходит в состояние CLOSED - Если опять ошибка -> обратно в OPEN И получается вот такая работа состояний: Нормальная работа (CLOSED) - Юзер жмет "оплатить" - Запрос идет через Circuit Breaker в платежный API - Всё ок, платеж проходит Платежный API упал (OPEN) - 10 запросов подряд вернули ошибку - Circuit Breaker "размыкается" - Следующие 100 запросов НЕ идут в API - сразу возвращается ошибка - Наш сервис не висит в ожидании, не копит очереди - А через 30 секунд пробует снова (это режим HALF-OPEN) Зачем это нужно: Без Circuit Breaker падение платежного API, может вызвать каскадное падение всей системы, если будет копиться очередь запросов, расти память и тд. А с Circuit Breaker отключается слабое звено системы, чтобы сохранить всю остальную функциональность в рабочем состоянии. Реализация этого паттерна есть в готовых библиотеках: Для Go: https://github.com/sony/gobreaker Для Node.js: https://github.com/nodeshift/opossum

Вывод: Не надо пытаться сделать все супер-надежным. Вместо этого можно определить "Жертвенные элементы" - что должно сломаться первым, чтобы спасти систему.

5/100 Telegram