微服务体系结构，每个浏览器都有一个Websocket连接

遵循典型的微服务REST体系结构 多台服务器运行并公开不同的控制器，分别为每个功能提供服务

我的问题是：

假设我的业务逻辑=需要实时计算和实时响应的实时web应用程序，其中应用程序中的多个客户端相互通信

我的选项仅限于在每个浏览器之间使用websocket连接，并在它们之间连接中介服务器

但是，这个架构对我来说有点模糊，因为我对一个巨石调解人不感兴趣

如果我遵循REST微服务体系结构，我将强制每个浏览器打开多个/许多套接字连接，这不是我的目标

我的方法是通过每个客户机的一个套接字连接使用所有套接字事件，并在后端领域处理它

我的想象让我进一步想象了一个由多个微服务组成的体系结构，如下所示：

套接字处理程序服务

功能1服务

功能2服务

所有连接与内部插座，就像一个大的后端网格

但那会失败，因为我需要扩大规模。。。 扩展每个功能后端服务器以支持每秒数百万个请求

所以这将使我能够维护彼此相关的集群

通过阅读本文，您可能会理解此主题的原因 需要一些建筑学的想法

我对高可维护性和高性能的追求需要复杂的体系结构 但是我越想它，我就越回到巨石的方法

---

是否有推荐的体系结构？

不确定推荐的体系结构，但我会给出我的想法，因为我一直在与类似的体系结构决策作斗争

在前端，假设您正在处理30万用户，假设一台服务器可以处理5千个套接字连接，那么负载平衡器后面将有60台服务器。这60台服务器中的每台服务器大约都会打开5千个套接字连接，如果用户刷新浏览器，他将获得到60台服务器中任何一台的新套接字连接

这60台服务器中的每台都连接到Kafka群集

在连接到这60台服务器中的任何一台时，您将返回某种标识令牌、GUID或其他内容（

309245f8-05bd-4221-864f-1a0c42b82133）

），然后该服务器将通过卡夫卡向GUID

309245f8-05bd-4221-864f-1a0c42b82133

连接到自身的所有其他59台服务器广播，这59台服务器中的每台都将更新其内部注册表，以注意

309245f8-05bd-4221-864f-1a0c42b82133

属于服务器1

您需要决定当用户刷新时会发生什么，他是丢失现有消息还是您希望保留这些消息？ 如果用户在刷新后仍应继续接收消息，即使用户现在已连接到新服务器，则在连接到新服务器时，浏览器需要将该GUID存储在Cookie或其他内容中，新服务器将广播到所有其他59台服务器，这些服务器现在属于Server2，Server1将更新自身以注意它

将GUID存储在前端时，您需要考虑安全性，如果有人劫持该GUID，他们可以拦截您的请求，因此确保cookie仅限于HTTP、安全并设置相关CORS设置

您的后端将是侦听来自Kafka的消息的服务器，您可以以这种方式拥有任意数量的服务，如果一台服务器难以跟上，只需启动更多实例，从1个实例增加到2个实例，您的处理能力将翻一番（例如）。每个后端实例将只跟踪前端具有的同一注册表，而不是通过GUID跟踪哪个套接字连接到哪个前端实例，后端将跟踪哪个前端实例处理哪个GUID

通过套接字接收消息后，Server2将通过Kafka发布消息，在Kafka中，任何数量的后端实例都可以拾取消息并对其进行处理。该消息包含GUID，因此如果需要返回响应，后端只需发送回标有该GUID的消息，正确的前端服务器将接收该消息，并通过套接字将响应消息发送回浏览器客户端

如果60个前端实例中的任何一个脱机，websocket应重新连接到剩余的任何实例，后端应收到通知，这些5k GUID已移动到其他服务器。如果消息到达错误的服务器，前端实例应将该消息发送回后端，并带有重新路由指令

Kafka只是许多可能的解决方案之一，您可以使用RabbitMQ或任何其他排队系统，也可以自己构建一个。消息队列应具有高可用性，并可根据需要自动缩放，并且在任何时候都不应丢失消息

---

因此，简言之，负载平衡器后面的许多前端实例使用消息队列在它们之间进行同步，并与能够访问数据库和集成的后端实例进行对话。

只考虑同一领域中的事情。 事实上，我认为你的想法很复杂，目前我看不出有什么真正的问题

所以可能是为了同步或澄清，以防我误解。 我的方法是：

---

客户端-Websocket->FDS负载平衡器->功能调度器服务（FDS）

FDS-Websocket->FS1负载平衡器->功能服务1（FS 1）

FDS-Websocket->FS2负载平衡器->功能服务2（FS 2）

---

->客户端与前端负载均衡器通话。所以你可能会制造出很多FDS

->然后，每个客户端都有一个持久连接