如何在Azure上为匿名HTTP API消息创建代理？

Question

我们需要Azure上的API，以便在我的系统（云服务）不可用或数据库繁忙的情况下，通过HTTP存储发送给它（代理）的消息。更改将发送的确切消息并不容易。有哪些方法可以在Azure上建立这样的经纪人？

Service Bus Queue看起来很有趣，但据我所知它需要Shared Access Signatures。

另一个WebRole应该是一个解决方案，但需要时间来实现。

使用某种工具（MSMQ？）的虚拟机似乎是一种方式，但它需要维护。

你怎么看？

Answer 1

您的方案是应用以队列为中心的工作模式的主要候选人。

来自http://www.asp.net/aspnet/overview/developing-apps-with-windows-azure/building-real-world-cloud-apps-with-windows-azure/queue-centric-work-pattern：

如果您的工作人员或数据库不可用，则邮件仍会放在持久存储中并在以后消耗。

任务队列可以采用Azure存储队列或服务总线队列的形式。在每一个伟大的设计中，完成工作的最不复杂的组件都会获胜。在这种情况下，Azure存储队列，耐用，可靠，移动部件非常少。除非您绝对需要精确的FIFO排序，否则您需要使用Service Bus。

来自https://msdn.microsoft.com/en-us/library/dn568101.aspx：

  

此解决方案具有以下优势：

     

  

• 它启用了一个固有的负载分级系统，可以处理应用程序实例发送的请求量的大范围变化。该队列充当应用程序实例和使用者服务实例之间的缓冲区，这有助于最小化对应用程序和服务实例的可用性和响应性的影响（如基于队列的负载级别模式所述）。处理需要执行长时间运行处理的消息不会阻止消费者服务的其他实例同时处理其他消息。

  

• 提高可靠性。如果生产者直接与消费者通信而不是使用此模式，但不监视消费者，则消费者失败时消息很可能丢失或无法处理。在此模式中，消息不会发送到特定服务实例，失败的服务实例不会阻止生产者，并且任何工作服务实例都可以处理消息。

  

• 它不需要消费者之间或生产者和消费者实例之间的复杂协调。消息队列确保每条消息至少传递一次。

  

• 可扩展。随着消息量的波动，系统可以动态增加或减少消费者服务的实例数量。

  

• 如果消息队列提供事务性读取操作，它可以提高弹性。如果消费者服务实例在事务操作中读取并处理消息，并且此消费者服务实例随后失败，则此模式可以确保将消息返回到队列以由另一个实例接收和处理。消费者服务。

  

Answer 2

鉴于您无法更改客户端，我会代理呼叫。使用Azure中的API Management Service重新创建API，并将Web URL更改为指向API Management Service代理。

然后，代理可以使用function application

轻松委托给您问题的评论中提到的API Management Service policies.类似Aravind的{{3}}