在应用服务计划中托管 Azure 函数时，与使用与相同应用服务计划相关联的应用服务（编辑：对于 Restful API）相比，是否存在显着差异？我认为唯一的区别是函数提供了额外的开箱即用触发器。我遗漏的任何差异会导致更喜欢另一个？
我还想确认，如果应用服务计划中未配置缩放，在应用服务计划中托管 Azure Functions 实际上会限制可扩展性。据我了解，在使用 Consumption 或 Premium 托管时，Functions 会根据需要自动扩展，无需额外配置。
答案 0 :(得分：0)
主要区别在于您如何付款。
当您使用应用服务计划时，您还可以控制您的函数在哪个 VNET 中运行。您可能有使这变得重要的安全要求。
您是对的，如果您在未配置为可扩展的应用服务中运行它，那么吞吐量将受到分配的硬件的限制。
详情见：https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale
答案 1 :(得分：0)
在应用服务计划中托管 Azure 函数时，与使用与同一应用服务计划关联的应用服务相比，是否存在显着差异？我认为唯一的区别是函数提供了额外的开箱即用触发器。我遗漏的任何差异会导致更喜欢另一个？
嗯，Azure 函数与应用服务不同。 Azure 函数是 triggered by an external event or a timer。然后它执行函数的代码。当托管在消费计划上时，允许此执行运行 5 or 10 minutes max。当您需要更长的执行时间时，您需要在应用服务计划上运行它。
应用服务可以托管您创建的任何应用。比如一个网站（连续运行，在开始做某事之前不需要触发）或 api。
<块引用>我还想确认，如果应用服务计划中未配置缩放，在应用服务计划中托管 Azure Functions 实际上会限制可扩展性。据我了解，在使用 Consumption 或 Premium 托管时，Functions 会根据需要自动扩展，无需额外配置。
正确，在应用服务计划中托管 Azure Functions 时，您有责任确保扩展应用服务以允许该功能在负载下良好运行。这就是消耗计划旨在处理此问题的原因，以便开发人员可以专注于功能，而无需担心基础架构。
所以，对于集成场景来说，天蓝色的函数是非常自然的搭配。对于网站，应用服务可能是最佳解决方案。
解决您的评论：
<块引用>我应该提到这个问题是在托管 RESTful API 而不是 UI 应用程序的上下文中。在这种情况下，我看不到函数和应用服务之间的太大区别，但如果我遗漏了什么，请纠正我
有几件事：首先，有一个特定的甜蜜点。如果流量足够大，基于 azure 功能的消费计划可能比拥有专用应用服务计划的成本更高。这当然取决于很多因素（CPU 使用率、请求持续时间等）。此外，您将无法开箱即用地使用诸如 Asp.Net Core Middleware 之类的东西。 最后，我认为，如果您的 api 变得足够大，管理单个 asp.net 核心解决方案可能比管理许多具有小功能的 azure 函数或一个具有大量功能的 azure 函数项目更容易，但是嘿，这只是我的意见（老实说还没有真正处理过）
需要考虑的一些资源：