场景
执行业务交易时，我们应该将这些数据提供给最终客户。
当前设计
我们将发布交易消息的Web应用程序添加到Azure服务总线上的主题。
我们向客户端公开API，客户端可以通过这些API消费这些交易中的数据。
调用这些API后，我们会从订阅中读取消息并将其返回给客户端。
问题
我们希望有保证的交付-我们希望确保客户确认数据的交付。因此，我们不想立即从订阅中删除该消息。我们希望保留它，直到客户确认为止。
所以我们只想做一个“窥视”而不是“接收”。
因此，客户端调用第一个API来获取数据，然后在此处进行窥视。
一旦客户端收到数据包，客户端将调用第二个API进行确认。 此时，我们要从“订阅”中删除该消息，使其完整。
Service Bus Message Receiver的当前设计是，根据文档，只能使用执行Peek的同一Receiver实例执行Complete，并且在试用时也观察到相同。
>这两个API都是两个单独的API，我们无法使用同一接收者实例来进行“窥视”和“完成”操作。
正在考虑通过某种方式使该App Service中的API成为Receiver作为Singleton的选项。 但是，当App Service向外扩展时，这将是一个问题。
有没有其他方法可以实现我们在这里要做的事情？
答案 0 :(得分：2)
Azure服务总线中提供了一个选项来延迟消息。延迟邮件后，可以借助其序列号来接收它。
第一个客户端应该接收到该消息，而不是完成它，而应该推迟并返回它。
第二个客户端（具有序列号）可以从订阅中接收消息。有关更多详细信息，请参见here。
答案 1 :(得分：1)
另一种选择是不在后端使用Service Bus客户端，而您的客户端可以使用其Service REST API直接与Service Bus一起使用（假设我了解您的情况，则他们不能使用AMQP客户端）正确）。
有一些API
如果您想使用自己的后端，或者如果已经使用APIM之类的服务，也可以代理这些请求。
PS：在MSDN forum
上交叉发布相同查询的答案