Բարև գործընկերներ:
Այսօր ձեր ուշադրությանն ենք առաջարկում Թուգբերկ Ուգուրլուի հոդվածի թարգմանությունը, ով պարտավորվել է համեմատաբար փոքր ծավալով ուրվագծել ժամանակակից ծրագրային համակարգերի նախագծման սկզբունքները։ Ահա թե ինչ է ասում հեղինակն իր մասին ամփոփ կերպով.
Քանի որ 2019 թվականի դրությամբ հաբրո հոդվածում բացարձակապես անհնար է լուսաբանել այնպիսի հսկայական թեմա, ինչպիսին են ճարտարապետական նախշերը + դիզայնի նախշերը, խորհուրդ ենք տալիս ոչ միայն պարոն Ուրուգլուի տեքստը, այլև բազմաթիվ հղումները, որոնք նա սիրով ներառել է դրանում: Եթե ձեզ դուր է գալիս, մենք կհրապարակենք ավելի բարձր մասնագիտացված տեքստ բաշխված համակարգերի նախագծման մասին:
Լուսանկարը Unsplash-ից
Եթե դուք երբեք ստիպված չեք եղել դիմակայել այնպիսի մարտահրավերների, ինչպիսին է զրոյից ծրագրային համակարգի նախագծումը, ապա նման աշխատանք սկսելիս երբեմն նույնիսկ պարզ չէ, թե որտեղից սկսել: Կարծում եմ, որ նախ պետք է սահմաններ գծել, որպեսզի քիչ թե շատ վստահ պատկերացում ունենաս այն մասին, թե կոնկրետ ինչ ես պատրաստվում նախագծել, իսկ հետո թևերդ քաշել և աշխատել այդ սահմաններում: Որպես ելակետ, դուք կարող եք վերցնել ապրանքը կամ ծառայությունը (իդեալականում այն, որը ձեզ իսկապես դուր է գալիս) և պարզել, թե ինչպես դա իրականացնել: Դուք կարող եք զարմանալ, թե որքան պարզ է այս ապրանքի տեսքը և որքան բարդ է այն իրականում պարունակում: Չմոռանաս: , և դա նորմալ է:
Կարծում եմ, լավագույն խորհուրդը, որ կարող եմ տալ բոլորին, ովքեր սկսում են համակարգ նախագծել, սա է. ոչ մի ենթադրություն մի արեք: Հենց սկզբից պետք է հստակեցնել այս համակարգի մասին հայտնի փաստերն ու դրա հետ կապված ակնկալիքները։ Ահա մի քանի լավ հարցեր, որոնք կարող են օգնել ձեզ սկսել ձեր դիզայնը.
- Ո՞րն է այն խնդիրը, որը մենք փորձում ենք լուծել։
- Որքա՞ն է օգտատերերի առավելագույն թիվը, որոնք կշփվեն մեր համակարգի հետ:
- Գրելու և կարդալու տվյալների ի՞նչ օրինաչափություններ ենք օգտագործելու:
- Որո՞նք են սպասվող ձախողման դեպքերը, ինչպե՞ս ենք դրանք վարվելու։
- Որո՞նք են համակարգի հետևողականության և հասանելիության ակնկալիքները:
- Աշխատելիս պետք է հաշվի առնե՞ք արտաքին ստուգման և կարգավորման հետ կապված որևէ պահանջ:
- Ի՞նչ տեսակի զգայուն տվյալներ ենք մենք պատրաստվում պահել:
Սրանք ընդամենը մի քանի հարցեր են, որոնք օգտակար են եղել ինչպես ինձ, այնպես էլ այն թիմերին, որոնց ես մասնակցել եմ մասնագիտական գործունեության տարիների ընթացքում։ Եթե դուք գիտեք այս հարցերի պատասխանները (և ցանկացած այլ, որը վերաբերում է այն համատեքստին, որտեղ դուք պետք է աշխատեք), ապա կարող եք աստիճանաբար խորանալ խնդրի տեխնիկական մանրամասների մեջ:
Սահմանեք նախնական մակարդակը
Ի՞նչ նկատի ունեմ այստեղ «բազային» ասելով: Փաստորեն, մեր ժամանակներում ծրագրային ապահովման ոլորտում առկա խնդիրների մեծ մասը «կարելի է» լուծվել՝ օգտագործելով առկա մեթոդներն ու տեխնոլոգիաները։ Համապատասխանաբար, այս լանդշաֆտով նավարկելով, դուք որոշակի առաջընթաց եք ստանում, երբ բախվում եք խնդիրների, որոնք մեկ ուրիշը պետք է լուծեր ձեզանից առաջ: Մի մոռացեք, որ ծրագրերը գրված են բիզնեսի և օգտատերերի խնդիրները լուծելու համար, ուստի մենք ձգտում ենք լուծել խնդիրը ամենապարզ և պարզ (օգտատիրոջ տեսանկյունից): Ինչու՞ է սա կարևոր հիշել: Միգուցե ձեր կոորդինատային համակարգում դուք սիրում եք յուրօրինակ լուծումներ փնտրել բոլոր խնդիրների համար, որովհետև մտածում եք՝ «ի՞նչ ծրագրավորող եմ ես, եթե ամենուր հետևում եմ օրինաչափություններին»: Իրականում, արվեստն այստեղ որոշումներ է կայացնում, թե որտեղ և ինչ անել. Իհարկե, մեզանից յուրաքանչյուրը ժամանակ առ ժամանակ պետք է առնչվի յուրահատուկ խնդիրների հետ, որոնցից յուրաքանչյուրն իսկական մարտահրավեր է։ Այնուամենայնիվ, եթե մեր սկզբնական մակարդակը հստակ սահմանված է, ապա մենք գիտենք, թե ինչի վրա ծախսենք մեր էներգիան՝ մեր առջեւ դրված խնդրի լուծման պատրաստի տարբերակների որոնում, թե՞ հետագա ուսումնասիրություն և ավելի խորը պատկերացում ձեռք բերելու համար:
Կարծում եմ՝ կարողացա ձեզ համոզել, որ եթե մասնագետը վստահորեն հասկանա, թե որն է որոշ հրաշալի ծրագրային համակարգերի ճարտարապետական բաղադրիչը, ապա այս գիտելիքն անփոխարինելի կլինի ճարտարապետի արվեստին տիրապետելու և այս ոլորտում ամուր հիմքեր ստեղծելու համար։
Լավ, ուրեմն որտեղի՞ց սկսել: U GitHub-ում կա պահեստ, որը կոչվում է , որտեղից կարող եք սովորել, թե ինչպես նախագծել լայնածավալ համակարգեր, ինչպես նաև պատրաստվել այս թեմայով հարցազրույցների։ Պահեստն ունի բաժին օրինակներով , որտեղ, մասնավորապես, դիտարկվում է, թե ինչպես են մոտենում իրենց համակարգերի նախագծմանը օրինակ՝ Twitter, Uber և այլն:
Այնուամենայնիվ, նախքան այս նյութին անցնելը, եկեք ավելի սերտ նայենք ճարտարապետական ամենակարևոր մարտահրավերներին, որոնք մենք բախվում ենք գործնականում: Սա կարևոր է, քանի որ համառ և բազմաբնույթ խնդրի ՇԱՏ ասպեկտներ պետք է հստակեցնել, հետո լուծել տվյալ համակարգում գործող կանոնակարգերի շրջանակներում։ Facebook-ի նախկին աշխատակիցը գրել է , որտեղ նա կիսվել է հարյուրավոր դիմորդների զննման սեփական փորձով։ Թեև տեսանյութը մեծապես կենտրոնանում է խոշոր համակարգերի նախագծման և հաջողության չափանիշների վրա, որոնք կարևոր են նման պաշտոնի համար թեկնածու փնտրելիս, այն դեռևս կծառայի որպես համապարփակ ռեսուրս այն մասին, թե ինչ բաներ են առավել կարևոր համակարգեր նախագծելիս: Ես էլ եմ առաջարկում այս տեսանյութը.
Ձեռք բերեք գիտելիքներ տվյալների պահպանման և առբերման վերաբերյալ
Սովորաբար, ձեր որոշումը այն մասին, թե ինչպես եք պահում և առբերում ձեր տվյալները երկարաժամկետ հեռանկարում, կարևոր ազդեցություն ունի համակարգի աշխատանքի վրա: Հետևաբար, նախ պետք է հասկանաք ձեր համակարգի ակնկալվող գրելու և կարդալու բնութագրերը: Ապա դուք պետք է կարողանաք գնահատել այս ցուցանիշները և ընտրություն կատարել՝ հիմնվելով կատարված գնահատումների վրա: Այնուամենայնիվ, դուք կարող եք արդյունավետորեն հաղթահարել այս աշխատանքը միայն այն դեպքում, եթե հասկանում եք տվյալների պահպանման գոյություն ունեցող օրինաչափությունները: Սկզբունքորեն սա ենթադրում է հիմնավոր գիտելիքներ՝ կապված .
Տվյալների բազաները կարելի է դիտարկել որպես տվյալների կառուցվածքներ, որոնք չափազանց լայնածավալ և դիմացկուն են: Հետևաբար, տվյալների կառուցվածքների իմացությունը պետք է շատ օգտակար լինի ձեզ հատուկ տվյալների բազա ընտրելիս: Օրինակ, տվյալների կառուցվածքի սերվեր է, որն աջակցում է տարբեր տեսակի արժեքների: Այն թույլ է տալիս աշխատել տվյալների կառուցվածքների հետ, ինչպիսիք են ցուցակներն ու հավաքածուները, և կարդալ տվյալները՝ օգտագործելով հայտնի ալգորիթմներ, օրինակ. , կազմակերպելով նման աշխատանքները երկարակյաց և մատչելի ոճով։
Լուսանկարը Unsplash-ից
Տվյալների պահպանման տարբեր օրինաչափությունների մասին բավականաչափ հասկանալուց հետո անցեք տվյալների հետևողականության և մատչելիության ուսումնասիրությանը: Առաջին հերթին պետք է հասկանալ գոնե ընդհանուր գծերով, և այնուհետև հղկեք այս գիտելիքները՝ ավելի մոտիկից նայելով հաստատված օրինաչափություններին и . Այսպիսով, դուք կզարգացնեք ոլորտի ըմբռնումը և կհասկանաք, որ տվյալներ կարդալն ու գրելը իրականում երկու տարբեր խնդիրներ են, որոնցից յուրաքանչյուրն ունի իր յուրահատուկ մարտահրավերները: Զինված լինելով մի քանի հետևողականության և մատչելիության օրինաչափություններով՝ դուք կարող եք զգալիորեն բարձրացնել համակարգի աշխատանքը՝ միաժամանակ ապահովելով տվյալների սահուն հոսք դեպի ձեր հավելվածներ:
Ի վերջո, ավարտելով զրույցը տվյալների պահպանման խնդիրների մասին, պետք է նշել նաև քեշավորումը։ Արդյո՞ք այն պետք է միաժամանակ աշխատի հաճախորդի և սերվերի վրա: Ի՞նչ տվյալներ կլինեն ձեր քեշում: Իսկ ինչո՞ւ։ Ինչպե՞ս եք կազմակերպում քեշի անվավերությունը: Արդյո՞ք դա կկատարվի կանոնավոր, որոշակի պարբերականությամբ։ Եթե այո, ապա որքան հաճախ: Խորհուրդ եմ տալիս սկսել ուսումնասիրել այս թեմաները համակարգի նախագծման վերը նշված այբբենարանը:
Հաղորդակցության ձևեր
Համակարգերը բաղկացած են տարբեր բաղադրիչներից. դրանք կարող են լինել տարբեր գործընթացներ, որոնք աշխատում են նույն ֆիզիկական հանգույցում, կամ տարբեր մեքենաներ, որոնք աշխատում են ձեր ցանցի տարբեր մասերում: Ձեր ցանցի այս ռեսուրսներից մի քանիսը կարող են մասնավոր լինել, բայց մյուսները պետք է լինեն հանրային և բաց սպառողների համար, ովքեր մուտք ունեն դրանք դրսից:
Անհրաժեշտ է ապահովել այդ ռեսուրսների հաղորդակցությունը միմյանց հետ, ինչպես նաև տեղեկատվության փոխանակում ամբողջ համակարգի և արտաքին աշխարհի միջև։ Համակարգերի նախագծման համատեքստում այստեղ կրկին բախվում ենք մի շարք նոր և եզակի մարտահրավերների: Տեսնենք, թե ինչպես կարող են դրանք օգտակար լինել , իսկ ինչ պ.
Լուսանկարը Unsplash-ից
Արտաքին աշխարհի հետ շփումը կազմակերպելիս դա միշտ շատ կարևոր է , որի տրամադրմանը նույնպես պետք է լրջորեն ու ակտիվորեն հետամուտ լինել։
Միացման բաշխում
Վստահ չեմ, որ այս թեման առանձին բաժին դնելը բոլորին արդարացված թվա: Այնուամենայնիվ, ես այստեղ մանրամասն կներկայացնեմ այս հայեցակարգը, և կարծում եմ, որ այս բաժնի նյութը առավել ճշգրիտ նկարագրված է «միացման բաշխում» տերմինով:
Համակարգերը ձևավորվում են շատ բաղադրիչներ պատշաճ կերպով միացնելու միջոցով, և դրանց հաղորդակցությունը միմյանց հետ հաճախ կազմակերպվում է սահմանված արձանագրությունների հիման վրա, օրինակ՝ TCP և UDP: Այնուամենայնիվ, այս արձանագրությունները որպես այդպիսին հաճախ անբավարար են ժամանակակից համակարգերի բոլոր կարիքները բավարարելու համար, որոնք հաճախ աշխատում են մեծ ծանրաբեռնվածության տակ և նույնպես մեծապես կախված են օգտագործողի կարիքներից: Հաճախ անհրաժեշտ է լինում գտնել միացումներ բաշխելու ուղիներ՝ համակարգի վրա նման բարձր բեռներին դիմակայելու համար:
Այս բաշխումը հիմնված է հայտնի (DNS): Նման համակարգը թույլ է տալիս տիրույթի անունների փոխակերպումներ, ինչպիսիք են կշռված կլոր ռոբին և ուշացման վրա հիմնված մեթոդները, որոնք կօգնեն բաշխել բեռը:
սկզբունքորեն կարևոր է, և գրեթե յուրաքանչյուր խոշոր ինտերնետ համակարգ, որի հետ մենք առնչվում ենք այսօր, գտնվում է մեկ կամ մի քանի բեռի հավասարակշռող սարքերի հետևում: Բեռնվածության հավասարակշռողներն օգնում են բաժանորդների հարցումները մի քանի մատչելի ատյաններում: Բեռի հավասարակշռիչները գալիս են և՛ ապարատային, և՛ ծրագրային ապահովման, սակայն գործնականում ավելի հաճախ պետք է գործ ունենալ ծրագրային ապահովման հետ, օրինակ. и . Կոնցեպտուալ առումով նույնպես շատ նման է բեռի հավասարակշռողներին, թեև առաջինի և երկրորդի միջև կա միջակայք . Այս տարբերությունները պետք է հաշվի առնվեն ձեր կարիքների հիման վրա համակարգ նախագծելիս:
Դուք նույնպես պետք է իմանաք դրա մասին (CDN): CDN-ն պրոքսի սերվերների գլոբալ բաշխված ցանց է, որը տեղեկատվություն է հաղորդում այն հանգույցներից, որոնք աշխարհագրորեն ավելի մոտ են գտնվում կոնկրետ օգտագործողին: CDN-ները նախընտրելի են օգտագործել, եթե աշխատում եք JavaScript, CSS և HTML-ով գրված ստատիկ ֆայլերի հետ: Բացի այդ, այսօր տարածված են ամպային ծառայությունները, որոնք տրամադրում են երթևեկության կառավարիչներ, օրինակ. , որը ձեզ տալիս է գլոբալ բաշխում և նվազեցված ուշացում դինամիկ բովանդակության հետ աշխատելիս: Այնուամենայնիվ, նման ծառայությունները սովորաբար օգտակար են այն դեպքերում, երբ դուք պետք է աշխատեք քաղաքացիություն չունեցող վեբ ծառայությունների հետ:
Եկեք խոսենք բիզնեսի տրամաբանությունից: Բիզնեսի տրամաբանության, առաջադրանքների հոսքերի և բաղադրիչների կառուցվածքը
Այսպիսով, մեզ հաջողվեց քննարկել համակարգի տարբեր ենթակառուցվածքային ասպեկտներ։ Ամենայն հավանականությամբ, օգտվողը չի էլ մտածում ձեր համակարգի բոլոր այս տարրերի մասին և, անկեղծ ասած, ընդհանրապես չի մտածում դրանց մասին: Օգտագործողին հետաքրքրում է, թե ինչպիսին է ձեր համակարգի հետ շփվելը, ինչի կարելի է հասնել դրանով, ինչպես նաև ինչպես է համակարգը կատարում օգտվողի հրամանները, ինչ և ինչպես է դա անում օգտվողի տվյալների հետ:
Ինչպես հուշում է այս հոդվածի վերնագիրը, ես պատրաստվում էի խոսել ծրագրային ապահովման ճարտարապետության և համակարգի ձևավորման մասին: Համապատասխանաբար, ես չէի նախատեսում լուսաբանել ծրագրային ապահովման նախագծման օրինաչափությունները, որոնք նկարագրում են, թե ինչպես են ստեղծվում ծրագրային բաղադրիչները: Այնուամենայնիվ, որքան շատ եմ մտածում այդ մասին, այնքան ինձ թվում է, որ ծրագրային ապահովման նախագծման օրինաչափությունների և ճարտարապետական նախշերի միջև սահմանը շատ մշուշոտ է, և երկու հասկացությունները սերտորեն կապված են: Օրինակ վերցնենք (միջոցառումների աղբյուր): Այս ճարտարապետական օրինաչափությունն ընդունելուց հետո այն կազդի ձեր համակարգի գրեթե բոլոր ասպեկտների վրա՝ տվյալների երկարաժամկետ պահպանում, ձեր համակարգում ընդունված հետևողականության մակարդակը, դրա բաղադրիչների ձևը և այլն և այլն: Ուստի ես որոշեցի նշել որոշ ճարտարապետական նախշեր, որոնք ուղղակիորեն վերաբերում են բիզնես տրամաբանությանը: Թեև այս հոդվածը պետք է սահմանափակվի պարզ ցուցակով, ես ձեզ խորհուրդ եմ տալիս ծանոթանալ դրա հետ և մտածել այդ օրինաչափությունների հետ կապված գաղափարների մասին: Ահա եւ դու:
- Հայեցակարգեր մասնավորապես ,
Համագործակցային մոտեցումներ
Չափազանց քիչ հավանական է, որ դուք հայտնվեք նախագծում որպես մասնակից, ով բացառապես պատասխանատու է համակարգի նախագծման գործընթացի համար: Ընդհակառակը, դուք, ամենայն հավանականությամբ, ստիպված կլինեք շփվել գործընկերների հետ, ովքեր աշխատում են ինչպես ձեր առաջադրանքում, այնպես էլ դրսում: Այս դեպքում ձեզ կարող է անհրաժեշտ լինել գործընկերների հետ գնահատել ընտրված տեխնոլոգիական լուծումները, բացահայտել բիզնեսի կարիքները և հասկանալ, թե ինչպես կարելի է լավագույնս զուգահեռել առաջադրանքները:
Լուսանկարը Unsplash-ից
Առաջին քայլը ճշգրիտ և ընդհանուր պատկերացում կազմելն է, թե որն է բիզնեսի նպատակը, որին փորձում եք հասնել և ինչ շարժվող մասերի հետ պետք է գործ ունենաք: Խմբային մոդելավորման տեխնիկան, մասնավորապես (միջոցառումների փոթորիկ) օգնում է զգալիորեն արագացնել այս գործընթացը և մեծացնել հաջողության ձեր հնարավորությունները: Այս աշխատանքը կարող է կատարվել նախքան ձեր ուրվագծերը կամ դրանից հետո , իսկ հետո խորացրեք այն, երբ ապրանքը հասունանա: Ելնելով այստեղ ձեռք բերվող հետևողականության մակարդակից, կարող եք նաև ձևակերպել սահմանափակ համատեքստի համար, որտեղ դուք աշխատում եք: Երբ դուք պետք է խոսեք ձեր համակարգի ճարտարապետության մասին, դա կարող է օգտակար լինել առաջարկված , հատկապես, երբ դուք պետք է հասկանաք, թե որքանով պետք է խորանաք խնդրի մանրամասների մեջ՝ պատկերացնելով այն բաները, որոնց հետ ցանկանում եք հաղորդակցվել:
Հավանաբար կա մեկ այլ հասուն տեխնոլոգիա այս թեմայի վերաբերյալ, որը ոչ պակաս օգտակար է, քան Domain Driven Design-ը: Այնուամենայնիվ, մենք ինչ-որ կերպ վերադառնում ենք առարկայական ոլորտը հասկանալուն, ուստի ոլորտում գիտելիքներն ու փորձը պետք է օգտակար լինի ձեզ համար:
Source: www.habr.com