因此,我正在分析使用函数来消费来自主题的服务总线消息是否可行。
我们选择的服务总线定价计划限制了“Brokered connections' (每月最多1000)。
我的理解是,在典型的使用场景中,消费者/听众/订阅者连接到主题并持续保持连接,在很长一段时间(一天,甚至一周)内接收多条消息而不断开连接,并且这被视为1'代理连接'。最后,您可以在单个代理连接上接收数千条消息。
这如何与Azure功能绑定一起使用?从我在文档中看到的,一个函数可以是空闲的(即没有运行),因此它无法维持这种持久连接。
是否有一个单独的功能组件可以保持此连接处于侦听传入消息的状态?或者,每当函数空闲然后重新启动时,我们是否会收到新的代理连接的费用?
我包括当前计划功能的屏幕截图: https://azure.microsoft.com/en-us/pricing/details/service-bus/
稍后在同一链接中:
修改
来自Docs:
服务总线收费超过所包含数量的并发代理连接峰值数量(标准层中为1,000)。峰值按小时计算,按一个月除以744小时按比例计算,并在每月结算期间累加。包含的数量(每月1,000个代理连接数)在结算周期结束时应用于按比例分配的每小时峰值的总和。
他们特别提及"每月1,000个经纪人连接"在最后一句话。
这是一个例子:
10,000个设备中的每一个都通过单个AMQP连接进行连接,并从服务总线主题接收命令。设备将遥测事件发送到事件中心。如果所有设备每天连接12小时,则需支付以下连接费用(除了任何其他服务总线主题费用):10,000个连接* 12小时* 31天/ 744 = 5,000个代理连接。在每月允许1,000个代理连接后,您将被收取4,000个代理连接,每个代理连接的费用为0.03美元,总计120美元。
所以我猜这一切都是为了在12小时内同时连接到主题的10.000个订户,如果他们每天连接24小时,那么会收取9,000个代理连接(10,000减去所包含的1,000个)?
无论如何,我还试图验证功能是否可以持久连接(我告诉他们使用webjobs)。
答案 0 :(得分:3)
Azure Functions有一个称为ScaleController的独立组件,可以全天候监控服务总线的事件。
由于函数中的底层SB消息接收器是在WebJobs中实现的,因此将有一个连接可以在Function实例的整个生命周期内检索多个消息,尽管由于其当前的限制,它会传递这些消息。您的功能代码的处理时间。
您只需在功能代码实际运行时付费。这是一个链接,为您提供ScaleController的概述:https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale#runtime-scaling
如果您预计负载相对较高,您是否考虑使用Event Hub而不是Service Bus? Azure功能中的ServiceBus-Triggers目前一次只能处理一条消息,这对于高负载方案来说不是最佳的。这是一个GitHub问题,可以跟踪此功能请求:https://github.com/Azure/azure-webjobs-sdk/issues/1024
EventHub-Triggers可以批量处理消息,这样可以为每个Function执行提供更多功能。见https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-event-hubs