遵循典型的微服务REST架构 在其中运行多个服务器并公开不同的控制器，分别为每个功能提供服务。
我的问题是这个：
假设我的业务逻辑=需要实时计算和实时响应的实时Web应用程序，其中应用程序中的多个客户端彼此通信。
我的选择仅限于在每个浏览器之间使用websocket连接，并在它们之间连接中介服务器。
但是，由于我对整体式调解器不感兴趣，所以体系结构对我有些困惑！
如果我遵循REST微服务架构，我将强制每个浏览器打开多个/备用套接字连接，这不是我的目标
我的方法是通过每个客户端的一个套接字连接消耗所有套接字事件，并在后端领域中处理
我的想象力使我进一步想象了以下多个微服务的体系结构：
所有都与内部插座相连，就像一个大的后端网格
但这会失败，因为我需要向外扩展... 扩展每个功能后端服务器以支持每秒数百万个请求。
那么这将带我保持彼此相关的集群？
通过阅读本文章，您可能会了解该主题的原因 需要一些建筑思想。
我追求高可维护性和高性能的追求是需要一个高级架构 但是我思考的越多，我越会回到整体方法。
有没有推荐的体系结构？
答案 0 :(得分：1)
不确定推荐的体系结构，但是由于我一直在努力尝试类似的体系结构决策，因此我会考虑一下。
在前端，假设您正在处理30万个用户，假设单个服务器可以处理5k个套接字连接，那么在负载均衡器后面将有60台服务器。这60台服务器中的每台服务器大约都会打开5k套接字连接，如果用户刷新浏览器，他将获得与60台服务器中任何一个的新套接字连接。
这60台服务器中的每台都连接到Kafka集群
在连接到这60台服务器中的任何一台之后，您将返回某种识别令牌，GUID或其他内容（309245f8-05bd-4221-864f-1a0c42b82133
），然后该服务器将通过Kafka广播到GUID {{ 1}}连接到其自身，这59台服务器中的每台服务器都会更新其内部注册表，以注意309245f8-05bd-4221-864f-1a0c42b82133属于Server1。
您需要确定当用户刷新，用户丢失现有消息还是要保留这些消息时会发生什么？
如果即使用户现在已连接到新服务器，用户在刷新后仍应继续接收消息，则浏览器需要将该GUID存储在Cookie或其他内容中，连接到新服务器后，该新服务器将广播到所有其他59现在309245f8-05bd-4221-864f-1a0c42b82133属于Server2的服务器，Server1会更新以记录下来。
在前端存储GUID时，您需要考虑安全性，如果有人劫持了GUID，他们可以拦截您的请求，因此请确保仅将Cookie设为HTTP，安全并设置相关的CORS设置。
您的后端将是服务器，这些服务器将监听来自Kafka的消息，您可以通过这种方式获得任意数量的服务，如果一台服务器难以跟上，只需将更多实例（从1个实例扩展到2个实例），即可进行处理容量翻倍（例如）。每个后端实例将仅跟踪前端具有的相同注册表，而不是跟踪哪个套接字通过GUID连接到哪个前端实例，而是跟踪哪个前端实例处理哪个GUID。
Server2通过套接字接收到消息后，将通过Kafka发布消息，任何数量的后端实例都可以提取并处理该消息。该消息中包含GUID，因此，如果需要返回响应，则后端将简单地发送回带有该GUID的消息，并且正确的前端服务器将其接收并通过套接字将响应消息发送回浏览器。客户。
如果60个前端实例中的任何一个脱机，则websocket应该重新连接到任何其余实例，应该通知后端那些5k GUID已移至其他服务器。如果消息到达错误的服务器，则前端实例应将该消息连同重新路由说明一起发送回后端。
Kafka只是众多可能的解决方案之一，您可以使用RabbitMQ或任何其他排队系统，也可以自己构建。消息队列应该具有高可用性，并可以根据需要自动扩展，并且绝不会丢失消息。
简而言之，负载均衡器后面的许多前端实例使用消息队列在它们之间进行同步并与有权访问数据库和集成的后端实例进行通信。
答案 1 :(得分：0)
只需在同一领域中思考事物即可。 实际上，我认为您的想法相当复杂，目前还没有发现真正的问题。
所以，如果我误解了，可能是为了同步或澄清。 我的方法如下：
客户端-Websocket-> FDS负载平衡器->功能调度程序服务（FDS）
FDS-Websocket-> FS1负载平衡器->功能服务1（FS 1）
FDS-Websocket-> FS2负载平衡器->功能服务2（FS 2）
->客户端与前端负载均衡器对话。因此，您可能会启动许多FDS。
->然后，每个客户端都具有一个与1个FDS的持久连接。
->对于每个客户端，相应的FDS对于每个后续的FS将具有一个持久连接。
->同样，这些最终的FS也可以通过前端负载平衡器到达。 因此，您也可能会增加其中的许多。
当前，我认为这是一个很好的解决方案，它具有可伸缩性，并且使每个部分都非常简单。
唯一不那么简单的是负载平衡器如何为FS做出平衡决策。 （连接数量与FS繁忙度）