公共交通在交换后处理辅助部署槽中的Azure服务总线消息

Question

我们有一个使用Azure服务巴士的地下交通系统。在部署应用程序时，我们首先部署到一个暂存部署槽以预热服务，然后交换这些时隙以将暂存槽投入生产。但是，消息继续在时隙交换后的暂存槽上处理。作为止损间隙，我们现在关闭交换后的暂存槽。但是有一段时间(~15分钟)，消息在插槽实际关闭之前被处理，我们不能冒可能在不同版本的处理程序逻辑不同时产生的错误的风险。

这是地下铁路的问题，还是有方法可以防止呢？在继承应用程序时，我不确定需要提供哪些实现细节。我可以提供密码..。

Answer 1

它与MassTransit无关，它与A/B交换服务(例如Azure服务总线)在这种情况下不能很好地工作有关。

最好在将消息驱动服务交换到另一个时隙之前禁用它们，或者通过确保消息向后兼容性来设计您的服务以处理同时运行的多个版本。

此外，它还有助于将您的消息消费服务与您的前端API服务(这些服务通常是实时交换的，而不是升级的)分离开来。