it-roy-ru.com

Azure Webjobs vs Azure Функции: как выбрать

Я создал несколько Azure Webjobs , которые используют триггеры, и я только что узнал о Azure Functions .

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

  • В отличие от Webjobs, функции могут запускаться только потому, что они не предназначены для запуска непрерывного процесса (но вы можете написать код для создания непрерывной функции).

  • Вы можете писать веб-задания и функции на многих языках (C #, node.js, python ...), но вы можете написать свою функцию на портале Azure, чтобы было проще и быстрее разрабатывать тестирование и развертывание функции. ,.

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

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

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

Есть ли другие соображения, которые нужно иметь в виду, когда вам нужно выбрать?

134
Thomas

В Службе приложений есть несколько вариантов. Я не буду касаться приложений логики или Azure Automation, которые также затрагивают это пространство.

Azure WebJobs

Эта статья честно лучшее объяснение, но я здесь подведу итоги.

По требованию WebJobs ака. Запланированные WebJobs ака. Триггерные веб-задания

Триггерные веб-задания - это веб-задания, которые запускаются один раз при вызове URL-адреса или когда свойство schedule присутствует в schedule.job . Запланированные веб-задания - это просто веб-задания, в которых создано задание планировщика Azure для вызова нашего URL-адреса по расписанию, но мы также поддерживаем свойство расписания, как упоминалось ранее.

Резюме:

  • + Исполняемый файл/скрипт по требованию
  • + Запланированные казни
  • - Должен запускаться через конечную точку .scm
  • - Масштабирование выполняется вручную
  • - VM всегда требуется

Непрерывные веб-задания (не SDK)

Эти работы выполняются вечно, и мы разбудим их, когда они рухнут. Вам нужно включить Always On, чтобы они работали, что означает запуск их на уровне Basic и выше.

Резюме:

  • + Исполняемый файл/скрипт всегда работает
  • - Требуется всегда - Базовый уровень и выше
  • - VM всегда требуется

Непрерывные WebJobs с SDK WebJobs

Это не что-то с точки зрения "WebJobs the feature". По сути, у нас есть этот замечательный SDK, который мы написали для WebJobs, который позволяет выполнять код на основе простых триггеров. Я расскажу об этом позже.

Резюме:

  • + Исполняемый файл/скрипт всегда работает
  • + Richer logging/dashboard
  • + Триггеры поддерживаются наряду с длительными задачами
  • - Требуется всегда - Базовый уровень и выше
  • - Масштабирование настраивается вручную
  • - Начало работы может быть немного утомительным
  • - VM всегда требуется

Azure WebJobs SDK

Azure WebJobs SDK - это совершенно отдельный SDK от WebJobs, который является платформой. Он предназначен для запуска в WebJob, но действительно может быть запущен где угодно. У нас есть клиенты, которые выполняют их на рабочих ролях и даже на прем-или других облаках, хотя поддержка - только лучшее усилие.

SDK позволяет просто запускать некоторый код в ответ на какое-либо событие и связывать его со службами и т.д. легко. Честно говоря, это лучше всего описано в некоторых документах , но суть в том, что природа "событие" + "код". Мы также проделали отличную работу по расширению, но это вторично по отношению к основной цели.

Резюме:

  • Большинство из них упомянуты выше
  • + Вы можете расширять и запускать все, что вы хотите. Полный контроль.
  • - HTTP материал немного шаткий, но работает

Функции Azure

Функции Azure - это основная цель SDK WebJobs, размещение его в качестве службы и упрощение работы с другими языками. Мы также представляем здесь концепцию "без сервера", потому что это имело большой смысл - мы знаем, как масштабируется наш SDK, поэтому мы можем сделать интеллектуальные вещи для вас.

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

Большинство "каркасных" вещей, которые мы сделали для улучшения функций, проходят через WebJobs SDK. Например, мы будем загружать новый NuGet для WebJobs, который действительно значительно увеличивает скорость ведения журнала, что дает огромные преимущества для пользователей WebJobs SDK. В функции доставки как "WebJobs SDK как услуга" мы действительно исправили множество проблем с опытом.

  • + Поддерживается множество языков
  • + Полностью управляемое динамическое масштабирование
  • + Простой в использовании портал с UX для управления соединениями и т. д.
  • - Хост не настраивается (пока)
  • ~ Запускается в отдельном "приложении", которое требует определенной настройки в вашем репо, но значительно облегчает долгосрочное обслуживание.
  • ~ Нет инструментов (пока) Некоторые инструменты теперь доступны в альфа-версии или в режиме предварительного просмотра - https://www.npmjs.com/package/azurefunctions (обновление, февраль 2017 г .: инструменты Visual Studio для функций Azure теперь доступны в режиме предварительного просмотра: https : //blogs.msdn.Microsoft.com/webdev/2016/12/01/visual-studio-tools-for-Azure-functions/ )

Я, вероятно, предвзят, так как Functions - наша последняя и самая лучшая программа, но не стесняйтесь делать больше минусов для Functions.

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

151
Chris Anderson-MSFT

Будучи функциями Azure, основанными на SDK WebJobs, они предоставляют большую часть функциональности, уже доступной в WebJobs, но с некоторыми новыми интересными возможностями.

С точки зрения триггеров , в дополнение к тем, которые уже доступны для WebJobs (например, служебная шина, очереди хранения, BLOB-объекты хранения, расписания CRON, WebHooks, EventHub и Поставщики файлового облачного хранилища), функции Azure могут запускаться как API. HTTP-вызовы не требуют учетных данных kudu, но могут проходить проверку подлинности через Azure AD и сторонние поставщики удостоверений.

Что касается выходов , единственное отличие состоит в том, что функции могут возвращать ответ при вызове через HTTP.

Оба поддерживают большое разнообразие языков , в том числе: bash (.sh), batch (.bat/.cmd), C #, F #, Node.Js. , PHP, PowerShell и Python.

Будучи функциями в настоящее время в режиме предварительного просмотра, набор инструментов все еще не идеален. Но Microsoft работает над этим. Надеемся, что мы получим ту же гибкость разработки и тестирования локальных функций, что и в настоящее время для WebJobs с Visual Studio.

Наиболее существенные и интересные преимущества, предоставляемые функциями, - это наличие динамического плана обслуживания с "Безсерверным". модель , в которой нам не нужно управлять VM экземплярами или масштабированием; это все удалось для нас. Кроме того, не имея выделенных экземпляров, мы платим только за те ресурсы, которые фактически используем.

Более подробное сравнение между ними здесь: https://blog.kloud.com.au/2016/09/14/Azure-functions-or-webjobs/

HTH :)

16
Paco de la Cruz

Согласно docs функциям Azure есть следующее, чего нет у WebJobs:

  • Автоматическое масштабирование (ЦП и память масштабируются в соответствии с потребностями, определенными во время выполнения)
  • Плата за использование (план потребления вместо плана обслуживания приложения)
  • Больше триггерных событий (например, WebHooks)
  • Разработка в браузере (Visual Studio все еще возможна)
  • Поддержка F #

Проще говоря: Azure Functions - более новое животное. Если у вас еще нет плана службы приложений, я бы пошел с функциями, потому что в долгосрочной перспективе я не вижу причин, по которым начинать с WebJobs было бы лучше (хотя инструментальная функция может быть не столь стабильной).

12
user764754

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

Если вы хотите выполнять какие-либо задания более 10 минут, выберите веб-задания. Функции Azure, по умолчанию запускаются только на 5 минут, если ваш процесс превышает 5 минут, то функция Azure выдает исключение тайм-аута. Вы можете увеличить время ожидания до 10 минут в Host.json.

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

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

8
Karthikeyan VK

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

Если вам абсолютно необходимо то, что работает "бесплатно" (без дополнительных затрат по сравнению с тем, что вы уже заплатили за свое веб-приложение), тогда у вас есть два варианта:

  1. Веб-задания - развертываются вместе с существующим веб-приложением и используют те же ресурсы, что и ваше веб-приложение. Для использования веб-заданий не требуется никаких дополнительных денежных затрат, но есть уже упомянутые ограничения, которые могут привести к снижению производительности вашего веб-приложения.
  2. Функции - при использовании плана потребления вам предоставляется определенное количество бесплатных казней. Количество на момент написания этой статьи на самом деле довольно высокое, 1 миллион бесплатных казней. Тем не менее, ограничение в 1 миллион не является пределом, который может создать вам проблемы; это 400K ГБ-с (гигабайтные секунды). По сути, это подсчет объема памяти, используемой вашей функцией, умноженный на количество секунд, в течение которых она работает (см. Официальный расчет на страница с ценами здесь ). Вы будете удивлены, как быстро это бесплатное выделение будет использовано.

Если вы обеспокоены расходами, но не ограничены никакими расходами , у вас есть больше вариантов.

  1. Функции - Вы можете запустить либо в плане потребления, либо в плане обслуживания приложения по относительно недорогой цене. Имейте в виду, однако, модель биллинга Великобритании. Если вы используете план потребления и выполняете частую, "тяжелую" работу - вас может удивить большой счет.
  2. Облачные сервисы - этот вариант не обсуждался как альтернатива, главным образом потому, что ОП не спрашивал об этом. Но это тоже жизнеспособный вариант. Облачные сервисы - это, в конечном счете, просто виртуальные машины, работающие в облаке, так что вы можете запускать на них любые фоновые задания, которые вам нужны, и они довольно хорошо масштабируются (хотя вам приходится подключать собственные триггеры для выполнения, небольшое неудобство по сравнению с веб-заданиями/функциями). ). С ними связана большая начальная стоимость (потому что вы платите за экземпляр независимо от того, используете вы ее или нет), но если у вас есть задания, которые должны выполняться постоянно и выполняющие много "тяжелых" работ, то облачные службы могут быть лучшим выбором. потому что проще, по моему мнению, управлять/контролировать VM с фиксированной ценой, чем выполнение и гигабайтные секунды. Еще одна приятная вещь в облачных сервисах заключается в том, что вам никогда не придется беспокоиться о тайм-аутах или некоторых других ограничениях, упомянутых в предыдущих ответах.

Если вы заинтересованы в чтении некоторых конкретных сценариев и почему я бы выбрал один (веб-задания, функции, облачные сервисы) вместо другого, я только недавно написал сообщение в блоге на веб-работа против функций против облачных сервисов .

3
Dan