Проблеми на тристепенната архитектура

N-Tier срещу eXtreme Application Platform
Проблеми на тристепенната архитектура

Повечето съвременни бизнес софтуерни приложения се състоят от 3 нива. Първият слой съдържа данни, които се съхраняват предимно в релационна база данни. Тук данните се запазват, актуализират, извличат и изпращат към следващия, логически слой. Вторият слой е бизнес логиката, която обработва команди и изчисления, изпълнява логически решения и прехвърля и обработва данни между околните слоеве. В света на JEE този слой обикновено се представя от сървъри за приложения на JEE като WebSphere, WebLogic и JBoss. В повечето случаи има отделен уеб слой или клиентски слой, който отговаря за представянето на задачи и резултати, които потребителят може да разбере. Обикновено има балансьор на натоварването пред уеб слоя.
Много приложения също използват слоя за съобщения, осигурявайки надеждна асинхронна комуникация с компонентите на приложението и възможност за внедряване на обработка на информация, използвайки шаблони, управлявани от събития. Услугите за бизнес логика вземат съобщения от този слой в реда, в който влизат в системата и ги обработват. За да се постигне висока наличност и да се увеличи способността за обработка на повече данни, всички нива използват клъстерна архитектура.

Анализирайки тази архитектура, можете лесно да идентифицирате няколко очевидни проблема:
1. Трудност при управлението: всички нива имат различни клъстерни модели. За да работи такава система, са необходими знания и опит с всички тях. Това включва:
а. Висока цена: компаниите трябва да придобият отделни лицензи за всички части и да наемат експерти, които да инсталират и поддържат всеки от нивата. Освен това групирането на някои компоненти не винаги е лесно и често е пълно с непредвидени трудности дори за най-опитните специалисти.
б. Трудност при управлението: Проследяването и наблюдението на толкова много компоненти в реална работеща система отново изисква допълнителни ресурси. В повечето случаи е необходимо да закупите допълнителни софтуерни приложения за такива цели.
° С. Трудности при идентифициране и решаване на проблеми: трудно е да се определи какво се е случило и на какво ниво, ако системата не работи
д. Трудност при внедряването на софтуер: Интермодулната интеграция и конфигурация също могат да добавят допълнителни разходи. Принуждаването на всички модули да „комуникират“ правилно един с друг обикновено отнема известно време и допълнителни ресурси.
2. Тази архитектура е обвързана със статични ресурси като твърди дискове и имена на сървъри. Ще бъде много трудно да инсталирате такова приложение на виртуализирани платформи/среди, тъй като тези (платформи) са с много динамичен характер.
3. Латентност и производителност: В тези архитектури бизнес транзакцията обикновено преминава през повечето (ако не всички) нива на системата, преди да прекрати. Това включва много мрежови скокове между и в рамките на нивата.
Освен това гарантирането на валидността на бизнес транзакциите включва запис на диск в даден момент от програмата. Мрежовите и дисковите I/O значително ограничават мащабируемостта и увеличават латентността на бизнес транзакциите. В резултат на това тристепенната архитектура не може да бъде мащабирана предсказуемо. Ако увеличите натоварването на системата, което от своя страна ще изисква повече ресурси за обработка на информация, добавянето на допълнителен хардуер е малко вероятно да реши проблема. Вградената зависимост от мрежови и дискови I/O по същество ограничава възможностите на системата. Освен това, често добавянето на допълнителни ресурси към едно от нивата (например слой с данни) не само не помага, но дори може да увеличи латентността и да намали производителността на системата като цяло поради режийните разходи, свързани със синхронизирането на клъстера възли.

Защо решенията за кеш и мрежи от данни не решават проблема
За да се справят с проблемите на латентността и мащабируемостта, често се поставя мрежа от данни в паметта пред релационна база данни. Несъмнено това е решение в правилната посока, което частично разтоварва системата и е подходящо предимно за осребряване на данни. Трябва да се отбележи, че повечето мрежи от данни са ограничени от способността им да извличат данни, използвайки само уникален идентификатор. Въпреки че това решение може да се приложи в отделни случаи, то все още не е идеално поради следните причини:
1. Добавя още един слой, който изисква допълнителни лицензи. Както всички останали, и нов слой трябва да бъде интегриран, конфигуриран, наблюдаван и отстранени грешки, ако възникнат. По този начин това увеличава общата сложност на управлението на архитектурата и разходите за нейното инсталиране, поддържане и поддържане.
2. Както бе споменато по-горе, решенията в тази извадка ще помогнат за системи, при които данните се извличат при повечето операции. Но това е абсолютно безполезно за системи, в които данните трябва да бъдат запазени или актуализирани.

Пример от реалния свят
След толкова дълъг предговор предлагам да демонстрирам цялата горепосочена теория с пример, в противен случай всичко няма смисъл. Нека разгледаме реална архитектура на много нива на компанията на Kohl от сферата на интернет продажбите.

Веднага прави впечатление, че навсякъде чакаме самите тесни места, през които цялата входяща информация трябва да бъде предадена по всякакъв начин. Очевидно добавянето на допълнителни ресурси към всяко от нивата няма да помогне по никакъв начин да се отървете от съществуващите критични елементи (тесни места) на цялата система (между нивата).
Сървърите на бази данни WebLogic, Apache и Oracle свършиха работата добре, използвайки 50 физически сървъра. 30 000 едновременно свързани потребители редовно получават отговори на всички искания и запитвания. Всичко ще продължи да работи и в бъдеще, ако например компанията трябва да обслужва определен фиксиран брой транзакции всяка секунда и няма да има драстични промени в системните изисквания.
Въпреки това, самият „черен петък“ (черен петък, когато милиони американци бързат да пазаруват, а търговците правят 20, а понякога и 30 процента от годишните приходи за един ден) от 2009 г. изискваше следните условия: системата трябва да се справи с товара в 500 000 потребители едновременно. Гореспоменатата архитектура не беше готова за такъв удар и впоследствие нямаше смисъл да се ремонтира потъващия кораб без пълната му реконструкция. Резултат: многомилионна загуба на доход.

Епилог
Някой ще каже: „И аз използвам многослойна архитектура и съм много доволен“. И много добре. Не всички системи в света се считат за критични, отказите на които могат да доведат до загуба на критична информация или до прекъсване на работата, което в крайна сметка води до загуби от милиони долари. Живеейки в свят, в който през последните 2 години са генерирани 90% от всички (да, ВСИЧКИ) данни, трябва да разберем, че дори днес да няма нужда от изчислителна платформа в паметта, тогава трябва поне да знаем за тяхното съществуване и колко полезни са те. Може би в близко бъдеще изискванията за количеството данни, обработвани от вашето приложение, ще се увеличат и тогава несъмнено изчислителните платформи в паметта могат да помогнат, да не говорим за критично важни и приложения BigData RealTime Analytics, за които използването им е просто необходимо.

След епилог:
Приятели, както каза Боромир: не можете просто да отидете и да пишете за всичко това. Елате в JUG в събота на 31-ви в PetroCongress и ще ви разкажа за XAP-e много по-цветно и с ярки живи примери.