我需要在微服务中实现服务器发送事件功能。有问题的应用程序在两个pod的Kubernetes集群中运行。但是，我不相信集群环境中的服务器发送事件会可靠地通知所有客户机他们已经注册的事件，原因如下。作为示例，客户端1被注册用于通知在pod 1中运行的应用示例。客户端2注册了在pod 2中运行的应用程序示例以获得通知。下一次发生有问题的事件时，pod 1中运行的应用程序将成功处理该事件（因为无论出于何种原因，pod 1都是负载均衡器将其定向到的位置）。因此客户端1将被通知该事件，但客户端2不会，因为在pod2中运行的应用程序不知道pod1上刚刚发生了什么。对于后续事件，依此类推（例如，下一个请求可能会转到pod 2）。
所以我正在考虑使用React流。
有人不同意我对实现SSE的看法吗？在SSE中，应用程序将在集群环境中运行。
1条答案
按热度按时间kjthegm61#
根本问题在于将状态信息保存在pod本身中。
在Kubernetes环境中运行的服务器需要完全无状态。这不仅仅是为了让负载均衡器将请求发送到哪个pod无关紧要。但更根本的是，Kubernetes希望能够关闭一个pod并启动一个新的pod，而不会对应用程序产生任何影响。如果状态保存在服务器中，则当pod关闭时，该状态将丢失。
考虑到这一点，实现事件驱动流程的一个好方法是使用消息代理。无论何时发生事件，都会通过代理向服务器的所有示例发送一条消息。在您的特定情况下，这将触发相关的服务器示例通过服务器发送事件发送该事件。
在Kubernetes环境中使用服务器发送事件有一个讨厌的问题，尽管这也适用于任何基于推送的机制，其中客户端保持对服务器的连接打开（基本上是所有这些）。当Kubernetes关闭一个pod时，所有连接到该pod的客户端都将断开连接。因此客户端需要为此做好准备，并自动重新连接，从中断的地方无缝地继续。