Fault Tolerance

В архитектуре микросервисов сервисы образуют сеть распределенных сетевых вызовов. Хотя это позволяет командам самостоятельно создавать и масштабировать сервисы, это также означает, что общая надежность вашей системы зависит от ее самого слабого звена. Если критически важная служба выходит из строя или перестает отвечать на запросы, это может вызвать каскадный сбой, который нарушит работу всего приложения. Возврат пользователям общего сообщения «500 Internal Server Error» или пустой страницы в момент сбоя одной зависимости — это плохой пользовательский опыт. Вместо этого устойчивые системы созданы для того, чтобы плавно деградировать, когда что-то идет не так.

В архитектуре микросервисов службы взаимодействуют по сети, а не через вызовы в памяти. Хотя такое разделение обеспечивает масштабное горизонтальное масштабирование и независимое развертывание, оно также создает серьезную уязвимость: сеть ненадежна. В любой момент у нижестоящей службы может возникнуть кратковременный сбой в сети, временный скачок ЦП, быстрый конфликт блокировки базы данных или перезапуск обновления. Эти временные сбои известны как переходные сбои.

В архитектуре микросервисов одно приложение разбивается на десятки или сотни независимых взаимодействующих сервисов. Хотя такая конструкция улучшает модульность и масштабируемость, она также создает серьезный риск: сбой в одной службе может каскадно привести к выходу из строя всей системы. Если нижестоящая служба становится медленной или не отвечает на запросы, входящие запросы к вашим вышестоящим службам начнут накапливаться. Если все они используют одну и ту же память, процессор или пул потоков, медленная зависимость может быстро исчерпать все доступные ресурсы, что приведет к сбою всего вашего приложения.