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

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

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

тристепенната

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