我正在计划一个解决方案，用于创建从 SaaS 到本地软件的通信。 一些细节：
我的目标是在这些服务器上调用 REST API。
我的方法是创建一个轻量级的“代理”软件，它位于防火墙后面并启动与云“中继服务”的通信（从而避免防火墙问题）。无论是使用（或滥用）HTTP 协议的基于拉取或推送的方法，它都可以保持双向连接。 其他服务将通过中继服务与本地服务器通信。
我的设计考虑：
我想从您使用此类软件系统的经验中学习。
【问题讨论】：
标签： architecture cloud software-design
您在远程计算机上安装代理的计划实际上是绕过防火墙和您将遇到的其他此类问题的要求。这里没有具体说明相关的细节，所以我将做一些假设。
我将假设您希望远程服务器接收所有消息。换句话说，如果远程服务器宕机又回来，它宕机时发送的消息应该仍然可用。我还将假设本地服务器和远程服务器之间不需要实时“对话”——远程服务器将接收消息并在该服务器方便时对其采取行动。
有了这些假设，您最好使用 RabbitMQ、Amazon SQS 或 Azure 队列服务等队列消息传递系统。您可以为每个远程服务器创建一个队列（具有可预测的名称，以便远程代理可以找到它），并且本地服务器可以根据需要将消息添加到队列中。远程服务器上的代理将从队列中读取数据并对其进行操作（也许该操作只是调用另一个 API 并传递任何数据）。使用队列，您可以保证远程服务器将收到所有发送给它的消息，即使该服务器在发送消息时已关闭。这也消除了远程服务器和特定内部服务器之间的紧密耦合，从而显着提高了您和远程客户端的可扩展性（如果他们希望有 2 台运行代理的服务器）
顺便说一句，如果您确实需要两台服务器实时交换信息，您可以将消息发送到远程服务器的队列以“呼叫我”，在这种情况下，远程服务器会打开一个 Web 套接字到内部服务器只是为了需要更及时交互的通信。其他对时间不敏感的交互可以使用如上所述的请求队列，以及用于远程服务器的类似响应队列来发布响应以供内部服务器从队列中提取。在每条消息中都有一个 conversationID，这也将允许在内部进行大规模扩展。
另一个注意事项，根据您的用例，持久消息传递可能是一个优势。还可以看看 Kafka、AWS Kinesis 或 Azure Event Hubs。
【讨论】：