Azure Webjobs ve Azure İşlevleri: Nasıl seçilir


163

Tetikleyiciler kullanan bazı Azure Webjobs oluşturdum ve Azure İşlevleri hakkında yeni bilgi edindim .

Anladığım kadarıyla Azure İşlevleri Azure Webjobs özellikleri ile örtüşüyor gibi görünüyor ve İşlev ve Webjob arasında ne zaman seçim yapabileceğinizi anlamakta biraz zorlanıyorum:

  • Webjobs'un aksine, İşlevler yalnızca tetiklenebilir, sürekli işlemi çalıştırmak için tasarlanmamıştır (ancak sürekli bir işlev oluşturmak için kod yazabilirsiniz).

  • Webjobs ve İşlevleri birçok dil (C #, node.js, python ...) kullanarak yazabilirsiniz, ancak işlevinizi Azure portalından yazabilirsiniz, böylece bir İşlev geliştirmek ve sınamak daha kolay ve hızlıdır.

  • Webjobs, bir App Service web uygulaması, API uygulaması veya mobil uygulama bağlamında arka plan işlemleri olarak çalışır, İşlevler ise Klasik / Dinamik Uygulama Hizmet Planı kullanarak çalışır.

  • Ölçekleme ile ilgili olarak, Dinamik bir uygulama hizmet planı kullanabileceğiniz ve tek bir işlevi ölçeklendirebileceğiniz için işlevler daha fazla olasılık veriyor gibi görünürken, webjob için tüm web uygulamasını ölçeklendirmeniz gerekir.

Bu nedenle, bir fiyatlandırma farkı olduğundan, çalışan bir web uygulamanız varsa, herhangi bir ek ücret ödemeden bir webjob çalıştırmak için kullanabilirsiniz, ancak mevcut bir web uygulamam yoksa ve bir kuyruğu tetiklemek için kod yazmak zorundayım bir webjob veya bir işlev kullanmalıyım?

Seçmeniz gerektiğinde aklınızda bulundurmanız gereken başka noktalar var mı?


6
Bu borçlu olduğum bir blog yazısı. :) Bir cevap hazırlamaya çalışacağım, ancak Stack Overflow için biraz açık uçlu olabilir, bu yüzden MSDN'de kapanıp kapanmadığını sormanız gerekebilir.
Chris Anderson-MSFT

Bu konuda güzel (kısa) blog yazısı geekswithblogs.net/tmurphy/archive/2016/06/02/…
Todd Menier

Hey Todd, bağlantıyı eklemek için sorumu düzenlemekten çekinmeyin. İlginç makale ^^
Thomas

@ chris-anderson-msft PowerShell'i webjob olarak çalıştırabilir miyiz? Webjob üzerine PowerShell paketini kurabilir miyiz?
anomepani

Yanıtlar:


170

Burada App Service içinde birkaç seçenek var. Bu alana da dokunan Mantık Uygulamaları veya Azure Otomasyonu'na dokunmayacağım.

Azure WebJobs

Bu makale dürüst olmak gerekirse en iyi açıklamadır, ancak burada özetleyeceğim.

Talep Üzerine WebJobs aka. Zamanlanmış WebJobs aka. Tetiklenen Web İşleri

Tetiklenen WebJobs, bir URL çağrıldığında veya schedule.job içinde schedule özelliği bulunduğunda bir kez çalıştırılan WebJobs'tur . Zamanlanmış WebJobs, yalnızca URL'imizi bir zamanlamaya göre aramak için Azure Zamanlayıcı İşi oluşturulmuş WebJobs'dur, ancak daha önce de belirtildiği gibi zamanlama özelliğini de destekliyoruz.

Özet:

  • + Yürütülebilir / İsteğe bağlı komut dosyası
  • + Zamanlanmış infazlar
  • - .Scm uç noktası üzerinden tetiklenmelidir
  • - Ölçeklendirme manueldir
  • - VM her zaman gereklidir

Sürekli WebJobs (SDK olmayan)

Bu işler sonsuza dek sürüyor ve çöktüklerinde onları uyandıracağız. Bunların çalışması için Her Zaman Açık'ı etkinleştirmeniz gerekir, yani Temel katman ve üstünde çalıştırmak anlamına gelir.

Özet:

  • + Yürütülebilir / Komut Dosyası her zaman çalışıyor
  • - Her zaman açık gerektirir - Temel katman ve üstü
  • - VM her zaman gereklidir

WebJobs SDK ile Sürekli WebJobs

Bunlar "WebJobs özelliği" açısından bir şey değildir. Temel olarak, basit tetikleyicilere dayalı kod yürütmenizi sağlayan WebJobs'u hedeflediğimiz bu tatlı SDK'ya sahibiz. Bunun hakkında daha sonra konuşacağım.

Özet:

  • + Yürütülebilir / Komut Dosyası her zaman çalışıyor
  • + Daha zengin günlük / gösterge tablosu
  • + Uzun süren görevlerle birlikte desteklenen tetikleyiciler
  • - Her zaman açık gerektirir - Temel katman ve üstü
  • - Ölçeklendirme kurulum için manueldir
  • - Başlamak biraz yorucu olabilir
  • - VM her zaman gereklidir

Azure WebJobs SDK'sı

Azure WebJobs SDK, platform özelliğinden WebJobs'tan tamamen ayrı bir SDK'dır. Bir WebJob'da çalışacak şekilde tasarlanmıştır, ancak gerçekten her yerde çalıştırılabilir. Destek yalnızca en iyi çaba olsa da, onları çalışan rollerinde, hatta prem ya da diğer bulutlarda yöneten müşterilerimiz var.

SDK, bir olaya tepki olarak bazı kodların çalıştırılmasını ve hizmetler / vb. kolay. Bu dürüst olmak gerekirse en iyi bazı dokümanlar ile kaplıdır , ancak kalbi "olay" + "kod" doğasıdır. Ayrıca bazı serinletilebilir genişletilebilirlik çalışmaları yaptık, ancak bu temel amaca ikincil.

Özet:

  • Bunların çoğu yukarıda belirtilmiştir
  • +İstediğinizi genişletebilir ve çalıştırabilirsiniz. Tam kontrol.
  • - HTTP işleri biraz sakat, ama işe yarıyor

Azure İşlevleri

Azure İşlevleri, WebJobs SDK'nın temel amacını ele almak, bir hizmet olarak barındırmak ve diğer dillerle başlamayı kolaylaştırmakla ilgilidir. Burada "Sunucusuz" konseptini de sunuyoruz çünkü bunu yapmak çok mantıklıydı - SDK'mızın nasıl ölçeklendiğini biliyoruz, böylece sizin için akıllı şeyler yapabiliriz.

Azure İşlevleri çok yoğun bir şekilde yönetilen bir deneyimdir. Kendi sunucunuzu getirmeyi desteklemiyoruz. Şu anda, özel uzantıları desteklemiyoruz, ancak araştırdığımız bir şey. Neler yapabileceğiniz ve yapamayacağınız konusunda düşünüyoruz, ancak etkinleştirdiğimiz şeyler için kaygan ve kullanımı ve yönetimi kolaydır.

Bununla birlikte, İşlevleri iyileştirmek için yaptığımız "çerçeve" şeylerin çoğu WebJobs SDK'sından geçer. Örneğin, WebJobs SDK kullanıcıları için büyük bir avantaj sağlayan günlük kaydetme hızını büyük ölçüde artıran yeni bir WebJobs NuGet'i yükleyeceğiz. "Hizmet olarak WebJobs SDK" olarak sunulan işlevlerde, birçok deneyim sorununu gerçekten geliştirdik.

İşlevler en son ve en büyüklerimiz olduğu için muhtemelen yanlıyım, ancak İşlevler için daha fazla eksilerini çekmekten çekinmeyin.

Muhtemelen biraz daha ayrıntılı bir blog yayınlayacağım, ancak bunu bu forum için mümkün olduğunca öz tutmaya çalıştım.


1
Kulağa harika geliyor. Herhangi bir sorunuz varsa Twitter'da bana DM (@crandycodes) yazın. İsterseniz örneklerinizi Azure.com'da tanıtmanıza da yardımcı olabilirim.
Chris Anderson-MSFT

1
Bunun yararlı olduğunu görebiliyordum. Sunucudan sunucusuz uygulama modellerine nasıl geçiş yapılacağını tartışmak için çok yer olduğunu biliyorum. Bu tür, az önce tanımladığınız şeyle ilgili görünüyor.
Chris Anderson-MSFT

1
Temel olarak, kodunuzu ve yapılandırmanızı alıp kapakların altında bir WebJob SDK İşlevi (dolayısıyla Azure İşlevleri adı) oluştururuz. Kodunuz sizin için yönettiğimiz bir WebJob SDK İşlevinde çalışıyor.
Chris Anderson-MSFT

1
Her Fonksiyon Uygulaması 1 ana bilgisayara sahiptir (WebJob olarak düşünebilirsiniz). Bir İşlev Uygulaması içindeki işlevleriniz bir dosya sistemi, uygulama ayarları, bellek, işlemci vb. Paylaşır. Yeni bir soru sormaktan çekinmeyin.
Chris Anderson-MSFT


17

WebJobs SDK'sını temel alan Azure İşlevleri olarak, WebJobs'ta zaten mevcut olan işlevlerin çoğunu sağlarlar, ancak bazı yeni harika yeteneklere sahiptirler.

Tetikleyiciler açısından, WebJobs için zaten mevcut olanlara ek olarak (örn. Hizmet Veri Yolu, Depolama Kuyrukları, Depolama Blobları, CRON zamanlamaları, WebHooks, EventHub ve Dosya Bulutu Depolama sağlayıcıları), Azure İşlevleri API olarak tetiklenebilir. HTTP çağrıları kudu kimlik bilgileri gerektirmez, ancak Azure AD ve üçüncü taraf kimlik sağlayıcıları aracılığıyla doğrulanabilir.

Çıktılarla ilgili olarak , tek fark İşlevlerin HTTP üzerinden çağrıldığında bir yanıt döndürebilmesidir.

Her ikisi de bash (.sh), toplu iş (.bat / .cmd), C #, F #, Node.Js, PHP, PowerShell ve Python gibi çok çeşitli dilleri destekler .

Şu anda Önizlemedeki İşlevler olmak, takımlama hala ideal değildir. Ancak Microsoft bunun üzerinde çalışıyor. Umarım şu anda Visual Studio ile WebJobs için yaptığımız gibi Fonksiyonları yerel olarak geliştirme ve test etme esnekliğini elde ederiz.

İşlevlerin getirdiği en önemli ve harika avantajlar, Dinamik Hizmet Planına sahip olmanın alternatifidir , VM örneklerini veya ölçeklendirmeyi yönetmemiz gerekmediği "Sunucusuz" modelli sahip olmaktır; her şey bizim için başardı. Ayrıca, özel örneklere sahip olmadığımız için, yalnızca gerçekte kullandığımız kaynaklar için ödeme yaparız.

Bu ikisi arasında daha ayrıntılı bir karşılaştırma: https://blog.kloud.com.au/2016/09/14/azure-functions-or-webjobs/

HTH :)


Cevabınız için teşekkürler Paco! Bu karşılaştırma çok sayıda insanı ilgilendirebilir :-) Ama bir karşılaştırma aramıyordum ama sadece webjobs yerine fonksiyonlarla ne zaman gitmem gerektiğini anlamaya çalışıyorum!
Thomas

6
İçeriği bilmeden net bir yol göstermesi zor. Bu yüzden bir karşılaştırma yapmanın insanların seçmesi için yardımcı olabileceğine inandım :) Bunu söyleyebilirim: if (((preference == "Serverless") || (isRequired(flexibleHttpTriggers)) && (isOk(currentFunctionsTooling))) { goWithFunctions(); } else { continueWIthWebJobs(); } :)
Paco de la Cruz

HTTP üzerinden çağrıldığında işlevler bir yanıt döndürebilir. Ancak işlevler WebJobs SDK'sını temel alır. Garip, değil mi?
RudyCo

Muhtemelen onlar söylemek daha iyidir edildi WebJobs SDK dayalı, ancak :) oradan biraz evrimleşmiş
Paco de la Cruz

14

Dokümanlara göre Azure İşlevleri, WebJobs'da aşağıdakilere sahip değildir:

  • Otomatik ölçeklendirme (CPU ve bellek, çalışma zamanında belirlenen ihtiyaçlara göre ölçeklendirilir)
  • Kullanım başına ödeme fiyatlandırması (Uygulama Hizmeti planı yerine Tüketim planı)
  • Daha fazla tetikleyici etkinlik (WebHooks gibi)
  • Tarayıcı içi geliştirme (Visual Studio hala mümkün)
  • F # desteği

Basitçe söylemek gerekirse: Azure İşlevleri daha yeni bir hayvandır. Zaten bir Uygulama Hizmeti planınız yoksa, İşlevlerle birlikte giderdim çünkü uzun vadede WebJobs ile başlamanın daha iyi olmasının nedenlerini görmüyorum (İşlevler takım zaten zaten istikrarlı olmayabilir).


14

Yukarıdaki uzun ve biraz eski yazılara iki nokta daha eklemek istiyorum. masmavi işlevlerde tüketim planını seçerseniz, sınırlamalar aşağıdadır

10 dakikadan fazla iş yapmak istiyorsanız webjobs'u seçin. Azure işlevleri, varsayılan olarak yalnızca 5 dakika çalışır , işleminiz 5 dakikayı aşarsa, masmavi işlevi zaman aşımı istisnası atar. Şunları yapabilirsiniz artırmak için zaman aşımı host.json 10 dakika .

Not: Uygulama hizmet planı masmavi işlevlerini kullanıyorsanız zaman aşımı sorunu yoktur.

Ayırt etmenin bir başka nedeni de. masmavi işlevini kullanırsanız, makineler (kaplar) anında oluşturulduğundan ve kullanıldıktan sonra yok edildiğinden ilk başlangıç ​​zamanınız yavaş olacaktır.

Soğuk başlatmayı önlemek için, masmavi işlev uygulaması, bir örneğin her zaman çalışacağı ve işlev uygulamasının ölçeklendirmeye başlayacağı yüke bağlı olarak premium planını yayınladı ve bir örnek ve tüketime dayalı diğer örnekler için faturalandırılacaksınız.


Sadece ilk puanınız tüketim planını kullanmanızdır, ücretli sku ile zaman aşımı sınırınız yoktur. İkinci noktaya katılıyorum.
Thomas

her iki noktanın da tüketim planı için geçerli olduğunu düşünüyorum. İşaret ettiğiniz için teşekkürler
Karthikeyan VK

4
Zaman aşımlarından büyük söz. Bizim için bu önemli bir faktör
Niels Filter

1
Ancak, masmavi işlevler oluştururken uygulama hizmeti planını seçebilirsiniz. Ama yine de tüm amacı yendi
Karthikeyan VK

1
@KarthikeyanVK, işlev çalışma zamanı v2 10 dakikadan fazla izin verdiği için hala doğru olup olmadığından emin değilim?
Thomas

6

Bu cevapla oyuna çok geç kaldığımı fark ettim, ancak bu hala Google'da en iyi arama sonucu olduğu için, bu konuya kesinlikle maliyet açısından bazı rehberlik etmek istedim olduğu için, OP'nin maliyetle ilgili bazı endişeleri olduğu için . Burada, teknik kısıtlamalar ve her bir hizmetin nasıl çalıştığına dair ayrıntılar hakkında konuşan bazı harika cevaplar var, bu yüzden bu cevapları yeniden şekillendirmeyeceğim.

Kesinlikle "ücretsiz" için çalışan bir şeye ihtiyacınız varsa (web uygulamanız için zaten ödediğinize ek bir ücret ödemeden olduğu gibi), iki seçeneğiniz vardır:

  1. Webjobs - mevcut web uygulamanızla birlikte dağıtılır ve web uygulamanızla aynı kaynakları kullanır. Webjobs'u kullanmak için ek parasal maliyet yoktur, ancak web uygulamanızda performans maliyetlerine yol açabilecek daha önce de belirtildiği gibi bazı sınırlamalar vardır.
  2. İşlevler - Tüketim planını kullanırken belirli miktarda ücretsiz yürütme yapılır. Bu yazı sırasındaki sayı aslında oldukça yüksek, 1 milyon ücretsiz icra. Ancak, 1 milyon yürütme limiti size sorun çıkartabilecek sınır değildir; 400K GB-s (gigabayt saniye). Bu, temel olarak, işlevinizin kullandığı bellek miktarının çalıştığı saniye sayısıyla çarpımının bir hesaplamasıdır (buradaki fiyatlandırma sayfasındaki resmi hesaplamaya bakın ). Bu ücretsiz tahsisin ne kadar çabuk tükendiğine şaşıracaksınız.

Maliyetlerden endişe ediyorsanız, ancak hiçbir maliyetle sınırlı değilse , daha fazla seçeneğiniz vardır.

  1. İşlevler - Nispeten ucuz bir fiyata tüketim planında veya uygulama hizmet planında çalışabilirsiniz. Bununla birlikte, GB-s faturalandırma modelini unutmayın. Tüketim planını kullanıyorsanız ve sık sık "ağır" bir iş yapıyorsanız - büyük bir fatura ile şaşırabilirsiniz.
  2. Bulut Hizmetleri - Bu seçenek bir alternatif olarak tartışılmamıştır, çünkü OP bu konuda sormadı. Ancak bu da uygun bir seçenektir. Bulut hizmetleri nihayetinde bulutta çalışan sanal makinelerdir, böylece ihtiyacınız olan arka plan işlerini çalıştırabilirsiniz ve oldukça iyi bir şekilde ölçeklendirilirler (yürütme için kendi tetikleyicilerinizi bağlamak zorunda olmanıza rağmen, webjobs / işlevlere kıyasla hafif bir rahatsızlık ). Onlarla ilişkili daha fazla başlangıç ​​maliyetine sahiptirler (çünkü kullansanız da kullanmasanız da ödeme yaparsınız) ancak sürekli çalışması gereken ve çok "ağır" kaldırma işlemi yapan işleriniz varsa, bulut hizmetleri daha iyi bir seçim olabilir çünkü sabit fiyatlı bir sanal makineyi yönetmek / izlemek, bence yürütmelerden ve gigabayt saniyeden daha kolaydır.

Bazı özel senaryoları okumakla ve neden birini (webjobs, fonksiyonlar, bulut hizmetleri) diğerine seçeceğimi merak ediyorsanız, kısa bir süre önce webjobs vs function vs cloud services hakkında bir blog yazısı yazdım .


1
Cevabınız için teşekkürler @Dan :-) Bulut hizmetinin hala güzel olduğunu söyleyebilirim ama aynı çekirdek SDK'yı ve 2 yıl önce paylaştıkları için webjob ve işlevleri karşılaştırmayı düşünüyordum, gerçekten sunucusuzun amacını anlamadım :-)
Thomas

3

Önemli bir nokta, Azure İşlevlerinin sürüm v2.0 ile devam ettirilmeyen ve şimdi v3.0 önizlemesinde değişmeyecek olan sürüm 1'den sonra tam .NET Framework'ü desteklemeyi bırakmasıdır. 😔

Bu arada, bu güçlü silahlı yaklaşım neyse ki Azure WebJobs'a uygulanmadı :

WebJobs SDK'nın 3.x sürümü hem .NET Core hem de .NET Framework konsol uygulamalarını destekler.


Evet iyi bir nokta. Tho bile, bundan böyle insanlar olabildiğince net çekirdeği kullanmayı denemeliler.
Thomas

0

Ortak özelliklerin ve farklılıkların neler olduğunu vermek istiyorumİki Azure işlevi arasındaki olduğunu AppService ve WebJobs SDK üzerine inşa etmek istiyorum. WebJobs SDK size daha fazla oyun oynama özgürlüğü sunarken, Azure işlevleri daha az sorumlulukla daha yapılandırılmış şekilde geliştiricilere yöneliktir.

Ortak noktalara baktığınızda Her ikisi de işlev odaklı programlama modunu kullanır, tetikleyici / giriş / çıkış için bağlar, harici kitaplıkları destekler ve yerel Supportruntime tuvaletlerini çalıştırabilir ve hata ayıklayabilir.

farklılıklar

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

resim açıklamasını buraya girin

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.