Ամեն օր, ամեն պահ մեր ինժեներական կարիերայի ընթացքում մենք բախվում ենք տարբեր բարդության բազմաթիվ խնդիրների և իրավիճակների, երբ անհրաժեշտ է որոշում կայացնել կամ հետաձգել այն տվյալների բացակայության պատճառով: Ամեն անգամ, երբ մենք կառուցում ենք նոր ծառայություններ, կառուցում ենք ենթակառուցվածքներ կամ նույնիսկ ձևավորում զարգացման գործընթացներ, մենք շոշափում ենք տարբեր մարտահրավերների հսկայական աշխարհ:
Դժվար է, և գուցե նույնիսկ անհնար է թվարկել բոլոր խնդիրները: Այս խնդիրներից մի քանիսին կհանդիպեք միայն այն դեպքում, եթե աշխատում եք կոնկրետ տեղամասում: Մյուս կողմից, կան շատերը, որոնք մենք բոլորս պետք է հասկանանք, թե ինչպես լուծել, քանի որ դրանք չափազանց կարևոր են ՏՏ համակարգեր կառուցելու համար: Մեծ հավանականությամբ նրանց կհանդիպեք բոլոր նախագծերում։
Այս հոդվածում ես կկիսվեմ իմ փորձով որոշ խնդիրների հետ կապված, որոնց հանդիպել եմ ծրագրային ծրագրեր ստեղծելիս:
Եթե նայենք Վիքիպեդիայում, ապա կգտնենք հետևյալ սահմանումը
Ասպեկտների վրա հիմնված ծրագրային ապահովման մշակման մեջ խաչաձեւ մտահոգությունները ծրագրի ասպեկտներն են, որոնք ազդում են մի քանի մոդուլների վրա՝ առանց դրանցից որևէ մեկում ներառվելու հնարավորության: Այս մտահոգությունները հաճախ չեն կարող հստակորեն քայքայվել համակարգի մնացած մասից և՛ նախագծման, և՛ իրականացման ընթացքում, և կարող են հանգեցնել կա՛մ ցրման (կոդերի կրկնօրինակում), կա՛մ խճճվելու (համակարգերի միջև զգալի կախվածություն) կամ երկուսն էլ:
Այն մեծապես նկարագրում է, թե ինչ է դա, բայց ես ուզում եմ մի փոքր ընդլայնել և պարզեցնել.
Խաչաձև մտահոգությունը համակարգի/կազմակերպության հասկացություն կամ բաղադրիչ է, որն ազդում է (կամ «հատում» է) շատ այլ մասերի:
Նման մտահոգությունների լավագույն օրինակներն են համակարգի ճարտարապետությունը, գրանցումը, անվտանգությունը, գործարքների կառավարումը, հեռաչափությունը, տվյալների բազայի ձևավորումը և շատ ուրիշներ: Դրանցից շատերի մասին մենք ավելի ուշ կանդրադառնանք այս հոդվածում:
Կոդի մակարդակում խաչաձեւ մտահոգությունները հաճախ իրականացվում են՝ օգտագործելով այնպիսի տեխնիկա, ինչպիսին է Aspect-Oriented Programming (AOP) , որտեղ այդ մտահոգությունները մոդուլյարացված են առանձին բաղադրիչների, որոնք կարող են կիրառվել ամբողջ հավելվածում: Սա պահում է բիզնես տրամաբանությունը մեկուսացված այս մտահոգություններից՝ ծածկագիրը դարձնելով ավելի ընթեռնելի և պահպանելի:
Կան բազմաթիվ հնարավոր եղանակներ, թե ինչպես կարելի է դասակարգել ասպեկտները՝ դրանք բաժանելով տարբեր հատկություններով, ինչպիսիք են շրջանակը, չափը, ֆունկցիոնալությունը, կարևորությունը, թիրախը և այլն, բայց այս հոդվածում ես պատրաստվում եմ օգտագործել շրջանակի պարզ դասակարգում: Սրանով ես նկատի ունեմ, թե ուր է ուղղված այս կոնկրետ ասպեկտը՝ լինի դա ամբողջ կազմակերպությունը, որոշակի համակարգ, թե այդ համակարգի որոշակի տարր:
Այսպիսով, ես պատրաստվում եմ ասպեկտները բաժանել մակրո և միկրո :
Մակրո ասպեկտ ասելով ես նկատի ունեմ հիմնականում այն նկատառումները, որոնք մենք հետևում ենք ամբողջ համակարգի համար, ինչպիսիք են ընտրված համակարգի ճարտարապետությունը և դրա ձևավորումը (միաձույլ, միկրոսերվիսներ, սպասարկման վրա հիմնված ճարտարապետություն), տեխնոլոգիական փաթեթ, կազմակերպչական կառուցվածք և այլն: Մակրո ասպեկտները կապված են հիմնականում ռազմավարական և բարձր մակարդակի հետ: որոշումներ։
Միևնույն ժամանակ, Micro ասպեկտը շատ ավելի մոտ է կոդի մակարդակին և զարգացմանը: Օրինակ, թե որ շրջանակն է օգտագործվում տվյալների բազայի հետ շփվելու, թղթապանակների և դասերի նախագծի կառուցվածքի կամ նույնիսկ օբյեկտների նախագծման հատուկ օրինաչափությունների համար:
Թեև այս դասակարգումը իդեալական չէ, այն օգնում է հասկանալ հնարավոր խնդիրների և լուծումների կարևորությունն ու ազդեցությունը, որոնք մենք կիրառում ենք դրանց նկատմամբ:
Այս հոդվածում իմ հիմնական ուշադրությունը կլինի մակրո ասպեկտների վրա:
Երբ ես նոր սկսեցի սովորել ծրագրային ապահովման ճարտարապետությունը, ես կարդացի շատ հետաքրքիր հոդվածներ Քոնուեյի օրենքի և կազմակերպչական կառուցվածքի վրա դրա ազդեցության մասին: Հատկապես այս մեկը : Այսպիսով, այս օրենքը ասում է, որ
Ցանկացած կազմակերպություն, որը նախագծում է համակարգ (ընդհանուր սահմանմամբ) կստեղծի դիզայն, որի կառուցվածքը հանդիսանում է կազմակերպության հաղորդակցման կառուցվածքի պատճենը:
Ես միշտ հավատացել եմ, որ այս հայեցակարգն իսկապես շատ ունիվերսալ է և ներկայացնում է Ոսկե կանոնը:
Հետո ես սկսեցի սովորել Էրիկ Էվանսի Domain-Driven Design (DDD) մոտեցումը մոդելավորման համակարգերի համար: Էրիկ Էվանսն ընդգծում է Սահմանափակ համատեքստի նույնականացման կարևորությունը: Այս հայեցակարգը ներառում է բարդ տիրույթի մոդելի բաժանում ավելի փոքր, ավելի կառավարելի բաժինների, որոնցից յուրաքանչյուրն ունի իր սահմանափակ գիտելիքների փաթեթը: Այս մոտեցումն օգնում է արդյունավետ թիմային հաղորդակցությանը, քանի որ այն նվազեցնում է ողջ տիրույթի լայնածավալ գիտելիքների անհրաժեշտությունը և նվազագույնի է հասցնում համատեքստի փոփոխությունը՝ այդպիսով դարձնելով խոսակցություններն ավելի արդյունավետ: Համատեքստի փոխարկումը երբևէ եղած ամենավատ և ռեսուրսներ սպառող բանն է: Նույնիսկ համակարգիչները պայքարում են դրա դեմ: Թեև դժվար թե հասնենք համատեքստի փոփոխման իսպառ բացակայությանը, ես կարծում եմ, որ դա այն է, ինչին մենք պետք է ձգտենք:
Վերադառնալով Քոնուեյի օրենքին, ես դրա հետ կապված մի քանի խնդիր գտա:
Առաջին խնդիրը, որը ես հանդիպեցի Conway-ի օրենքի հետ կապված, որը ենթադրում է, որ համակարգի դիզայնը արտացոլում է կազմակերպչական կառուցվածքը, բարդ և համապարփակ Սահմանափակ համատեքստեր ձևավորելու ներուժն է: Այս բարդությունն առաջանում է, երբ կազմակերպչական կառուցվածքը համահունչ չէ տիրույթի սահմաններին, ինչը հանգեցնում է Սահմանափակ համատեքստերի, որոնք մեծապես փոխկապակցված են և բեռնված են տեղեկատվությունով: Դա հանգեցնում է զարգացման թիմի հաճախակի համատեքստի փոփոխության:
Մեկ այլ խնդիր այն է, որ կազմակերպչական տերմինաբանությունը արտահոսում է կոդի մակարդակով: Երբ կազմակերպչական կառուցվածքները փոխվում են, դա պահանջում է կոդերի բազայի փոփոխություններ՝ սպառելով արժեքավոր ռեսուրսներ:
Այսպիսով, Inverse Conway Maneuver-ին հետևելը օգնում է կառուցել համակարգ և կազմակերպություն, որը խրախուսում է ցանկալի ծրագրային ապահովման ճարտարապետությունը: Այնուամենայնիվ, ուշագրավ է ասել, որ այս մոտեցումն այնքան էլ լավ չի աշխատի արդեն ձևավորված ճարտարապետության և կառույցներում, քանի որ փոփոխություններն այս փուլում երկարաձգվում են, բայց այն բացառիկ արդյունք է տալիս ստարտափներում, քանի որ նրանք արագ են փոփոխություններ մտցնում:
Այս օրինաչափությունը կամ «հակաօրինաչափությունը» մղում է համակարգ կառուցել առանց որևէ ճարտարապետության: Չկան կանոններ, չկան սահմաններ և ռազմավարություն, թե ինչպես վերահսկել անխուսափելի աճող բարդությունը: Բարդությունն ամենասարսափելի թշնամին է ծրագրային համակարգեր կառուցելու ճանապարհին:
Նման տիպի համակարգ կառուցելուց խուսափելու համար մենք պետք է հետևենք հատուկ կանոններին և սահմանափակումներին:
Ծրագրային ճարտարապետության համար կան բազմաթիվ սահմանումներ: Ինձ դուր են գալիս նրանցից շատերը, քանի որ դրանք ընդգրկում են դրա տարբեր կողմերը: Այնուամենայնիվ, ճարտարապետության մասին տրամաբանելու համար մենք բնականաբար պետք է դրանցից մի քանիսը ձևավորենք մեր մտքում: Եվ ուշագրավ է ասել, որ այս սահմանումը կարող է զարգանալ։ Այնպես որ, գոնե առայժմ ինձ համար հետեւյալ նկարագրությունն ունեմ.
Software Architecture-ն ամեն օր կայացրած որոշումների և ընտրությունների մասին է, որոնք ազդում են կառուցված համակարգի վրա:
Որոշումներ կայացնելու համար, որոնք դուք պետք է ունենաք ձեր «պայուսակում» ծագող խնդիրների լուծման սկզբունքներն ու օրինաչափությունները, անհրաժեշտ է նաև նշել, որ պահանջների ըմբռնումը առանցքային է բիզնեսի կարիքները կառուցելու համար: Այնուամենայնիվ, երբեմն պահանջները թափանցիկ չեն կամ նույնիսկ սահմանված չեն, այս դեպքում ավելի լավ է սպասել ավելի շատ պարզաբանումներ ստանալու կամ ապավինել ձեր փորձին և վստահել ձեր ինտուիցիային: Բայց և այնպես, դուք չեք կարող ճիշտ որոշումներ կայացնել, եթե չունեք սկզբունքներ և օրինաչափություններ, որոնց վրա կարող եք ապավինել: Այստեղ ես գալիս եմ Ծրագրային ճարտարապետության ոճի սահմանմանը:
Software Architecture Style-ը սկզբունքների և օրինաչափությունների մի շարք է, որոնք սահմանում են, թե ինչպես ստեղծել ծրագրակազմ:
Կան բազմաթիվ տարբեր ճարտարապետական ոճեր, որոնք կենտրոնացած են պլանավորված ճարտարապետության տարբեր կողմերի վրա, և դրանցից մի քանիսը միանգամից կիրառելը նորմալ իրավիճակ է:
Օրինակ, ինչպիսիք են.
Միաձույլ ճարտարապետություն
Դոմենի վրա հիմնված դիզայն
Բաղադրիչի վրա հիմնված
Միկրոծառայություններ
Խողովակներ և ֆիլտրեր
Իրադարձությունների վրա հիմնված
Միկրոմիջուկ
Ծառայություններին ուղղված
և այլն…
Իհարկե, նրանք ունեն իրենց առավելություններն ու թերությունները, բայց ամենակարևորը, որ ես սովորել եմ, այն է, որ ճարտարապետությունը զարգանում է աստիճանաբար՝ կախված իրական խնդիրներից: Միաձույլ ճարտարապետությունից սկսելը հիանալի ընտրություն է գործառնական բարդությունները նվազեցնելու համար, շատ հավանական է, որ այս ճարտարապետությունը կհամապատասխանի ձեր կարիքներին նույնիսկ արտադրանքի կառուցման Product-market Fit (PMI) փուլին հասնելուց հետո: Մասշտաբով, դուք կարող եք դիտարկել շարժվել դեպի իրադարձությունների վրա հիմնված մոտեցում և միկրոծառայություններ՝ անկախ տեղակայման, տարասեռ տեխնոլոգիական փաթեթային միջավայրի և ավելի քիչ զուգակցված ճարտարապետության հասնելու համար (և միևնույն ժամանակ ավելի քիչ թափանցիկ՝ իրադարձությունների վրա հիմնված և pub-sub մոտեցումների բնույթի պատճառով, եթե դրանք ընդունված են): Պարզությունն ու արդյունավետությունը մոտ են և մեծ ազդեցություն ունեն միմյանց վրա։ Սովորաբար, բարդ ճարտարապետությունները ազդում են նոր առանձնահատկությունների զարգացման արագության վրա՝ աջակցելով և պահպանելով գոյություն ունեցողները և մարտահրավեր նետելով համակարգի բնական էվոլյուցիայի վրա:
Այնուամենայնիվ, բարդ համակարգերը հաճախ պահանջում են բարդ և համապարփակ ճարտարապետություն, ինչն անխուսափելի է:
Ճիշտ է, սա շատ լայն թեմա է, և կան բազմաթիվ հիանալի գաղափարներ այն մասին, թե ինչպես կառուցել և կառուցել համակարգեր բնական էվոլյուցիայի համար: Իմ փորձի հիման վրա ես մշակել եմ հետևյալ մոտեցումը.
Կարևոր է նաև հասկանալ թվերն ու չափորոշիչները, ինչպիսիք են DAU (օրական ակտիվ օգտվողներ), MAU (ամսական ակտիվ օգտվողներ), RPC (խնդրանք մեկ վայրկյանում) և TPC (գործարք մեկ վայրկյանում), քանի որ դա կարող է օգնել ձեզ ընտրություն կատարել, քանի որ ճարտարապետությունը 100 ակտիվ օգտվողները և 100 միլիոն ակտիվ օգտվողները տարբեր են:
Որպես վերջնական նշում, ես կասեմ, որ ճարտարապետությունը էական ազդեցություն ունի արտադրանքի հաջողության վրա: Սանդղակավորման ժամանակ պահանջվում է արտադրանքի համար վատ մշակված ճարտարապետություն, ինչը, ամենայն հավանականությամբ, հանգեցնում է ձախողման, քանի որ հաճախորդները չեն սպասի, մինչև դուք մասշտաբեք համակարգը, նրանք կընտրեն մրցակից, ուստի մենք պետք է առաջ լինենք պոտենցիալ մասշտաբից: Թեև ես ընդունում եմ, որ երբեմն դա չի կարող նիհար մոտեցում լինել, գաղափարը մասշտաբային, բայց ոչ արդեն մասշտաբային համակարգ ունենալն է: Մյուս կողմից, շատ բարդ և արդեն մասշտաբային համակարգ ունենալը, առանց հաճախորդների կամ նրանցից շատերին ձեռք բերելու պլանների, ձեզ համար գումար կարժենա ձեր բիզնեսի վրա:
Տեխնոլոգիաների կույտի ընտրությունը նաև մակրո մակարդակի որոշում է, քանի որ այն ազդում է աշխատանքի ընդունման, համակարգի բնական էվոլյուցիայի հեռանկարների, մասշտաբայնության և համակարգի կատարողականի վրա:
Ահա հիմնական նկատառումների ցանկը տեխնոլոգիական կույտ ընտրելու համար.
Ինչպե՞ս կարող է բազմաթիվ տեխնոլոգիական կույտեր ունենալը ազդել բիզնեսի աճի վրա:
Մի տեսանկյունից, ևս մեկ կույտ ներկայացնելը կարող է մեծացնել ձեր աշխատանքի ընդունումը, բայց մյուս կողմից, դա բերում է լրացուցիչ պահպանման ծախսեր, քանի որ դուք պետք է աջակցեք երկու կույտերին: Այսպիսով, ինչպես ես նախկինում ասացի, իմ տեսանկյունից, միայն լրացուցիչ կարիքը պետք է լինի ավելի շատ տեխնոլոգիական կույտեր ներառելու փաստարկ:
Բայց ի՞նչ է վերաբերում կոնկրետ խնդրի համար լավագույն գործիքն ընտրելու սկզբունքին:
Երբեմն դուք այլ ելք չեք ունենում, քան նոր գործիքներ բերել կոնկրետ խնդրի լուծման համար՝ հիմնվելով վերոհիշյալ նույն նկատառումների վրա, նման դեպքերում իմաստ ունի ընտրել լավագույն լուծումը:
Համակարգերի ստեղծումն առանց որոշակի տեխնոլոգիայի բարձր զուգակցման կարող է մարտահրավեր լինել: Այնուամենայնիվ, օգտակար է ձգտել այնպիսի վիճակի, որտեղ համակարգը սերտորեն կապված չէ տեխնոլոգիայի հետ, և այն չի մեռնի, եթե վաղը որոշակի շրջանակ կամ գործիք դառնա խոցելի կամ նույնիսկ հնացած:
Մեկ այլ կարևոր նկատառում կապված է բաց կոդով և սեփականության ծրագրային ապահովման կախվածության հետ: Գույքային ծրագրաշարը ձեզ ավելի քիչ ճկունություն և հարմարեցման հնարավորություն է տալիս: Այնուամենայնիվ, ամենավտանգավոր գործոնը վաճառողի կողպումն է, որտեղ դուք կախված եք վաճառողի արտադրանքից, գներից, պայմաններից և ճանապարհային քարտեզից: Սա կարող է ռիսկային լինել, եթե վաճառողը փոխի ուղղությունը, բարձրացնի գները կամ դադարեցնի արտադրանքը: Բաց կոդով ծրագրակազմը նվազեցնում է այս ռիսկը, քանի որ մեկ կազմակերպություն չի վերահսկում այն: Բոլոր մակարդակներում ձախողման մեկ կետի վերացումը կարևոր է աճի համար հուսալի համակարգեր կառուցելու համար:
Խափանման մեկ կետը (SPOF) վերաբերում է համակարգի ցանկացած մասի, որը, եթե այն ձախողվի, կհանգեցնի ամբողջ համակարգի աշխատանքի դադարեցմանը: SPOF-ների վերացումը բոլոր մակարդակներում կարևոր է ցանկացած համակարգի համար, որը պահանջում է բարձր հասանելիություն: Ամեն ինչ, ներառյալ գիտելիքները, անձնակազմը, համակարգի բաղադրիչները, ամպային մատակարարները և ինտերնետ մալուխները, կարող են ձախողվել:
Կան մի քանի հիմնական տեխնիկա, որոնք մենք կարող ենք կիրառել ձախողման առանձին կետերը վերացնելու համար.
Այս հոդվածում մենք լուսաբանեցինք մի քանի հիմնական մակրո ասպեկտներ և ինչպես կարող ենք հաղթահարել դրանց բարդությունը:
Շնորհակալություն կարդալու համար: Կհանդիպենք հաջորդ անգամ: