Какой архитектуре Azure мне следует следовать, если моя функция web api / azure будет обслуживать большое количество запросов? - PullRequest
0 голосов
/ 01 ноября 2018

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

Я ищу реализацию архитектуры Azure, которая будет экономически эффективной и будет работать лучше при большом количестве запросов.

Любые предложения о том, какие компоненты Azure я могу использовать или какую архитектуру использовать.

1 Ответ

0 голосов
/ 01 ноября 2018

Больше подробностей и характеристик о рабочей нагрузке действительно необходимо, чтобы предложить какие-либо надежные предложения (например, интенсивно ли используется память, процессор? Зависит ли это от ресурсов ниже по течению и т. Д.). В зависимости от вашей рабочей нагрузки функции и \ или службы приложений могут не подходить.

На высоком уровне подумайте, возможен ли рефакторинг этого 10-минутного процесса. Много раз долго выполняющиеся задачи на самом деле представляют собой множество небольших задач, которые можно разбить на части, поэтому их индивидуальное время выполнения является разумным, и вы можете использовать аспекты масштабирования без сервера (функции Azure). Если это так, но разбить его слишком сложно, чтобы организовать его, подумайте об использовании чего-то вроде Durable Functions или Logic Apps, чтобы обеспечить эту оркестровку для вас.

Вообще говоря, если у меня есть длительные запросы, это обычно означает, что асинхронность с точки зрения пользователя не является проблемой, поэтому другой вариант заключается в том, чтобы Http Trigger (API) для функции Azure выполнялся в плане потребления, чтобы он будет масштабироваться по мере необходимости, и он принимает запрос и помещает его в очередь, но прослушиватель очереди находится на выделенных вычислениях без временных ограничений (например, функция в плане обслуживания приложения, экземпляры контейнера Azure и т. д.). Имейте в виду, что вы должны быть осторожны с длиной своей очереди, поскольку вы можете получить много запросов в своей очереди, но только ограниченные ресурсы для их обработки на выделенных вычислениях в течение приемлемого периода времени.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...