Azure Webjobs a Azure Functions: jak wybrać


163

Utworzyłem kilka zadań Webjobs platformy Azure, które używają wyzwalaczy, i właśnie dowiedziałem się o usłudze Azure Functions .

Z tego, co rozumiem, usługi Azure Functions wydają się nakładać na funkcje usługi Azure Webjobs i mam pewne trudności ze zrozumieniem, kiedy wybrać między funkcją a pracą w sieci Web:

  • W przeciwieństwie do zadań Webjob, funkcje mogą być wyzwalane tylko, nie zostały zaprojektowane do uruchamiania ciągłego procesu (ale możesz napisać kod, aby utworzyć ciągłą funkcję).

  • Możesz pisać zadania Webjobs i funkcje przy użyciu wielu języków (C #, node.js, python ...), ale możesz napisać swoją funkcję z Azure Portal, aby łatwiej i szybciej opracować test i wdrożyć funkcję.

  • Zadania Webjob działają jako procesy w tle w kontekście aplikacji internetowej App Service, aplikacji interfejsu API lub aplikacji mobilnej, podczas gdy funkcje działają przy użyciu planu klasycznej / dynamicznej usługi aplikacji.

  • Jeśli chodzi o skalowanie, Functions wydaje się dawać więcej możliwości, ponieważ możesz użyć dynamicznego planu usługi aplikacji i możesz skalować pojedynczą funkcję, podczas gdy w przypadku pracy sieciowej musisz skalować całą aplikację internetową.

Więc na pewno istnieje różnica cenowa, jeśli masz już uruchomioną aplikację internetową, możesz jej użyć do uruchomienia webjob bez żadnych dodatkowych kosztów, ale jeśli nie mam istniejącej aplikacji internetowej i muszę napisać kod, aby uruchomić kolejkę czy powinienem używać pracy internetowej czy funkcji?

Czy są jakieś inne kwestie, o których należy pamiętać przy wyborze?


6
To jest wpis na blogu, który jestem winien. :) Spróbuję przygotować odpowiedź, ale może to być trochę otwarte dla przepełnienia stosu, więc być może będziesz musiał zapytać o to w MSDN, jeśli zostanie zamknięty.
Chris Anderson-MSFT

Ładny (krótki) wpis na blogu na ten temat geekswithblogs.net/tmurphy/archive/2016/06/02/…
Todd Menier

Hej Todd, edytuj moje pytanie, aby dodać link. Ciekawy artykuł ^^
Thomas

@ chris-anderson-msft Czy możemy uruchomić PowerShell jako webjob? Czy możemy zainstalować pakiet PowerShell w Webjob?
anomepani

Odpowiedzi:


170

W ramach usługi App Service jest kilka opcji. Nie będę dotykać Logic Apps ani Azure Automation, które również dotykają tego miejsca.

Azure WebJobs

Ten artykuł jest szczerze najlepszym wyjaśnieniem, ale podsumuję tutaj.

On Demand WebJobs aka. Zaplanowane WebJobs aka. Wyzwalane zadania internetowe

Wyzwalane zadania WebJob to zadania WebJob uruchamiane jednorazowo po wywołaniu adresu URL lub gdy właściwość schedule jest obecna w schedule.job . Zaplanowane zadania WebJobs to po prostu zadania WebJobs, dla których utworzono zadanie Azure Scheduler w celu wywołania naszego adresu URL zgodnie z harmonogramem, ale obsługujemy również właściwość harmonogramu, jak wspomniano wcześniej.

Podsumowanie:

  • + Plik wykonywalny / skrypt na żądanie
  • + Zaplanowane egzekucje
  • - Muszę wywołać za pośrednictwem punktu końcowego .scm
  • - Skalowanie jest ręczne
  • - Maszyna wirtualna jest zawsze wymagana

Continuous WebJobs (non SDK)

Te prace trwają wiecznie, a my obudzimy je, gdy się zawieszą. Musisz włączyć opcję Zawsze włączone, aby działały, co oznacza uruchamianie ich w warstwie Podstawowa i nowszych.

Podsumowanie:

  • + Plik wykonywalny / skrypt zawsze działa
  • - Wymagane zawsze włączone - poziom podstawowy i wyższy
  • - Maszyna wirtualna jest zawsze wymagana

Ciągłe zadania WebJobs za pomocą zestawu SDK zadań WebJobs

To nie jest nic z punktu widzenia „WebJobs funkcja”. Zasadniczo mamy ten słodki zestaw SDK, który napisaliśmy dla WebJobs, który umożliwia wykonywanie kodu w oparciu o proste wyzwalacze. Porozmawiam o tym później.

Podsumowanie:

  • + Plik wykonywalny / skrypt zawsze działa
  • + Bogatsze logowanie / pulpit nawigacyjny
  • + Wyzwalacze obsługiwane wraz z długotrwałymi zadaniami
  • - Wymagane zawsze włączone - poziom podstawowy i wyższy
  • - Skalowanie jest konfigurowane ręcznie
  • - Rozpoczęcie pracy może być trochę męczące
  • - Maszyna wirtualna jest zawsze wymagana

Zestaw SDK Azure WebJobs

Azure WebJobs SDK to całkowicie oddzielny zestaw SDK z funkcji platformy WebJobs. Został zaprojektowany do uruchamiania w WebJob, ale naprawdę można go uruchomić wszędzie. Mamy klientów, którzy uruchamiają je w rolach roboczych, a nawet w chmurze stacjonarnej lub w innych chmurach, chociaż wsparcie to tylko najlepszy wysiłek.

SDK ma po prostu ułatwić uruchamianie kodu w reakcji na jakieś zdarzenie i tworzenie powiązań z usługami / itp. łatwo. Szczerze mówiąc, najlepiej jest to omówione w niektórych dokumentach , ale sednem tego jest natura „zdarzenia” + „kod”. Wykonaliśmy również kilka fajnych prac związanych z ekstensywnością, ale to jest drugorzędne w stosunku do podstawowego celu.

Podsumowanie:

  • Większość z nich została wymieniona powyżej
  • +Możesz przedłużyć i uruchomić, co chcesz. Pełna kontrola.
  • - Rzeczy związane z HTTP są trochę dziwne, ale działają

Azure Functions

Azure Functions polega na wykorzystaniu tego podstawowego celu zestawu SDK WebJobs, hostowaniu go jako usługi i ułatwianiu rozpoczynania pracy z innymi językami. Przedstawiamy tutaj również koncepcję „bezserwerowego”, ponieważ miało to duży sens - wiemy, jak skaluje się nasze SDK, więc możemy robić za Ciebie inteligentne rzeczy.

Azure Functions to bardzo mocno zarządzane środowisko. Nie wspieramy przyprowadzania własnego hosta. Obecnie nie obsługujemy rozszerzeń niestandardowych, ale właśnie to badamy. Zastanawiamy się, co możesz, a czego nie możesz zrobić, ale rzeczy, które umożliwiamy, są sprytne i łatwe w obsłudze i zarządzaniu.

Jednak większość „frameworkowych” rzeczy, które zrobiliśmy w celu ulepszenia funkcji, przechodzi przez pakiet SDK WebJobs. Na przykład będziemy przekazywać nowy pakiet NuGet dla zadań WebJobs, który naprawdę drastycznie zwiększa szybkość rejestrowania, co daje ogromne korzyści w zakresie perf dla użytkowników zestawu SDK zadań WebJobs. W funkcjach wysyłkowych, takich jak „WebJobs SDK jako usługa”, naprawdę poprawiliśmy wiele problemów związanych z obsługą.

Prawdopodobnie jestem stronniczy, ponieważ Functions jest naszym najnowszym i najlepszym, ale nie krępuj się strzelać więcej wad dla funkcji na swój sposób.

Prawdopodobnie skończę na opublikowaniu bloga, który omawia nieco więcej, ale starałem się, aby to było jak najbardziej zwięzłe na tym forum.


1
Brzmi świetnie. Napisz do mnie na Twitterze (@crandycodes), jeśli masz jakieś pytania. Mogę pomóc w promowaniu Twoich próbek w witrynie Azure.com, jeśli chcesz, a także, jeśli chcesz je udostępnić.
Chris Anderson-MSFT,

1
Widziałem, że jest to przydatne. Wiem, że jest dużo miejsca na dyskusję, jak przejść z wzorców aplikacji serwerowych do wzorców aplikacji bezserwerowych. Wydaje się, że jest to związane z tym, co właśnie opisałeś.
Chris Anderson-MSFT,

1
Zasadniczo bierzemy twój kod i konfigurację i tworzymy funkcję WebJob SDK (stąd nazwa Azure Functions) pod okładkami. Twój kod działa więc w funkcji WebJob SDK, którą zarządzamy dla Ciebie.
Chris Anderson-MSFT

1
Każda aplikacja funkcji ma 1 hosta (który można by pomyśleć jako zadanie WebJob). Twoje funkcje w aplikacji funkcji współużytkują system plików, ustawienia aplikacji, pamięć, procesor itp. Zapraszam do zadania nowego pytania.
Chris Anderson-MSFT

2
Tak. Wyzwalacz timera. Wyrażenie Crona {0 * / 30 * * * *} azure.microsoft.com/en-us/documentation/articles/…
Chris Anderson-MSFT

17

Będąc Azure Functions opartymi na zestawie SDK zadań WebJobs, zapewniają większość funkcji już dostępnych w zadaniach WebJobs, ale z kilkoma nowymi, ciekawymi możliwościami.

Jeśli chodzi o wyzwalacze , oprócz tych, które są już dostępne dla zadań WebJob (np. Service Bus, kolejki magazynu, obiekty BLOB magazynu, harmonogramy CRON, elementy WebHooks, EventHub i dostawcy magazynu w chmurze plików), Azure Functions można wyzwalać jako interfejsy API. A wywołania HTTP nie wymagają poświadczeń Kudu, ale mogą być uwierzytelniane za pośrednictwem usługi Azure AD i dostawców tożsamości innych firm.

Jeśli chodzi o dane wyjściowe , jedyną różnicą jest to, że funkcje mogą zwracać odpowiedź, gdy są wywoływane przez HTTP.

Obie obsługują szeroki gamę języków , w tym: bash (.sh), batch (.bat / .cmd), C #, F #, Node.Js, PHP, PowerShell i Python.

Będąc funkcjami w podglądzie, narzędzia nadal nie są idealne. Ale Microsoft nad tym pracuje. Mamy nadzieję, że uzyskamy taką samą elastyczność w tworzeniu i testowaniu funkcji lokalnie, jak obecnie w przypadku zadań WebJobs w programie Visual Studio.

Najbardziej znaczące i fajne korzyści, jakie przynosi Functions, to alternatywa posiadania dynamicznego planu serwisowego z rozszerzeniem modelem „bezserwerowym” , w którym nie musimy zarządzać maszynami wirtualnymi ani skalować; wszystko jest dla nas zarządzane. Dodatkowo, nie mając dedykowanych instancji, płacimy tylko za zasoby, z których faktycznie korzystamy.

Bardziej szczegółowe porównanie między tymi dwoma tutaj: https://blog.kloud.com.au/2016/09/14/azure-functions-or-webjobs/

HTH :)


Dzięki za odpowiedź Paco! To porównanie może zainteresować wiele osób :-) Ale nie szukałem porównania, ale po prostu starałem się zrozumieć, kiedy powinienem korzystać z funkcji, a nie zadań internetowych!
Thomas

6
Trudno jest mieć jasne wskazówki bez znajomości kontekstu. Dlatego uważałem, że porównanie może pomóc ludziom w wyborze :) Powiedziałbym tak: if (((preference == "Serverless") || (isRequired(flexibleHttpTriggers)) && (isOk(currentFunctionsTooling))) { goWithFunctions(); } else { continueWIthWebJobs(); } :)
Paco de la Cruz

Funkcje mogą zwracać odpowiedź, gdy są wywoływane za pośrednictwem protokołu HTTP, ale są oparte na zestawie SDK zadań WebJobs. Dziwne, prawda?
RudyCo

Chyba lepiej powiedzieć, że były one oparte na pakiecie WebJobs SDK, ale stamtąd trochę ewoluowały :)
Paco de la Cruz

14

Zgodnie z dokumentacją Azure Functions ma następujące elementy, których nie ma WebJobs:

  • Automatyczne skalowanie (procesor i pamięć są skalowane zgodnie z potrzebami określonymi w czasie wykonywania)
  • Cennik płatności za użycie (plan zużycia zamiast planu usługi App Service)
  • Więcej zdarzeń wyzwalających (takich jak WebHooks)
  • Programowanie w przeglądarce (nadal możliwe Visual Studio)
  • Obsługa języka F #

Mówiąc najprościej: Azure Functions to nowsze zwierzę. Jeśli nie masz jeszcze planu usługi App Service, wybrałbym Functions, ponieważ w dłuższej perspektywie nie widzę żadnych powodów, dla których rozpoczęcie pracy z WebJobs byłoby lepsze (chociaż narzędzia funkcji mogą nie być już tak stabilne).


14

Chciałbym dodać jeszcze dwa punkty do powyższych długich i trochę starych postów. Jeśli wybierzesz plan zużycia w Azure Functions, poniżej znajdują się ograniczenia

Jeśli chcesz wykonywać zadania dłużej niż 10 minut, wybierz webjobs. Azure functions, domyślnie działa tylko przez 5 minut , jeśli proces przekracza 5 minut, funkcja Azure zgłasza wyjątek limitu czasu. Możesz zwiększyć limit czasu do 10 minut w host.json .

Uwaga: nie ma problemu z przekroczeniem limitu czasu, jeśli używasz funkcji Azure Service planu usługi aplikacji.

Innym powodem do rozróżnienia jest. Jeśli używasz funkcji Azure, początkowy czas rozpoczęcia będzie długi, ponieważ maszyny (kontenery) są tworzone w locie i niszczone po ich użyciu.

Aby uniknąć zimnego startu, Azure Function App wydało plan premium, w którym jedno wystąpienie będzie działało przez cały czas i na podstawie obciążenia aplikacja funkcji rozpocznie skalowanie, a opłaty za jedno wystąpienie i inne wystąpienia będą naliczane na podstawie zużycia.


Twój pierwszy punkt dotyczy tylko tego, że korzystasz z planu zużycia, a płatny SKU nie ma żadnego limitu czasu. Zgadzam się z drugim punktem.
Thomas

Myślę, że oba punkty są ważne dla planu zużycia. Dzięki za zwrócenie uwagi
Karthikeyan VK

4
Świetna wzmianka o limitach czasu. Dla nas jest to ważny czynnik
Niels Filter

1
Ale możesz wybrać plan usługi aplikacji podczas tworzenia funkcji Azure. Ale to jednak przekreśla cały cel
Karthikeyan VK

1
@KarthikeyanVK, nie jestem pewien, czy nadal jest dokładny, ponieważ czas działania funkcji v2 pozwala na więcej niż 10 minut?
Thomas

6

Zdaję sobie sprawę, że z tą odpowiedzią jestem bardzo spóźniony, ale ponieważ jest to nadal najlepszy wynik wyszukiwania w Google, chciałem udzielić wskazówek na ten temat ściśle z punktu widzenia kosztów, ponieważ wydaje się, że OP ma pewne obawy dotyczące kosztów . Jest już tutaj kilka świetnych odpowiedzi, które mówią o ograniczeniach technicznych i szczegółach działania każdej usługi, więc nie zamierzam ich ponownie mieszać.

Jeśli absolutnie potrzebujesz czegoś, co działa „za darmo” (bez dodatkowych kosztów w stosunku do tego, co już zapłaciłeś za swoją aplikację internetową), masz dwie możliwości:

  1. Zadania internetowe - wdrażane wraz z istniejącą aplikacją internetową i wykorzystujące te same zasoby, co Twoja aplikacja internetowa. Korzystanie z zadań webjobs nie wiąże się z żadnymi dodatkowymi kosztami, ale jak już wspomniano, istnieją pewne ograniczenia, które mogą prowadzić do obniżenia wydajności aplikacji internetowej.
  2. Funkcje - Korzystając z planu zużycia, przydzielana jest określona liczba bezpłatnych wykonań. Liczba w chwili pisania tego tekstu jest w rzeczywistości dość wysoka, 1 milion bezpłatnych egzekucji. Jednak limit 1 miliona realizacji nie jest limitem, który może sprawić Ci kłopoty; to 400K GB-s (gigabajtowe sekundy). Jest to po prostu obliczenie ilości pamięci używanej przez funkcję pomnożoną przez liczbę sekund, przez które działa (zobacz oficjalne obliczenia na stronie z cenami tutaj ). Będziesz zaskoczony, jak szybko ten darmowy przydział się wyczerpuje.

Jeśli obawiasz się kosztów, ale nie ograniczasz się do żadnych kosztów , masz więcej dostępnych opcji.

  1. Funkcje - możesz uruchomić w planie zużycia lub planie usługi aplikacji za stosunkowo niedrogą cenę. Pamiętaj jednak o modelu rozliczeniowym GB-s. Jeśli korzystasz z planu zużycia i wykonujesz częste, „ciężkie” prace - możesz być zaskoczony dużym rachunkiem.
  2. Usługi w chmurze - ta opcja nie została omówiona jako alternatywa, głównie dlatego, że OP nie pytał o to. Ale jest to również realna opcja. Usługi w chmurze to ostatecznie tylko maszyny wirtualne działające w chmurze, więc możesz uruchamiać na nich dowolne zadania w tle, których potrzebujesz, i całkiem dobrze skalują się w górę / w dół (chociaż musisz podłączyć własne wyzwalacze do wykonania, niewielka niedogodność w porównaniu do zadań / funkcji internetowych) ). Mają z nimi większy koszt początkowy (ponieważ płacisz za wystąpienie, niezależnie od tego, czy go używasz, czy nie), ale jeśli masz zadania, które muszą być wykonywane w sposób ciągły i wykonują dużo „ciężkich” prac, wówczas usługi w chmurze mogą być lepszym wyborem ponieważ moim zdaniem łatwiej jest zarządzać / monitorować maszynę wirtualną o stałej cenie niż wykonywanie i gigabajtowe sekundy.

Jeśli jesteś zainteresowany przeczytaniem niektórych konkretnych scenariuszy i dlaczego wybrałbym jeden (zadania internetowe, funkcje, usługi w chmurze) zamiast drugiego, niedawno napisałem wpis na blogu na temat zadań internetowych, funkcji i usług w chmurze .


1
Dzięki za odpowiedź @Dan :-) Powiedziałbym, że usługa w chmurze jest nadal fajna, ale myślałem o porównaniu webjob i funkcji, ponieważ mają one ten sam rdzeń SDK i dwa i pół roku wcześniej, tak naprawdę nie rozumiałem celu bezserwerowego :-)
Thomas

3

Ważną kwestią jest to, że usługa Azure Functions przestała obsługiwać pełną platformę .NET Framework po wersji 1, która została wycofana z wersją 2.0 i która nie zostanie zmieniona w wersji zapoznawczej 3.0. 😔

W międzyczasie to silnie uzbrojone podejście nie zostało na szczęście zastosowane - jeszcze - do Azure WebJobs :

Wersja 3.x zestawu WebJobs SDK obsługuje zarówno aplikacje konsolowe .NET Core, jak i .NET Framework.


Tak, dobra uwaga. Mimo to, od teraz ludzie powinni próbować używać net core tak często, jak tylko mogą.
Thomas

0

Chciałbym podać jakie są podobieństwa i różnice między dwiema funkcjami platformy Azure, które są zbudowane w oparciu o AppService i WebJobs SDK. Pakiet WebJobs SDK zapewnia większą swobodę podczas zabawy, podczas gdy funkcje platformy Azure są bardziej ustrukturyzowane i mają mniej obowiązków dla programistów.

Patrząc na podobieństwa Obydwa używają trybu programowania zorientowanego na funkcje, powiązań dla wyzwalacza / wejścia / wyjścia, obsługują biblioteki zewnętrzne i mogą uruchamiać i debugować lokalnie przybory toaletowe Supportruntime.

Różnice

|-----------------------|------------------|
|      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|
--------------------------------------------

wprowadź opis obrazu tutaj

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.