选择哪种设计模式

Question

我需要一个指向正确方向的指针。我一直在环顾四周，似乎找不到任何可以为我指明正确方向的设计模式 (GoF)。

我正在开发一个小型数字标牌应用程序原型，其中有一个简单的服务器和连接到该服务器的大量播放器应用程序（显示图像/视频）。我的要求是能够将 100 个播放器连接到单个服务器，并向每个播放器分发 50Mb 数据。

我计划在服务器和玩家之间建立小型集线器（软件集线器），在集线器中收集玩家（每个大约 25 个？）并让集线器获取和分发 50Mb 数据（分而治之，对吗？） . 50Mb 仅适用于原型，我估计在现实生活中显示视频将更多约为 300Mb。这些集线器的原因是我会避免让 100 个玩家同时请求 50Mb，而只有 4 个（每个有 25 个玩家）集线器会请求和重新分配。

使用集线器时，我需要能够在集线器之间移动玩家，即从一个集线器中移除玩家并将其连接到另一个集线器。 （我的一个想法是所有连接到同一个集线器的玩家都必须共享内容，因此集线器将避免下载 25 部不同的电影）

请问，有谁知道这在现实生活中是如何做到的？您能否对我的概念发表评论和/或指出正确的方向，以帮助我解决这个问题。

Answer 1

在设计之前不要“选择”设计模式。 先设计，再与模式对比。

您的设计不必总是遵循模式。 但是，请确保您的设计不遵循反模式。

Answer 2

您需要退后一步。目前，您正试图专注于软件架构的细节，而没有考虑（或至少提及）一些重要要求。

您似乎只是在尝试流式传输视频。所以：

• 您可以使用现成的视频流产品吗？这可能比自己构建更便宜。

如果没有：

• 广播模型是否适合您，还是必须按需提供？也就是说，假设客户端 1 请求视频 A。如果几分钟后，客户端 2 也想要视频 A，如果客户端 2 成为客户端 1 正在接收的同一流的另一个查看器，是否可以？

  李>

• 这将通过互联网交付，还是在您可以控制的专用网络上交付？

如果您使用的是专用网络并且广播模型可以工作，那么您可以使用 UDP 多播，与纯粹的按需解决方案相比，它可以显着减少带宽。

因此，在您开始决定您的软件架构之前，您需要考虑您的硬件限制以及它们对您可用选择的影响。

回到您提出的解决方案，我认为它不会非常可靠地扩展。如果某一特定内容非常受欢迎，那么您的其中一个中心将严重超载，而其他中心则处于闲置状态。您可能想研究一种更传统的负载平衡技术，它允许您通过简单地添加更多服务器来进行横向扩展。