Технологии разработки распределенных приложений для социальных сетей (часть 1)

Социальные сети в начале XXI века приобрели большую популярность и широкое распространение. На сегодняшний день разработка такого типа приложений связана со значительными трудностями – инфраструктура социальных сетей недостаточно описана и не существует универсальных подходов для разработки эффективных приложений такого типа. Кроме того, в связи с очень быстрым ростом количества пользователей социальных сетей, возникает необходимость в построении надежной, расширяемой масштабируемой архитектуры социальных сетей на основе технологий распределенных вычислений.

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

Анализ современных архитектур построения распределенных приложений. Наиболее распространенными архитектурами являются двух-, трех- и пятислойные архитектуры соответственно (рис. 1).

Двухслойная архитектура появилась в первой половине 90-х годов при проектировании приложений клиент-сервер. Суть данной архитектуры заключается в следующем: существуют 2 слоя – клиент и сервер; на клиентской части приложения располагаются средства представления, а также предметная логика взаимодействия с источником данных. Такие приложения еще называют «толстыми» клиентами. На уровне сервера располагается слой источника данных, который может быть реализован в виде СУБД, LDAP, XML и др.. Такое приложение посылает серверу запросы на получение определенных данных и получает ответ в виде данных или сообщения об ошибке. Следует отметить, что приложения, состоящие из 2-х слоев, достаточно эффективны в тех случаях, когда нет необходимости в передаче данных на большие расстояния и необходимые данные и механизмы взаимодействия изменяются редко.

Трехслойная архитектура или архитектура MVC (Model View Controller) представляет собой эволюционное развитие двухслойной. В этой архитектуре слой предметной логики и представления разделены, что обеспечивает значительную гибкость создания приложений, но увеличивает сложность. Преимуществами дополнительного слоя является то, что логический слой предметной логики может быть адаптирован для различных видов представлений, таких как HTML, XML, WML и т. п. В свою очередь слой представления не зависит от источника данных, т. к. взаимодействует с ним косвенно, пользуясь услугами слоя предметной логики. Кроме того, слой источника данных может быть оставлен без изменений по сравнению с архитектурой из двух логических слоев.

Пяти, трех и двухслойная архитектура

Рис. 1. Пяти, трех и двухслойная архитектура

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

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

С серверами БД ситуация обстояла несколько хуже – промышленные сервера стоят дорого, поэтому с экономической точки зрения покупать для каждого приложения свой сервер БД невыгодно. При этом, используя трехслойную архитектуру, необходимо еще обеспечить соответствие предметной логики принципам хранилища данных, что в большинстве случаев делало приложения непереносимыми между различными серверами БД.

Решение проблемы взаимодействия слоев предметной логики и сервера БД заключается во введении дополнительного слоя – слоя сопоставления. Такой слой включает в свой состав механизмы отображения данных из БД, ориентированные на конкретную реализацию БД с одной стороны, а с другой стороны – обеспечение унифицированного интерфейса доступа со стороны слоя предметной области.

Распределенные приложения, построенные с использованием пятиуровневой архитектуры, показали значительно лучшую расширяемость при добавлении новых представлений или мигрировании на другие сервера БД. Предметная логика оставалась неизменной или дорабатывалась, но все изменения на этом уровне касались только уровней контроллера и сопоставления, но, как правило, эти изменения были достаточно простыми.

В начале XXI века начали появляться распределенные приложения, в которых большое количество пользователей стали обмениваться огромными объемами данных. Эти приложения получили название «социальные сети».

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

%d такие блоггеры, как: