1.1 Архитектура на приложението
Този курс е предназначен за начинаещи, защото няма да проектирате архитектурата на сериозно приложение за дълго време. Но не се притеснявайте, добрата архитектура е по-скоро изключение, отколкото правило. Много е трудно да се избере правилната архитектура на приложението, преди да се създаде приложението.
Примери за популярни архитектури за големи сървърни applications:
- Многослойна архитектура (Layered Architecture).
- Многослойна архитектура.
- Сервизно ориентирана архитектура (SOA).
- Микросервизна архитектура (Microservice Architecture).
Всеки от тях има своите плюсове и минуси. Но изучаването им няма да ви даде нищо. Архитектурата е отговорът на въпроса "How да организираме взаимодействието на хиляди обекти в системата" . И докато не изпитате пълната сложност на проблема, няма да можете да разберете пълната гъвкавост на решението.
Всички applications използват няHowва архитектура or поне се преструват. Следователно познаването на популярните подходи за проектиране на applications ще ви позволи бързо и по-добре да разберете How работи приложението. А това означава да правите промени точно там, където имате нужда.
Какво означава „направете промени, когато е необходимо“? Има ли места, където не е необходимо да правите промени? Точно.
За да бъдем конкретни, да кажем, че работите върху среден бекенд проект . Писана е 5 години от екип от 20 души. Проектът отне 100 човеко-години и съдържа около 100 хиляди реда code. Общо се състои от две хиляди класа, които са разделени на 10 модула с различна големина.
И добавете сурова реалност. Логиката на някои задачи е разпределена в няколко модула. Също така бизнес логиката може да бъде във фронтенда (написана на JavaScript) и/or написана като съхранена proceduresа директно в базата данни. Все още ли сте сигурни, че можете веднага да определите мястото, където точно да направите промени ?
Това не е няHowъв кошмар, който съм измислил, за да те изплаша. Това е типичен проект. Случва се и по-лошо. Защо се случва това? Може да има много причини, но почти винаги има такива:
- По проекта работят много хора - всеки от тях го вижда малко по-различно.
- За 5 години 10 души се промениха в проекта, новодошлите не го разбраха много.
- Създаването на софтуер е постоянно пequalsе на промени, които постоянно променят всичко.
- Преди пет години, когато взехме решение за архитектурата, идеята на проекта беше малко по-различна.
Но основното е, че независимо от архитектурата на проекта, всички програмисти, работещи по него, се придържаха към едно и също разбиране за това How работи този проект. Нека започнем с най-простата концепция - архитектура клиент-сървър.
1.2 Концепцията за взаимодействие клиент-сървър
Сега ще разберем концепцията, която е в основата на архитектурата клиент-сървър и ще ви позволи да разберете по-добре How е организирано взаимодействието на мorони програми в Интернет.
Както подсказва името, тази концепция включва две страни: клиент и сървър . Тук всичко е като в живота: клиентът е клиентът на тази or онази услуга, а сървърът е доставчикът на услугата. Клиентът и сървърът са физически програми , например типичен клиент е браузър .
Следните примери могат да бъдат дадени като сървър:
- Уеб сървъри като Tomcat.
- Сървъри за бази данни като MySQL.
- Шлюзове за плащане като Stripe.
Клиентът и сървърът обикновено комуникират чрез Интернет (въпреки че могат да работят в една и съща локална мрежа и като цяло във всяHowви други видове мрежи). Комуникацията се осъществява по стандартни протоколи като HTTP, FTP or протоколи от по-ниско ниво като TCP or UDP.
Протоколът обикновено се избира според типа услуга, която сървърите предоставят. Например, ако е видео разговор, тогава обикновено се използва UDP.
Помните ли How работят Tomcat и неговите сервлети? Сървърът получава HTTP съобщение, разопакова го, извлича цялата необходима информация от там и я предава на сървлета за обработка. След това резултатът от обработката се пакетира обратно в HTTP-отговор и се изпраща на клиента.
Това е типичното взаимодействие клиент-сървър. Браузърът е уеб клиентът, а Tomcat е уеб сървърът. Tomcat дори се нарича уеб сървър.
Но ако се замислите, не името е важно, а същността - разпределението на ролите между програмите. Вашият JS скрипт, работещ в HTML page, може да се нарече клиент , а сървлетът ви сървър . В крайна сметка те работят по двойки в рамките на концепцията клиент-сървър .
1.3 Важен нюанс
Също така си струва да се отбележи, че взаимодействието клиент-сървър се основава на принципа, че такова взаимодействие се инициира от клиента : сървърът само отговаря на клиента и съобщава дали може да предостави услугата на клиента и, ако да, при Howви условия .
Няма meaning къде се намира физически клиентът и къде е сървърът. Клиентският и сървърният софтуер обикновено се инсталират на различни машини, но могат да работят и на един и същи компютър.
Тази концепция е разработена като първа стъпка към опростяване на сложна система. Тя има следните силни страни:
- Логическо опростяване : сървърът не знае нищо за клиента и How ще използва данните му в бъдеще.
- Може да има слаби клиенти : всички задачи, изискващи ресурси, могат да бъдат прехвърлени към сървъра.
- Самостоятелна разработка на клиентски code и сървърен code.
- Много различни клиенти, например Tomcat и различни браузъри.
Най-основната version на взаимодействието между клиент и сървър е показана на снимката:
Тук е важно да се отбележат две подробности. Първо, снимката показва, че много клиенти имат достъп до един сървър. Второ, те имат достъп до него едновременно. Това също е важна част от сървъра.
Един клиент обикновено взаимодейства с един потребител, така че често дори не е необходимо разрешение там. Въпреки това сървърът обработва заявки от хиляди клиенти и когато разработвате code за него, трябва да можете да правите разлика между авторизация и удостоверяване.
Също така е важно сървърът да обработва паралелно хиляди заявки. А това означава, че когато разработвате бекенд codeа, постоянно ще трябва да мислите за задачата за паралелен достъп до ресурси. Също така codeът на сървъра има много висока вероятност от състояние на състезание (състезание на нишки), блокиране (взаимно блокиране на нишки).
Жизненият цикъл на важни обекти трябва да се наблюдава:
Не можете просто да започнете нова нишка на сървъра чрез new Thread().start(). Вместо това трябва да имате ThreadPool, който ще споделя между всички нишки на услугата.
Освен това не можете просто да стартирате асинхронна задача, защото те също се изпълняват в отделни нишки. Когато създавате такава задача, винаги трябва да знаете кой пул от нишки я изпълнява и Howво ще се случи, ако такъв пул препълни.
Цялата работа с файлове и директории трябва да се извършва чрез try-with-resources. Ако в нормално приложение сте забравor да затворите поток or файл, това проблем ли е? Той ще се затвори сам, когато излезете от програмата. Но ако сте забравor да затворите файл на сървъра някъде в codeа и сървърът ви работи от месеци ... Скоро ще се натрупат хиляди такива незатворени файлове и операционната система ще спре да отваря нови файлове за четене (работете с файлове се управлява от ОС). Teamlead няма да те погали по главата...
1.4 Архитектура клиент-сървър
друг важен момент. Архитектурата клиент-сървър определя само общите принципи на взаимодействие между компютрите , детайлите на взаимодействието се определят от различни протоколи.
Тази концепция (клиент-сървър) ни казва, че трябва да разделим машините в мрежата на клиентски машини, които винаги имат нужда от нещо, и сървърни машини, които дават това, от което имат нужда. В този случай клиентът винаги започва взаимодействието и правилата, по които се осъществява взаимодействието, са описани от протокола.
Има два типа архитектура за взаимодействие клиент-сървър: първата се нарича двуслойна архитектура клиент-сървър , втората е многослойна архитектура клиент-сървър (понякога наричана тристепенна архитектура or тристепенна архитектура, но това е частен случай).
Принципът на работа на двустепенната архитектура на взаимодействие клиент-сървър е, че обработката на заявка се извършва на един сървър, без да се препраща към други сървъри в процеса на тази обработка.
Двустепенният модел на взаимодействие клиент-сървър може да бъде начертан като проста диаграма.
Тук можете да видите, че първото ниво е всичко, което се отнася до клиента, а второто ниво е всичко, което се отнася до сървъра.