Azure Webjobs vs Azure Functions: Як вибрати


163

Я створив кілька веб- завдань Azure, які використовують тригери, і я щойно дізнався про функції Azure .

З того, що я розумію, функції Azure начебто збігаються з функціями Azure Webjobs, і я маю певні труднощі зрозуміти, коли вибрати між функціями та веб-роботою:

  • На відміну від Webjobs, Функції можна запускати лише вони не розроблені для запуску безперервного процесу (але ви можете написати код для створення безперервної функції).

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

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

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

Так що, безумовно, є різниця в ціні, якщо у вас є вже наявний веб-додаток, ви можете використовувати його для запуску веб-роботи без додаткових витрат, але якщо у мене немає наявного веб-додатка, і мені потрібно написати код, щоб викликати чергу я повинен використовувати веб-роботу або функцію?

Чи є якісь інші міркування, які слід пам’ятати, коли потрібно вибирати?


6
Це повідомлення в блозі, якому я зобов'язаний. :) Я спробую підготувати відповідь, але це може бути трохи відкритим для Stack Overflow, тому вам може знадобитися запитати це на MSDN, якщо він закривається.
Кріс Андерсон-MSFT

Хороший (короткий) допис у блозі на цю тему geekswithblogs.net/tmurphy/archive/2016/06/02/…
Тодд

Ей, Тодде, сміливо редагуй моє запитання, щоб додати посилання. Цікава стаття ^^
Томас

@ chris-anderson-msft Чи можемо ми запустити PowerShell як webjob? Чи можемо ми встановити пакет PowerShell на Webjob?
anomepani

Відповіді:


170

Тут є кілька варіантів в рамках Служби додатків. Я не торкаюсь програм Logic Apps або Azure Automation, які також торкаються цього простору.

Azure WebJobs

Ця стаття є чесно найкращим поясненням, але я підсумую тут.

За запитом WebJobs ака. Заплановані WebJobs ака. Запущені WebJobs

Запущені WebJobs - це WebJobs, які запускаються один раз, коли викликається URL-адреса або коли властивість розкладу присутня у raspored.job . Заплановані WebJobs - це лише WebJobs, у яких була створена робота Azure Scheduler для виклику нашої URL-адреси за графіком, але ми також підтримуємо властивість розкладу, як згадувалося раніше.

Підсумок:

  • + Виконавчий / сценарій на вимогу
  • + Заплановані страти
  • - Потрібно запустити через .scm кінцеву точку
  • - Масштабування ручне
  • - ВМ завжди потрібен

Постійні веб-роботи (без SDK)

Ці роботи працюють вічно, і ми їх розбудимо, коли вони завершаться. Вам потрібно ввімкнути Always On, щоб вони працювали, а значить, запускати їх у базовому рівні та вище.

Підсумок:

  • + Виконаний / сценарій завжди працює
  • - Потрібно завжди ввімкнено - Основний рівень і вище
  • - ВМ завжди потрібен

Постійні WebJobs за допомогою SDK WebJobs

Це не що інше, з точки зору "функції WebJobs". По суті, у нас є цей солодкий SDK, який ми писали націляючи на WebJobs, який дозволяє виконувати код на основі простих тригерів. Про це я розповім пізніше.

Підсумок:

  • + Виконаний / сценарій завжди працює
  • + Багаті лісозаготівля / приладова панель
  • + Тригери підтримуються разом із тривалими завданнями
  • - Потрібно завжди ввімкнено - Основний рівень і вище
  • - Налаштування масштабування вручну
  • - Початок роботи може бути трохи стомлюючим
  • - ВМ завжди потрібен

Пакет SDK Azure WebJobs

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

SDK якраз полягає в тому, щоб легко запустити якийсь код у відповідь на якусь подію і зробити прив'язку до служб / тощо. легко. Це справді найкраще висвітлюється в деяких документах , але суть його полягає в тому, що "подія" + "код" характер. Ми також виконали кілька цікавих робіт з розширення можливостей, але це важливо для основної мети.

Підсумок:

  • Більшість із них згадані вище
  • +Ви можете розширити та запустити все, що завгодно. Повний контроль.
  • - HTTP матеріал трохи химерний, але він працює

Функції Azure

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

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

Більшість «рамкових» речей, які ми зробили для вдосконалення Функцій, проходять через SDJ WebJobs. Наприклад, ми будемо завантажувати новий NuGet для WebJobs, який дійсно різко збільшує швидкість ведення журналу, що має величезні переваги для клієнтів SDJ WebJobs. Перевіряючи функції "WebJobs SDK як послугу", ми дійсно покращили багато проблем із досвідом.

  • + Багато мов підтримуються
  • + Повністю кероване, динамічне масштабування
  • + Простий у використанні портал w / 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-функции / )

Я, мабуть, упереджений, оскільки "Функції" - це наше останнє і найбільше, але не соромтеся знімати більше мінусів для Функцій.

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


1
Звучить приголомшливо. Напишіть мені у Twitter (@crandycodes), якщо у вас виникнуть запитання. Я можу допомогти вам просувати ваші зразки на Azure.com, якщо ви хочете, якщо ви хочете поділитися ними.
Кріс Андерсон-MSFT

1
Я бачив, що це корисно. Я знаю, що є багато місця для обговорення способів переходу з серверного на безсерверний шаблон програми. Цей вид, здається, пов'язаний з тим, що ви тільки що описали.
Кріс Андерсон-MSFT

1
В основному, ми беремо ваш код і конфігурацію і створюємо функцію WebJob SDK (звідси назва Azure Functions) під обкладинками. Таким чином, ваш код працює всередині функції WebJob SDK, якою ми керуємо для вас.
Кріс Андерсон-MSFT

1
У кожному додатку функцій є 1 хост (який ви можете вважати WebJob). Ваші функції в додатку Function розділяють файлову систему, налаштування додатків, пам'ять, процесор тощо. Не соромтеся задати нове запитання.
Кріс Андерсон-MSFT

2
Так. Спусковий механізм таймера. Вираз крона
Кріс Андерсон-MSFT

17

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

Що стосується тригерів , окрім тих, які вже доступні для WebJobs (наприклад, службова шина, черги на зберігання, сховища блоків, графіки 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 :)


Дякую за Вашу відповідь Пако! Це порівняння може зацікавити багатьох людей :-) Але я не шукав порівняння, а просто намагався зрозуміти, коли мені слід працювати з функціями, а не веб-роботами!
Томас

6
Важко мати чітке керівництво, не знаючи контексту. Ось чому я вважав, що порівняння може допомогти людям у виборі :) Я б сказав це: if (((preference == "Serverless") || (isRequired(flexibleHttpTriggers)) && (isOk(currentFunctionsTooling))) { goWithFunctions(); } else { continueWIthWebJobs(); } :)
Пако де ла Крус

Функції можуть повернути відповідь при виклику через HTTP.But Функції засновані на SDK WebJobs. Дивно, чи не так?
RudyCo

Ймовірно , це краще сказати , що вони були засновані на WebJobs SDK, але вони розвивалися зовсім небагато від там :)
Пако де ла Круз

14

За документами Azure Functions має таке, що WebJobs не має:

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

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


14

Я хотів би додати ще два пункти до вищезазначених довгих і трохи старих публікацій. якщо ви вибираєте план споживання в блакитних функціях, нижче наведені обмеження

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

Примітка: Якщо ви користуєтеся функцією плану роботи програми, блакитний час не виникає.

Ще одна причина для розрізнення - це. якщо ви використовуєте функцію azure, то ваш початковий час запуску буде повільним, оскільки машини (контейнери) створюються на льоту та знищуються після його використання.

Щоб уникнути холодного старту, додаток функцій azure випустив преміальний план, де один екземпляр буде працювати весь час, і на основі завантаження додаток функції почне масштабувати, і ви будете виставляти рахунок за один екземпляр та інші екземпляри на основі споживання.


Перша ваша думка застосовується лише в тому, що ви використовуєте план споживання, при цьому платна сума у ​​вас немає обмеження на час очікування. Я погоджуюся з другим моментом.
Томас

Я думаю, що обидва пункти справедливі для плану споживання. Дякуємо, що вказали на це
Karthikeyan VK

4
Чудова згадка про тайм-аути. Для нас це важливий фактор
Niels Filter

1
Але ви можете вибрати план програми, створюючи блакитні функції. Але це перемагає цілі, хоча
Карткікеян ВК

1
@KarthikeyanVK, я не впевнений, чи він все-таки точний, оскільки функція виконання v2 дозволяє більше 10 хв?
Томас

6

Я усвідомлюю, що я дуже спізнююся з грою з цією відповіддю, але оскільки це все ще найкращий результат пошуку в Google, я хотів дати певні вказівки з цієї теми суворо з точки зору витрат, оскільки, здається, ОП має певні занепокоєння щодо вартості . Тут уже є чудові відповіді, які розповідають про технічні обмеження та деталі роботи кожної служби, тому я не збираюсь повторно переглядати ці відповіді.

Якщо вам абсолютно потрібно щось, що працює на "безкоштовно" (як і без додаткових витрат до того, що ви вже заплатили за свій веб-додаток), у вас є два варіанти:

  1. Веб-роботи - розгортаються поряд із наявним веб-додатком і використовують ті самі ресурси, що й веб-додаток. Немає додаткових грошових витрат для використання веб-завдань, але є деякі обмеження, як уже згадувалося, що можуть призвести до витрат на продуктивність вашого веб-додатка.
  2. Функції - використовуючи план споживання, вам виділяється певна кількість безкоштовних страт. Кількість на момент написання цього тексту насправді досить висока, 1 мільйон безкоштовних страт. Однак ліміт виконання на 1 мільйон не є межею, яка, ймовірно, може доставити вам проблеми; це 400 Кб Гб (гігабайт секунд). Це в основному обчислення обсягу пам’яті, яку використовує ваша функція, помножене на кількість секунд, які вона виконує (див. Офіційний розрахунок на сторінці ціноутворення тут ). Ви здивуєтеся, як швидко цей безкоштовний наділ звикне.

Якщо ви турбуєтесь про витрати, але не обмежуєтесь взагалі ніякими витратами , тоді у вас є більше варіантів.

  1. Функції - Ви можете запускати або план споживання або план обслуговування додатків за відносно недорогу ціну. Майте на увазі, модель виставлення рахунків в GB. Якщо ви використовуєте план споживання і займаєтесь частою "важкою" роботою - вас може здивувати велика плата.
  2. Хмарні послуги - Цей варіант не обговорювався як альтернатива, головним чином тому, що ОП не запитувала про це. Але це теж життєздатний варіант. Хмарні сервіси - це врешті-решт віртуальні машини, що працюють у хмарі, тому ви можете виконувати будь-які фонові завдання, які вам знадобляться, і вони доволі добре масштабуються вгору / вниз (хоча для виконання вам доведеться підключити власні тригери, незначні незручності порівняно з веб-роботами / функціями ). З ними пов’язана більше початкова вартість (тому що ви платите за екземпляр, чи користуєтесь ви її чи ні), але якщо у вас є роботи, які потрібно постійно працювати і робити багато "важких" підйомів, то хмарні послуги можуть бути кращим вибором тому що легше керувати / контролювати VM з фіксованою ціною, ніж виконання та гігабайт секунд, на мій погляд.

Якщо вам цікаво читати деякі конкретні сценарії, і чому я вибрав би один (веб-роботи, функції, хмарні сервіси) над іншим, я нещодавно написав допис у блозі про веб-роботи vs функції та хмарні сервіси .


1
Дякую за відповідь @Dan :-) Я б сказав, що хмарний сервіс все ще приємний, але я думав про порівняння webjob та функцій, оскільки вони мають один і той же основний SDK і за два з половиною роки до цього, я не дуже розумів мету без серверів :-)
Томас

3

Важливим питанням є те, що функції Azure відмовилися від підтримки повної .NET Framework після версії 1, яка була припинена з v2.0 і яка не буде змінюватися в теперішньому вікні попереднього перегляду v3.0. 😔

Тим часом цей сильний збройний підхід, на щастя, не застосовувався до Azure WebJobs :

Версія 3.x SDK WebJobs підтримує додатки консолі .NET Core та .NET Framework.


Так, хороший момент. Навіть тому, відтепер люди повинні намагатися використовувати мережеве ядро ​​скільки завгодно.
Томас

0

Я хотів би розповісти, які спільності та відмінності між двома функціями Azure побудовані на версії AppService та WebJobs SDK. WebJobs SDK надасть вам більше свободи для гри, тоді як функції Azure більш структуровані з меншою кількістю відповідальності перед розробниками.

Коли ви дивитеся на спільність Обидва використовують функціонально орієнтований режим програмування, прив’язки для тригера / вводу / виводу, підтримують зовнішні бібліотеки та можуть запускати та налагоджувати локальну підтримку під час виконання туалетних приналежностей.

Відмінності

|-----------------------|------------------|
|      Functions        |     Web Jobs     |
|-----------------------|------------------|
|Can support HTTP       | Can't support HTTP
|                       |  requests        |
|-----------------------|------------------|
|Supports a variety of  | Traditional .NET |
|languages/tools        | developer        |
|                       | experience       |
|-----------------------|------------------|
|Bindings are configured| Config files are |
|using attributes       | used             |
|-----------------------|------------------|
|Scale is managed by    | Scale is managed |
|Azure                  | by user          |
|-----------------------|------------------|
|Limited control over   |Host can be       |
|host                   |controlled by user|
--------------------------------------------

введіть тут опис зображення

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.