我有几个使用RESTful API的HTTP服务器和一个使用Akka w/ Play Framework的Scala WebSocket服务器。（React式）服务器被我的移动的应用程序用于实时更新。HTTP服务器将与Scala服务器通信，将数据推送到移动应用程序。当有1个Scala服务器时，这很好用，因为所有的移动客户端都连接到同一个Scala服务器。然而，我想部署第二个WebSocket服务器，这会中断流程。
Scala 1
- 客户端1
- 客户端2
斯卡拉2
- 客户端3
- 客户端4
HTTP 1（为客户端3发送消息）-〉LoadBalancer -〉Scala 1
Scala 1没有连接到客户端3，所以消息永远不会到达客户端。
如何将两个Scala服务器连接在一起，以便即使Scala 1收到消息，Scala 2也会将消息发送到客户端3？或者可能共享客户端池，以便Scala 1可以通过套接字将消息发送到客户端，即使客户端最初连接到Scala 2？
我曾想过实现SNS，让HTTP后端将事件推送到Queue，然后让Scala后端订阅Queue，但我并不热衷于此，因为有些事件是从移动的客户端发送的，我也希望两个Scala服务器都能接收到。示例：HTTP 1（向所有客户端发送报价）-〉SNS -〉两个Scala服务器向所有客户端广播报价-〉客户端3向Scala发送接受-〉Scala 2接收，取消对Scala 2上其他客户端的报价，Scala 1不知道，保持报价对Scala 1上连接的客户端开放
我不得不再次发布事件到SNS取消其他服务器上的现有优惠。这将是一个很大的工作。
我真的需要两个服务器作为一个。
1条答案
按热度按时间bakd9h0s1#
一般来说，您需要做的是让两台服务器形成一个cluster，这可以有效地看作是允许两台服务器形成一个系统。（由于各种原因，通常，集群中最好至少有三台服务器）。然后，到任何服务器的HTTP或WebSocket连接都可以（对HTTP/WebSocket连接的另一端透明）与任何其他服务器交互。
在Akka中使用集群工具包的具体部分取决于具体情况。例如，如果来自HTTP的大多数消息都是针对单个客户端的，并且有少量（比如少于10万左右）的WebSocket客户端，并且客户端错过偶尔的更新是可以接受的，那么在集群中使用distributed pub sub是合理可行的：当客户端连接到WebSocket时，处理程序生成一个actor，它订阅一个具有与客户端相关联的唯一ID的主题。请求向给定客户端发布消息的HTTP请求的处理程序然后将向与该客户端相关联的主题发布消息。如果相反，你的HTTP消息主要是广播，并且预期接收者集比客户端少（并且最多有10 k左右的接收者集），然后你可以把这个反过来：对于每个允许的接收者集合都有一个主题，并且客户端通过发布到该主题的HTTP请求订阅相应的主题。
如果需要保证消息的传递，并且您可能有超过数万个客户端，并且大多数消息都是点对点的，那么cluster sharding（以及可能的持久性，取决于您希望在集群成员关系等更改方面的保证有多强）是一个很好的工具：你的HTTP请求处理程序将给定客户端的消息转发到与该客户端关联的分片实体，而你的WebSocket处理程序本质上订阅了该分片实体（你可能需要自己实现缓冲等功能：这是Akka文档中谈到的那种“更自定义的解决方案”），并转发来自客户端的确认（这样的确认本质上是域问题的一部分）：注意，任何给定的HTTP-message-〉entity -message-〉WebSocket -ack-〉entity消息流都可能需要集群中的至少三个或四个网络跳（取决于您是否想要响应HTTP请求，并指示该消息是否明确为websocket客户端缓冲）。