TL; DR. Недавно я посетил обзор дизайна, где мне показалось, что повторение вызовов API - это обычная хорошая практика. В этой короткой статье я хочу объяснить, почему этот подход всегда следует ставить под сомнение и как этот подход может привести к серьезному отключению всего вашего стека.
При разработке компонента в распределенной системе я всегда задаю вопрос, когда кто-то упоминает свой подход к повторной попытке:
«Что является корневой службой в этой цепочке вызовов?»
Есть 3 возможных ответа:
- Я не знаю (никогда не бывает хорошего ответа)
- Моя служба - это корневая служба
- Другая служба - это корневая служба
Если вы слепо реализуете повторные попытки для своих зависимостей, единственный приемлемый ответ здесь - 2. Это означает, что ваша служба инициирует цепочку вызовов и должна управлять политикой повторных попыток.
«Что плохого в повторной попытке, если я не являюсь корневой службой?»
Объясню на примере.
Предположим, у вас есть 3 службы, в которых A вызывает B, а B вызывает C (см. Диаграмму выше).
Предположим также, что в службе C возникают внутренние ошибки.
Служба C - это фактически парк из 5 машин за балансировщиком нагрузки, и каждая машина может обслуживать 5 вызовов API в секунду. Таким образом, в целом полнофункциональный парк может обслуживать 25 запросов в секунду.
Что произойдет, если служба A вызовет службу B, которая вызывает C, и вызов завершится неудачно из-за внутренней ошибки в C? Предположим, что и A, и B реализовали стратегию пяти человек. Теперь A будет повторять 5 попыток, а B будет повторять 5 попыток для каждого вызова от A. Вы видите, к чему это идет?
Давайте посмотрим на поток событий:
- A вызывает B, и вызов не выполняется
- A 5 попыток
- B вызывает C, и вызовы не выполняются
- B повторяет 5x5 раз (5 раз для каждого вызова от A)
- C пытается восстановить и скрыть
Служба A повторит попытку 5 раз, для каждого из этих вызовов B повторит попытку 5 раз. Это добавляет до 25 вызовов C, который даже не может восстановиться после сбоя, потому что мы продолжаем забивать его большим количеством повторных попыток. Неизбежно вы получите отключение службы C.
Когда парк службы C пытается восстановиться, он запускает 1 машину, которая может принимать 5 вызовов, и немедленно отключается, потому что она обрабатывается 25 вызовами службы B. И цикл продолжается и продолжается до тех пор, пока весь ваш стек не станет коричневым. -вне.
Итак, к чему вы пришли, доктор Ватсон?
Если у вас распределенная система и ваша служба находится в середине цепочки вызовов, вам следует дважды подумать, прежде чем автоматически повторять неудавшиеся вызовы.
Шонн.
