我正在尝试就我的特定应用程序中的服务“名册”建议获得一些反馈。我有一个与客户端保持持久套接字连接的服务器应用程序。我想进一步开发服务器以支持分布式实例。服务器“A”需要能够将数据广播到其他在线服务器实例。所有其他活动实例也是如此。
我正在尝试研究的选项:
- Redis / Zookeeper / Doozer - 每个服务器实例都会将自己注册到配置服务器,并且所有连接的服务器都会在配置更改时接收到配置更新。然后怎样呢?
- 维护与每个服务器实例的端到端连接并使用每个传出数据迭代列表?
- 一些自定义的 UDP 多播,但我需要在它之上增加我自己的可靠性。
- 自定义消息代理 - 在每个服务器连接并通知它时运行和维护注册表的服务。与每个服务器保持连接以接受数据并将其重新广播到其他服务器。
- 一些可靠的 UDP 多播传输,其中每个服务器实例只是直接广播并且不维护名册。
以下是我的担忧:
- 我很想避免依赖外部应用程序,例如 zookeeper 或 doozer,但如果它是最好的解决方案,我显然会使用它们
- 使用自定义消息代理,我不希望它成为吞吐量的瓶颈。这意味着我可能还必须能够运行多个消息代理并在扩展时使用负载均衡器?
- 如果我设法自己滚动,多播不需要任何外部进程,但否则我可能需要使用 ZMQ,这再次使我处于依赖的情况。
我意识到我也在谈论消息传递,但它与我采用的解决方案密切相关。顺便说一句,我的服务器是用 Go 编写的。关于保持可扩展性的最佳推荐方法的任何想法?
* 目标编辑 *
我真正要问的是,在给定以下条件的情况下,在分布式服务器实例之间实现广播数据的最佳方法是什么:
- 每个服务器实例与其远程客户端保持持久的 TCP 套接字连接,并在它们之间传递消息。
- 消息需要能够广播到其他正在运行的实例,以便它们可以传递到相关的客户端连接。
- 低延迟很重要,因为消息传递可以是高速的。
- 顺序和可靠性很重要。
*更新的问题摘要*
如果您有多个服务器/多个端点需要在彼此之间发布/订阅,那么它们之间的推荐通信模式是什么?一个或多个消息代理将消息重新发布到一组已发现的服务器?直接来自每台服务器的可靠多播?如何在分布式系统中连接多个端点,同时保持低延迟、高速度和可靠交付?