Kim*_*orn 5 spring activemq-classic stomp spring-websocket spring-cloud
我们一直在评估 Spring-Stomp-Broker-websockets，以使其成为在 AWS 上运行的全双工类型消息应用程序。我们原本希望使用 Amazon MQ。我们向个人用户推送消息，也进行广播。所以从功能上来说，这个堆栈看起来确实不错。我们有大约 40,000 - 80,000 名用户。通过负载测试，我们很快发现 Spring 堆栈或 Amazon MQ 都无法很好地扩展，存在以下问题：
\n\n是的，我们增加了机器上的文件句柄等，因此 TCP 连接不是限制。Spring 不可能接近这里的限制。我们正在发送一条 18 K 的消息，用于负载，这是我们期望的最大值。在我们的结果中，消息大小几乎没有影响，它只是 Spring Stack 上的连接开销。
\n\nStompBrokerRelayMessageHandler 为每个 STOMP Connect 打开与 Broker 的连接。没有办法集中连接。因此，这使得这个 Spring 功能对于任何 \xe2\x80\x98real\xe2\x80\x99 Web 应用程序完全无用。为了支持我们的用户，用于 MQ 的 AWS 大型服务器的成本意味着该解决方案非常昂贵，需要 40 台最大的服务器。在负载测试中，Amazon MQ 机器不执行任何操作，对于 1000 个用户，它没有加载。实际上，我们所有代理只需要几台中型机器即可。
\n\n有没有人曾经使用 Spring Stack 构建过一个现实世界的解决方案（如上所述）。似乎没有人这样做过，也没有人扩大规模。\n有人写过池化 StompBrokerRelayMessageHandle 吗？我认为这一定有一个原因可以\xe2\x80\x99t工作，因为它应该是默认方法？这里有什么问题？
\n\n似乎这个问题使得整个 Spring Websocket + STOMP + Broker 方法变得毫无用处，我们现在被迫使用不同的方法来保证消息可靠性，以及在用户未连接的服务器之间进行消息传递（我们使用代理的主要原因）并且已经消失也使用简单代理，并编写了一个注册表来管理客户端服务器位置。所以我们现在已经消除了经纪人，上面的数字是该模型的。为了消息的可靠性，我们可能会添加 AWS SQS。
\n\n还剩下什么。我们本来打算使用 Spring Cloud Gateway 在多个小型 WebSocket 服务器之间进行负载平衡，但似乎这种方法行不通，因为服务器可以处理的 WebSocket 负载太小了。网关无法处理它。我们现在正在删除 Spring Cloud Gateway 并改用 AWS 负载均衡器。所以现在我们可以获得更多的连接负载平衡。为什么Spring Cloud Gateway没有负载均衡？
\n\n还剩下什么。websocket 服务器实例是 t3.mediums，它们没有业务逻辑，只是在 2 个客户端之间传递消息，因此它确实不需要更大的服务器。我们预计连接数会明显好于 4,000 个。不过，这已经接近可用了。
\n\n我们现在正在深入研究这些问题，以获取有关性能瓶颈所在的更多详细信息，但缺乏任何调优指南或扩展信息并不意味着 Spring 有什么好处。将此与 Node 解决方案进行比较，Node 解决方案可扩展性非常好，并且可以在小型计算机上处理大量连接。
\n\n下一个方法是看看 WebFlux + WebSocket，但随后我们就失去了 STOMP。也许我们\xe2\x80\x99会检查原始的websockets？
\n\n这只是一个早期尝试，看看是否有人真正愤怒地使用过 Spring Websockets 并可以分享真实的工作生产架构，因为只有玩具示例可用。因此，任何有关上述问题的帮助将不胜感激。
\n| 归档时间： |
|
| 查看次数： |
1419 次 |
| 最近记录： |