Проблеми Трирівневої Архітектури

N-Tier vs eXtreme Application Platform Проблеми Трирівневої Архітектури

Більшість сучасних програм програм для бізнесів складаються з трьох рівнів. Перший шар містить дані, які у більшості зберігаються в реляційної базі даних (relational database). Тут дані зберігаються, модернізуються, витягуються та вирушають у наступний, логічний шар. Другий шар це бізнес-логіка (business logic), який обробляє команди та обчислення, виконує логічні рішення та передає та обробляє дані між оточуючими шарами. У світі JEE цей рівень зазвичай представлений за допомогою JEE application servers, таких як WebSphere, WebLogic та JBoss. У більшості випадків існує окремий веб-рівень, або шар клієнта, який відповідальний за подання завдань і результатів, зрозумілих користувачеві. Як правило, перед інтернет рівнем стоїть балансувальник навантаження (load balancer). Багато програм також використовують рівень повідомлень (messaging), забезпечуючи надійну асинхронну взаємодію з компонентами додатків та можливість впровадження обробки інформації за допомогою подієво-орієнтованих (event-driven) шаблонів. Сервіси бізнес-логіки приймають повідомлення з цього рівня у порядку їх надходження до системи та обробляють їх. Для досягнення високої доступності (high availability) та збільшення здатності обробки більшої кількості даних усі рівні використовують кластерну архітектуру (cluster).

Аналізуючи цю архітектуру легко можна виявити кілька очевидних проблем: 1. Труднощі в управлінні: всі рівні мають різні моделі кластеризації. Для управління такою системою потрібні знання та досвід роботи з усіма з них. Це тягне у себе: a. Високу вартість: компанії змушені купувати окреміліцензії для всіх складових частин та наймати експертів для встановлення та підтримки кожного з рівнів. Крім того, кластеризація деяких складових не завжди проста і часто сповнена непередбачених труднощів навіть для найдосвідченіших фахівців. b. Труднощі в контролюванні: відстеження та моніторинг такої великої кількості компонентів у цій працюючій системі вкотре потребує додаткових ресурсів. У більшості випадків, необхідно придбати додаткові софт програми для таких цілей. с. Труднощі в ідентифікації та вирішенні проблем: важко визначити що і на якому рівні сталося, якщо система вийшла з ладу 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 зі сфери інтернет-продажів.

Одразу впадає в око, що скрізь нас чекають ті самі «вузькі місця» (bottlenecks), через які будь-якими способами потрібно пропустити всю інформацію, що приходить. Очевидно, що додавання додаткових ресурсів у кожен із рівнів ніяк не допоможе позбутися існуючих критичних елементів (bottlenecks) всієї системи (між рівнями). Сервера WebLogic, Apache та база даних Oracle чудово справлялися із завданням, використовуючи 50 фізичних серверів. 30,000 одночасно приєднаних користувачів справно отримували відповіді на всі вимоги та запити. Воно б усе продовжувало працювати і надалі, якби, наприклад, компанія мала б обслуговувати певну фіксовану кількість транзакцій щомиті, і не відбувалося б жодних різких змін у вимогах до системи. Однак, та сама «чорна п'ятниця» (Black Friday, коли мільйони американців рвуться до магазинів, а рітейлери роблять 20, а іноді й 30 відсотків від річного виторгу за один день) 2009-го року зажадала наступні умови: система повинна справлятися з навантаженням 500,000 користувачів одночасно. До такого удару вищезгадана архітектура була не готова, а згодом не було сенсу лагодити корабель, що тоне, без його повної реконструкції. Результат: мультимільйонна втрата доходів.

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

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