Эффективно ли асинхронное использование Google Cloud Tasks для вызова внутренней конечной точки Django (даже в WSGI)?
Я запускаю приложение Django в Google Cloud Run, используя настройки на основе WSGI по умолчанию (например, Gunicorn/ runserver для локального разработчика).
Чтобы избежать блокировки во время длительных операций, таких как вызовы сторонних API, я планирую использовать Google Cloud Tasks.
Текущий дизайн:
На конечную точку Django поступает запрос (например, веб-соединение или ping от внешней службы)
Вместо обработки запроса в режиме реального времени я ставлю в очередь облачную задачу
Эта задача отправляется в другую конечную точку Django в рамках той же службы, которая выполняет вызов стороннего API, используя данные, переданные в полезной нагрузке задачи
Это означает:
Я не собираюсь перекладывать работу на отдельный облачный сервис
Логика выборки по-прежнему является частью того же сервиса/контейнера Django, просто отделена задачей
Мой вопрос:
Позволяет ли эта настройка выполнять сторонний вызов эффективно асинхронно (т.е. не блокировать исходный запрос), несмотря на использование WSGI, а не ASGI или Celery?
При поиске я в основном вижу статьи и примеры, в которых облачные задачи используются для вызова отдельной облачной службы, а не другого внутреннего маршрута в том же приложении.
Является ли этот шаблон внутреннего вызова допустимым и масштабируемым в WSGI, или есть предостережения, о которых я должен знать?
Чтобы убедиться в правильности и возможности такой настройки, лучше всего проконсультироваться со специалистом по продажам Google Cloud. Они могут предоставить индивидуальные консультации и технические рекомендации, адаптированные к потребностям вашего приложения. Их информация может оказаться бесценной - от определения подходящих вариантов использования до эффективного управления будущими затратами на рабочую нагрузку.
Это немного зависит от того, что вы пытаетесь здесь не блокировать. Выполнение задачи займет одинаковое количество времени независимо от способа ее выполнения, поэтому клиент в любом случае не сможет воспользоваться результатом до тех пор, пока она не будет завершена.
Что, на мой взгляд, вам может понадобиться, так это способ для клиента быстро получить ответ на свой запрос, а не ждать завершения задачи, потому что клиент не заботится о результате и просто хочет инициировать процесс. Таким образом, вы действительно хотите, чтобы длительный процесс не блокировал ответ на первоначальный запрос. Если это так, то описанный вами шаблон должен работать нормально.
Этот шаблон хорошо сработал для нас в App Engine, где длительно выполняющиеся задачи запускались из исходного запроса клиента. Исходный запрос получал ответ, как только задача была создана с идентификатором задачи. Затем Cloud tasks отправляет запрос на давно работающую конечную точку в рамках того же приложения и записывает прогресс в хранилище данных. Cloud tasks не зависит от того, что оно вызывает, независимо от того, является ли это частью исходного приложения или нет, поэтому нет необходимости в дополнительном приложении или службе. Затем клиент может дополнительно запросить у конечной точки обновления статуса.
С точки зрения масштабирования сервера, запуск ASGI может позволить экземпляру обрабатывать больше запросов одновременно (особенно если они заблокированы сторонним API), что может снизить затраты. Но даже при использовании WSGI cloud run просто создаст больше экземпляров для обработки большего количества запросов. Другими словами, если бы вы использовали сервер ASGI и возвращали результат длительной операции в первом запросе, клиенту все равно пришлось бы долго ждать первого ответа, вы просто могли бы обрабатывать больше клиентов на экземпляр.