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

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

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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

Azure WebJobs

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

По запросу WebJobs aka. Запланированные WebJobs aka. Triggered WebJobs

Triggered WebJobs - это WebJobs, которые запускаются один раз при вызове URL-адреса или когда свойство расписания

Резюме:

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

Azure WebJobs SDK

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

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

Резюме:

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

Функции лазера

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

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

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

+ Поддерживается множество языков. + Полностью управляемое динамическое масштабирование + Простой в использовании портал w/UX для управления соединениями и т.д. - Хост не настраивается (пока) ~ Работает в отдельном "приложении", которое требует некоторой конфигурации в вашем репо, но упрощает долгосрочное обслуживание. ~ Нет инструментов (пока) Некоторые инструменты теперь находятся в альфа или превью - (обновление февраль 2017: Инструменты Visual Studio для функций Azure теперь доступны в предварительном просмотре: )

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

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

Ответ 2

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

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

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

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

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

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

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

HTH:)

Ответ 3

В соответствии с docs Функции Azure имеют следующее, что WebJobs не делает:

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

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

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

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