Вчера впервые написал статью на Хабре, не зная местных тонкостей.
Я исправляю себя! Теперь понятным языком и с юмором! Черная пятница оказалось правдой черный для американского интернет-универмага Коля .
В день рождественской распродажи все серверы сошли с ума.
Обычные 20% годового дохода, получаемые в этот день, превратились в смешную мелочь, а все потому, что Боливар не выдержал такой нагрузки.
Традиционная архитектура Tomcat+WebLogic+DB полностью облажалась! Напрасно бегали по этажам сисадмины, в панике суетились ведущие программисты, а архитекторы вырывали последние волосы.
Горлышко бутылки оказалось слишком узким, чтобы в него могли втиснуться все потенциальные клиенты, и не эластичным.
достаточно, чтобы его можно было расширить за короткое время.
Бутылка была чертовски разорвана.
И раны, нанесенные его осколками, еще долго продолжали кровоточить.
Проблемы трехуровневой архитектуры
— Сынок, оно работает — не трогай! – Папа, это не работает, это ГРАДУЕТ!!! Вы все прекрасно знаете старую, но не всегда хорошую трехуровневую архитектуру.трехуровневая архитектура Первый уровень содержит данные, которые в основном хранятся в реляционной базе данных; если речь идет о больших объемах, то, видимо, выбор падет на Oracle. Здесь данные сохраняются, обновляются, извлекаются и отправляются на следующий логический уровень.
Второй уровень содержит бизнес-логику, всякие EJB, Spring и Hibernate. Где будет находиться весь этот код? Ну и конечно вариантов в сервере приложений масса — JBoss, WebLogic, WebSphere. Затем третий уровень — это веб-клиент. Здесь можно обойтись Томкэтами и даже подключить балансировщик нагрузки.
Что я забыл? Ах да, обмен сообщениями — он обеспечит надежное асинхронное взаимодействие с компонентами приложения.
Событийно-ориентированная архитектура — наше все! И конечно же кластеры, которые будут использоваться в каждом из слоев для надежности.
Анализируя такое решение, можно легко выявить несколько очевидных проблем.
Трудности в управлении
Все уровни имеют разные модели кластеризации.Управление такой системой требует знаний и опыта работы со всеми из них.
Это влечет за собой: Высокая стоимость: компании вынуждены приобретать отдельные лицензии на все компоненты и нанимать специалистов для установки и обслуживания каждого уровня.
Кроме того, кластеризация некоторых компонентов не всегда проста и зачастую сопряжена с непредвиденными трудностями даже для самых опытных специалистов.
Трудности управления: отслеживание и мониторинг такого большого количества компонентов в реальной работающей системе снова требует дополнительных ресурсов.
В большинстве случаев для таких целей необходимо приобрести дополнительные программные приложения.
Сложности выявления и решения проблем: сложно определить, что произошло и на каком уровне, если система дает сбой Трудности с внедрением программного обеспечения.
Межмодульная интеграция и настройка также могут привести к дополнительным затратам.
Чтобы все модули правильно «общались» друг с другом, обычно требуется некоторое время и дополнительные ресурсы.
Привязка к статическим ресурсам
Например, жесткие диски и имена серверов.Трудности возникают при установке таких приложений в облака, поскольку они очень динамичны по своей природе.
Производительность
Практически любой запрос проходит через все три уровня системы и может включать множество сетевых переходов между уровнями и внутри них, что отрицательно влияет на среднее время ответа.Кроме того, рано или поздно данные придется сбрасывать на диск.
Сетевой и дисковый ввод-вывод существенно ограничивает масштабируемость и, опять же, приводит к замедлению работы системы.
В результате трехуровневая архитектура не может предсказуемо масштабироваться.
Увеличение нагрузки на систему потребует больше ресурсов для обработки данных, но эту проблему невозможно решить простым добавлением оборудования.
Более того, часто добавление дополнительных ресурсов на один из уровней (например, серверов баз данных) не только не поможет, но, наоборот, увеличит время ожидания и снизит пропускную способность системы в целом из-за накладных расходов на синхронизация между узлами кластера.
Почему кеш и datagrid не решают проблему
Чтобы решить проблемы задержки и масштабируемости, обычно перед реляционной базой данных помещают сетку данных в памяти.Это определенно шаг в правильном направлении, снимет часть нагрузки на систему и подойдет в основном для кэширования.
Стоит отметить, что большинство сеток данных ограничены в возможности извлекать данные только с использованием уникального идентификатора.
Хотя это решение и может быть применено в отдельных случаях, оно все же не идеально по следующим причинам: Он добавляет еще один уровень, требующий дополнительных лицензий.
Как и все остальные, новый уровень необходимо интегрировать, настраивать, отслеживать и устранять неполадки в случае его возникновения.
Таким образом, это увеличивает общую сложность управления данной архитектурой и затраты на ее установку, поддержку и обслуживание.
Как уже говорилось выше, такие решения помогут для систем, в которых много операций чтения.
Но это абсолютно бесполезно для систем, где операций записи очень много.
Более того, при наличии кэша возникают дополнительные затраты на синхронизацию между кэшем и базой данных.
Пример из реального мира
Давайте посмотрим на реальную многоуровневую архитектуру системы онлайн-продаж Коля.
Сразу видно, что любая часть этой системы может играть роль узкого места.
Очевидно, что добавление дополнительных ресурсов в любое место, кроме «узкого», никак не поможет избавиться от тормозов в системе.
В случае с WebLogic Коля базы данных Apache и Oracle показали хорошие результаты при использовании 50 физических серверов.
30 000 одновременно подключенных пользователей регулярно получали ответы на все запросы.
Он все равно продолжал бы работать, если бы, например, компании приходилось обслуживать определенное фиксированное количество транзакций каждую секунду, и не было бы резких изменений системных требований.
Однако та самая «Черная пятница» (Черная пятница, когда миллионы американцев спешат в магазины, а ритейлеры за один день получают 20, а иногда и 30 процентов годовой выручки) 2009 года потребовала от системы справиться с нагрузкой в 500 000 пользователей на в то же время.
Трехуровневая архитектура оказалась не готова к такому удару.
В результате потери составляют десятки миллионов долларов.
Отсюда вопрос:
Не пора ли заменить старых героев?
Итак, сформулируем ключевые требования к современной платформе: Операции с данными должны быть быстрыми Разделение между уровнями абстракции не должно влиять на производительность.
Добавление новых ресурсов должно линейно (или почти линейно) увеличивать производительность, а также не наталкиваться на какие-либо ограничения.
Развертывание должно быть одновременно гибким и простым.
Система должна быть «неразрушимой» и заранее предупреждать о потенциальных проблемах.
Примерно такими требованиями руководствовались инженеры Gigaspaces, которые 10 лет назад начали разработку новой платформы XAP (eXtreme Application Platform).
Вот так они все это придумали
Все данные хранятся в оперативной памяти, а не на диске.
Во всяком случае, оперативная память сегодня очень дешева, в отличие от базы данных Oracle даже с самой простой поддержкой.
Логика приложения находится в том же контейнере, что и данные.
Это, конечно, может не понравиться преподавателям вузов и другим любителям классической архитектуры.
Некоторые хабровцы могут даже решить, что такое решение способствует нездоровой смеси данных и логики.
Однако опыт показывает, что никакие слои не могут остановить настоящих мастеров, и при должном умении винегрет можно сделать с любой понравившейся «архитектурой»! Все данные разделены на неограниченное количество частей, каждая из которых может находиться в отдельной машине.
Диплом описан декларативно! «разбейте мне все данные на 100500 частей, сделайте по 2 резервные копии для каждой части, а не дипломатические резервные копии в одном дата-центре, не используйте для дипломатии машины, загруженные более чем на 146 процентов» Специальные диспетчеры записывают данные сразу в несколько мест и в случае сбоя автоматически перенаправляют запросы на другие машины.
Параллельно с этим действует удобная система мониторинга, оповещающая обо всех потенциальных проблемах, таких как недостаточное количество узлов в кластере, сбои системы или перегруженные машины.
И здесь видео
Коля восстает из пепла
После кризиса 2009 года Коль заменил всю старую архитектуру на XAP. В результате, по данным Google, сегодня их сайт занимает одно из первых мест в мире по скорости рендеринга страниц.
Сегодня не только Kohl’s использует платформу XAP. В список его клиентов сегодня входят ведущие швейцарские банки (например, ЮБС ), Нью-Йоркская фондовая биржа, компания Авая и сотни других компаний.
Эпилог
Кто-то скажет: «Я использую многоуровневую архитектуру и очень доволен!» И очень хорошо.Но живя в мире, где объемы данных растут в геометрической прогрессии, мы должны понимать, что даже если сегодня нет необходимости в платформах вычислений в памяти, то мы должны хотя бы знать об их существовании и преимуществах, которые они приносят. Возможно, в ближайшем будущем требования к объёму данных, обрабатываемых вашим приложением, возрастут и тогда, несомненно, смогут помочь платформы in-memory вычислений, не говоря уже о приложениях, работающих в режиме реального времени с огромными объёмами данных, для которых их использование нецелесообразно.
просто необходимо.
P.S.
Приходить в JUG в субботу 31-го , а я расскажу вам о XAP гораздо красочнее и продемонстрирую его работу вживую.
А вот видео: Теги: #Большие данные #java #производительность #надежность #надежность #java ee #3-уровень #xap
-
3 Греха Мобильной Разработки На Mobius 2016
19 Oct, 24 -
Рабочий Стол «Оранжевое Цунами»
19 Oct, 24 -
Мобильное Шифрование
19 Oct, 24 -
Рбк И «Ведомости» Снова Встретятся В Суде
19 Oct, 24 -
Сетевое Кэширование В Ios. Введение
19 Oct, 24
