我计划创建一个从SaaS到on软件的通信解决方案.一些细节:
我的目标是在这些服务器上调用REST调用.
我的方法是创建一个轻量级的“代理”软件,它位于防火墙后面,并启动与云‘中继服务’的通信(从而避免防火墙问题)。它可以维护双向连接,无论是使用使用(或滥用) HTTP协议的基于拉或推的方法。其他服务将通过中继服务与前提服务器通信.
我的设计考虑:
我想从你对这样的软件系统的经验学习。
发布于 2018-06-29 11:57:55
您在远程计算机上设置代理的计划实际上是绕过防火墙和您将遇到的其他此类问题的一个要求。这里没有具体说明的细节是相关的,所以我要做一些假设。
我将假设您希望远程服务器接收所有消息。换句话说,如果远程服务器关机并返回,那么在关闭时发送的消息仍然是可用的。我还假设不需要本地服务器和远程服务器之间的实时“会话”--远程服务器将接收消息并在方便时对其进行操作。
有了这些假设,您最好使用像RabbitMQ、Amazon或Azure队列服务这样的队列消息传递系统。您可以为每个远程服务器创建一个队列(具有可预测的名称,以便远程代理能够找到它),并且本地服务器可以根据需要向队列添加消息。远程服务器上的代理将从队列中读取并对其执行操作(可能该操作只是调用另一个API并传递任何数据)。通过队列,您可以保证远程服务器将接收到所有用于它的消息,即使该服务器在发送消息时处于瘫痪状态。这也消除了远程服务器和特定内部服务器之间的紧密耦合,从而极大地提高了您和远程客户端的可伸缩性(如果他们想让两个服务器运行代理)。
顺便说一句,如果您确实需要这两个服务器实时交换信息,您可以向队列中发送一条消息,以便远程服务器“调用我”,在这种情况下,远程服务器只为需要更及时的交互而向内部服务器打开一个web套接字。其他不像时间敏感的交互可以像上面描述的那样使用请求队列,远程服务器可以使用类似的响应队列来发布内部服务器从队列中提取的响应。在每条消息中都有一个conversationID,这也允许在内部端进行大规模的扩展。
另一个注意事项,取决于您的用例持久消息传递可能是一个优势。也请看一下卡夫卡,AWS,或Azure事件中心。
https://stackoverflow.com/questions/51061214
复制相似问题