Как заставить ваше приложение работать, когда все разваливается
В этом сообщении в блоге мы собираемся изучить один фактор, который может сделать интерфейсное приложение более стабильным, и понять, почему разработчики интерфейсного интерфейса должны не только заботиться о пользовательском интерфейсе, но и понимать важность устойчивости своего приложения и меры, которые поддерживают работу внешнего приложения, когда некоторые из компоненты системы выходят из строя.
Приложение Frontend - это не просто приложение для рендеринга пользовательского интерфейса
Я действительно вижу, что слишком многие разработчики внешнего интерфейса игнорируют тот факт, что приложение внешнего интерфейса на самом деле является серверной частью, которая обслуживает пользовательский интерфейс приложения и выполняет оркестровку служб. Понимание крайних случаев, которые могут произойти с приложением во время выполнения, и заблаговременное принятие мер безопасности для правильной обработки этих случаев повысит отказоустойчивость всей системы.
Мы собираемся рассмотреть одну из проблем, которые могут возникнуть с веб-интерфейсом, и способы ее решения. Если вам понравился этот пост, дайте мне знать, и последуют другие посты, посвященные другим крайним случаям, с которыми мы работали как команда платформы здесь, на eBay.
Когда последующее обслуживание перестает работать
Давайте возьмем упрощенное интерфейсное приложение node.js, которое вызывает одну службу, отображает страницу и отправляет ее обратно в браузер.
Если предположить, что наше веб-приложение хорошо написано, что может пойти не так? Что-либо!
Одним из примеров является то, что нижестоящая служба по какой-то причине становится медленной. Это может быть связано с проблемой емкости - центр обработки данных в одном регионе выходит из строя, емкость уменьшается, и потребуется некоторое время для восстановления или увеличения емкости. Внешнее приложение может долго ждать ответа службы; что, в свою очередь, создаст ситуацию, когда запросы начнут накапливаться в очереди входящего трафика, потребляя больше памяти с каждой секундой и еще больше замедляя работу вашего внешнего приложения, что в конечном итоге может привести к нехватке памяти или замедлению работы вмешательство путем перезапуска коробки или, что еще хуже, всей группы ящиков становится необходимым.
Мониторинг - это всегда хорошо и помогает в этом случае, но обычно уже поздно. Нам нравится автоматизировать процессы, добавляя в приложение самовосстановление, которое предотвратило бы описанную выше ситуацию.
Есть несколько популярных стратегий решения проблемы.
Использование тайм-аутов и повторных попыток
Общий подход заключается в использовании стратегии тайм-аута и повтора при вызове служб. Большинство разработчиков останавливаются на этом, в то время как решение все еще несет серьезные проблемы, если мы осмелимся смотреть дальше. Одна потенциальная проблема заключается в том, что это может привести к медленному отклику с сайта (общее время = тайм-аут * повторные попытки) и, следовательно, к негативным впечатлениям для пользователей сайта. Но это еще не все, это может не позволить нижестоящему сервису восстанавливаться быстрее из-за бомбардировки слишком большого количества запросов повторными попытками, особенно когда стратегия повторных попыток плохо спроектирована. Другими словами, наше приложение в этом случае не заботится о том, что оно делает с нижележащими сервисами.
Автоматический выключатель
Более продвинутый подход - использовать автоматический выключатель для сервисных вызовов. Автоматический выключатель может обнаруживать вышеупомянутые ситуации, отмечать путь и предотвращать медленное движение с быстрым откатом к другим службам, кешу или какой-либо специальной стратегии.
Поступая таким образом, мы можем не тратить время на ожидание тайм-аута, немедленно получить 503 от нашей службы и решить на стороне интерфейса, что делать дальше (использовать старый кеш, подождать и повторить попытку немедленно или использовать более продвинутый подход, такой как DNS браузера), в то же время разгрузить трафик с нашего сервиса и дать ему возможность быстрее восстановиться.
А зачем здесь останавливаться?
Бэкэнд также может применять ту же стратегию к входящему трафику, чтобы избежать бомбардировки запросами от внешних приложений, а также внешние приложения могут получить защиту от скачков трафика из внешнего мира. Единственная разница заключается в стратегии действий при активации запасного пути.
Здесь вы можете увидеть демонстрацию самовосстановления, когда загрузка ЦП становится слишком высокой для нашего приложения из-за слишком большого трафика.
Если теперь это имеет для вас смысл, вы можете перейти к более подробным и пространным прочтениям здесь, а также к описанной выше проблеме здесь.
