Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Задачи Трёхуровневой Архитектуры

Anna | 4.06.2014 | нет комментариев
N-Tier vs eXtreme Application Platform
Задачи Трёхуровневой Архитектуры

Множество современных софт приложений для бизнесов состоят из 3-ех ярусов. 1-й слой содержит данные, которые в своем большинстве хранятся в реляционной базе данных (relational database). Тут данные сохраняются, модернизируются, извлекаются и отправляются в дальнейший, логичный слой. 2-й слой это бизнес-логика (business logic), тот, что обрабатывает команды и вычисления, исполняет логические решения и передает и обрабатывает данные между окружающими слоями. В мире JEE данный ярус обыкновенно представлен при помощи JEE application servers, такими как WebSphere, WebLogic и JBoss. В большинстве случаев существует обособленный веб ярус, либо слой заказчика, тот, что ответственен за представление задач и итогов, внятных пользователю. Как правило, перед веб ярусом стоит балансировщик нагрузки (load balancer).
Уйма приложений также применяют ярус сообщений (messaging), обеспечивая верное асинхронное взаимодействие с компонентами приложений и вероятность внедрения обработки информации при помощи событийно-ориентированных (event-driven) образцов. Сервисы бизнес-логики принимают сообщения из этого яруса в порядке их поступления в систему и обрабатывают их. Для достижения высокой доступности (high availability) и увеличения способности обработки большего числа данных все ярусы применяют кластерную архитектуру (cluster).

image
Анализируя эту архитектуру с легкостью дозволено выявить несколько явственных задач:
1. Сложности в управлении: все ярусы имеют разные модели кластеризации. Для управления такой системой требуются познания и навык работы со всеми из них. Это влечет за собой:
a. Высокую стоимость: компании обязаны приобретать отдельные лицензии для всех комбинированных частей и нанимать специалистов для установки и поддержки всякого из ярусов. Помимо того, кластеризация некоторых составляющих не неизменно примитивна и, нередко, полна непредусмотренных сложностей даже для самых опытных экспертов.
b. Сложности в контролировании: отслеживание и мониторинг такого большого числа компонентов в настоящей работающей системе в следующий раз требует дополнительных источников. В большинстве случаев, нужно приобретать добавочные софт приложения для таких целей.
c. Сложности в идентификации и решении задач: сложно определить что и на каком ярусе случилось если система вышла из строя
d. Сложности во внедрении программного обеспечения: межмодульная интеграция и конфигурация также может послужить дополнительным источником затрат. Принудить все модули «общаться» верно один с иным, как правило, займет некоторое время и добавочные источники.
2. Такая зодчество привязана к статическим источникам, таким как суровые диски и имена серверов. Дюже сложно будет установить такое приложение на виртуализированных платформах (virtual platforms/environments), так как те (платформы) дюже динамичны по своей натуре.
3. Время ожидания (latency) и эффективность (performance): в таких архитектурах бизнес-транзакция (transaction) обыкновенно проходит через множество (если не через все) ярусов системы перед ее заключением. Это включает в себя уйма сетевых прыжков (network hops) между ярусами и внутри них.
В добавок, гарантирование достоверности бизнес-транзакций подразумевает запись на диск в тот либо другой этап программы. Сетевой и дисковой I/O гораздо ограничивает масштабируемость (scalability) и увеличивает latency бизнес-транзакций. Как итог, Трехуровневая Зодчество не может быть предсказуемо масштабирована. Если увеличить нагрузку на систему, что в свою очередь затребует огромнее источников для обработки информации, то добавка добавочного аппаратного обеспечения вряд ли решит задачу. Встроенная опора на сетевое и дисковое I/O по сути ограничивает вероятности системы. Больше того, нередко добавка дополнительных источников в один из ярусов (скажем, слой данных) не только не поможет, но может даже повысить время ожидания и понизить эффективность системы в целом из-за убыточных затрат связанных с синхронизацией узлов кластера.

Отчего cache и datagrid решения не разрешают загвоздку
Дабы решить задачи времени ожидания и масштабируемости обыкновенно ставят in-memory datagrid перед реляционной базой данных. Бесспорно, это решение в верном направлении, которое Отчасти разгружает систему и, в основном, подходит для считывания данных (data cashing). Стоит обратить внимание, что множество datagrids ограничены своей вероятностью извлекать данные только при помощи неповторимого идентификатора. Правда такое решение может быть примененов отдельных случаях, все же оно не безупречно по дальнейшим причинам:
1. Оно добавляет еще один ярус, для которого требуются добавочные лицензии. Как и все другие, новейший ярус необходимо интегрировать, конфигурировать, контролировать и удалять неисправности, если возникнут. Таким образом, это увеличивает всеобщую трудность управления данной архитектурой и расходы на ее установку, поддержку и обслуживание.
2. Как было упомянуто выше, решения данного примера помогут для систем, где в большинстве операций извлекаются данные. Но это безусловно напрасно для систем, где данные необходимо сберегать либо модернизировать.

Пример из реального мира
Позже столь длинного вступления, я предлагаю продемонстрировать всю вышесказанную теорию на примере, напротив все это не имеет никакого смысла. Разглядим реальную многоуровневую архитектуру системы компании Kohl’s из сферы интернет продаж.
image
Сразу кидается в глаза, что всюду нас поджидают те самые «тесные места» (bottlenecks), через которые всякими методами необходимо пропустить всю приходящую информацию. Очевидно, что добавление дополнительных источников в всякий из ярусов никак не поможет избавиться от существующих скептических элементов (bottlenecks) каждой системы (между ярусами).
Сервера WebLogic, Apache и база данных Oracle восхитительно справлялись с заданием, применяя 50 физических серверов. 30,000 единовременно подсоединенных пользователей исправно получали результаты на все требования и запросы. Оно бы все продолжало трудиться и отныне, если бы, скажем, компания должна была бы обслуживать определенное фиксированное число транзакций ежесекундно, и не происходило бы никаких крутых изменений в требованиях к системе.
Впрочем, та самая «черная пятница» (Black Friday, когда миллионы американцев рвутся в магазины, а ритейлеры делают 20, а изредка и 30 процентов от годовой выручки за один день) 2009-го года затребовала следующие данные: система должна справляться с нагрузкой в 500,000 пользователей единовременно. К такому удару вышеупомянутая зодчество была не готова, а позднее не было смысла чинить тонущий корабль без его полной реконструкции. Итог: мульти-миллионная потеря прибылей.

Альтернатива
На протяжении последних десяти лет на рынке возникли приложения, которые с легкостью справляются с данными задачами и находятся в эксплуатации в скептически значимых системах (mission critical systems) в сферах финансовых служб, интернет продаж (как у Kohl’s), онлайн игр и других. Одним из таких является XAP (eXtreme Application Platform) так же вестимо как In-Memory Computing Platform.
image
XAP это платформа для разработки программного обеспечения, которая:
1. Разрешает запускать всё приложение в целом на одной платформе, в то время как все ярусы из многоуровневой архитектуры работают в одном контейнере (container).
2. Разрешает стремительное обращение к данным, так как всё хранится в памяти. Хранение данных близко к бизнес-логике ликвидирует задержки в транзакциях связанные с обращениями к дискам либо сетевыми задачами. Следственно, расположение данных, бизнес-логики и messaging в одном контейнере значительно увеличивает эффективность (performance). Увеличение продуктивности измеряется в десятки, сотни, а изредка и в тысячи раз.
3. Разрешает секционирование данных (data partitioning) для самостоятельных вычеслительных единиц (processing units), предоставляет механизмы, Дабы гибко подключать компоненты приложения для обработки всяких нагрузок и динамично выделять источники для оптимального применения. Как итог, мы получаем линейную масштабируемость, оптимизированную балансировку нагрузки и результативное применение источников.
4. Гарантирует нулевое время простоя (zero downtime) при помощи жгучего резервирования (hot backup) и механического поправления позже сбоя. Совместно это также вестимо, как высокая доступность (high availability). Добавочно XAP предоставляет многоуровневые мониторинговые вероятности для нахождения и идентификации операционных и функциональных задач.
Всеобщая диаграмма архитектуры приложения разработанного на XAP:
image
(видео: www.gigaspaces.com/xap-in-memory-computing-event-processing/Meet-XAP)

Эпилог
Кто-то скажет: «А я использую многоуровневую архитектуру и дюже доволен». И дюже отлично. Не все системы в мире считаются скептически значимыми, сбои в которых могут привести к потере скептически главной информации либо к перебою в работе, что, в конце концов, переводится в потери миллионов баксов. Живя в мире, где 90% всех (да да, ВСЕХ!!!) данных было сгенерировано за последние 2 года мы обязаны понимать, что даже если сегодня нет необходимости в in-memory computing platform, то нам стоит правда бы знать о их существовании и о том какую пользу они несут. Может теснее в ближайшем грядущем подрастут требования к числу обрабатываемых данных Вашим приложением и тогда, бесспорно, in-memory computing platforms могут подмогнуть, не говоря о mission critical и BigData RealTime Analytics applications, для которых их применение легко нужно.

Пост Эпилог:
Друзья, как говорил Боромир: невозможно легко взять и написать обо каждому этом. Приходите на JUG в субботу 31 числа в ПетроКонгресс, и я расскажу вам о XAP-e гораздо больше красочно и с яркими живыми примерами.

Источник: programmingmaster.ru
Оставить комментарий
БАЗА ЗНАНИЙ
СЛУЧАЙНАЯ СТАТЬЯ
СЛУЧАЙНЫЙ БЛОГ
СЛУЧАЙНЫЙ МОД
СЛУЧАЙНЫЙ СКИН
НОВЫЕ МОДЫ
НОВЫЕ СКИНЫ
НАКОПЛЕННЫЙ ОПЫТ
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB