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

XAP (Хреновая Зодчество Разоряет)

Anna | 4.06.2014 | нет комментариев
чера я 1-й раз написал статью на прогр, не зная местных тонкостей.

Исправляюсь! Сейчас внятным языком и с юмором!

Чёрная пятница оказалась воистину чёрной для aмериканского интернет-универмага Kohl’s. Все сервера накрылись медным тазом именно в день рождественских распродаж. Привычные 20% годового дохода, добываемые в данный день, обернулись смешным пустяком, а все потому что Боливар не перенес такой нагрузки.

Традиционная зодчество Tomcat WebLogic БД облажалась по полной программе! Бесполезно бегали по этажам сисадмины, суетились в панике ведущие программисты, а архитекторы выдирали остатки волос… Горлышко бутылки оказалось слишком тесным для того, Дабы в него могли протиснуться все потенциальные заказчики и неудовлетворительно гибким, Дабы за короткое время его дозволено было поспеть расширить. Бутылку разорвало нахрен. И длинно еще кровоточили раны, нанесённые ее осколками…

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

– Сынок, работает – не трогай!
– Отец, оно не работает, оно ТОРМОЗИТ!!!

Каждому вам восхитительно вестима ветхая, но вдалеке не неизменно добросердечная трёхуровневая зодчество.

трёхуровневая зодчество

1-й слой содержит данные, которые в своем большинстве хранятся в реляционной базе данных, если мы говорим про крупные объёмы, то, видимо, выбор падёт на Oracle. Тут данные сохраняются, модернизируются, извлекаются и отправляются в дальнейший, логичный слой. На втором слое находит бизнес-логика, любые EJB, Spring и Hibernate. Где будет сидеть каждый данный код? Ну безусловно в сервере приложений – JBoss, WebLogic, WebSphere – вариантов хватает. Дальше 3-й слой – веб заказчик. Здесь дозволено томкатами отделаться, да еще и балансировщик нагрузки прикрутить.

Что я позабыл? Ах да, messaging – он обеспечит верное асинхронное взаимодействие с компонентами приложений. Event-driven-зодчество – наше всё! Ну и безусловно, кластеры, которые будут применяться в всяком из слоев для надёжности.

image

Анализируя такое решение, с лёгкостью дозволено выявить несколько явственных задач

Сложности в управлении

Все ярусы имеют разные модели кластеризации. Для управления такой системой требуются познания и навык работы со всеми из них. Это влечет за собой:

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

Таким, как жёсткие диски и имена серверов. Трудности появляются при установке таких приложений в облака, так как те дюже динамичны по своей натуре.

Продуктивность

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

  • Все данные разбиваются на неограниченное число партишенов, всякий из которых может сидеть в отдельной машине.
  • Диплоймент описывается декларативно! «разбей мне все данные на 100500 кусков, на всякий кусок сделай по 2 бэкапа, не диплой бэкапы в одном дата центре, не используй для диплойменты машины нагруженные огромнее чем на 146 процентов»
  • Особые диспетчеры пишут данные сразу в несколько мест и в случае сбоя механически перенаправляют запросы на другие машины. Паралельно с этим существует комфортная система мониторинга, которая уведомляет обо всех возможных загвоздках, таких как неудовлетворительное число нодов в кластере, сбои в системе либо перегруженность машин.

image
А вот видео

Компания Kohl воскресла из пепла

Позже коллапса 2009 года компания Коhl заменила всю ветхую архитектуру на XAP. В итоге, по данным гугла сегодня их сайт занимает одно из первых мест в мире по скорости выдачи страниц

На сегодняшний день платформой XAP пользуется вдалеке не только Kohl. В списке её заказчиков сегодня присутствуют ведущие швейцарские банки (скажем, UBS), нью-йоркская биржа, компания Avaya и еще сотни других компаний.

Эпилог

Кто-то скажет: «А я использую многоуровневую архитектуру и дюже доволен!» И дюже отлично. Но живя в мире, где объём данных растёт экспоненциально, мы обязаны понимать, что даже если сегодня нет необходимости в in-memory computing platform, то нам стоит правда бы знать об их существовании и о том, какую пользу они несут. Может, теснее в ближайшем грядущем подрастут требования к числу обрабатываемых Вашим приложением данных и тогда, бесспорно, in-memory computing platforms могут подмогнуть, не говоря о приложениях, оперирующих в настоящем времени громадными объёмами данных, для которых их применение легко нужно.

Постскриптум

Приходите на JUG в субботу 31 числа, и я расскажу вам о XAP гораздо больше красочно и вживую продемонстрирую его работу.

 Источник: programmingmaster.ru
Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB