在设计与SaaS与本地软件的通信时需要帮助

时间:2018-06-27 11:06:46

标签: architecture cloud software-design

我正在计划一个解决方案,用于创建从SaaS到本地软件的通信。 一些细节:

  1. 具有REST API的Java WEB服务器
  2. 〜10,000台服务器
  3. 没有全局访问权限

我的目标是在这些服务器上调用REST API调用。

我的方法是创建一个位于防火墙后面的轻型“代理”软件,并启动与云“中继服务”的通信(从而避免出现防火墙问题)。无论是使用HTTP协议(或滥用)的基于拉或推的方法,它都可以维持双向连接。 其他服务将通过中继服务与本地服务器通信。

我的设计注意事项:

  1. 我应该使用网络套接字还是HTTP长轮询技术?
  2. SaaS服务响应是同步到达还是异步到达?换句话说,请求者服务将被阻塞,直到响应到达或响应可用时将其推送。中继服务将管理请求生命周期以进行进度监视。
  3. 扩展云服务
  4. 由于间接通信,请求和响应的大小应该受到限制吗?
  5. 我还缺少另一种方法吗?

我想向您学习有关此类软件系统的经验。

1 个答案:

答案 0 :(得分:1)

您的在远程计算机上安装代理的计划实际上是绕过防火墙和您将遇到的其他此类问题的要求。这里没有指定相关的详细信息,因此我将作一些假设。

我将假设您希望远程服务器接收所有消息。换句话说,如果远程服务器关闭并恢复正常,则关闭时发送的消息仍将可用。我还要假设本地服务器和远程服务器之间不需要实时的“对话” –远程服务器将接收消息并在方便时使用该消息。

基于这些假设,使用RabbitMQ,Amazon SQS或Azure Queue Service之类的队列消息传递系统会更好。您可以为每个远程服务器创建一个队列(名称具有可预测的名称,以便远程代理可以找到它),并且本地服务器可以根据需要向队列中添加消息。远程服务器上的代理将从队列中读取并对其执行操作(也许该操作只是调用另一个API并传递任何数据)。使用队列,您可以确保远程服务器将接收所有针对它的消息,即使该服务器在发送消息时已关闭也是如此。这也消除了远程服务器和特定内部服务器之间的紧密耦合,从而极大地提高了您和远程客户端的可伸缩性(如果他们希望有2台运行代理的服务器)

顺便说一句,如果您确实需要两台服务器实时交换信息,则可以将消息发布到远程服务器的队列中以“呼叫我”,在这种情况下,远程服务器会打开Web套接字仅用于需要更及时交互的通信的内部服务器。对时间不太敏感的其他交互可以使用如上所述的请求队列,以及用于远程服务器的类似响应队列,以发布用于内部服务器从队列中拉出的响应。在每封邮件中都带有一个sessionID,这也将允许在内部进行大规模扩展。

另一个注意事项,取决于您的用例,持久消息传递可能是一个优点。还可以查看Kafka,AWS Kinesis或Azure Event Hub。