我创建了一些使用触发器的Azure Webjobs ，我刚刚了解了Azure函数 。
从我所了解的Azure功能似乎与Azure Webjobs功能重叠，我有一些困难，了解什么时候在功能和Webjob之间进行选择：
与Webjobs不同，函数只能被触发，它没有被设计为运行连续的进程（但是你可以编写代码来创建一个连续的函数）。
您可以使用多种语言编写Webjobs和函数（C＃，node.js，python ...），但您可以从Azure门户编写函数，以便更轻松，更快速地开发测试和部署功能。
Webjob作为App Service Web应用程序，API应用程序或移动应用程序的上下文中的后台进程运行，而功能则使用经典/动态应用程序服务计划运行。
关于缩放，功能似乎有更多的可能性，因为您可以使用动态应用程序服务计划，您可以扩展单个功能，而对于Webjob，您必须扩展整个Web应用程序。
所以确定有一个定价的差异，如果你有一个现有的网络应用程序运行，你可以使用它运行一个webjob没有任何额外的费用，但如果我没有现有的Web应用程序，我必须编写代码来触发一个队列我应该使用一个Webjob还是一个Function？
当您需要选择时，请记住其他注意事项吗？
I've created some Azure Webjobs that use triggers and I've just learnt about Azure Functions.
From what I understand Azure Functions seem to overlap with Azure Webjobs features and I have some difficulty to understand when to choose between Function and Webjob:
Unlike Webjobs, Functions can only be triggered, it hasn't been designed to run continuous process (but you can write code to create a continuous function).
You can write Webjobs and Functions using many languages (C#, node.js, python ...) but you can write your function from the Azure portal so it is easier and quicker to develop test and deploy a Function.
Webjobs run as background processes in the context of an App Service web app, API app, or mobile app whereas Functions run using a Classic/Dynamic App Service Plan.
Regarding the scaling, Functions seems to give more possibilities since you can use a dynamic app service plan and you can scale a single function whereas for a webjob you have to scale the whole web app.
So for sure there is a pricing difference, if you have an existing web app running you can use it to run a webjob without any additional cost but if I don't have an existing web app and I have to write code to trigger a queue should I use a webjob or a Function ?
Is there any other considerations to keep in mind when you need to choose ?
最满意答案
App Service中有几个选项。 我不会碰触Logic Apps或Azure Automation，这也触及了这个空间。
Azure WebJobs
这篇文章是老实说的最好的解释，但我在这里总结一下。
又名WebJobs。 预定的WebJobs又名。 触发的WebJobs
触发的WebJobs是WebJobs，当调用URL时运行一次，或者在schedule.job中显示schedule属性 。 计划的WebJobs只是WebJobs已经创建了一个Azure调度程序作业，以按计划调用我们的URL，但是我们也支持schedule属性，如前所述。
概要：
+可执行/脚本按需 +预定执行 -必须通过.scm端点触发 -缩放是手动的 -永远需要VM连续WebJobs（非SDK）
这些工作永远运行，我们会在他们崩溃时醒来。 您需要启用始终开启这些工作，这意味着在基本层次和以上运行它们。
概要：
+可执行文件/脚本始终运行 -需要始终在 - 基础层及以上 -永远需要VM使用WebJobs SDK连续的WebJobs
这些都不是从“WebJobs的功能”的角度来看的。 本质上，我们有一个我们写的针对WebJobs的甜蜜的SDK，它允许您基于简单的触发器执行代码。 我会在稍后再说一遍。
概要：
+可执行文件/脚本始终运行 +更丰富的日志/仪表板 +支持的触发器以及长时间运行的任务 -需要始终在 - 基础层及以上 -缩放是手动设置的 -入门可能有点麻烦 -永远需要VMAzure WebJobs SDK
Azure WebJobs SDK是与WebJobs平台功能完全独立的SDK。 它的设计是在WebJob中运行，但可以在任何地方运行。 我们有客户谁运行他们的工作角色，甚至在首要或其他云，虽然支持只是最好的努力。
SDK只是为了容易地运行一些代码来响应某些事件并对services / etc进行绑定。 简单。 这在一些文档中是诚实的最好的，但它的核心是“事件”+“代码”性质。 我们还做了一些很酷的可扩展性工作，但这是次要的核心目的。
概要：
其中大部分都是在上面提到的 +你可以扩展和运行任何你想要的。 完全控制。 - HTTP的东西有点笨，但它的作品Azure功能
Azure功能全部涉及WebJobs SDK的核心目标，托管它作为一项服务，并使其易于使用其他语言。 我们还在这里介绍“无服务器”的概念，因为这样做很有意义 - 我们知道我们的SDK是如何扩展的，所以我们可以为您做点智慧的事情。
Azure功能是非常重的管理体验。 我们不支持自己的主机。 目前，我们不支持自定义扩展，但是我们正在调查的内容。 我们对您可以做什么和不能做的事情有所了解，但是对于我们所能做的事情，他们很光滑，易于使用和管理。
尽管如此，我们为改进功能而完成的大部分“框架”都是通过WebJobs SDK完成的。 例如，我们将上传一个新的WebGob的NuGet，这真的大大提高了日志记录速度，这对WebJobs SDK用户来说具有巨大的优势。 运送功能作为“WebJobs SDK即服务”，我们真的改善了很多经验问题。
+支持多种语言 +完全管理，动态缩放 +易于使用的门户网站，用于管理连接等。 -主机不可定制（还） ~运行在一个单独的“应用程序”，这需要您的回购中的一些配置，但使长期维护更容易。 ~我可能有偏见，因为功能是我们最新的和最伟大的，但随时可以为我的功能拍摄更多的缺点。
我可能会最终发布一篇更详细的博客，但是我尽量保持这个简明扼要的论坛。
There are a couple options here within App Service. I won't touch on Logic Apps or Azure Automation, which also touch this space.
Azure WebJobs
This article is honestly the best explanation, but I'll summarize here.
On Demand WebJobs aka. Scheduled WebJobs aka. Triggered WebJobs
Triggered WebJobs are WebJobs which are run once when a URL is called or when the schedule property is present in schedule.job. Scheduled WebJobs are just WebJobs which have had an Azure Scheduler Job created to call our URL on a schedule, but we also support the schedule property, as mentioned previously.
Summary:
+ Executable/Script on demand + Scheduled executions - Have to trigger via .scm endpoint - Scaling is manual - VM is always requiredContinuous WebJobs (non SDK)
These jobs run forever and we will wake them up when they crash. You need to enable Always On for these to work, which means running them in Basic tier and above.
Summary:
+ Executable/Script always running - Requires always on - Basic tier and above - VM is always requiredContinuous WebJobs with the WebJobs SDK
These aren't anything from a "WebJobs the feature" point of view. Essentially, we have this sweet SDK we wrote targeting WebJobs which lets you execute code based on simple triggers. I'll talk about this more later on.
Summary:
+ Executable/Script always running + Richer logging/dashboard + Triggers supported along with long running tasks - Requires always on - Basic tier and above - Scaling is manual to set up - Getting started can be a bit tiresome - VM is always requiredAzure WebJobs SDK
Azure WebJobs SDK is a completely separate SDK from WebJobs the platform feature. It's designed to be run in a WebJob, but can really be run anywhere. We have customers who run them on worker roles and even on prem or other clouds, though support is only best effort.
The SDK is just about making it easy to run some code in reaction to some event and make binding to services/etc. easy. This is honestly best covered in some docs, but the heart of it is that "event" + "code" nature. We've also done some cool extensiblity work, but that's secondary to the core purpose.
Summary:
Most of these are mentioned above + You can extend and run whatever you want. Full control. - HTTP stuff is a little wonky, but it worksAzure Functions
Azure Functions is all about taking that core purpose of the WebJobs SDK, hosting it as a service, and making it easy to get started with other languages. We also introduce the "Serverless" concept here because it made a lot of sense to do so - we know how our SDK scales, so we can do intelligent things for you.
Azure Functions is a very heavily managed experience. We aren't supporting bringing your own host. Currently, we don't support custom extensions but its something we're investigating. We're opinionated about what you can and can't do, but for the things we enable, they are slick, and easy to use and manage.
Most of the "framework" things we've done to improve Functions go through the WebJobs SDK, though. For instance, we'll be uploading a new NuGet for WebJobs which really drastically increases the speed of logging, which has huge perf benefits for WebJobs SDK users. In shipping Functions as "WebJobs SDK as a Service" we've really improved a lot of experience issues.
+ Lots of languages supported + Fully managed, dynamic scaling + Easy to use portal w/ UX for managing connections/etc. - Host not customizable (yet) ~ Runs in a separate "app" which requires some configuration in your repo, but makes long term maintenance much easier. ~I'm probably biased since Functions is our latest and greatest, but feel free to shoot more cons for Functions my way.
I'll probably end up publishing a blog which elaborates a bit more, but I tried to keep this as succinct as possible for this forum.
更多推荐
发布评论