SBA: Архитектура на основе пространства
Большинство веб-приложений для бизнеса следуют одному и тому же общему потоку запросов: запрос из браузера попадает на веб-сервер, затем на сервер приложений и, наконец, на сервер базы данных. Хотя эта схема отлично работает для небольшого числа пользователей, при увеличении нагрузки на пользователя начинают возникать узкие места, сначала на уровне веб-сервера, затем на уровне сервера приложений и, наконец, на уровне сервера баз данных. Обычная реакция на узкие места, возникающие при увеличении нагрузки на пользователей, заключается в уменьшении масштаба веб-серверов. Это относительно просто и недорого, и иногда помогает решить проблему узких мест. Однако в большинстве случаев при высокой пользовательской нагрузке масштабирование уровня веб-серверов просто переносит узкое место на сервер приложений. Масштабирование серверов приложений может быть более сложным и дорогим, чем веб-серверов, и обычно просто перемещает узкое место на сервер базы данных, масштабировать который еще сложнее и дороже. Даже если вы сможете масштабировать базу данных, в итоге вы получите топологию в форме треугольника, где самая широкая часть треугольника - это веб-серверы (их легче всего масштабировать), а самая маленькая - база данных (ее труднее всего масштабировать).
В любом высокопроизводительном приложении с очень большой одновременной пользовательской нагрузкой база данных обычно является конечным ограничивающим фактором в том, сколько транзакций вы можете обрабатывать одновременно. Хотя различные технологии кэширования и продукты для масштабирования баз данных помогают решить эти проблемы, факт остается фактом: масштабирование обычного приложения для экстремальных нагрузок - очень сложная задача.
Архитектурный паттерн на основе пространства специально разработан для решения проблем масштабируемости и параллелизма. Этот архитектурный паттерн также полезен для приложений с переменным и непредсказуемым объемом одновременных пользователей. Решение проблемы экстремальной и переменной масштабируемости архитектурным путем часто является лучшим подходом, чем попытки масштабировать базу данных или внедрять технологии кэширования в немасштабируемую архитектуру.
Описание паттерна
Шаблон space-based (также иногда называемый шаблоном облачной архитектуры) минимизирует факторы, ограничивающие масштабирование приложений. Этот паттерн получил свое название от концепции пространства кортежей (tuple space), идеи распределенной общей памяти. Высокая масштабируемость достигается за счет устранения ограничений, связанных с центральной базой данных, и использования вместо нее реплицируемых решеток данных in-memory. Данные приложения хранятся в памяти и реплицируются между всеми активными блоками обработки. Блоки обработки могут динамически включаться и выключаться по мере увеличения или уменьшения нагрузки на пользователя, что позволяет решать проблему переменной масштабируемости. Поскольку центральная база данных отсутствует, узкое место в базе данных устраняется, обеспечивая практически бесконечную масштабируемость приложения.
Большинство приложений, которые соответствуют этому шаблону, представляют собой стандартные веб-сайты, которые получают запрос от браузера и выполняют какие-то действия. В качестве примера можно привести сайт аукциона. Сайт постоянно получает ставки от пользователей Интернета через запрос браузера. Приложение получает ставку на определенный товар, записывает ее с меткой времени, обновляет информацию о последней ставке на товар и отправляет ее обратно в браузер.
В этом архитектурном шаблоне есть два основных компонента: блок обработки и виртуализированное промежуточное программное обеспечение. На рисунке 5-1 показан базовый шаблон архитектуры на основе пространства и его основные архитектурные компоненты.
Компонент блока обработки содержит компоненты приложения (или части компонентов приложения). Сюда входят как веб-компоненты, так и внутренняя бизнес-логика. Содержание блока обработки зависит от типа приложения - небольшие веб-приложения, скорее всего, будут развернуты в одном блоке обработки, в то время как более крупные приложения могут разделить функциональность приложения на несколько блоков обработки в зависимости от функциональных областей приложения. Блок обработки обычно содержит модули приложения, а также сетку данных in-memory и дополнительное асинхронное постоянное хранилище для восстановления после сбоев. Он также содержит механизм репликации, который используется виртуализированным промежуточным ПО для репликации изменений данных, сделанных одним блоком обработки, на другие активные блоки обработки.
Компонент virtualized-middleware занимается обслуживанием и коммуникациями. Он содержит компоненты, которые управляют различными аспектами синхронизации данных и обработки запросов. В состав виртуализированного промежуточного ПО входят сетка обмена сообщениями, сетка данных, сетка обработки и менеджер развертывания. Эти компоненты, подробно описанные в следующем разделе, могут быть написаны на заказ или приобретены как продукты сторонних производителей.
Динамика паттерна
Магия архитектуры на основе пространства заключается в виртуализированных компонентах промежуточного ПО и сетке данных in-memory, содержащихся в каждом блоке обработки. На рисунке 5-2 показана типичная архитектура блока обработки, содержащая модули приложений, сетку данных in-memory, дополнительное асинхронное хранилище для обеспечения отказоустойчивости и механизм репликации данных.
Виртуализированное промежуточное ПО является, по сути, контроллером архитектуры и управляет запросами, сеансами, репликацией данных, распределенной обработкой запросов и развертыванием процесс-блоков. В виртуализированном промежуточном ПО есть четыре основных компонента архитектуры: сетка обмена сообщениями, сетка данных, сетка обработки и менеджер развертывания.
Сетка обмена сообщениями
Сетка обмена сообщениями, показанная на рисунке 5-3, управляет входным запросом и информацией о сеансе. Когда запрос поступает в компонент virtualized-middleware, компонент messaging-grid определяет, какие активные компоненты обработки доступны для получения запроса, и направляет запрос одному из этих компонентов обработки. Сложность сетки обмена сообщениями может варьироваться от простого алгоритма round-robin до более сложного алгоритма next-available, который отслеживает, какой запрос обрабатывается тем или иным блоком обработки.
Сетка данных
Компонент сетки данных - это, пожалуй, самый важный и ключевой компонент данного паттерна. Сетка данных взаимодействует с механизмом репликации данных в каждом блоке обработки для управления репликацией данных между блоками обработки, когда происходит обновление данных. Поскольку сетка обмена сообщениями может направить запрос на любой из доступных блоков обработки, важно, чтобы каждый блок обработки содержал абсолютно одинаковые данные в своей сетке данных in-memory. Хотя на рисунке 5-4 показана синхронная репликация данных между
блоками обработки, в реальности она выполняется параллельно асинхронно и очень быстро, иногда синхронизация данных завершается за считанные микросекунды (одну миллионную долю секунды).
Сетка обработки
Сетка обработки, показанная на рисунке 5-5, - это дополнительный компонент виртуализированного промежуточного ПО, который управляет распределенной обработкой запросов при наличии нескольких блоков обработки, каждый из которых обрабатывает свою часть приложения. Если поступает запрос, требующий координации между типами блоков обработки (например, блок обработки заказов и блок обработки клиентов), именно сетка обработки является посредником и организует обработку запроса между этими двумя блоками обработки.
Менеджер развертывания
Компонент deployment-manager управляет динамическим запуском и выключением блоков обработки в зависимости от условий нагрузки. Этот компонент постоянно отслеживает время отклика и нагрузку пользователей, запускает новые блоки обработки при увеличении нагрузки и выключает блоки обработки при ее снижении. Это критически важный компонент для достижения переменной масштабируемости приложения.
Перевод книги "Software Architecture Patterns".