Azure Webjobs vs ฟังก์ชั่น Azure: วิธีการเลือก

ฉันได้สร้างบางWebjobs Azureที่ใช้ทริกเกอร์และฉันได้เรียนรู้เพียงเกี่ยวกับฟังก์ชั่นสีฟ้า

จากสิ่งที่ฉันเข้าใจฟังก์ชั่น Azure ดูเหมือนจะทับซ้อนกับคุณสมบัติ Azure Webjobs และฉันมีความยากลำบากในการเข้าใจเมื่อเลือกระหว่าง Function และ Webjob:

• ฟังก์ชั่นนี้สามารถเปิดใช้งานได้ แต่ไม่ได้ออกแบบมาเพื่อให้ทำงานต่อเนื่อง (แต่คุณสามารถเขียนโค้ดเพื่อสร้างฟังก์ชั่นต่อเนื่องได้)

• คุณสามารถเขียน Webjobs และฟังก์ชั่นโดยใช้หลายภาษา (C #, node.js, python ... ) แต่คุณสามารถเขียนฟังก์ชันของคุณได้จากพอร์ทัล Azure เพื่อให้ง่ายต่อการพัฒนาทดสอบและปรับใช้ฟังก์ชั่น

• Webjobs ทำงานเป็นกระบวนการพื้นหลังในบริบทของแอปบริการเว็บแอพ API หรือแอพมือถือในขณะที่ฟังก์ชั่นทำงานโดยใช้แผนบริการแอพแบบคลาสสิค / ไดนามิก

• เกี่ยวกับการปรับขนาดฟังก์ชั่นดูเหมือนจะให้ความเป็นไปได้มากขึ้นเนื่องจากคุณสามารถใช้แผนบริการแอพแบบไดนามิกและคุณสามารถปรับขนาดฟังก์ชั่นเดียวในขณะที่สำหรับ webjob คุณต้องปรับขนาดเว็บแอปทั้งหมด

ดังนั้นแน่นอนว่ามีความแตกต่างด้านราคาหากคุณมีแอพพลิเคชั่นเว็บที่มีอยู่คุณสามารถใช้มันเพื่อรัน webjob ได้โดยไม่มีค่าใช้จ่ายเพิ่มเติม แต่ถ้าฉันไม่มีแอพพลิเคชั่นบนเว็บที่มีอยู่แล้ว ฉันควรใช้ webjob หรือ Function

มีข้อควรพิจารณาอื่น ๆ อีกหรือไม่เมื่อคุณจำเป็นต้องเลือก

มีตัวเลือกสองสามอย่างที่นี่ในบริการแอพ ฉันจะไม่แตะบนแอพลอจิกหรือ Azure Automation ซึ่งสัมผัสกับพื้นที่นี้

AzJu WebJobs

บทความนี้เป็นคำอธิบายที่ดีที่สุดโดยสุจริต แต่ฉันจะสรุปที่นี่

WebJobs ตามต้องการ WebJobs ตามกำหนดเวลา ทริกเกอร์ WebJobs

WebJobs เรียกเป็น WebJobs ซึ่งจะถูกเรียกใช้ครั้งเดียวเมื่อ URL ที่เรียกว่าหรือเมื่อคุณสมบัติกำหนดการอยู่ใน schedule.job WebJobs ตามกำหนดเวลาเป็นเพียง WebJobs ซึ่งมีงาน Azure Scheduler ที่สร้างขึ้นเพื่อเรียก URL ของเราตามกำหนดเวลา แต่เรายังสนับสนุนคุณสมบัติกำหนดการตามที่กล่าวไว้ก่อนหน้านี้

สรุป:

• + ปฏิบัติการ / สคริปต์ตามต้องการ
• + กำหนดการประหารชีวิต
• - ต้องเรียกใช้ผ่าน. scm endpoint
• - การปรับสเกลเป็นคู่มือ
• - จำเป็นต้องใช้ VM เสมอ

WebJobs ต่อเนื่อง (ไม่ใช่ SDK)

งานเหล่านี้ทำงานตลอดไปและเราจะปลุกพวกเขาเมื่อพวกเขาล้มเหลว คุณต้องเปิดใช้งาน Always On เพื่อให้ทำงานได้ซึ่งหมายถึงการเปิดใช้งานในระดับขั้นพื้นฐานและสูงกว่า

สรุป:

• + ปฏิบัติการ / สคริปต์ทำงานอยู่เสมอ
• - ต้องใช้ตลอดเวลา - ระดับพื้นฐานและสูงกว่า
• - จำเป็นต้องใช้ VM เสมอ

WebJobs อย่างต่อเนื่องกับ WebJobs SDK

สิ่งเหล่านี้ไม่ได้มาจากมุมมอง "WebJobs the feature" โดยพื้นฐานแล้วเรามี SDK ที่แสนหวานนี้ที่เราเขียนไปที่การกำหนดเป้าหมาย WebJobs ซึ่งจะช่วยให้คุณสามารถรันโค้ดโดยใช้ทริกเกอร์อย่างง่าย ฉันจะพูดเกี่ยวกับเรื่องนี้ในภายหลัง

สรุป:

• + ปฏิบัติการ / สคริปต์ทำงานอยู่เสมอ
• + การเข้าสู่ระบบ / แดชบอร์ดยิ่งขึ้น
• + รองรับทริกเกอร์พร้อมกับงานที่ต้องใช้เวลานาน
• - ต้องใช้ตลอดเวลา - ระดับพื้นฐานและสูงกว่า
• - สเกลเป็นคู่มือในการตั้งค่า
• - เริ่มต้นใช้งานได้น่าเบื่อเล็กน้อย
• - จำเป็นต้องใช้ VM เสมอ

Azure WebJobs SDK

Azure WebJobs SDK เป็น SDK แยกต่างหากอย่างสมบูรณ์จาก WebJobs คุณสมบัติแพลตฟอร์ม มันถูกออกแบบมาให้ทำงานใน WebJob แต่สามารถทำงานได้ทุกที่ เรามีลูกค้าที่ทำงานในบทบาทของผู้ปฏิบัติงานและแม้กระทั่งบนพื้นฐานหรือคลาวด์อื่น ๆ แม้ว่าการสนับสนุนจะเป็นความพยายามที่ดีที่สุดเท่านั้น

SDK เป็นเพียงการทำให้มันง่ายต่อการเรียกใช้โค้ดบางอย่างเพื่อตอบสนองต่อเหตุการณ์บางอย่างและทำให้ผูกพันกับบริการ / ฯลฯ ง่าย. สิ่งนี้ได้รับการกล่าวถึงอย่างดีที่สุดในเอกสารบางประเภทแต่หัวใจของมันคือธรรมชาติ "เหตุการณ์" + "รหัส" นอกจากนี้เรายังได้ทำงาน extensiblity เจ๋ง ๆ แต่นั่นก็รองจากวัตถุประสงค์หลัก

สรุป:

• สิ่งเหล่านี้ส่วนใหญ่ถูกกล่าวถึงข้างต้น
• +คุณสามารถขยายและเรียกใช้สิ่งที่คุณต้องการ ควบคุมทั้งหมด.
• - สิ่ง HTTP เป็นสิ่งเล็ก ๆ น้อย ๆ แต่มันใช้งานได้

ฟังก์ชันสีฟ้า

ฟังก์ชั่น Azure คือทั้งหมดที่เกี่ยวกับการใช้จุดประสงค์หลักของ WebJobs SDK ให้บริการโฮสต์และทำให้ง่ายต่อการเริ่มต้นใช้งานกับภาษาอื่น นอกจากนี้เรายังแนะนำแนวคิด "Serverless" ที่นี่เพราะมันสมเหตุสมผลอย่างมากที่จะทำเช่นนั้น - เรารู้ว่า SDK ของเราปรับขนาดได้อย่างไรเพื่อให้เราสามารถทำสิ่งที่ชาญฉลาดสำหรับคุณ

ฟังก์ชั่นสีฟ้าเป็นประสบการณ์ที่มีการจัดการอย่างมาก เราไม่สนับสนุนการนำโฮสต์ของคุณเอง ปัจจุบันเราไม่สนับสนุนส่วนขยายที่กำหนดเอง แต่เป็นสิ่งที่เรากำลังตรวจสอบ เราให้ความเห็นเกี่ยวกับสิ่งที่คุณทำได้และไม่สามารถทำได้ แต่สำหรับสิ่งที่เราเปิดใช้งานสิ่งเหล่านี้มันลื่นและใช้งานและจัดการได้ง่าย

สิ่งที่ "กรอบงาน" ส่วนใหญ่ที่เราทำเพื่อปรับปรุงฟังก์ชั่นนั้นผ่าน WebJobs SDK ตัวอย่างเช่นเราจะอัปโหลด NuGet ใหม่สำหรับ WebJobs ซึ่งเพิ่มความเร็วในการบันทึกอย่างมากซึ่งมีประโยชน์อย่างมากสำหรับผู้ใช้ WebJobs SDK ในฟังก์ชั่นการจัดส่งในฐานะ "WebJobs SDK เป็นบริการ" เราได้ปรับปรุงประสบการณ์การใช้งานมากมาย

• + รองรับหลายภาษา
• + การปรับขนาดแบบไดนามิกที่มีการจัดการอย่างเต็มที่
• + ง่ายต่อการใช้พอร์ทัลด้วย UX สำหรับจัดการการเชื่อมต่อ / อื่น ๆ
• - โฮสต์ไม่สามารถปรับแต่งได้ (แต่)
• ~ ทำงานใน "แอพ" แยกต่างหากซึ่งต้องการการกำหนดค่าบางอย่างใน repo ของคุณ แต่ทำให้การบำรุงรักษาในระยะยาวง่ายขึ้นมาก
• ~ ไม่มีเครื่องมือ (ยัง)เครื่องมือบางอย่างอยู่ในอัลฟ่าหรือแสดงตัวอย่าง - https://www.npmjs.com/package/azurefunctions (อัปเดต ก.พ. 2017: เครื่องมือ Visual Studio สำหรับฟังก์ชัน Azure พร้อมใช้งานในตัวอย่าง: https: //blogs.msdn .microsoft.com / webdev / 2016/12/01 / visual-studio-tools-for-azure-function / )

ฉันอาจเอนเอียงเพราะฟังก์ชั่นเป็นรุ่นล่าสุดและยอดเยี่ยมที่สุดของเรา แต่อย่าลังเลที่จะถ่ายภาพข้อเสียเพิ่มเติมสำหรับฟังก์ชั่นของฉัน

ฉันอาจจะลงเอยด้วยการเผยแพร่บล็อกที่มีเนื้อหาเพิ่มเติมอีกเล็กน้อย แต่ฉันพยายามทำให้เรื่องนี้สั้นที่สุดเท่าที่จะเป็นไปได้สำหรับฟอรัมนี้

การเป็นฟังก์ชัน Azure ขึ้นอยู่กับ WebJobs SDK พวกเขามีฟังก์ชั่นส่วนใหญ่ที่มีอยู่แล้วใน WebJobs แต่มีความสามารถใหม่ ๆ

ในส่วนของทริกเกอร์นอกเหนือจากที่มีอยู่แล้วสำหรับ WebJobs (เช่น Service Bus, Storage Queues, Blobs ของที่เก็บข้อมูล, ตารางเวลา CRON, WebHooks, EventHub และผู้ให้บริการ Storage Cloud File) ฟังก์ชัน Azure สามารถเรียกใช้เป็น API ได้ และการโทร HTTP ไม่จำเป็นต้องมีข้อมูลรับรอง kudu แต่สามารถตรวจสอบได้ผ่าน Azure AD และผู้ให้บริการข้อมูลบุคคลที่สาม

ในเรื่องผลที่แตกต่างเพียงอย่างเดียวคือฟังก์ชั่นสามารถกลับตอบสนองเมื่อเรียกผ่านทาง HTTP

ทั้งสองรองรับภาษาหลากหลายได้แก่ : bash (.sh), batch (.bat / .cmd), C #, F #, Node.Js, PHP, PowerShell และ Python

การเป็นฟังก์ชั่นใน Preview อยู่ในขณะนี้การใช้เครื่องมือยังไม่เหมาะ แต่ Microsoft กำลังทำงานอยู่ หวังว่าเราจะได้รับความยืดหยุ่นเท่ากันในการพัฒนาและทดสอบฟังก์ชั่นในพื้นที่เช่นเดียวกับที่เราทำกับ WebJobs ด้วย Visual Studio

ข้อได้เปรียบที่สำคัญที่สุดและยอดเยี่ยมที่นำโดยฟังก์ชั่นคือทางเลือกของการมีแผนบริการแบบไดนามิกที่มีรูปแบบ"ไร้เซิร์ฟเวอร์"ซึ่งเราไม่จำเป็นต้องจัดการกับอินสแตนซ์ของ VM หรือการปรับขนาด มันมีการจัดการทั้งหมดสำหรับเรา นอกจากนี้หากไม่มีอินสแตนซ์เฉพาะเราจ่ายเงินสำหรับทรัพยากรที่เราใช้จริงเท่านั้น

การเปรียบเทียบรายละเอียดเพิ่มเติมระหว่างทั้งสองที่นี่: https://blog.kloud.com.au/2016/09/14/azure-functions-or-webjobs/

HTH :)

ตามฟังก์ชั่นเอกสาร Azure มีสิ่งต่อไปนี้ที่ WebJobs ไม่มี:

• การปรับสเกลอัตโนมัติ (CPU และหน่วยความจำจะถูกปรับขนาดตามความต้องการที่กำหนดในช่วงรันไทม์)
• การกำหนดราคาแบบจ่ายต่อการใช้งาน (แผนการบริโภคแทนแผนบริการแอป)
• กิจกรรมทริกเกอร์เพิ่มเติม (เช่น WebHooks)
• การพัฒนาในเบราว์เซอร์ (Visual Studio ยังเป็นไปได้)
• สนับสนุน F #

พูดง่ายๆ: ฟังก์ชั่น Azure เป็นสัตว์ที่ใหม่กว่า หากคุณยังไม่มีแผนบริการ App ฉันจะไปกับฟังก์ชั่นเพราะในระยะยาวฉันไม่เห็นสาเหตุใด ๆ ที่เริ่มต้นด้วย WebJobs จะดีกว่า (ฟังก์ชั่นการใช้เครื่องมืออาจไม่เสถียรเท่าที่ควร)

ฉันต้องการเพิ่มอีกสองจุดให้กับโพสต์เก่าที่มีความยาว & เล็กน้อย หากคุณเลือกแผนการบริโภคในฟังก์ชั่นสีฟ้าด้านล่างเป็นข้อ จำกัด

ถ้าคุณต้องการใช้งานมากกว่า 10 นาทีให้เลือก webjobs ฟังก์ชัน Azure ทำงานเพียง5 นาทีโดยค่าเริ่มต้นหากกระบวนการของคุณเกิน 5 นาทีฟังก์ชัน Azure จะส่งข้อยกเว้นการหมดเวลา คุณสามารถเพิ่มหมดเวลาไป10 นาทีใน host.json

หมายเหตุ: ไม่มีปัญหาการหมดเวลาหากคุณใช้ฟังก์ชั่นบริการแผนสีฟ้า

เหตุผลที่ทำให้แตกต่างก็คือ หากคุณใช้ฟังก์ชันสีน้ำเงินแล้วเวลาเริ่มต้นเริ่มต้นของคุณจะช้าเนื่องจากเครื่อง (ตู้คอนเทนเนอร์) ถูกสร้างขึ้นทันทีและถูกทำลายเมื่อมีการใช้งาน

เพื่อหลีกเลี่ยงการเริ่มเย็นแอปฟังก์ชั่นสีฟ้าได้เปิดตัวแผนระดับพรีเมี่ยมโดยที่อินสแตนซ์หนึ่งจะทำงานตลอดเวลาและขึ้นอยู่กับโหลดแอพพลิเคชั่นจะเริ่มขยายขนาดและคุณจะถูกเรียกเก็บเงินสำหรับอินสแตนซ์เดียว

ฉันรู้ว่าฉันมาช้ามากกับเกมด้วยคำตอบนี้ แต่เนื่องจากนี่ยังเป็นผลการค้นหาอันดับต้น ๆ ของ Google ฉันต้องการให้คำแนะนำเกี่ยวกับหัวข้อนี้อย่างเคร่งครัดจากมุมมองด้านต้นทุนเนื่องจากดูเหมือนว่า OP มีความกังวลเกี่ยวกับต้นทุน . มีคำตอบที่ดีอยู่แล้วที่นี่ที่พูดคุยเกี่ยวกับข้อ จำกัด ทางเทคนิคและรายละเอียดเกี่ยวกับการทำงานของแต่ละบริการดังนั้นฉันจะไม่ตอบคำถามเหล่านั้นซ้ำอีก

หากคุณต้องการบางสิ่งบางอย่างที่ทำงานเพื่อ "ฟรี" (เหมือนไม่มีค่าใช้จ่ายเพิ่มเติมสำหรับสิ่งที่คุณจ่ายไปแล้วสำหรับแอปพลิเคชันเว็บของคุณ) จากนั้นคุณมีสองตัวเลือก:

1. Webjobs - ปรับใช้พร้อมกับเว็บแอพที่มีอยู่ของคุณและใช้ทรัพยากรเดียวกับเว็บแอปของคุณ ไม่มีค่าใช้จ่ายทางการเงินเพิ่มเติมในการใช้ webjobs แต่มีข้อ จำกัด บางประการดังที่กล่าวไปแล้วซึ่งสามารถนำไปสู่ต้นทุนด้านประสิทธิภาพในแอปพลิเคชันเว็บของคุณ
2. ฟังก์ชั่น - เมื่อใช้แผนการใช้งานคุณจะได้รับการดำเนินการฟรีจำนวนหนึ่ง จำนวนตอนที่เขียนนี้จริง ๆ ก็สูงมากการประหารชีวิตฟรี 1 ล้านครั้ง อย่างไรก็ตามขีด จำกัด การดำเนินการ 1 ล้านไม่ใช่ขีด จำกัด ที่น่าจะทำให้เกิดปัญหา มันคือ 400K GB-s (กิกะไบต์วินาที) นี่คือการคำนวณจำนวนหน่วยความจำที่ฟังก์ชันของคุณใช้คูณด้วยจำนวนวินาทีที่ทำงาน (ดูการคำนวณอย่างเป็นทางการในหน้าการกำหนดราคาที่นี่ ) คุณจะประหลาดใจที่การจัดสรรฟรีนี้หมดไปอย่างรวดเร็ว

หากคุณมีความกังวลเกี่ยวกับค่าใช้จ่าย แต่ไม่ จำกัด อยู่ที่ไม่มีค่าใช้จ่ายเลยคุณมีตัวเลือกเพิ่มเติมให้เลือก

1. ฟังก์ชั่น - คุณสามารถเรียกใช้ทั้งในแผนบริโภคหรือแผนบริการแอพในราคาที่ไม่แพง โปรดทราบว่ารูปแบบการเรียกเก็บเงินของ GB หากคุณใช้แผนการบริโภคและกำลังทำบ่อยงานหนัก "- คุณอาจประหลาดใจกับใบเรียกเก็บเงินขนาดใหญ่
2. บริการคลาวด์ - ตัวเลือกนี้ไม่ได้ถูกกล่าวถึงเป็นทางเลือกส่วนใหญ่เป็นเพราะ OP ไม่ได้ถามเกี่ยวกับมัน แต่นี่ก็เป็นตัวเลือกที่ทำงานได้ ในที่สุดบริการคลาวด์ก็คือ VMs ที่ทำงานอยู่ในคลาวด์ดังนั้นคุณจึงสามารถเรียกใช้งานพื้นหลังใดก็ได้ที่คุณต้องการและปรับขนาดขึ้น / ลงได้ค่อนข้างดี (แม้ว่าคุณต้องเชื่อมต่อทริกเกอร์ของคุณเองเพื่อดำเนินการ ) พวกเขามีค่าใช้จ่ายเริ่มต้นมากขึ้นที่เกี่ยวข้องกับพวกเขา (เพราะคุณจ่ายต่อกรณีไม่ว่าคุณจะใช้หรือไม่) แต่ถ้าคุณมีงานที่ต้องทำงานอย่างต่อเนื่องและมีการยก "หนัก" จำนวนมากบริการคลาวด์อาจเป็นทางเลือกที่ดีกว่า เพราะมันง่ายต่อการจัดการ / ตรวจสอบ VM ราคาคงที่กว่าการประมวลผลและวินาทีกิกะไบต์ในความคิดของฉัน

หากคุณมีความสนใจในการอ่านผ่านสถานการณ์บางอย่างและเหตุผลที่ผมจะเลือกอย่างใดอย่างหนึ่ง (webjobs ฟังก์ชั่นการให้บริการคลาวด์) ในช่วงอื่น ๆ ผมก็เพิ่งเขียนบล็อกโพสต์บนwebjobs เทียบกับฟังก์ชั่นเทียบกับบริการคลาวด์

ข้อควรพิจารณาที่สำคัญคือฟังก์ชัน Azure ออกจากการสนับสนุน. NET Framework แบบเต็มหลังจากเวอร์ชัน 1 ซึ่งถูกยกเลิกด้วย v2.0 และซึ่งจะไม่เปลี่ยนแปลงในตอนนี้ในเวอร์ชันพรีวิว v3.0 😔

• เอกสารนี้จะทำให้ล้างที่นี่ ,

• เช่นเดียวกับการตอบสนองความคิดเห็นนี้ ,

• เช่นเดียวกับปัญหานี้ GitHub / การตอบสนอง

ในขณะเดียวกันแนวทางการใช้อาวุธที่แข็งแกร่งนี้ยังไม่ได้นำไปใช้กับAzure WebJobs :

เวอร์ชัน 3.x ของ WebJobs SDK สนับสนุนทั้งแอปคอนโซล. NET Core และ. NET Framework

ฉันอยากจะให้สิ่งที่เป็นเรื่องธรรมดาและความแตกต่างระหว่างสองฟังก์ชั่น Azure ที่สร้างขึ้นบน AppService และ WebJobs SDK WebJobs SDK จะให้อิสระแก่คุณในการเล่นมากขึ้นในขณะที่ฟังก์ชั่น Azure มีโครงสร้างที่มากขึ้นโดยมีความรับผิดชอบน้อยลงสำหรับนักพัฒนา

เมื่อคุณดู commonalities ทั้งสองใช้โหมดการเขียนโปรแกรมฟังก์ชั่นที่มุ่งเน้นการผูกสำหรับทริกเกอร์ / อินพุต / เอาต์พุตสนับสนุนห้องสมุดภายนอกและสามารถเรียกใช้และแก้จุดบกพร่องในท้องถิ่น Supportruntime อุปกรณ์ในห้องน้ำ

ความแตกต่าง

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