Тристепенна архитектура

Въведение в тристепенната архитектура

Тристепенната архитектура е най-често срещаната архитектура за взаимодействие в Интернет. Появи се, когато двуслойната сървърна част беше разделена на две части: логически слой и слой данни .

Изглеждаше нещо подобно:

Клиентският слой е частта от "разпределеното приложение", която отговаря за взаимодействието с потребителя. Този слой не трябва да съдържа бизнес логика и не трябва да съхранява критични данни. Освен това не трябва да взаимодейства директно със слоя база данни, а само чрез слоя бизнес логика.

Тук обаче все пак има няHowва логика. Първо, това е взаимодействие с потребителя чрез интерфейса, проверка на въведените от него данни, работа с локални файлове. Това включва и всичко свързано с авторизацията на потребителя и криптирането на данни при работа със сървъра.

Второ, това е проста бизнес логика. Например, ако онлайн магазин изпрати списък с продукти, ние можем да ги сортираме и филтрираме от страна на клиента. И примитивното съхранение на данни също е тук: кеширане, бисквитки на влезли потребители и други подобни.

Слоят на бизнес логиката се намира на второ ниво, по-голямата част от бизнес логиката е концентрирана върху него. Извън него остават само фрагменти, които се експортират към клиента, Howто и логически елементи, които са потопени в базата данни (съхранени proceduresи и тригери).

Голяма част от сървъра на бизнес логиката съдържа не само същата тази логика, но и решава проблеми с мащабирането: codeът се разделя на части и се разпространява на различни сървъри. Някои високо търсени услуги могат да работят на десетки сървъри. Натоварването между тях се управлява от балансиращото натоварване.

Сървърните applications обикновено са проектирани по такъв начин, че друго копие на сървъра може лесно да бъде стартирано и да започне да работи в сътрудничество с други негови копия. Тоест, дори в процеса на писане на сървърен code, никога няма да имате гаранции, че вашият статичен клас се стартира в един единствен екземпляр.

Слоят на данните осигурява съхранение на данни и се поставя на отделно ниво, реализирано, като правило, чрез системи за управление на бази данни (СУБД), връзката към този компонент се осигурява само от ниво сървър на applications.

Причини за отделяне на слоя данни

Разделянето на слоя данни в пълнопequals трети слой се случи по много причини, но основната е повишеното натоварване на сървъра.

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

При повишено натоварване бекендът лесно можеше да бъде дублиран и можеха да бъдат повдигнати десет копия на един сървър, но беше невъзможно да се дублира базата данни - базата данни все още оставаше единствен и неделим компонент на системата.

Второ, базите данни станаха умни - те имат собствена бизнес логика. Те започнаха да поддържат съхранени proceduresи, тригери, собствени езици като PLSQL. И дори се появиха програмисти, които започнаха да пишат code, който работи в СУБД.

Цялата логика, която не беше свързана с данни, беше извадена в бекенда и стартирана паралелно на десетки сървъри. Всичко, което е критично свързано с данните, остана в СУБД и там вече проблемите с увеличеното натоварване трябваше да бъдат решени с помощта на нашите собствени методи:

• Клъстерът на база данни е група от сървъри на база данни, които съхраняват едни и същи данни и ги синхронизират с помощта на определен протокол.
• Шардинг - данните се разделят на логически блокове и се разпределят между различни сървъри на бази данни. Много е трудно да се поддържат промени в базата данни с този подход.
• Подходът NoSQL е да се съхраняват данни в бази данни, които са създадени да съхраняват огромни количества данни. Това често дори не са бази данни, а специфични файлови хранorща. Много слаба функционалност в сравнение с релационните бази данни.
• Кеширане на данни. Вместо обикновен кеш на ниво база данни се появи цяла кешираща СУБД, която съхранява резултата само в паметта.

Ясно е, че са бor необходими отделни хора и/or цели екипи, за да управляват този зоопарк от сървърни технологии, което доведе до премахването на слоя с данни в отделен слой.

важно! Всички напреднали технологии се раждат в дълбините на големите ИТ корпорации, когато старите подходи вече не се справят с новите предизвикателства. Създаването на бази данни в отделен слой не е измислено от програмист, а от група инженери някъде в дълбините на Oracle or IBM.

Интересно! Когато Зукърбърг започна да пише Facebook, той работеше просто върху PHP + MySQL. Когато имаше мorони потребители, те написаха специален преводач, който преведе целия PHP code в C ++ и го компorра в собствен машинен code.

Освен това MySQL не е в състояние да съхранява данните на мorарди потребители, така че Facebook разработи концепцията за NoSQL бази данни и написа мощна сървърна NoSQL DBMS - Cassandra. Между другото, той е изцяло написан на Java.

Неяснота на местоположението на логиката на приложението

И въпреки че тристепенната архитектура почти недвусмислено разпределя ролите между своите части, не винаги е възможно правилно да се определи къде точно в системата трябва да се добави нова част от бизнес логиката (нов code).

Пример за такава неяснота е показан на снимката по-долу:

Сървърната част е запълнена със сив фон, клиентската част е запълнена с бяло. Добър пример за последния подход (най-вдясно) са модерните мобилни applications. Клиентската страна (на телефона) съдържа изглед (дисплей), логика и данни. И само понякога тези данни се синхронизират със сървъра.

Пример за най-лявата опция е типичен PHP сървър, който има цялата логика на сървъра и дава на клиента вече статичен HTML. Някъде между тези две крайности ще се намира вашият проект.

В началото на работата, след като се запознаете с проекта, ще трябва да се консултирате с програмистите, работещи по него, за местата, където е по-добре да приложите логиката на следващата задача.

Чувствайте се свободни да го направите. Първо, те не се качват в манастира на някой друг с хартата си. Второ, ще бъде по-лесно за всички (и за вас също) да намерите codeа, от който се нуждаете, на мястото, където очаквате да го намерите.