Azure Webjobs và Chức năng Azure: Cách chọn


162

Tôi đã tạo một số Webjob Azure sử dụng kích hoạt và tôi vừa tìm hiểu về Chức năng Azure .

Từ những gì tôi hiểu Chức năng Azure dường như trùng lặp với các tính năng của Azure Webjobs và tôi gặp một số khó khăn để hiểu khi nào nên chọn giữa Chức năng và Webjob:

  • Không giống như Webjobs, Chức năng chỉ có thể được kích hoạt, nó không được thiết kế để chạy quy trình liên tục (nhưng bạn có thể viết mã để tạo chức năng liên tục).

  • Bạn có thể viết Webjobs và Hàm bằng nhiều ngôn ngữ (C #, node.js, python ...) nhưng bạn có thể viết chức năng của mình từ cổng thông tin Azure để việc phát triển kiểm tra và triển khai Hàm dễ dàng và nhanh chóng hơn.

  • Webjobs chạy dưới dạng quá trình nền trong ngữ cảnh của ứng dụng web Dịch vụ ứng dụng, ứng dụng API hoặc ứng dụng di động trong khi Chức năng chạy bằng Gói dịch vụ ứng dụng cổ điển / động.

  • Về tỷ lệ, Hàm dường như cung cấp nhiều khả năng hơn vì bạn có thể sử dụng gói dịch vụ ứng dụng động và bạn có thể chia tỷ lệ một chức năng trong khi đối với webjob, bạn phải mở rộng toàn bộ ứng dụng web.

Vì vậy, để chắc chắn có sự khác biệt về giá, nếu bạn có một ứng dụng web hiện có đang chạy, bạn có thể sử dụng nó để chạy webjob mà không phải trả thêm phí nhưng nếu tôi không có ứng dụng web hiện có và tôi phải viết mã để kích hoạt hàng đợi Tôi nên sử dụng một webjob hoặc một chức năng?

Có bất kỳ cân nhắc nào khác để ghi nhớ khi bạn cần chọn?


6
Đây là một bài viết blog tôi nợ. :) Tôi sẽ cố gắng chuẩn bị phản hồi, nhưng điều này có thể là kết thúc mở một chút cho Stack Overflow, vì vậy bạn có thể cần phải hỏi điều này trên MSDN nếu nó bị đóng.
Chris Anderson-MSFT

Bài đăng trên blog đẹp (ngắn) về chủ đề này geekswithbloss.net/tmurphy/archive/2016/06/02/ Kẻ
Todd Menier

Xin chào, hãy chỉnh sửa câu hỏi của tôi để thêm liên kết. Bài viết thú vị ^^
Thomas

@ chris-anderson-msft Chúng ta có thể chạy PowerShell dưới dạng webjob không? Chúng tôi có thể cài đặt gói PowerShell trên Webjob không?
anomepani

Câu trả lời:


170

Có một vài lựa chọn ở đây trong Dịch vụ ứng dụng. Tôi sẽ không chạm vào Ứng dụng Logic hoặc Tự động hóa Azure, cũng chạm vào không gian này.

Azure WebJobs

Bài viết này thực sự là lời giải thích tốt nhất, nhưng tôi sẽ tóm tắt ở đây.

Theo yêu cầu WebJobs aka. WebJobs theo lịch trình aka. WebJobs kích hoạt

WebJob kích hoạt là WebJob được chạy một lần khi URL được gọi hoặc khi thuộc tính lịch biểu có mặt trong calendar.job . WebJob được lên lịch chỉ là WebJob đã có Công việc Lập lịch biểu Azure được tạo để gọi URL của chúng tôi theo lịch, nhưng chúng tôi cũng hỗ trợ thuộc tính lịch biểu, như đã đề cập trước đây.

Tóm lược:

  • + Thực thi / Script theo yêu cầu
  • + Thực hiện theo lịch trình
  • - Phải kích hoạt thông qua điểm cuối .scm
  • - Thu nhỏ là thủ công
  • - VM luôn được yêu cầu

WebJobs liên tục (không phải SDK)

Những công việc này chạy mãi mãi và chúng ta sẽ đánh thức chúng khi chúng gặp sự cố. Bạn cần bật Luôn bật để những thứ này hoạt động, có nghĩa là chạy chúng trong lớp Cơ bản trở lên.

Tóm lược:

  • + Thực thi / Script luôn chạy
  • - Yêu cầu luôn bật - Cấp cơ bản trở lên
  • - VM luôn được yêu cầu

WebJobs liên tục với SDK WebJobs

Đây không phải là bất cứ điều gì từ quan điểm "WebJobs tính năng". Về cơ bản, chúng tôi có SDK ngọt ngào này, chúng tôi đã viết nhắm mục tiêu WebJobs cho phép bạn thực thi mã dựa trên các kích hoạt đơn giản. Tôi sẽ nói về điều này nhiều hơn sau này.

Tóm lược:

  • + Thực thi / Script luôn chạy
  • + Ghi nhật ký / bảng điều khiển phong phú hơn
  • + Kích hoạt được hỗ trợ cùng với các tác vụ chạy dài
  • - Yêu cầu luôn bật - Cấp cơ bản trở lên
  • - Thu nhỏ là thủ công để thiết lập
  • - Bắt đầu có thể là một chút mệt mỏi
  • - VM luôn được yêu cầu

Azure WebJobs SDK

Azure WebJobs SDK là một SDK hoàn toàn tách biệt với WebJobs tính năng nền tảng. Nó được thiết kế để chạy trong WebJob, nhưng thực sự có thể chạy ở bất cứ đâu. Chúng tôi có những khách hàng chạy chúng trên vai trò công nhân và thậm chí trên các đám mây đầu hoặc khác, mặc dù hỗ trợ chỉ là nỗ lực tốt nhất.

SDK chỉ đơn giản là giúp bạn dễ dàng chạy một số mã để phản ứng với một số sự kiện và thực hiện ràng buộc với các dịch vụ / v.v. dễ dàng. Điều này thực sự được đề cập tốt nhất trong một số tài liệu , nhưng cốt lõi của nó là bản chất "sự kiện" + "mã". Chúng tôi cũng đã thực hiện một số công việc mở rộng tuyệt vời, nhưng đó là mục đích thứ yếu.

Tóm lược:

  • Hầu hết trong số này được đề cập ở trên
  • +Bạn có thể mở rộng và chạy bất cứ thứ gì bạn muốn. Kiểm soát hoàn toàn.
  • - Công cụ HTTP có một chút rắc rối, nhưng nó hoạt động

Hàm Azure

Azure Chức năng là lấy mục đích cốt lõi của SDK WebJobs, lưu trữ nó như một dịch vụ và giúp bạn dễ dàng bắt đầu với các ngôn ngữ khác. Chúng tôi cũng giới thiệu khái niệm "Serverless" ở đây vì nó rất có ý nghĩa để làm điều đó - chúng tôi biết SDK của chúng tôi có quy mô như thế nào, vì vậy chúng tôi có thể làm những điều thông minh cho bạn.

Azure Chức năng là một kinh nghiệm được quản lý rất nhiều. Chúng tôi không hỗ trợ mang máy chủ của riêng bạn. Hiện tại, chúng tôi không hỗ trợ các tiện ích mở rộng tùy chỉnh nhưng đó là thứ chúng tôi đang điều tra. Chúng tôi quan tâm đến những gì bạn có thể và không thể làm, nhưng đối với những thứ chúng tôi kích hoạt, chúng rất trơn tru, dễ sử dụng và quản lý.

Mặc dù vậy, hầu hết các "khung" chúng tôi đã thực hiện để cải thiện Chức năng đều đi qua SDK WebJobs. Chẳng hạn, chúng tôi sẽ tải lên NuGet mới cho WebJobs, điều này thực sự làm tăng đáng kể tốc độ ghi nhật ký, điều này mang lại lợi ích rất lớn cho người dùng SDK WebJobs. Trong các chức năng vận chuyển như "WebJobs SDK như một dịch vụ" chúng tôi thực sự đã cải thiện rất nhiều vấn đề về kinh nghiệm.

  • + Rất nhiều ngôn ngữ được hỗ trợ
  • + Quản lý đầy đủ, nhân rộng
  • + Dễ dàng sử dụng cổng thông tin w / UX để quản lý kết nối / vv.
  • - Máy chủ không thể tùy chỉnh (chưa)
  • ~ Chạy trong một "ứng dụng" riêng biệt yêu cầu một số cấu hình trong repo của bạn, nhưng giúp bảo trì dài hạn dễ dàng hơn nhiều.
  • ~ Không cụ (chưa) Một số dụng cụ hiện đang ở alpha hoặc xem trước - https://www.npmjs.com/package/azurefunctions (cập nhật tháng 2 năm 2017: Visual Studio cụ cho Azure Chức năng bây giờ đã có trong preview: https: //blogs.msdn .microsoft.com / webdev / 2016/12/01 / visual-studio-tools-for-azure-tests / )

Tôi có lẽ thiên vị vì Chức năng là mới nhất và lớn nhất của chúng tôi, nhưng hãy thoải mái chụp nhiều khuyết điểm hơn cho Chức năng theo cách của tôi.

Có lẽ cuối cùng tôi sẽ xuất bản một blog xây dựng thêm một chút, nhưng tôi đã cố gắng giữ cho nó ngắn gọn nhất có thể cho diễn đàn này.


1
Âm thanh tuyệt vời. DM cho tôi trên Twitter (@crandycodes) nếu bạn có bất kỳ câu hỏi nào. Tôi có thể giúp bạn quảng cáo các mẫu của mình trên Azure.com nếu bạn muốn, nếu bạn muốn chia sẻ chúng.
Chris Anderson-MSFT

1
Tôi có thể thấy rằng nó hữu ích. Tôi biết có rất nhiều chỗ để thảo luận về cách chuyển từ máy chủ sang các mẫu ứng dụng không có máy chủ. Đó có vẻ như liên quan đến những gì bạn vừa mô tả.
Chris Anderson-MSFT

1
Về cơ bản, chúng tôi lấy mã và cấu hình của bạn và tạo Hàm WebJob SDK (do đó có tên Azure Hàm) dưới vỏ. Vì vậy, mã của bạn đang chạy bên trong Chức năng SDK WebJob mà chúng tôi đang quản lý cho bạn.
Chris Anderson-MSFT

1
Mỗi ứng dụng chức năng có 1 máy chủ (mà bạn có thể nghĩ là WebJob). Các chức năng của bạn trong Ứng dụng chức năng chia sẻ hệ thống tệp, cài đặt ứng dụng, bộ nhớ, cpu, v.v. Hãy thoải mái đặt câu hỏi mới.
Chris Anderson-MSFT

2
Đúng. Bộ kích hoạt hẹn giờ. Biểu thức cron của {0 * / 30 * * * *} azure.microsoft.com/en-us/documentation/articles/ Kẻ
Chris Anderson-MSFT

17

Là các chức năng Azure dựa trên SDK WebJobs, chúng cung cấp hầu hết các chức năng đã có trong WebJobs, nhưng với một số khả năng thú vị mới.

Về các trình kích hoạt , ngoài các trình kích hoạt đã có sẵn cho WebJobs (ví dụ: Bus dịch vụ, Hàng đợi lưu trữ, Blobs lưu trữ, lịch CRON, WebHooks, EventHub và Nhà cung cấp lưu trữ đám mây tệp), Chức năng Azure có thể được kích hoạt dưới dạng API. Và các cuộc gọi HTTP không yêu cầu thông tin xác thực kudu, nhưng có thể được xác thực thông qua Azure AD và nhà cung cấp nhận dạng bên thứ ba.

Liên quan đến đầu ra , sự khác biệt duy nhất là Hàm có thể trả về phản hồi khi được gọi qua HTTP.

Cả hai đều hỗ trợ nhiều ngôn ngữ , bao gồm: bash (.sh), batch (.bat / .cmd), C #, F #, Node.Js, PHP, PowerShell và Python.

Là các chức năng hiện tại trong Xem trước, công cụ vẫn không lý tưởng. Nhưng Microsoft đang làm việc trên nó. Hy vọng rằng chúng tôi có được sự linh hoạt tương tự trong việc phát triển và thử nghiệm Chức năng cục bộ như chúng tôi hiện đang làm cho WebJobs với Visual Studio.

Những lợi thế đáng kể và thú vị nhất mà Hàm mang lại là sự thay thế của việc có Gói dịch vụ động với mô hình "Máy chủ" , trong đó chúng tôi không cần phải quản lý các phiên bản VM hoặc chia tỷ lệ; tất cả đều được quản lý cho chúng tôi. Ngoài ra, bằng cách không có các phiên bản dành riêng, chúng tôi chỉ trả tiền cho các tài nguyên chúng tôi thực sự sử dụng.

Một so sánh chi tiết hơn giữa hai người ở đây: https://blog.kloud.com.au/2016/09/14/azure-fifts-or-webjobs/

HTH :)


Cảm ơn câu trả lời của bạn Paco! Sự so sánh này có thể khiến nhiều người quan tâm :-) Nhưng tôi không tìm kiếm sự so sánh mà chỉ cố gắng hiểu khi nào tôi nên đi với các chức năng hơn là webjobs!
Thomas

6
Thật khó để có một hướng dẫn cắt rõ ràng mà không biết bối cảnh. Đó là lý do tại sao tôi tin rằng việc so sánh có thể giúp mọi người lựa chọn :) Tôi sẽ nói rằng: if (((preference == "Serverless") || (isRequired(flexibleHttpTriggers)) && (isOk(currentFunctionsTooling))) { goWithFunctions(); } else { continueWIthWebJobs(); } :)
Paco de la Cruz

Các hàm có thể trả về phản hồi khi được gọi thông qua HTTP. Các hàm được dựa trên SDK WebJobs. Lạ thật phải không?
RudyCo

Có lẽ tốt hơn để nói rằng họ đã dựa trên SDK WebJobs, nhưng họ đã phát triển khá nhiều từ đó :)
Paco de la Cruz

14

Theo các tài liệu Azure Chức năng có những điều sau đây mà WebJobs không:

  • Tự động điều chỉnh tỷ lệ (CPU và bộ nhớ được chia tỷ lệ theo nhu cầu được xác định khi chạy)
  • Giá trả cho mỗi lần sử dụng (gói tiêu dùng thay vì gói Dịch vụ ứng dụng)
  • Nhiều sự kiện kích hoạt hơn (như WebHooks)
  • Phát triển trong trình duyệt (Visual Studio vẫn có thể)
  • Hỗ trợ F #

Nói một cách đơn giản: Azure Chức năng là động vật mới hơn. Nếu bạn chưa có gói Dịch vụ ứng dụng, tôi sẽ sử dụng Hàm vì về lâu dài tôi không thấy bất kỳ lý do nào khiến việc bắt đầu với WebJobs sẽ tốt hơn (mặc dù công cụ chức năng có thể chưa ổn định).


14

Tôi muốn thêm hai điểm nữa vào các bài viết cũ & dài một chút ở trên. Nếu bạn chọn gói tiêu thụ trong các chức năng của phương vị, dưới đây là những hạn chế

Nếu bạn muốn chạy bất kỳ công việc nào hơn 10 phút, hãy chọn webjobs. Các chức năng Azure, chỉ chạy trong 5 phút theo mặc định, nếu quá trình của bạn vượt quá 5 phút, thì chức năng azure sẽ ném ngoại lệ thời gian chờ. Bạn có thể tăng thời gian chờ lên 10 phút trong host.json .

Lưu ý: Không có vấn đề thời gian chờ nếu bạn đang sử dụng các chức năng azure của gói dịch vụ ứng dụng.

Một lý do khác để phân biệt là. nếu bạn sử dụng chức năng azure, thì thời gian bắt đầu ban đầu của bạn sẽ chậm vì các máy (thùng chứa) được tạo ra khi đang bay và bị phá hủy một khi nó được sử dụng.

Để tránh khởi động lạnh, ứng dụng chức năng azure đã phát hành gói cao cấp, trong đó một phiên bản sẽ chạy mọi lúc và dựa trên tải, ứng dụng chức năng sẽ bắt đầu mở rộng và bạn sẽ được lập hóa đơn cho một trường hợp và các trường hợp khác dựa trên mức tiêu thụ.


Điểm đầu tiên của bạn chỉ áp dụng là bạn đang sử dụng gói tiêu dùng, với một sku trả phí, bạn không có bất kỳ giới hạn thời gian chờ nào. Tôi đồng ý với điểm thứ hai.
Thomas

Tôi nghĩ rằng cả hai điểm là hợp lệ cho kế hoạch tiêu thụ. Cảm ơn bạn đã chỉ ra
Karthikeyan VK

4
Tuyệt vời đề cập đến thời gian chờ. Đối với chúng tôi đây là một yếu tố quan trọng
Bộ lọc Niels

1
Nhưng bạn có thể chọn gói dịch vụ ứng dụng trong khi tạo các hàm azure. Nhưng nó đánh bại toàn bộ mục đích mặc dù
Karthikeyan VK

1
@KarthikeyanVK, tôi không chắc liệu nó có còn chính xác không vì chức năng runtime v2 cho phép hơn 10 phút?
Thomas

6

Tôi nhận ra rằng tôi rất muộn với trò chơi với câu trả lời này nhưng vì đây vẫn là kết quả tìm kiếm hàng đầu trên Google, tôi muốn đưa ra một số hướng dẫn về chủ đề này một cách nghiêm túc từ góc độ chi phí vì có vẻ như OP có một số lo ngại về chi phí . Đã có một số câu trả lời tuyệt vời ở đây nói về những hạn chế kỹ thuật và chi tiết về cách thức hoạt động của từng dịch vụ, vì vậy tôi sẽ không thử lại những câu trả lời đó.

Nếu bạn thực sự cần thứ gì đó chạy "miễn phí" (vì không tính thêm chi phí cho những gì bạn đã trả cho ứng dụng web của mình) thì bạn có hai tùy chọn:

  1. Webjobs - được triển khai cùng với ứng dụng web hiện tại của bạn và sử dụng cùng các tài nguyên như ứng dụng web của bạn. Không có chi phí tiền tệ bổ sung để sử dụng webjobs nhưng có một số hạn chế như đã đề cập có thể dẫn đến chi phí hiệu suất trên ứng dụng web của bạn.
  2. Chức năng - Khi sử dụng gói tiêu thụ, bạn được phân bổ một số lượng thực thi miễn phí nhất định. Con số tại thời điểm viết bài này thực sự khá cao, 1 triệu lượt thực hiện miễn phí. Tuy nhiên, giới hạn thực hiện 1 triệu không phải là giới hạn có khả năng gây rắc rối cho bạn; đó là 400K GB-giây (gigabyte giây). Về cơ bản, đây là phép tính dung lượng bộ nhớ mà hàm của bạn sử dụng nhân với số giây nó chạy (xem phần tính toán chính thức trên trang định giá tại đây ). Bạn sẽ ngạc nhiên khi sự phân bổ miễn phí này nhanh chóng được sử dụng.

Nếu bạn lo lắng về chi phí nhưng không giới hạn ở tất cả các chi phí , thì bạn có nhiều lựa chọn hơn.

  1. Chức năng - Bạn có thể chạy trong gói tiêu dùng hoặc gói dịch vụ ứng dụng với giá tương đối rẻ. Hãy ghi nhớ mặc dù, mô hình thanh toán GB-s. Nếu bạn đang sử dụng kế hoạch tiêu thụ và đang làm công việc "nặng nhọc" - bạn có thể ngạc nhiên với một hóa đơn lớn.
  2. Dịch vụ đám mây - Tùy chọn này chưa được thảo luận thay thế, chủ yếu là do OP không hỏi về nó. Nhưng đây cũng là một lựa chọn khả thi. Các dịch vụ đám mây cuối cùng chỉ là các máy ảo chạy trên đám mây để bạn có thể chạy bất kỳ công việc nền nào bạn cần trên chúng và chúng tăng / giảm tỷ lệ khá tốt (mặc dù bạn phải kết nối các trình kích hoạt của riêng mình để thực thi, một sự bất tiện nhỏ so với các chức năng / webjobs ). Họ có nhiều chi phí ban đầu liên quan đến họ (vì bạn trả cho mỗi trường hợp dù bạn có sử dụng hay không) nhưng nếu bạn có công việc cần chạy liên tục và thực hiện nhiều công việc "nặng", thì dịch vụ đám mây có thể là lựa chọn tốt hơn bởi vì nó dễ quản lý / giám sát một VM có giá cố định hơn so với thực thi và gigabyte giây, theo ý kiến ​​của tôi.

Nếu bạn quan tâm đến việc đọc qua một số tình huống cụ thể và lý do tại sao tôi chọn một (webjobs, chức năng, dịch vụ đám mây), thì tôi mới viết một bài đăng trên blog về webjobs và chức năng so với dịch vụ đám mây .


1
Cảm ơn câu trả lời @Dan :-) Tôi sẽ nói dịch vụ đám mây vẫn tốt nhưng tôi đã suy nghĩ về việc so sánh webjob và các chức năng khi chúng chia sẻ cùng một SDK lõi và 2 năm rưỡi trước đó, tôi không thực sự hiểu mục đích của serverless :-)
Thomas

3

Một cân nhắc chính là các Hàm Azure bỏ hỗ trợ .NET Framework đầy đủ sau phiên bản 1, đã bị ngừng với v2.0 và hiện tại sẽ không thay đổi trong bản xem trước v3.0. 😔

Trong khi đó, cách tiếp cận vũ trang mạnh mẽ này rất may chưa được áp dụng - cho Azure WebJobs :

Phiên bản 3.x của WebJobs SDK hỗ trợ cả ứng dụng bảng điều khiển .NET Core và .NET Framework.


Yep điểm tốt. Ngay cả tho, từ bây giờ mọi người nên thử sử dụng lõi net càng nhiều càng tốt.
Thomas

0

Tôi muốn đưa ra những điểm tương đồngkhác biệt giữa hai chức năng Azure được xây dựng dựa trên SDK AppService và WebJobs. WebJobs SDK sẽ giúp bạn tự do hơn khi chơi trong khi các chức năng Azure có cấu trúc chặt chẽ hơn với ít trách nhiệm hơn cho các nhà phát triển.

Khi bạn nhìn vào điểm tương đồng Cả hai đều sử dụng chế độ lập trình hướng chức năng, các ràng buộc cho kích hoạt / đầu vào / đầu ra, hỗ trợ các thư viện bên ngoài và có thể chạy và gỡ lỗi các thiết bị vệ sinh Supportr.78 cục bộ.

Sự khác biệt

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

nhập mô tả hình ảnh ở đây

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.