51CTO 博客地址：https://blog.51cto.com/14669127 

需求：某个企业使用Azure设计一个订单处理系统，需包含以下Azure资源：

订单处理系统将具有以下事务流：

·       客户将通过使用App1下订单

·       当收到订单时，App1将生成一条消息来检查供应商1和供应商2的产品可用性

·       集成组件将处理消息，然后根据订单的类型触发Function1或者Function2

·       一旦供应商确认产品可用性，可由Function1或Function2生成App1的状态消息

·       事务的所有步骤都将被记录到Storage1

现在需要为集成组件推荐一种类型的Azure资源以满足需求。

需求分析：Service Bus Queue是一种代理消息传递系统，它将消息存储在“broker”中，直接消费方准备好接收消息为止，因此，在获取响应时可能会有延迟，这超出了实时用户交互会话的目的，轮询可能会延迟响应，因为它将等待函数选择消息，而两个函数都应该选择相同的消息以检查两个不同供应商的可用性。一旦消息被使用，它就不再可供其他人使用。

集成组件将处理消息，然后根据订单类型触发Function1或Function2，需求中没有提到将在何处存储消息，但是Azure data Factory可以与各种平台集成并选择消息，并根据订单类型激活Function1或者Function2.

Microsoft Service Bus Queue是一个安全托管的企业消息broker，其中包含消息队列和订阅主题，Service Bus Queue是用于分离应用程序和服务，提供以下优势：

·       快Competing Workers实现负载均衡

·       跨服务和应用程序边界安全路由和传输数据和控制

·       协调需要高度可靠性的事务性工作

 

当 接收到订单时，App1将生成一个消息来检查产品可用性供应商1和供应商2，对于topic，发布者向topic发送消息，一个或多个订阅者接收消息的副本，这取决于在这些订阅上设置的筛选规则。

综上，为了满足客户需求，需要为集成组件推荐Azure Service Bus Queue为解决方案。

相关资料：

·       Service Bus queues, topics, and subscriptions

·       Use Azure portal to create a Service Bus namespace and a queue