2-бөлүк. Келгиле, программалык камсыздоонун архитектурасы жөнүндө бир аз сүйлөшөлү

Бул материал " Ишкананы өнүктүрүүгө киришүү " сериясынын бир бөлүгү . Тармак жөнүндө биринчи бөлүгү бул жерде . Программалык камсыздоонун архитектурасы – бул түзүм, анын негизинде тиркеме түзүлөт жана бүт программанын модулдары жана компоненттери өз ара аракеттенет. Программисттер көптөн бери жакшы архитектураны түзүүгө аракет кылып келишкен, ошондуктан биз азыр көптөгөн архитектуралык үлгүлөрдү билебиз деп таң калыштуу эмес. Сиз аларды түшүнүшүңүз керек: веб-тиркемени жазганда архитектура маселеси курч болуп калат, анткени анда кадимки тиркемеге караганда компоненттер жана модулдар көбүрөөк. Архитектуралык үлгү кандайдыр бир программалык камсыздоону долбоорлоо маселесин чечүүнүн мурунтан эле ойлонулган жолу. Сиз Factory Method, Abstract Factory, Builder, Prototype, Singleton жана балким башкалар сыяктуу дизайн үлгүлөрүн мурунтан эле кезиктирсеңиз керек. Алар жөн гана code жазуу, класстарды түзүү жана алардын өз ара аракеттенүүсүн пландаштыруу үчүн колдонулат. Архитектуралык үлгүлөр абстракциянын жогорку деңгээлинде колдонулат - колдонуучунун server, маалыматтар жана долбоордун башка компоненттери менен өз ара аракеттенүүсүн пландаштырууда. Келгиле, кээ бир калыптарды жана аларды кантип колдонууну тез карап көрөлү.

Кардар-server архитектурасы

Аты менен бул темада бардыгы жөнөкөй жана түшүнүктүү деген ой пайда болот. Бирок, келгиле, кээ бир пункттарды тактап көрөлү, ошондуктан шарттуу Жазды изилдеп баштаганда, эмне жөнүндө сөз болуп жатканын так түшүнөсүң. Сиз чат жаздыңыз дейли, сиз жана досуңуз аны колдоно баштадыңыз. Бул жерде жөнөкөй вариант болушу мүмкүн - сиз билген IP даректерди колдонуп, Интернет аркылуу бири-бириңизге билдирүү жөнөтөсүз: Башында баары жакшы болуп жаткандай сезorши мүмкүн, сиздин дагы бир досуңуз: "Эмне үчүн? мени чатыңа кошпойсуңбу? Ал эми чатта өз ара досуңузду кошууну чечкенде, сиз архитектуралык көйгөйгө туш болосуз: чаттын ар бир колдонуучусу колдонуучулардын саны тууралуу маалыматты жаңыртып, жаңы колдонуучунун IP дарегин кошуусу керек. Ал эми билдирүү жөнөтүүдө ал бардык катышуучуларга жеткирorши керек. Бул пайда боло турган эң ачык көйгөйлөр. Коддун өзүндө дагы көп көйгөйлөр жашырылат. Аларды болтурбоо үчүн, колдонуучулар жөнүндө бардык маалыматты сактай турган жана алардын даректерин билген serverди колдонушуңуз керек . Билдирүү serverге гана жөнөтүлүшү керек. Ал, өз кезегинде, бардык алуучуларга билдирүү жөнөтөт. Чатыңызга server тарабын кошууну чечкенде, сиз кардар-server архитектурасын кура баштайсыз.

Кардар-server архитектурасынын компоненттери

Кел, анын эмне экенин аныктап көрөлү. Кардар-server архитектурасы дизайн үлгүсү, веб тиркемелерди түзүү үчүн негиз болуп саналат. Бул архитектура үч компоненттен турат:

1. Кардар - аталышынан бул кандайдыр бир маалыматты алуу үчүн serverге кайрылган кызматтын (веб тиркемесинин) колдонуучусу экени айкын болот.

2. Сервер бул сиздин веб тиркемеңиз же анын server бөлүгү жайгашкан жер. Ал колдонуучулар жөнүндө керектүү маалыматка ээ же аны сурай алат. Ошондой эле, кардар байланышканда, server суралган маалыматты кайтарып берет.

3. Тармак жөнөкөй: ал кардар менен serverдин ортосунда маалымат алмашууну камсыздайт.

Сервер ар кандай колдонуучулардын көп сандагы суроо-талаптарын иштете алат. Башкача айтканда, кардарлар көп болушу мүмкүн жана алар бири-бири менен маалымат алмашуу керек болсо, бул server аркылуу жасалышы керек. Ошентип, server дагы бир кошумча функцияны алат - трафикти башкаруу. Эгерде биз түзгөн көп колдонуучу чат жөнүндө сөз кыла турган болсок, анда программанын бүт codeу эки модулдан турат:

• кардар - авторизациялоо, билдирүүлөрдү жөнөтүү/кабыл алуу үчүн графикалык интерфейсти камтыйт;

• server тарап - serverде жайгаштырылган жана колдонуучулардан билдирүүлөрдү кабыл алып, аларды иштетип, анан алуучуларга жөнөтүүчү веб-тиркеме.

Биз Интернеттен пайдалуу (же анчалык деле пайдалуу эмес) маалыматты карагыбыз келгенде, браузерди ачабыз, издөө тилкесине суроо киргизебиз жана жооп катары издөө системасынан маалымат алабыз. Бул чынжырда браузер биздин кардар болуп саналат. Ал serverге биз издеп жаткан маалымат менен суроо-талапты жөнөтөт. Сервер суроо-талапты иштеп чыгат, эң керектүү натыйжаларды табат, аларды браузерге (кардарга) түшүнүктүү форматка топтоп, кайра жөнөтөт. Издөө системалары сыяктуу татаал кызматтарда көптөгөн serverлер болушу мүмкүн. Мисалы, авторизация serverи, маалыматты издөө serverи, жоопту түзүү үчүн server. Бирок кардар бул жөнүндө эч нерсе билбейт: ал үчүн server бирдиктүү нерсе. Кардар кирүү чекити жөнүндө, башкача айтканда, суроо-талапты жөнөтүшү керек болгон serverдин дарегин гана билет. Мурунку бөлүктө караган тиркемени эстеп көрөлү - реалдуу убакыт режиминде бардык өлкөлөрдө абанын орточо температурасын көзөмөлдөө үчүн. Анын архитектурасы төмөнкүдөй болот: Биздин тиркеме serverде жайгашкан. Айталы, ар беш секунд сайын жергorктүү гидрометеорологиялык борборлордун serverлерине суроо-талаптарды жөнөтүп, алардан тигил же бул өлкөнүн температурасы тууралуу маалымат алып, бул маалыматты сактап турат. Кардар бизге "дүйнөдөгү абанын учурдагы температурасын көрүү" өтүнүчү менен кайрылганда, биз өлкө боюнча иреттелген акыркы сакталган маалыматты кайтарып беребиз. Ошентип, биздин тиркеме бир эле server (колдонуучунун суроо-талаптарын иштеп чыкканда) жана клиент (башка serverлерден маалымат алганда) болуп саналат. Жөнөкөй кардар-server архитектурасы өтө сейрек жана өтө жөнөкөй колдонмолор үчүн гана колдонулат. Чынында эле чоң жана татаал долбоорлор үчүн архитектуранын ар кандай түрлөрү колдонулат, алар менен келечекте көбүрөөк тааныш болосуз. Эми кардар-server моделине абдан окшош моделди карап көрөлү.

Үч катмарлуу архитектура

Бул үчүнчү оюнчуну киргизген архитектуралык үлгү: маалымат кампасы . Бул үлгүнү колдонууда үч деңгээл адатта катмарлар деп аталат:

1. Кардар катмары колдонуучу интерфейси болуп саналат. Бул HTML баракчалары жөнөтүлгөн веб-браузер же JavaFX аркылуу жазылган GUI тиркемеси болушу мүмкүн. Эң негизгиси, анын жардамы менен колдонуучу serverге суроо-талаптарды жөнөтүп, анын жоопторун иштете алат.

2. Логикалык катмар – бул суроо-талаптар/жооптор иштетилүүчү server. Ал көбүнчө server катмары деп да аталат. Бардык логикалык операциялар да бул жерде ишке ашат: математикалык эсептөөлөр, маалымат операциялары, башка кызматтарга чалуу же маалыматтарды сактоо.

3. Маалымат катмары маалымат базасы serverи болуп саналат: биздин server ага кире алат. Бул катмар колдонмо операция учурунда колдонгон бардык керектүү маалыматты сактайт.

Ошентип, биздин server колдонуучуга түздөн-түз кирүү мүмкүнчүлүгүн бербестен, маалыматтарга жетүү боюнча бардык милдеттенмелерди өзүнө алат.

Үч баскычтуу архитектуранын артыкчылыктары

Мындай архитектураны колдонуу менен биз көптөгөн артыкчылыктарга ээ болобуз, анын ичинде:

1. SQL инъекцияларынан коргоону куруу мүмкүнчүлүгү SQL codeу өткөрүлүп жаткан serverге чабуул болуп саналат жана бул code аткарылганда чабуулчу биздин маалымат базасына таасир этиши мүмкүн.

2. Колдонуучунун мүмкүнчүлүгүн жөнгө салгыбыз келген маалыматтардын чеги.

3. Кардарга жөнөтүүдөн мурун маалыматтарды өзгөртүү мүмкүнчүлүгү.

4. Масштабдуулук - бир эле маалымат базасын колдоно турган бир нече serverлерге биздин тиркемени кеңейтүү мүмкүнчүлүгү.

5. Колдонуучунун байланышынын сапатына азыраак талаптар. Серверде жоопту түзүүдө биз көп учурда маалымат базасынан ар кандай маалыматтарды алып, аны форматтап, колдонуучуга керектүү нерсени гана калтырабыз. Ошентип, биз кардарга жооп катары жөнөтүүчү маалыматтын көлөмүн азайтабыз.

Архитектуралык үлгүлөрдү канчалык көп колдонуу керек?

Эгер сиз, айталы, Фабрика методунун дизайн үлгүсү менен тааныш болсоңуз , аны качан колдонуу керектиги жөнүндө ойлонуп жаткандырсыз. Кээде эмне кылууну чечиш кыйын: жаңы операторду колдонуу же заводдук ыкманы колдонуу менен an object түзүү. Бирок убакыттын өтүшү менен түшүнүү пайда болот. Архитектуралык үлгүлөр менен нерселер бир аз башкача. Ишкана алHowтары программист аларды жалпы кабыл алынган үлгүнүн негизинде долбоор түзүү үчүн колдонуу үчүн иштелип чыккан. Ошондуктан, Spring Framework үйрөнүүдөн мурун, сиз сөзсүз түрдө кардар-server архитектурасы, үч деңгээлдүү архитектура жана MVC архитектурасы эмне экенин түшүнүшүңүз керек. Кабатыр болбоңуз: MVC архитектурасы жөнүндө кийинчерээк сүйлөшөбүз. 1-бөлүк. Жазды жана JavaEEди үйрөнүүдөн мурун эмнени бorшиңиз керек 3-бөлүк. HTTP/HTTPS протоколдору 4-бөлүк. Maven негиздери 5-бөлүк. Сервлеттер. Жөнөкөй веб-тиркеме жазуу 6-бөлүк. Сервлет контейнерлери 7-бөлүк. MVC (Модель-Көрүү-Контроллер) үлгүсүн киргизүү 8-бөлүк. Чакан жазгы жүктөө тиркемесин жазуу