我需要在微服务中实现服务器发送事件功能。相关应用程序在由两个 Pod 组成的 Kubernetes 集群中运行。但是,我不相信集群环境中的服务器发送事件能够可靠地将其注册的事件通知给所有客户端,原因如下。例如,客户端 1 注册了 pod 1 中运行的应用程序实例的通知。客户端 2 注册了 pod 2 中运行的应用程序实例的通知。下次发生相关事件时,应用程序会成功处理该事件在 pod 1 中运行(因为无论出于何种原因,负载均衡器将其定向到该位置)。因此,客户端 1 将收到该事件的通知,但客户端 2 不会,因为在 pod 2 中运行的应用程序不知道 pod 1 上刚刚发生了什么。后续事件依此类推(下一个请求可能会发送到 pod 2,例如)。
所以我正在考虑转向使用反应式流。
有人不同意我对实现 SSE(应用程序将在集群环境中运行)的看法吗?
根本问题是在 Pod 本身中保存状态信息。
在 Kubernetes 环境中运行的服务器需要完全无状态。不仅如此,负载均衡器将请求发送到哪个 Pod 并不重要。但更根本的是,Kubernetes 希望能够关闭一个 pod 并启动一个新的 pod,而不会对应用程序产生任何影响。如果状态保存在服务器中,那么当 pod 关闭时该状态将会丢失。
鉴于此,实现事件驱动流程的一个好方法是使用消息代理。每当事件发生时,都会通过代理将消息发送到服务器的所有实例。在您的特定情况下,这将触发相关服务器实例通过服务器发送事件发送该事件。
在 Kubernetes 环境中使用服务器发送的事件有一个令人讨厌的问题,尽管这也适用于任何基于推送的机制,其中客户端保持对服务器开放的连接(本质上是所有服务器)。当 Kubernetes 关闭某个 Pod 时,连接到该 Pod 的所有客户端都将断开连接。因此,客户端需要为此做好准备,并自动重新连接,从中断处无缝继续。
归档时间: |
|
查看次数: |
1759 次 |
最近记录: |