我们设置了一个事件网格和一个逻辑应用程序作为事件网格的订阅者。我们的核心需求之一是，一旦事件网格收到请求，就不能释放请求。不丢失请求意味着这个系统必须返回给调用者，无论成功还是失败。
所以我们所拥有的，
1.事件网格中的生存时间：当逻辑应用程序死亡时（不从事件网格中提取请求），请求将落在“生存时间”队列中，并通知调用者“失败”
1.逻辑应用程序超时：当Logic应用程序的某些部分出现故障或循环时，会发生超时，我们通知调用者“fail”
- Logic应用程序运行顺利，然后“成功”。（过于简化）
现在的问题是，如果逻辑应用程序完全崩溃怎么办？因为如果逻辑应用程序崩溃，那么它的超时（上面的2）将无法正常工作？所以我们永远不能返回到调用者？
我们是否可以在基础设施层面上采取解决方案，而无需构建复杂的机制？
比如Logic应用容灾，在不同地域设置两个示例？
或者我们应该做点什么
1.我们是否应该创建另一个计时器，与逻辑应用程序完全分离？所以额外的计时器不会和逻辑应用程序一起下降？
1.我们是否应该在逻辑应用程序进行时保存请求状态，然后创建另一个功能应用程序来查看请求状态，当逻辑应用程序重新启动时，功能应用程序根据状态拾取请求并将其再次推送到逻辑应用程序？
非常感谢
查看了MS logic应用程序技术文档
1条答案
按热度按时间bnlyeluc1#
你的问题很有意思。我只是想把一些想法扔到虚空中去塑造一些想法：）
如果你担心你的LA崩溃，并且不能通知你的事件源崩溃，当然只有两个选择，那就是冗余和/或事件持久性。
冗余：通过将解决方案展开，并让多个工作进程处理事件网格发送的事件，可以增加消息实际返回事件源的可能性。然而，该解决方案要求“成功/失败”消息的接收者能够处理重复。这个解决方案，在我看来是一个懒惰的解决方案，将在短期内工作，但并没有真正解决问题。
x1c 0d1x的数据
事件耐久度：我认为您应该做的是以某种方式涉及服务总线，以利用Dead Letter Queue / Max delivery count的优势。第一个问题是，我们如何将事件放入服务总线主题/队列？好吧，我们可以使用几个函数应用程序（在不同的区域中有多个应用程序，以避免出现单点故障）将数据摄取到服务总线中，请参见图片：
的
在正常情况下，函数应用程序将事件的多个副本摄取到服务总线，这就是Duplicate detection进来并保存我们的地方。我们现在可以正常触发Logic App，让它处理事件。一旦事件被标记为成功，消息将从服务总线中删除，并向事件源发送成功消息。
这个解决方案可能有点多，但我只是把想法扔在那里引发你的想象力。