Концептуальная модель масштабируемого сервиса социальной сети



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

Ключевые слова: концептуальная модель, сервис, социальная сеть, микросервисная архитектура, масштабируемость

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

С каждым годом уровень проникновения Интернета в общество неуклонно растёт. Для России это утверждение также справедливо, о чём свидетельствуют исследования маркетинговой компании Comscore за 2011 год [1]. В отчёте компании отмечен интересный факт: среди россиян количество уникальных пользователей Интернета превысило аналогичный показатель для Германии. По результатам исследования [2], в 2015 году в России уровень проникновения Интернета среди населения в возрасте от 16 до 55 лет уже достиг отметки 70,4 %, что немало, учитывая относительно «молодой» возраст самой сети Интернет. Логично предположить, что этот показатель сохранит положительную динамику, тем самым свидетельствуя о возрастающей вовлечённости населения в сферу Интернет-технологий и, в частности, социальные сети.

Согласно данным Федеральной службы государственной статистики на 2015 год среди населения в возрасте от 15 до 72 лет численность пользователей Сети на 100 человек составила 70,1 % [3], причём по тем же данным 74,6 % пользователей посещают социальные сети [4]. Столь высокие показатели отчасти могут быть объяснены ростом доступности мобильного Интернета. С ростом числа активных пользователей Интернета увеличилось среднее время присутствия пользователей в Сети: по данным 2014 года, в среднем пользователи проводят в Интернете 121 минуту в день (в 2013 году — 100 минут), причём на социальные сети приходится значительная доля этого времени — 36 % [5].

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

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

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

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

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

Если рассматривать разработку сложного программного обеспечения, можно выявить ряд недостатков, общих для монолитных систем [6]:

‒ компоненты системы сильно связаны между собой, что существенно затрудняет их модернизацию и сопровождение;

‒ сильная связь между компонентами приводит к затягиванию жизненного цикла разработки всего продукта, поскольку участники процесса разработки вынуждены тесно взаимодействовать между собой, согласовывая все действия во избежание ошибок;

‒ монолитная архитектура делает невозможным масштабирование системы или существенно его ограничивает.

Также нужно отметить, что структура команды разработки оказывает заметное влияние на продукт, возможно и обратное. Джон Хортон Конвей однажды заявил: «Организация которая разрабатывает систему... вынуждена делать систему, по структуре повторяющую структуру коммуникаций внутри организации», и это явление носит социологический характер. Сложность монолитных по своей структуре систем и вытекающие из этого технические и организационные ограничения привели к поискам новых подходов к разработке. Результатом стремления разработчиков упростить взаимодействие между частями цельной системы стало изменение самих принципов проектирования архитектуры: акцент сместился с бизнес-сущностей на бизнес-процессы, что соответствует процессному подходу и лучше отражает реальность. Вместо сложных монолитных систем появились многокомпонентные приложения, состоящие из отдельных, самостоятельных веб-сервисов, выполняющих по одной задаче; фактически, по своей архитектуре приложения стали распределёнными. Такая архитектура получила название микросервисной (англ. microservice architecture) [7]. Микросервисная архитектура является развитием концепции сервисно-ориентированной архитектуры (SOA, англ. service-oriented architecture) [8], которая широко известна в среде корпоративных решений, но до недавнего времени не имела простых и платформонезависимых решений, что сдерживало её распространение.

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

‒ вести разработку единого продукта несколькими слабосвязанными командами;

‒ использовать разные технологические стеки для разных задач в рамках одного продукта;

‒ обеспечить разный жизненный цикл разработки разных частей приложения в зависимости от бизнес требований.

Применение микросервисной архитектуры наделяет системы следующими преимуществами:

1) технологическая разнородность. Совместно работающие микросервисы, составляющие единую систему, могут использовать внутри себя различные технологические стеки. Такой подход эффективен, поскольку позволяет для каждой задачи выбирать соответствующий инструментарий;

2) устойчивость. Микросервисная архитектура обеспечивает некоторую изоляцию компонентов системы. При отказе одного из компонентов система может сохранить работоспособность;

3) масштабирование. Можно расширить только те из микросервисов, которые требуют масштабирования.

Стандартизация механизмов взаимодействия пользователя с веб-сервисом, а также разных веб-сервисов между собой, привела к появлению нового архитектурного стиля взаимодействия приложений, который получил название REST (англ. Representational State Transfer, «передача состояния представления») [9].

Принципы REST представляют собой согласованный набор архитектурных ограничений, которые учитываются при проектировании распределённых систем [9,10]:

‒ клиент-серверная архитектура;

‒ сервер не хранит клиентское состояние (stateless-сервер);

‒ кешируемость;

‒ многослойная структура;

‒ единый интерфейс;

‒ код по требованию (опционально).

Для обозначения того факта, что дизайн веб-сервиса соответствует принципам REST, служит термин «RESTful», а интерфейс взаимодействия обозначается как RESTful API. Ниже каждый из принципов рассматривается детально.

1. Клиент-серверная архитектура требует разделения системы на серверное приложение, реализующее бизнес-логику, и различные клиенты, использующие это приложение. При такой архитектуре структура сервера становится более простой и масштабируемой, а разработка клиентской части может вестись независимо.
2. Stateless-сервер ни в каком виде не хранит состояние клиента. Эта мера упрощает не только структуру сервера, но и его доработку, а также позволяет достичь лучшей стабильности сервера.
3. Кешируемость. Наличие чёткой системы кеширования запросов к серверу может заметно снизить нагрузку на него, повысив производительность.
4. Многослойная структура сервера скрывает от клиента наличие или отсутствие промежуточных компонентов, например, серверов кеширования и балансировки нагрузки.
5. Единый интерфейс выдвигает следующие требования:

‒ идентификация ресурсов,

‒ взаимодействие с ресурсами через представления,

‒ самодостаточные сообщения,

‒ гипермедиа как двигатель состояний приложения (принцип HATEOAS).

В рамках единого интерфейса каждый ресурс обладает уникальным идентификатором URI (Uniform Resource Identifier, «универсальный идентификатор ресурса»). Например: /users/id0123 или /post/123. В качестве идентификатора рекомендуется использовать UUID (Universally Unique Identifier, «универсальный уникальный идентификатор»). UUID поддерживается большинством баз данных и поможет обеспечить кросc-системную уникальность идентификаторов.

Клиент взаимодействует с ресурсами через представление: когда клиент хранит представление ресурса, включая метаданные, то имеет достаточно данных для модификации или удаления ресурса. Также представлением можно считать URI ресурса.

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

HATEOAS (Hypermedia As The Engine Of Application State, «гипермедиа как механизм управления состояниями приложения») означает, что в каждом полученном ответе помимо информации ресурса содержится ссылка на следующий ресурс, благодаря чему происходит смена состояний.

6.Код по требованию — это опциональный элемент структуры, который позволяет клиенту получать программный код для его исполнения на стороне клиента.

Проектирование приложений как RESTful-сервисов наделяет их следующими преимуществами [10]:

‒ надёжность (за счёт отказа от хранения состояния клиента);

‒ производительность (за счёт использования кэша);

‒ масштабируемость;

‒ прозрачность системы взаимодействия;

‒ простота интерфейсов;

‒ портативность компонентов;

‒ лёгкость внесения изменений;

‒ способность эволюционировать, приспосабливаясь к новым требованиям.

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

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

‒ аутентификация и авторизация;

‒ политика безопасности;

‒ аккаунты и профили пользователей;

‒ роли пользователей;

‒ публикационная активность;

‒ хостинг медиа-контента;

‒ система аналитики.

Некоторые из представленных аспектов между собой тесно взаимосвязаны и могут рассматриваться только в совокупности, поэтому логично объединить их реализации в программных модулях. Основные компоненты приложения могут быть вынесены в отдельные модули и реализованы как микросервисы, взаимодействующие через RESTful API. Вспомогательные компоненты имеет смысл объединить с теми модулями, в которых их роль наиболее очевидна и логична.

Применение REST и микросервисной архитектуры в данном случае оправдано и позволит решить многие из поставленных задач. Такой подход к разработке даст следующие преимущества:

‒ разработка всех сервисов приложения может быть распределена между слабосвязанными командами;

‒ для каждой задачи могут быть использовать наиболее подходящие технологические стеки;

‒ жизненный цикл разработки разных частей приложения может быть разным, что позволяет быстро адаптировать приложение к новым биз-нес требованиям;

‒ пользовательский интерфейс может быть реализован отдельно и во множестве вариантов, если приложение сделать как одностраничное (англ. Single Page Application, SPA).

Планируемая архитектура приложения показана на рисунке 1. Она учитывает основные требования к сервису и позволит разработать веб-приложение с минимальными затратами.

Рис. 1. Архитектура распределённого REST-приложения

Литература:

1. Comscore. Comscore releases overview of european internet usage in September 2011. [Электронный ресурс]. 2011. — Режим доступа: http://www.comscore.com/Press_Events/Press_Releases/2011/11/comScore_Releases_Overview_of_European_Internet_Usage_in_September_2011 (дата обращения: 04.05.2016).
2. GfK. «Проникновение Интернета в России: Итоги 2015 года» [Электронный ресурс]. — Режим доступа: http://www.gfk.com/ru/insaity/press-release/issledovanie-gfk-za-2015-god-internet-auditorija-v-rossii-uvelichilas-eshche-na-4-mln-chelovek/ (дата обращения: 28.04.2016).
3. Использование сети Интернет городским и сельским населением в возрасте 15–72 лет, по Российской Федерации (ноябрь-декабрь 2015 года): Федеральная служба государственной статистики [Электронный ресурс]. — Режим доступа: http://www.gks.ru/free_doc/new_site/business/it/fed_nabl-croc/PublishData/Reports/Files/2015/3.1.xlsx (Дата обращения 04.06.2016).
4. Доля населения, использовавшего сеть Интернет, по целям его использования, типам поселения и полу, по Российской Федерации (ноябрь-декабрь 2015 года): Федеральная служба государственной статистики [Электронный ресурс]. — Режим доступа: http://www.gks.ru/free_doc/new_site/business/it/fed_nabl-croc/PublishData/Reports/Files/2015/3.11.xlsx (Дата обращения 04.06.2016).
5. Интернет в России: Состояние, тенденции и перспективы развития. Отчет по итогам 18-го российского интернет форума РИФ+КИБ 2014 — М., 2014.
6. Михайлов В. Microservices. Как правильно делать и когда применять? / Habrahabr. М.: Тематические медиа, 2016. Режим доступа: https://habrahabr.ru/company/dataart/blog/280083 (дата обращения: 15.02.2016).
7. Ньюмен С. Создание микросервисов. — СПб.: Питер, 2016. — 304 с.: ил. — Серия «Бест-селлеры O’Reilly». — ISBN 978–5-496–02011–4.
8. Коптелов А. Системы управления процессами и SOA. / КомпьютерПресс. — М.: КомпьютерПресс, 2008. URL: http://compress.ru/article.aspx?id=19374 (дата обращения: 17.09.2015).
9. REST // Википедия. [2016]. Дата обновления: 07.04.2016. URL: http://ru.wikipedia.org/?oldid=77621452 (дата обращения: 23.03.2016).
10. Thomas E. SOA with REST. // Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian. — Prentice Hall, 2013.