Архитектура ПО для веб-приложений высокой степени сложности

 

Автор: Александр Третьякевич

Задачи архитектуры

Архитектура приложения должна строиться исходя из следующих задач:

  • обеспечение необходимого уровня производительности для конкретной подсистемы/отрасли
  • масштабируемость для обеспечения жизненных циклов приложения (небольшой масштаб в начале; рост масштаба при росте популярности системы)
  • независимость (масштабирование одного компонента не должно влечь за собой масштабирование всей системы или изменение среды функционирования приложения)
  • удобство обслуживания

 

Высокоуровневое определение архитектуры

Архитектура ПО будет основываться на сервис-ориентированной концепции, с разделением служб по вертикальной и горизонтальной иерархии (в зависимости от свойств конкретной службы). Все службы сообщаются друг с другом двумя способами:

  • синхронный способ (прямое/управляемое взаимодействие через синхронную шину ESB)
  • асинхронный способ (генерирование и захват событий при помощи высокопроизводительного конвейера на основе сообщений)

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

Компоненты архитектуры

Высокоуровневая схема архитектуры представлена ниже:

top level architecture

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

Синхронная шина ESB

Synchronous ESB bus

В приложении будет использован ESB-подобный тип коммуникации между отдельными службами, формирующими цельное приложение. Все службы имеют открытый публичный интерфейс (через реестр служб), и используют системную синхронную транспортную шину для связи между собой по типу точка-точка. Синхронная свяязь используется для запроса данных и выполнения процессов по запросу.
Архитектура обеспечивает службам возможность использования различных средств связи, в т.ч. веб-сервисов (Java Axis и др.), XML-RPC вызовов, RPC-вызовов (Corba и др.), собственных протоколов. Самое очевидное решение – привязка к одному транспорту (например, к веб-сервисам) для уменьшения избыточности. Реализация ESB может основываться и на проприетарном облегченном протоколе собственной разработки, и на уже имеющихся решениях с открытым исходным кодом (типа Mule Java).

Реестр служб

service registry

Реестр служб отвечает за отслеживание и сбор информации (для системы в целом) о зарегистрированных службах, их адресах, текущем состоянии и возможностях, в т.ч.:

  • информации о хостах, содержащих текущие службы (или о точках входа для кластеров служб)
  • состоянии текущей службы (доступна/недоступна)
  • версии службы (для оперативного отслеживания состояния развертывания приложения в целом)
  • получение запросов от бизнес-служб и перевод их в адресные запросы

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

Асинхронная шина событий

asynchronous event bus
Приложение будет использовать асинхронную шину событий для обмена асинхронными событиями между компонентами системы (как локальными, так и удаленными). Обработка событий начинается с получения их службами (хотя время обработки того или иного события определяется только самой службой) и заканчивается либо формированием новых событий, либо обработкой в режиме “тихого” процесса.
Шина событий имеет следующие режимы работы:

  • широковещательная рассылка события всем получателям
  • адресная посылка события определенному получателю
  • Р2Р-обмен между двумя службами

Асинхронный транспорт

async transport
Асинхронный транспорт предназначен для использования в качестве высокоскоростного средства связи для асинхронной шины событий. Возможно использование следующих решений:

  • JMS (сервер+брокеры, напр. Apache MQ) – стандарт де-факто в настоящее время
  • AMQP (напр. RabbitMQ) – быстро набирающая популярность альтернатива
  • любой проприетарный легковесный протокол обмена сообщениями (меньше вероятность дополнительных расходов на разработку)

База данных приложения

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

Клиентское приложение

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

  • слой DAO (может быть основан на Hibernate)
  • бизнес-слой (образующий доменную структуру вместе с DAO), для облегчения разработки может быть использован Spring IoC
  • презентационный слой (веб-интерфейс пользователя с компонентами на AJAX, выбор конкретного способа реализации будет произведен после уточнения деталей спецификации с заказчиком).

Клиентское приложение с самого начала должно быть готово к установке в кластере (несколько веб-серверов + Apache Balancer).

Административное приложение

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

  • слой DAO (может быть основан на Hibernate)
  • бизнес-слой (образующий доменную структуру вместе с DAO), для облегчения разработки может быть использован Spring IoC
  • презентационный слой (веб-интерфейс пользователя с компонентами на AJAX, выбор конкретного способа реализации будет произведен после уточнения деталей спецификации с заказчиком).

Служба контроля доступа (СКД)

access control service
В состав системы входит централизованная СКД, обеспечивающая всем остальным службам возможность контроля доступа. Учитывая кластерную организацию системы, СКД может использовать следующие способы упрощения системы и повышения её производительности:

  • единый сервис авторизации, включенный в состав службы (все контексты пользователя сохраняются в самой службе, клиентские службы и приложения работают только с токенами)
  • каждая служба может использовать кэш разрешений (через интеграцию с универсальным узлом СКД на сервере) для уменьшения нагрузки на сеть; дальнейшим архитектурным усовершенствованием может стать использование распределенного пула памяти/кэша (напр. Terracota) для увеличения производительности и упрощения процедуры синхронизации кэша.

Служба массовых уведомлений (СМУ)

mass notification service
СМУ обеспечивает системе возможность отправки уведомлений по e-mail (в зависимости от ситуации, служба может быть сделана максимально независимой от канала связи для обеспечения поддержки возможно большего числа способов уведомления, таких как внутренние сообщения, SMS и т.д.). СМУ решает следующие проблемы:

  • балансировка нагрузки на систему в случае необходимости отправки большого числа e-mail сообщений
  • использование нескольких хостов SMTP для обхода ограничений на число отправляемых сообщений (в т.ч. ограничений спам-фильтра) и увеличения пропускной способности системы в целом
  • отложенная обработка заданий на уведомление (полностью асинхронный режим работы клиента)

Служба статистики

statistics service
Служба статистики предназначена для обработки сырых данных из приложения и генерирования рассчитанной и подготовленной статистики (в системах большого масштаба немедленная обработка статистики по каждому запросу является крайне неэффективной). Статистические данные могут сохраняться как в главной БД, так и в выделенной БД статистики (для повышения производительности и облегчения резервного копирования). Служба статистики также ответственна за контроль целостности данных в БД статистики.
Т.к. служба статистики является асинхронной, пользователь может выделять записи основной БД типа “только чтение” в качестве источника для сбора статистических данных (незначительная латентность БД в данном случае не представляет серьезной проблемы).

Служба оплаты

payment service
Служба оплаты обеспечивает необходимый уровень абстракции для работы с различными платежными системами в интернете и предоставляет интерфейс для оплаты в режиме оффлайн. Ядро службы оплаты предоставляет стандартный набор платежных инструментов, в т.ч. комбинированные платежи (по картам и т.д.), возвраты / Net30, периодическое пополнение, отчеты и т.д.

Служба рекламы

advertisiment service
Служба рекламы предоставляет возможность размещения баннерной рекламы раличных типов (PPC/PPI) и осуществляет отслеживание баннеров для службы статистики.

Служба поиска

search service
В системе предусмотрено 2 способа поиска: полнотекстовый (основан на внутреннем индексировании данных, индексах из внешних источников и тэгах) и бизнес-поиск (специфический поиск для бизнеса с расширенными возможностями). Полнотекстовый поиск может быть реализован на поисковом движке Lucene (например, в форме интеграции Compass / Hibernate Search). Реализация бизнес-поиска зависит от его конкретного придназначения.

Служба индексирования / веб-обходчик

indexing service
Веб-обходчик предназначен для индексирования внутренних страниц приложения (для текстового поиска) и внешних сайтов. Служба позволяет управлять процессом обхода страниц для каждого конкретного ресурса (в случае защищенного сайта и т.д.).

Вам понравилась статья и Вы хотите заказать у нас приложение? Свяжитесь с нами прямо сейчас!