Какой шаблон дизайна выбрать - PullRequest
4 голосов
/ 01 сентября 2010

Мне нужен указатель в правильном направлении. Я оглядывался по сторонам и, похоже, не могу найти какой-либо шаблон дизайна (GoF), который укажет мне правильное направление.

Я занимаюсь разработкой небольшого прототипа приложения для цифровых вывесок, в котором есть простой сервер и несколько приложений проигрывателя (отображающих изображение / видео), подключенных к этому серверу. Мои требования состоят в том, чтобы иметь возможность подключить 100 игроков к одному серверу и распределять данные по 50 МБ каждому.

Я планирую создать небольшие хабы (программные хабы) между сервером и игроками, собирая игроков (около 25 в каждом?) В хабах, и чтобы хабы получали и распределяли данные по 50 Мб (разделяй и властвуй, верно?) , 50 МБ предназначены только для прототипа, и я считаю, что в реальной жизни показ видео будет более 300 МБ каждый. Причина этих концентраторов заключается в том, что я бы не стал требовать, чтобы 100 игроков запрашивали 50 МБ одновременно, вместо этого только 4 (по 25 игроков в каждом) будут запрашивать и перераспределять.

При использовании хабов мне нужно будет иметь возможность перемещать игроков между хабами, то есть вынимать игрока из одного хаба и прикреплять его к другому хабу. (я думаю, что все плееры, подключенные к одному и тому же концентратору, должны обмениваться контентом, поэтому хаб не будет загружать 25 разных фильмов)

Пожалуйста, кто-нибудь знает, как это делается в реальной жизни? Не могли бы вы прокомментировать мои концепции и / или указать мне правильное направление на шаблон / книгу, которая поможет мне решить эту проблему.

Ответы [ 2 ]

8 голосов
/ 01 сентября 2010

Не « выбирайте » шаблон проектирования перед дизайном. Сначала создайте , а затем сравните с шаблонами.

Ваш дизайн не всегда должен соответствовать шаблонам. Но убедитесь, что ваш дизайн не соответствует анти-шаблонам.

5 голосов
/ 01 сентября 2010

Вы должны сделать шаг назад от этого. В данный момент вы пытаетесь сконцентрироваться на мелочах вашей программной архитектуры, не учтя (или не упомянув) некоторые важные требования.

Похоже, вы действительно пытаетесь транслировать видео. Итак:

  • Можете ли вы использовать готовый продукт для потокового видео? Это может быть дешевле, чем строить свой собственный.

Если нет:

  • Подойдет ли вам модель вещания или она должна быть по запросу? То есть, скажем, Клиент 1 запрашивает Видео А. Если через несколько минут Клиент 2 также хочет Видео А, нормально ли, если Клиент 2 становится другим зрителем того же потока, который получает Клиент 1?

  • Будет ли это доставлено через Интернет или по частной сети, которой вы управляете?

Если вы используете частную сеть, и широковещательная модель будет работать, вы сможете использовать UDP Multicast, которая может значительно снизить пропускную способность по сравнению с решением по требованию.

Поэтому, прежде чем вы начнете выбирать архитектуру программного обеспечения, вам необходимо рассмотреть ограничения оборудования и их влияние на доступные вам варианты.

Возвращаясь к вашему предложенному решению, я не думаю, что оно будет очень надежно масштабироваться. Если какой-то конкретный фрагмент контента очень популярен, то один из ваших узлов будет перегружен, а другие бездействуют. Возможно, вы захотите изучить более традиционную технику балансировки нагрузки, которая позволит вам масштабироваться, просто добавляя больше серверов.

...