在下面描述的场景中，我需要一些关于如何将Azure功能与Azure服务总线结合使用的第二意见和指导。编码不是问题，而是选择最合适的方法。遗憾的是，我在网上没有找到任何好的例子，所以现在我正在寻求帮助。
场景
我有一个电子商务客户，他每天向ERP系统发送几千个订单。正常的日常运营不是问题，但我们希望使解决方案更加稳健，以应对例如"黑色星期五"的激增。目前，在数据库满之前，该网站可以容纳x笔订单，并被迫关闭或向下游发送订单。目前，网站将订单直接发送到ERP系统中，正是这一部分，我想与Azure Server总线队列解耦。通过这种解耦，我们可以继续将新订单推到队列中，并在ERP中以自己的速度消耗这些订单，而不会淹没任何系统。
我对如何设置的想法
-
网站可以直接向服务总线队列发送消息。Azure功能绑定为队列中的每一条新消息触发，并将该消息发送到ERP系统。
-
与上面相同，但是网站首先向Azure功能发送消息，该功能将其放入队列。
-
网站会像第1点或第2点那样向队列发送消息。我们设置了一个调度函数，而不是将函数绑定到队列。该功能将频繁运行，每次运行向ERP系统发送1条消息。
-
网站会像第1点或第2点那样向队列发送消息。在这里，我们不向ERP系统发送消息，而是由ERP系统读取队列。不喜欢这种方法，但它可以做到，而且易于ERP用户管理。
问题
- 如果我同意上面的第1点或第2点，负责向ERP系统传递消息的功能是否应该在每个触发器中发送1个或多个订单
- 如果我采用第1点或第2点，那么仍然有可能淹没ERP系统，因为它们很可能在投入的同时触发
- 如果ERP系统关闭，队列增加，我是否需要一个单独的调度功能来处理队列，直到它变空
我们不必在这里讨论死信队列，这是另一个主题。
你会如何处理这个问题，或者如果你已经做了类似的解决方案，你使用了什么方法？
非常感谢您的指导！
在过去几年中，我们通过使用Azure功能和服务总线来解决您上面提到的类似场景，学到了很多。你肯定走在了正确的轨道上，想要在激增的情况下脱钩。为了让您对使用Azure Service Bus的选择感到安心，我们通常每分钟通过我们的主题和订阅推送数百个事件，而且效果很好。
让我分享一下我们学到的一些教训：
- 同一秒内并发的传入请求数是我们的转折点之一。网站书写正确将很容易适应多个传入请求，但我们了解到关于与出站web请求相关的"端口耗尽"Azure功能。查看您的web客户端的范围和使用寿命您的应用程序服务计划/web服务器的限制
- 如果您选择使用Azure功能的消费计划，请意识到有时需要很长时间才能开始。不管是什么点击该函数将不得不实现重试(可能是一个好的无论如何都要练习)
- 服务总线消息有大小限制(可以增加，但是仍然存在限制)。我们随机用一个有效载荷击中它其中包含大量信息。了解最坏的情况您可能遇到的有效负载大小
- 如果出现问题消息，没有简单的方法可以查询队列中的内容那里确保你对此很满意，否则请考虑对可查询的数据库进行快速写入
- Azure功能可以由服务总线触发，并且可以派生代码的多次并发执行(这是所需的)，以及有限制。请注意代码的任何限制，以更新您的ERP。您将无法控制服务总线触发器
- 注意函数的存储帐户，函数相同的名称将有其触发器设置和锁定彼此(dev与prod环境)
- 与Azure服务总线的连接有时会失败，只是托管在云中的服务的性质。这种情况只发生几次并在几秒钟后恢复
考虑这样做：
网站->Azure API管理网关->Azure功能A->服务总线->AzureFunction B->ERP
-
启用了AppInsights的Azure API管理是一个很好的额外层，允许您保护、监视和路由到功能a。在您需要将传入请求路由到某个紧急存储桶的情况下，这是一个救命稻草。
-
考虑允许函数1接受一个项目数组。启用AppInsights，添加遥测代码，提供订单吞吐量预览。
-
功能B具有可配置的定时器触发器和一些应用程序配置，用于处理队列中的消息数量。允许您限制到ERP的数据流。这可能是有争议的，因为你无法用多个实例来扩展这个函数，但我认为最初的关注点是控制速度。还启用相同的AppInsights、遥测、日志记录等
我希望我不会因此受到太多批评。我们从艰难的道路上学到了东西，并最终从Azure架构师和工程师那里得到了一些非常好的指导。