选择哪种设计模式

Question

我需要一个指引。我一直在寻找设计模式（GoF），但似乎找不到能指引我正确方向的模式。

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

我计划在服务器和播放器之间制作小型软件集线器（hubs），将播放器（每个集线器大约25个）收集到集线器中，并让集线器获取和分配50Mb数据（分而治之，对吧？）。50Mb只是用于原型，我认为在实际生活中，显示视频将更接近每个300Mb。使用集线器时，我需要能够在集线器之间移动播放器，即从一个集线器中删除播放器并将其连接到另一个集线器中。（我的想法之一是，所有连接到同一集线器的播放器必须共享内容，这样集线器就可以避免下载25个不同的电影）

请问，有人知道现实生活中如何做到这一点吗？您能否评论我的概念并/或指导我寻找可帮助我解决此问题的模式/书籍？

- Brian Hvarregaard

Answer 1

在设计之前不要“选择”设计模式，先进行设计，然后再与模式进行比较。

你的设计不一定要遵循模式。 但是，请确保你的设计不遵循反模式。

- pavanlimo

---

+1 - 我同意：在选择模式之前，您需要进行一些思考；解决方案（模式）应始终适合问题-而不是相反。 - Adrian K

Answer 2

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

看起来你只是想流视频。那么：

- 你能使用现成的视频流产品吗？这可能比自己构建更便宜。 - 如果不能：

- 广播模型对你是否有效，或者必须是按需的？也就是说，假设客户端1请求视频A。如果几分钟后，客户端2也想要视频A，那么客户端2成为客户端1正在接收的同一流的另一个观众是否可以？ - 这将通过互联网传递还是通过你控制的私有网络传递？

如果你使用的是私有网络，广播模型可行，则可以使用UDP组播，它可以在纯按需解决方案上提供显着的带宽降低。

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

回到你提出的解决方案，我不认为它会非常可靠地扩展。如果某个特定内容非常受欢迎，那么你的其中一个中心将过载，而其他中心则处于空闲状态。你可能需要研究更常规的负载平衡技术，这将允许你通过添加更多服务器来扩展。

- Winston Smith

---

玩家们有一个时间表，例如[视频1]，[图像1]，[图像2]，[视频2]等。当时间表过期时，它会重新开始循环，而且一个频道可能会在上午10点至11点播放，而另一个频道可能会在上午10:30至11:30播放。这意味着广播不是一个选项。此外，每个播放器（屏幕+计算机/笔记本电脑）都可以“离线”。还要求其中一些工作通过http，因此它们可以位于小商店窗口。 - Brian Hvarregaard

有时间表的频道...听起来完全像广播。多个客户端会订阅一个频道，还是你真正意思的是客户端？无论如何，如果是通过互联网，这是一个无用的问题，因为UDP组播不起作用，不幸的是。 - Winston Smith

对于我糟糕的描述，我指的是客户端。也就是在显示器上展示内容的客户端。（在我的原帖中，我也称之为“播放器”。对于我糟糕的描述，我表示歉意。） - Brian Hvarregaard