我有一个用于 IoT 场景的 Azure 函数,具有可预测的事件负载。目前,15个函数在同一个函数应用程序(单个dll)下运行
现在我们计划为每个函数创建一个单独的函数(15 个 dll 项目)。
为什么是 15 个函数?
- 一项功能每天处理数百万个事件,将将此功能纳入专用应用服务计划中。
- Rest 14 功能的负载非常有限,因此我们计划进入消费计划。每月免费执行 100 万次。
- 每个功能都可以独立扩展
关注
- 我需要在我的解决方案中创建 15 个项目(将根据此设计添加更多项目)
- 门户上会显示太多资源(15 个功能应用程序 + 15 个应用程序服务计划 + 1 个存储帐户(所有功能通用)),乘以 env 数量 (DEV+INT+QA+Perf+Stag+Prod) 共有186个资源
这个设计对我来说看起来不太好,但有一些优点。以敏捷模式工作:P
此设计中的资源数量或任何其他方面是否存在任何限制/问题?
最佳答案
基于此post Fabio 提出,您可以使用消费计划为所有功能应用程序提供 1 个应用程序服务。此外,如果所有函数(在消耗计划上)的负载加起来少于 100 万次执行,您也可以将它们放在一个应用程序中,但请考虑 limits在消费计划姿势中发挥作用。
至于资源数量,我认为除了Resource Group之外不会直接造成任何问题。限制。
关于Azure Function 消耗计划限制,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/53932588/