Когда ваши микросервисы начинают ссориться: как автоматические выключатели сохраняют спокойствие вашей системы Spring Boot

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

Вероятно, это повседневная жизнь микросервисной архитектуры без автоматических выключателей. В распределенном мире, созданном Spring Boot, службы каждый день совершают звонки и отправляют сообщения. В большинстве случаев все идет хорошо. Пока однажды один из сервисов не начал медленно отвечать или просто перестал отвечать из-за нагрузки на базу данных, колебаний сети или просто скрытой ошибки в коде.

Что произойдет в это время? Другая служба не знает, что это неправильно, и продолжает отправлять запросы. Запросы накапливаются в очередях, потоки заняты, а ресурсы постепенно исчерпываются. Сбой в обслуживании распространяется как инфекционное заболевание и в конечном итоге парализует всю систему. Это называется «эффект лавины» — звучит профессионально, но ощущается как технический кошмар.

Что такое автоматический выключатель?

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

Последующие запросы больше не отправляются в отказавшую службу, а быстро отклоняются или возвращается заранее заданный резервный ответ (резервный). Основной трафик системы защищен и ему больше не препятствует выход из строя ветки. Автоматический выключатель периодически выполняет проверку «полуразомкнутости», тайно пытаясь отправить один или два запроса целевой службе, чтобы проверить, восстановится ли она. В случае восстановления автоматический выключатель автоматически «замыкается», и движение возобновляется в обычном режиме.

Весь процесс не требует вмешательства вручную в три часа ночи. Это происходит автоматически, спокойно и рационально.

Почему это особенно необходимо проектам Spring Boot?

Потому что Spring Boot упрощает разработку микросервисов. Несколько строк аннотации, класс запуска и сервис онлайн. Это удобство также упрощает создание сложных сетей телефонной связи. Но обратная сторона удобства в том, что есть и более уязвимые ссылки.

Автоматический выключатель здесь выполняет не «функцию», а «устойчивое мышление». Он признает, что сбой неизбежен, и больше не гонится за иллюзией 100% доступности, а разрабатывает системы, которые по-прежнему могут поддерживать основные функции при возникновении частичных сбоев. Ваше приложение электронной коммерции, возможно, не сможет выполнять транзакции, когда платежная служба временно недоступна, но, по крайней мере, такие функции, как просмотр продуктов и добавление в корзины, все равно можно использовать. Вместо совершенно пустой страницы с ошибкой или длительного ожидания пользователи видят «Платежная система занята, повторите попытку позже».

существоватьмощностьЧто мы увидели в технической практике?

Несколько очень практичных изменений. Например, серверная система управления клиента изначально имела медленную реакцию на обслуживание заказов в период рекламной акции, из-за чего интерфейс управления полностью зависал, и служба поддержки клиентов не могла обрабатывать какие-либо запросы. После доступа к политике автоматического выключателя интерфейс управления автоматически блокирует некоторые неосновные запросы при высокой загрузке службы заказов и устанавливает приоритет обработки возврата и запросов клиентов. Интерфейс может быть немного медленнее, но он никогда не зависнет полностью.

Другой распространенный сценарий — вызовы сторонних API. Метеорологические службы, картографические службы, шлюзы SMS — это не те вещи, которые вы поддерживаете, но вы полагаетесь на них. Их нестабильность — это ваша нестабильность. Настройка автоматического выключателя позволяет установить четкий таймаут и количество отказов. Если сторонний сервис не соответствует требованиям, система автоматически переключается на кэшированные данные или статические значения по умолчанию вместо того, чтобы бесконечно ждать.

Как начать об этом думать?

Если вы еще этого не сделали, начните с одного из самых чувствительных сервисов. Спросите себя: если эта услуга будет работать медленно или неработоспособно, что пострадает? Какие сервисы, вызывающие его, следует защитить?

Сама конфигурация не сложная. В экосистеме Spring Boot существуют зрелые библиотеки для реализации шаблона автоматического выключателя. В основном вам нужно определиться с несколькими параметрами: сколько раз в течение определенного периода времени считается «сбоем»? После включения автоматического выключателя как часто вы пытаетесь проверить, восстановлено ли обслуживание? Что должен вернуть альтернативный ответ — простое сообщение об ошибке или немного устаревший, но пригодный к использованию набор кэшированных данных?

На эти решения не существует стандартных ответов, и это зависит от того, что может вынести ваш бизнес. Очевидно, что финансовые услуги и службы просмотра контента имеют разные допуски.

Постепенно вы обнаружите, что этот дизайн меняет образ мышления вашей команды. Все начали говорить о «границах отказа», а не только о «функциональных границах». Контракт между службами, помимо того, «что возвращать в случае успеха», также включает в себя «как обрабатывать сбой». Устойчивость системы вплетается в нее постепенно.

Скажите что-нибудь вроде отрывка из романа

В дата-центре поздно вечером регулярно мигают только индикаторы серверов. Служба A отправляет запрос службе B, как обычно. Но на этот раз ответа не последовало. Подожди, тайм-аут. Автоматический выключатель молча добавил галочку на свой счетчик. При пятом провале слегка "отскочил". Последующие запросы подобны потоку, встречающему шлюз и спокойно поворачивающему на другой путь. Никакой тревоги, никакой паники. Основной процесс продолжается, как ни в чем не бывало. Лишь небольшая заметка на диаграмме мониторинга фиксирует эту краткую изоляцию.

После рассвета инженер проверил журналы и обнаружил пиковую нагрузку ЦП службы B в этот период. Причина поломки была найдена и устранена. И когда все это происходит, большинство пользователей даже не замечают ничего необычного. Система позаботилась о себе сама.

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

Основанная в 2005 году,мощностьбыла посвящена профессиональному производителю компактных приводов со штаб-квартирой в Дунгуане, провинция Гуандун, Китай. Используя инновации в технологии модульных приводов,мощностьобъединяет высокопроизводительные двигатели, прецизионные редукторы и многопротокольные системы управления, обеспечивая эффективные и индивидуальные решения для интеллектуальных систем привода. Kpower предоставила профессиональные решения в области приводных систем более чем 500 корпоративным клиентам по всему миру, предлагая продукты, охватывающие различные области, такие как системы «умный дом», автоматическая электроника, робототехника, точное земледелие, дроны и промышленная автоматизация.