Является ли универсальный обработчик, указывающий на «авто», плохой идеей?

Question

В моем экземпляре практически отсутствует трафик, но у меня установлен экземпляр минимального простоя, равный 1. Я замечаю, что всякий раз, когда существует случайный URL-адрес (через какого-либо бота), к которому нет доступа, он считаетсядинамический запрос, так как мой обработчик catch all - auto. Это нормально, за исключением того, что я вижу эти 404 ошибки (404, потому что нет никаких обработчиков http, связанных с этими шаблонами URL, даже если yaml определяет шаблон перехвата всех), в результате чего экземпляр перезапускается. Зачем перезапускать экземпляр, если он сталкивается с 404 ошибками?

У меня все мои динамические обработчики следуют шаблону "/ api", а некоторые - нет. Таким образом, я могу явно перечислить все допустимые шаблоны и сопоставить их с автоматическим обработчиком. Будет ли это тогда рассматривать эти случайные ссылки как статические, но не присутствующие и выдавать ошибку 404 (с которой я в порядке)? Я хочу убедиться, что экземпляр не продолжает работать только из-за некоторых запросов румян.

Answer 1

Согласно документации, которая цитирует следующее:

"Когда экземпляр отвечает на запрос / _ah / start с кодом состояния HTTP 200–299 или 404, считается, что он запущен правильно и чтоон может обрабатывать дополнительные запросы. В противном случае App Engine отменяет экземпляр. Экземпляры с ручной настройкой масштаба перезапускаются немедленно, а экземпляры с базовой настройкой масштаба перезапускаются только тогда, когда это необходимо для доставки трафика. "

Более подробную информацию о том, какУправление экземплярами для среды Standard App Engine для Go 1.12 осуществляется по ссылке: https://cloud.google.com/appengine/docs/standard/go112/how-instances-are-managed

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

"Вторичная маршрутизация Если запрос соответствует части [YOUR_PROJECT_ID] .appspot.com имени хоста, но содержит имя службы, версии или экземпляра, который не существует, служба маршрутизируется по умолчанию. Вторичная маршрутизация не выполняетсяприменять к пользовательским доменам; запросы отправляются надля этих доменов будет показан код состояния HTTP 404, если имя хоста недопустимо. "

https://cloud.google.com/appengine/docs/standard/go112/how-instances-are-managed

Answer 2

Я только что провел локальный эксперимент (в настоящее время у меня нет быстро развертываемого игрового приложения), и, похоже, ваша довольно интересная идея может сработать.

Я заменил шаблон .*, ранее ловив всех отставшихи направив их в мой скрипт службы по умолчанию (я использую среду выполнения Python) с определенными шаблонами, затем добавил этот обработчик после всех остальных:

- url: /(.*)$
  static_files: images/\1
  upload: images/.*

Мой каталог images является реальным, содержит статические изображения (но для которого у меня уже есть другой обработчик с более конкретным шаблоном).

С этим на месте я сделал запрос к /crap и получил, как и ожидалось (нет файла images/crap):

ИНФОРМАЦИЯ 2019-11-08 03: 06: 02,463 module.py:861] default: «GET / crap HTTP / 1.1» 404 -

Я добавил запись вызовов ввызовы get() и dispatch() моего обработчика сценариев для подтверждения того, что они на самом деле не вызываются (регистрация запросов сервера разработки вызывает некоторые сомнения).

Я также проверил в уже развернутом приложении GAE, которое запрашиваетяmage, который соответствует шаблону статического обработчика, но который на самом деле не существует, получает ответ 404, не вызывая запуск экземпляра службы (в данный момент ни один экземпляр не был запущен), т.е. он поступает непосредственно из CDN статического содержимого GAE.

Так что я думаю, что стоит попробовать с средой выполнения go, это может сэкономить значительное время для приложения без особой активности, связанной со случайным трафиком бота.

Что касается перезапуска экземпляраЯ подозреваю, что то, что вы видите, является лишь симптомом вашего экземпляра min-idle, установленного в 1. В отличие от динамического экземпляра, экземпляр idle (aka resident) обычно не предназначен для обработки трафика, он просто готов сделать это, если / когда это необходимо. Только когда динамический экземпляр не запущен (и способен эффективно обрабатывать входящий трафик) и в него поступает новый запрос, этот запрос немедленно направляется в незанятый экземпляр. В этот момент:

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

Примечание: ваша идея поможет с частью часов экземпляра, используемой динамическими экземплярами, но не с частью экземпляра простоя.