ERP订单导入中使用带azure功能的天蓝色服务总线的最佳方法
在下面的场景中，我需要一些关于如何结合Azure服务总线使用Azure函数的第二种观点和指导。编码不是一个问题，而是选择最合适的方法。可悲的是，我还没有在网上找到一个很好的例子，所以现在我正在寻求帮助。
场景
我有一个电子商务客户，每天向ERP系统发送几千份订单。正常的日常操作不是一个问题，但我们想要使解决方案更有力地处理，例如“黑色星期五”激增。目前，该网站可以容纳x数量的订单之前，该数据库是充分的，并被迫关闭或发送订单下游。目前，该网站直接发送订单到ERP系统，这是这一部分，我想解耦与Azure服务器总线队列。通过这种解耦，我们可以继续将新订单推到队列中，并以我们自己的速度在ERP中使用这些订单，而不会淹没任何系统。
我对如何设置这个问题的思考
- 网站可以直接向服务总线队列发送消息。Azure函数将在队列中的每个新消息上触发，并将该消息发送到ERP系统。
- 和上面一样，网站首先向Azure函数发送一条消息，并将其放入队列中。
- 向队列发送消息，如第1或第2点所示。而不是将函数绑定到队列，而是设置一个预定函数。
- 网站会像第1点或第2点那样将消息发送到队列中。在这里，我们不向ERP系统发送消息，而是由ERP系统读取队列。不喜欢这种方法，但它是可行的，易于管理的ERP用户。
问题
- ，如果我按照上面第1点或第2点，负责向ERP系统传递消息的函数应该每个触发器发送1或多个命令？
- ，如果我使用第1或2点，那么仍然有可能淹没ERP系统，因为它们很可能同时触发?如果ERP系统关闭并且队列增加，那么是否需要一个单独的计划函数来处理队列直到队列为空？
我们不必在这里讨论死信队列，这是另一个话题。
您将如何处理这个问题，或者如果您已经完成了类似的解决方案，您使用了什么方法？
非常感谢您的指导！
回答 1
Stack Overflow用户
发布于 2020-06-05 04:10:00
在过去的几年中，我们学到了很多，使用Azure函数和服务总线来解决上面提到的类似场景。你绝对是在正确的轨道上想要脱钩的情况下，浪涌。为了让您对选择使用Azure Service Bus感到安心，我们通常每分钟通过我们的主题和订阅推送数百个事件，并且它很好地支持。
让我分享一下我们学到的一些教训：
- --同一秒钟内传入请求的并发数--是我们的突破点之一。该网站当正确编写时，将很容易容纳多个传入请求，但我们了解了“端口耗尽”与出站web请求，我们的Azure功能。检查web客户端的范围和生命周期以及应用服务计划/ web服务器的限制。如果您选择为Azure功能使用消费计划，请注意，启动有时需要很长时间。
- A服务总线消息有一个大小限制(可以增加，但仍然有限制)。我们随机选择了一个包含大量信息的有效载荷。了解您可能遇到的最坏情况下的有效负载大小。
- 在出现问题时，如果队列中有数万条消息，那么就没有一种简单的方法来查询其中的内容。确保您对此很满意，否则可以考虑快速写入可以查询的数据库。
- -- Azure函数可以由Service触发，并且可以产生多个并发执行代码(这是需要的)，并且有一定的限制。注意使用代码更新ERP的任何限制。您将无法控制服务总线触发器。environment).
- Connections
- 需要注意该函数的存储帐户，同名函数的触发器设置和锁将相互执行(dev vs.prod
- to Azure Service Bus有时会失败，这只是托管在云中的服务的性质)。这种情况只发生几次，几秒钟后就会恢复。
考虑这样做：
网站 -> Azure API管理网关 -> Azure函数A -> Service Bus -> Azure Function BE 227 -> >E 128ERPE 229
启用了saver.
- Consider的
- Azure API管理是一个很好的额外层，允许您保护、监视和路由到您的函数A。在需要将传入请求路由到某个紧急桶的情况下，这是一个生命
- ，它允许函数1接受您的项目数组。启用AppInsights，为遥测添加代码，通过一个可配置的计时器触发器和一些应用程序配置从队列中处理消息的数量，提供吞吐量的预览。允许您节流的数据到您的ERP。这可能是有争议的，因为您将无法使用多个实例扩展此函数，但我假设最初的考虑是控制速度。还启用相同的AppInsights、遥测、日志记录等
我希望我不会因此而招致太多的批评。我们学习了困难的方法，并最终从Azure建筑师和工程师那里得到了一些非常好的指导。
https://stackoverflow.com/questions/62201074
复制相似问题
腾讯云开发者
