🥇 Архитектура софтвера и дизајн система: Водич за велику слику и ресурсе

Здраво колеге.

Данас вам нудимо на разматрање превод чланка Тугберка Угурлуа, који се обавезао да у релативно малом обиму изнесе принципе пројектовања савремених софтверских система. Ево шта укратко каже аутор о себи:

Пошто је апсолутно немогуће у хабро чланку покрити тако колосалну тему као што су архитектонски обрасци + обрасци дизајна од 2019. године, препоручујемо не само текст господина Уруглуа, већ и бројне линкове које је љубазно укључио у њега. Ако вам се свиђа, објавићемо више специјализовани текст о дизајну дистрибуираних система.

Снапсхот Исаац Смитх од Унспласх-а

Ако никада нисте морали да се суочите са таквим изазовима као што је пројектовање софтверског система од нуле, онда када започнете такав посао, понекад није јасно одакле да почнете. Верујем да прво треба да повучете границе како бисте имали колико-толико сигурну представу шта ћете тачно дизајнирати, а затим засукати рукаве и радити у тим границама. Као почетну тачку, можете узети производ или услугу (идеално онај који вам се заиста свиђа) и смислити како да га имплементирате. Можда ћете бити запањени колико једноставно овај производ изгледа и колико сложености заправо садржи. Не заборавите: једноставно - обично сложено, и то је у реду.

Мислим да је најбољи савет који могу дати свакоме ко почиње да дизајнира систем: немојте правити никакве претпоставке! Од самог почетка, потребно је да наведете познате чињенице о овом систему и очекивања у вези са њим. Ево неколико добрих питања која би вам помогла да почнете са дизајном:

Који је проблем који покушавамо да решимо?
Колики је највећи број корисника који ће комуницирати са нашим системом?
Које обрасце писања и читања података ћемо користити?
Који су очекивани случајеви неуспеха, како ћемо их решити?
Која су очекивања за доследност и доступност система?
Да ли приликом рада морате да узмете у обзир било какве захтеве везане за спољну верификацију и регулацију?
Које врсте осетљивих података ћемо чувати?

Ово су само нека питања која су била корисна и мени и тимовима у којима сам учествовао током година професионалног деловања. Ако знате одговоре на ова питања (и било која друга која су релевантна за контекст у коме морате да радите), онда можете постепено да улазите у техничке детаље проблема.

Поставите почетни ниво

Шта овде подразумевам под „основном линијом“? Заправо, у наше време већина проблема у софтверској индустрији „може“ да се реши коришћењем постојећих метода и технологија. Сходно томе, навигацијом овим пејзажом, добијате одређену предност када се суочите са проблемима које је неко други морао да реши пре вас. Не заборавите да су програми написани да решавају пословне и корисничке проблеме, тако да настојимо да проблем решимо на најједноставнији (са корисничке тачке гледишта) начин. Зашто је ово важно запамтити? Можда у свом координатном систему волите да тражите јединствена решења за све проблеме, јер мислите „какав сам ја програмер ако свуда пратим шаблоне“? Заправо, уметност овде доноси одлуке о томе где и шта да се ради. Наравно, свако од нас се с времена на време мора суочити са јединственим проблемима, од којих је сваки прави изазов. Међутим, ако је наш почетни ниво јасно дефинисан, онда знамо на шта да трошимо енергију: тражење готових опција за решавање проблема који је пред нама, или његово даље проучавање и стицање дубљег разумевања.

Мислим да сам успео да вас убедим да ако специјалиста са сигурношћу разуме шта је архитектонска компонента неких дивних софтверских система, онда ће ово знање бити неопходно за савладавање уметности архитекте и развој чврсте основе у овој области.

У реду, одакле да почнем? У Донна Мартина На ГитХуб-у постоји спремиште под називом систем-дизајн-прајмер, из које можете научити како да дизајнирате системе великих размера, као и да се припремите за интервјуе на ову тему. Репозиторијум има одељак са примерима стварне архитектуре, где се посебно разматра како они приступају пројектовању својих система неке познате компанијенпр. Твитер, Убер итд.

Међутим, пре него што пређемо на овај материјал, хајде да поближе погледамо најважније архитектонске изазове са којима се суочавамо у пракси. Ово је важно јер морате навести МНОГЕ аспекте једног тврдоглавог и вишеструког проблема, а затим га решити у оквиру прописа који су на снази у датом систему. Јацксон Габбард, написао је бивши радник Фејсбука 50-минутни видео о интервјуима за дизајн система, где је поделио сопствено искуство скрининга стотина кандидата. Док се видео у великој мери фокусира на дизајн великог система и критеријуме успеха који су важни када се тражи кандидат за такву позицију, он ће и даље служити као свеобухватан ресурс о томе шта је најважније при дизајнирању система. такође предлажем резиме овај видео.

Изградите знање о чувању и преузимању података

Обично ваша одлука о томе како чувате и преузимате своје податке на дужи рок има критичан утицај на перформансе система. Стога, прво морате да разумете очекиване карактеристике писања и читања вашег система. Затим морате бити у стању да процените ове индикаторе и направите избор на основу направљених процена. Међутим, можете ефикасно да се носите са овим послом само ако разумете постојеће обрасце складиштења података. У принципу, ово подразумева солидно знање у вези са избор базе података.

Базе података се могу сматрати структурама података које су изузетно скалабилне и издржљиве. Због тога би вам познавање структура података требало бити веома корисно када бирате одређену базу података. На пример, Редис је сервер структуре података који подржава различите врсте вредности. Омогућава вам да радите са структурама података као што су листе и скупови и читате податке користећи познате алгоритаме, на пример, ЛРУ, организујући такав рад у трајном и веома приступачном стилу.

Снапсхот Самуел Зеллер од Унспласх-а

Када сте довољно разумели различите обрасце складиштења података, пређите на проучавање конзистентности и доступности података. Пре свега, морате разумети ЦАП теорема барем у општем смислу, а затим усавршити ово знање пажљивије сагледавајући утврђене обрасце доследност и приступачност. На овај начин ћете стећи више знања у овој области и разумети да су читање и писање података заправо два веома различита проблема, сваки са својим јединственим изазовима. Наоружани са неколико образаца конзистентности и доступности, можете значајно повећати перформансе система док истовремено обезбеђујете несметан проток података до ваших апликација.

На крају, закључујући разговор о проблемима складиштења података, треба поменути и кеширање. Да ли треба да ради истовремено на клијенту и серверу? Који подаци ће бити у вашој кеш меморији? И зашто? Како организујете поништавање кеша? Да ли ће се то радити редовно, у одређеним интервалима? Ако да, колико често? Препоручујем да почнете да проучавате ове теме са следећи одељак горе поменути прајмер за дизајн система.

Комуникациони обрасци

Системи се састоје од различитих компоненти; то могу бити различити процеси који се покрећу унутар истог физичког чвора или различите машине које раде у различитим деловима ваше мреже. Неки од ових ресурса унутар ваше мреже могу бити приватни, али други треба да буду јавни и отворени за потрошаче који им приступају споља.

Неопходно је обезбедити међусобну комуникацију ових ресурса, као и размену информација између целог система и спољашњег света. У контексту пројектовања система, овде смо поново суочени са низом нових и јединствених изазова. Хајде да видимо како они могу бити корисни асинхрони токови задатака, а шта стрДоступни су различити комуникацијски обрасци.

Снапсхот Тони Стоддард од Унспласх-а

Приликом организовања комуникације са спољним светом, то је увек веома важно сигурностчију одредбу такође треба схватити озбиљно и активно пратити.

Дистрибуција везе

Нисам сигуран да ће стављање ове теме у посебан одељак свима изгледати оправдано. Ипак, овде ћу детаљно представити овај концепт и верујем да је материјал у овом одељку најтачније описан термином „дистрибуција везе“.

Системи се формирају правилним повезивањем многих компоненти, а њихова комуникација међу собом се често организује на основу успостављених протокола, на пример, ТЦП и УДП. Међутим, ови протоколи као такви често су недовољни да задовоље све потребе савремених система, који често раде под великим оптерећењем и такође у великој мери зависе од потреба корисника. Често је потребно пронаћи начине за дистрибуцију веза како би се носили са тако великим оптерећењима система.

Ова дистрибуција се заснива на добро познатом систем имена домена (ДНС). Такав систем омогућава трансформације имена домена, као што су пондерисани роунд робин и методе засноване на кашњењу да помогну у расподели оптерећења.

Балансирање оптерећења је фундаментално важно, и практично сваки велики Интернет систем са којим се данас бавимо налази се иза једног или више балансера оптерећења. Балансери оптерећења помажу да се захтеви клијената дистрибуирају на више доступних инстанци. Балансери оптерећења долазе и у хардверу и у софтверу, међутим, у пракси, чешће морате да имате посла са софтверским, нпр. ХАПроки и ЕЛБ. Обрнути проксији концептуално такође веома сличан балансаторима оптерећења, иако постоји распон између првог и другог изразите разлике. Ове разлике се морају узети у обзир приликом пројектовања система заснованог на вашим потребама.

Такође би требало да знате о мреже за испоруку садржаја (ЦДН). ЦДН је глобална дистрибуирана мрежа прокси сервера која испоручује информације са чворова који су географски лоцирани ближе одређеном кориснику. ЦДН-ове је пожељно користити ако радите са статичким датотекама написаним у ЈаваСцрипт-у, ЦСС-у и ХТМЛ-у. Поред тога, данас су уобичајене услуге у облаку које пружају менаџере саобраћаја, нпр. Азуре Траффиц Манагер, што вам даје глобалну дистрибуцију и смањено кашњење када радите са динамичким садржајем. Међутим, такве услуге су обично корисне у случајевима када морате да радите са веб услугама без држављанства.

Хајде да причамо о пословној логици. Структурирање пословне логике, токова задатака и компоненти

Дакле, успели смо да разговарамо о различитим инфраструктурним аспектима система. Највероватније, корисник чак и не размишља о свим овим елементима вашег система и, искрено, уопште не брине о њима. Корисника занима како је у интеракцији са вашим системом, шта се тиме може постићи, као и како систем извршава корисничке команде, шта и како ради са корисничким подацима.

Као што наслов овог чланка сугерише, хтео сам да причам о архитектури софтвера и дизајну система. Сходно томе, нисам планирао да покривам обрасце дизајна софтвера који описују како се софтверске компоненте креирају. Међутим, што више размишљам о томе, све ми се више чини да је граница између шаблона софтверског дизајна и архитектонских образаца веома замагљена, а два концепта су уско повезана. Узмимо за пример регистрација догађаја (извор догађаја). Једном када усвојите овај архитектонски образац, он ће утицати на скоро сваки аспект вашег система: дугорочно складиштење података, ниво конзистентности усвојен у вашем систему, облик компоненти у њему, итд, итд. Стога сам одлучио да поменем неке архитектонске обрасце који се директно односе на пословну логику. Иако ће се овај чланак морати ограничити на једноставну листу, охрабрујем вас да се упознате с њим и размислите о идејама повезаним са овим обрасцима. Овде си:

Колаборативни приступи

Изузетно је мало вероватно да ћете се наћи на пројекту као учесник који је искључиво одговоран за процес пројектовања система. Напротив, највероватније ћете морати да комуницирате са колегама који раде и унутар и изван вашег задатка. У овом случају, можда ћете морати да процените изабрана технолошка решења са колегама, идентификујете пословне потребе и разумете како најбоље да паралелизујете задатке.

Снапсхот Калеидицо од Унспласх-а

Први корак је да развијете тачно и заједничко разумевање шта је пословни циљ који покушавате да постигнете и са којим покретним деловима ћете морати да се носите. Технике групног моделирања, посебно јуришних догађаја (олуја догађаја) помажу да се овај процес значајно убрза и повећају шансе за успех. Овај рад се може обавити пре или после вашег нацрта границе ваших услуга, а затим продубљује како производ сазрева. На основу нивоа доследности који ће се овде постићи, можете и формулисати заједнички језик због ограниченог контекста у којем радите. Када треба да разговарате о архитектури вашег система, можда ће вам бити од користи модел Ц4, предложено Симон Бровн, посебно када треба да схватите колико ћете морати да улазите у детаље проблема, визуелизујући ствари које желите да комуницирате.

Вероватно постоји још једна зрела технологија на ову тему која није ништа мање корисна од Домаин Дривен Десигн. Ипак, некако се враћамо разумевању предметне области, дакле знању и искуству у тој области Дизајн вођен доменом требало би да вам буде корисно.

Извор: ввв.хабр.цом

Архитектура софтвера и дизајн система: Водич за велику слику и ресурсе

Додај коментар Одустани од одговора