Архитектура Сервиса Проект задумавылся для реализации высоконагрузочного сервиса подобно YouTube. Для выполнения этой задачи я выделил следующие независимые компоненты сервиса :
- Ядро сервиса.
- Хранилище.
- Пользовательский интерфейс.
В проекте реализована горизонтальная масштабируемость вместе с вертикальной.
Вертикальная масштабируемость реализуется елементарно за счет наращивания мощностей определенных серверов, что есть не очень хорошо, потому что хорошое серверное оборудование стоит порядка от 20,000 $, поэтому и была реализована горизонтальная масштабируемость.
Горизонтальная масштабируемость была реализована логикой размещения роликов на разные серверы и размещение информации по разным базам данных (б/д), основываясь на критериях : категория в которую добавляют ролик, дата добавления, и id пользователя.
Реализована возможность легкой перегруппировки роликов на серверах, так как id ролика универсален. Он создается из массива 9 символов в котором находится инфа об Id клиента, дате добавления, категории и случайного числа. Благодаря этой реализации первичный ключ таблиц роликов простой, что уменьшает нагрузку на субд в разы, и предоставляет возможность передвигать записи по разным б/д без проблем, только группируя их определенным образом.
Балансировка для файловых хранилищ и субд реализована косвено по умолчанию благодаря горизонтальной масштабируемости. А вот с ядрами сервиса существует только одно предложение от меня – установка железного балансировщика. Можно организовать для файл хранилищ кластерную файловую систему, что даст лучший показатель производительности. Из кластерных фс мне известны только на Unix like системах, поэтому привязывать к определеной ОС не имело смысла, поэтому и зделал интерфейс к файл хранилищу в виде веб сайта, который можно с имулировать на любой ФС и на любом языке.
С mssql столкнулся только первый раз, поэтому и обошелся только использованием пулов соединений и хранимыми процедурами . Но в ядрах осталась возможность использовать различные субд . При использовании MySql первым же тюнингом была бы Master - Slave архитектура, с которой прекрасно уживается железный балансировщик нагрузки.
В проекте реализована работа с псевдо двумя файло хранилищами (псевдо, потому что находятся на 1 сервере, а различаются только размещением сайтов и размещением роликов). Так же рализовано в проекте две псевдо б/д (псевдо, потому что доступна на хостинге 1 б/д и, так как б/д должны были иметь стандартную структуру, как вывод, данные находятся в одних и тех же таблицах).
Выбор файл хранилища и субд производится по категориям, потому что на id пользователя и дате делать сей час бессмысленно – в плане на данном этапе развития проекта.
Реализация Сервиса Для просмотра сайта надо использовать Silverlight 2 Beta 2 Developer http://go.microsoft.com/fwlink/?LinkID=119972
Для написания проекта были использованы ASP.NET, Silverlight, MSSQL, CMS DotNetNuke.
Что зделал :
- получение первых фреймов роликов используя ffmpeg и так же с него получение длины самого ролика;
- систему коментариев;
- поиск;
- просмотр статистики пользователя, загруженных им роликов;
- автоматический выбор файл сервара на загрузку ролика;
- воплотил архитектуру сервиса в жизнь;
- всё остальное умеет делать CMS .
Что не зделал :
- - не реализован пользовательский интерфейс голосования;
- - не реализована совместимость браузеров(Opera, IE, Firefox).
Несовместимость выражается только в одном: при появлении на странице двух Silverlight приложений первый из них (вверхний – показ thumbnail'ов) не хочет автоматом подгружаться, а происходит его загрузка непосредственно только после активации его левой кнопкой мыши. Причем IE 6 и Opera 9.4(тестировал на ней) загружают всё без проблем... А IE 7 не хочет...
Проблемы в Silverlight : - Не корректную реализацию елемента MediaElement, а именно его взаимодействие с серверами, на которых размещены ролики, основываясь на ссылке http://silverlight.net/blogs/jesseliberty/archive/2008/01/31/download-error-code-4001.aspx
Обхожу это только повторной инициировкой соединения в плеере при обнаружении этой ошибки.