Ինչպես հաղթահարել բարդությունը ծրագրային համակարգերի նախագծման ժամանակ

Ինչի՞ մասին է խոսքը։

Ամեն օր, ամեն պահ մեր ինժեներական կարիերայի ընթացքում մենք բախվում ենք տարբեր բարդության բազմաթիվ խնդիրների և իրավիճակների, երբ անհրաժեշտ է որոշում կայացնել կամ հետաձգել այն տվյալների բացակայության պատճառով: Ամեն անգամ, երբ մենք կառուցում ենք նոր ծառայություններ, կառուցում ենք ենթակառուցվածքներ կամ նույնիսկ ձևավորում զարգացման գործընթացներ, մենք շոշափում ենք տարբեր մարտահրավերների հսկայական աշխարհ:

Դժվար է, և գուցե նույնիսկ անհնար է թվարկել բոլոր խնդիրները: Այս խնդիրներից մի քանիսին կհանդիպեք միայն այն դեպքում, եթե աշխատում եք կոնկրետ տեղամասում: Մյուս կողմից, կան շատերը, որոնք մենք բոլորս պետք է հասկանանք, թե ինչպես լուծել, քանի որ դրանք չափազանց կարևոր են ՏՏ համակարգեր կառուցելու համար: Մեծ հավանականությամբ նրանց կհանդիպեք բոլոր նախագծերում։

Այս հոդվածում ես կկիսվեմ իմ փորձով որոշ խնդիրների հետ կապված, որոնց հանդիպել եմ ծրագրային ծրագրեր ստեղծելիս:

Ի՞նչ է խաչաձեւ մտահոգությունը:

Եթե նայենք Վիքիպեդիայում, ապա կգտնենք հետևյալ սահմանումը

Ասպեկտների վրա հիմնված ծրագրային ապահովման մշակման մեջ խաչաձեւ մտահոգությունները ծրագրի ասպեկտներն են, որոնք ազդում են մի քանի մոդուլների վրա՝ առանց դրանցից որևէ մեկում ներառվելու հնարավորության: Այս մտահոգությունները հաճախ չեն կարող հստակորեն քայքայվել համակարգի մնացած մասից և՛ նախագծման, և՛ իրականացման ընթացքում, և կարող են հանգեցնել կա՛մ ցրման (կոդերի կրկնօրինակում), կա՛մ խճճվելու (համակարգերի միջև զգալի կախվածություն) կամ երկուսն էլ:

Այն մեծապես նկարագրում է, թե ինչ է դա, բայց ես ուզում եմ մի փոքր ընդլայնել և պարզեցնել.

Խաչաձև մտահոգությունը համակարգի/կազմակերպության հասկացություն կամ բաղադրիչ է, որն ազդում է (կամ «հատում» է) շատ այլ մասերի:

Նման մտահոգությունների լավագույն օրինակներն են համակարգի ճարտարապետությունը, գրանցումը, անվտանգությունը, գործարքների կառավարումը, հեռաչափությունը, տվյալների բազայի ձևավորումը և շատ ուրիշներ: Դրանցից շատերի մասին մենք ավելի ուշ կանդրադառնանք այս հոդվածում:

Կոդի մակարդակում խաչաձեւ մտահոգությունները հաճախ իրականացվում են՝ օգտագործելով այնպիսի տեխնիկա, ինչպիսին է Aspect-Oriented Programming (AOP) , որտեղ այդ մտահոգությունները մոդուլյարացված են առանձին բաղադրիչների, որոնք կարող են կիրառվել ամբողջ հավելվածում: Սա պահում է բիզնես տրամաբանությունը մեկուսացված այս մտահոգություններից՝ ծածկագիրը դարձնելով ավելի ընթեռնելի և պահպանելի:

Ասպեկտների դասակարգում

Կան բազմաթիվ հնարավոր եղանակներ, թե ինչպես կարելի է դասակարգել ասպեկտները՝ դրանք բաժանելով տարբեր հատկություններով, ինչպիսիք են շրջանակը, չափը, ֆունկցիոնալությունը, կարևորությունը, թիրախը և այլն, բայց այս հոդվածում ես պատրաստվում եմ օգտագործել շրջանակի պարզ դասակարգում: Սրանով ես նկատի ունեմ, թե ուր է ուղղված այս կոնկրետ ասպեկտը՝ լինի դա ամբողջ կազմակերպությունը, որոշակի համակարգ, թե այդ համակարգի որոշակի տարր:

Այսպիսով, ես պատրաստվում եմ ասպեկտները բաժանել մակրո և միկրո :

Մակրո ասպեկտ ասելով ես նկատի ունեմ հիմնականում այն նկատառումները, որոնք մենք հետևում ենք ամբողջ համակարգի համար, ինչպիսիք են ընտրված համակարգի ճարտարապետությունը և դրա ձևավորումը (միաձույլ, միկրոսերվիսներ, սպասարկման վրա հիմնված ճարտարապետություն), տեխնոլոգիական փաթեթ, կազմակերպչական կառուցվածք և այլն: Մակրո ասպեկտները կապված են հիմնականում ռազմավարական և բարձր մակարդակի հետ: որոշումներ։

Միևնույն ժամանակ, Micro ասպեկտը շատ ավելի մոտ է կոդի մակարդակին և զարգացմանը: Օրինակ, թե որ շրջանակն է օգտագործվում տվյալների բազայի հետ շփվելու, թղթապանակների և դասերի նախագծի կառուցվածքի կամ նույնիսկ օբյեկտների նախագծման հատուկ օրինաչափությունների համար:

Թեև այս դասակարգումը իդեալական չէ, այն օգնում է հասկանալ հնարավոր խնդիրների և լուծումների կարևորությունն ու ազդեցությունը, որոնք մենք կիրառում ենք դրանց նկատմամբ:

Այս հոդվածում իմ հիմնական ուշադրությունը կլինի մակրո ասպեկտների վրա:

Մակրո ասպեկտներ

Կազմակերպչական կառուցվածքը

Երբ ես նոր սկսեցի սովորել ծրագրային ապահովման ճարտարապետությունը, ես կարդացի շատ հետաքրքիր հոդվածներ Քոնուեյի օրենքի և կազմակերպչական կառուցվածքի վրա դրա ազդեցության մասին: Հատկապես այս մեկը : Այսպիսով, այս օրենքը ասում է, որ

Ցանկացած կազմակերպություն, որը նախագծում է համակարգ (ընդհանուր սահմանմամբ) կստեղծի դիզայն, որի կառուցվածքը հանդիսանում է կազմակերպության հաղորդակցման կառուցվածքի պատճենը:

Ես միշտ հավատացել եմ, որ այս հայեցակարգն իսկապես շատ ունիվերսալ է և ներկայացնում է Ոսկե կանոնը:

Հետո ես սկսեցի սովորել Էրիկ Էվանսի Domain-Driven Design (DDD) մոտեցումը մոդելավորման համակարգերի համար: Էրիկ Էվանսն ընդգծում է Սահմանափակ համատեքստի նույնականացման կարևորությունը: Այս հայեցակարգը ներառում է բարդ տիրույթի մոդելի բաժանում ավելի փոքր, ավելի կառավարելի բաժինների, որոնցից յուրաքանչյուրն ունի իր սահմանափակ գիտելիքների փաթեթը: Այս մոտեցումն օգնում է արդյունավետ թիմային հաղորդակցությանը, քանի որ այն նվազեցնում է ողջ տիրույթի լայնածավալ գիտելիքների անհրաժեշտությունը և նվազագույնի է հասցնում համատեքստի փոփոխությունը՝ այդպիսով դարձնելով խոսակցություններն ավելի արդյունավետ: Համատեքստի փոխարկումը երբևէ եղած ամենավատ և ռեսուրսներ սպառող բանն է: Նույնիսկ համակարգիչները պայքարում են դրա դեմ: Թեև դժվար թե հասնենք համատեքստի փոփոխման իսպառ բացակայությանը, ես կարծում եմ, որ դա այն է, ինչին մենք պետք է ձգտենք:

Վերադառնալով Քոնուեյի օրենքին, ես դրա հետ կապված մի քանի խնդիր գտա:

Առաջին խնդիրը, որը ես հանդիպեցի Conway-ի օրենքի հետ կապված, որը ենթադրում է, որ համակարգի դիզայնը արտացոլում է կազմակերպչական կառուցվածքը, բարդ և համապարփակ Սահմանափակ համատեքստեր ձևավորելու ներուժն է: Այս բարդությունն առաջանում է, երբ կազմակերպչական կառուցվածքը համահունչ չէ տիրույթի սահմաններին, ինչը հանգեցնում է Սահմանափակ համատեքստերի, որոնք մեծապես փոխկապակցված են և բեռնված են տեղեկատվությունով: Դա հանգեցնում է զարգացման թիմի հաճախակի համատեքստի փոփոխության:

Մեկ այլ խնդիր այն է, որ կազմակերպչական տերմինաբանությունը արտահոսում է կոդի մակարդակով: Երբ կազմակերպչական կառուցվածքները փոխվում են, դա պահանջում է կոդերի բազայի փոփոխություններ՝ սպառելով արժեքավոր ռեսուրսներ:

Այսպիսով, Inverse Conway Maneuver-ին հետևելը օգնում է կառուցել համակարգ և կազմակերպություն, որը խրախուսում է ցանկալի ծրագրային ապահովման ճարտարապետությունը: Այնուամենայնիվ, ուշագրավ է ասել, որ այս մոտեցումն այնքան էլ լավ չի աշխատի արդեն ձևավորված ճարտարապետության և կառույցներում, քանի որ փոփոխություններն այս փուլում երկարաձգվում են, բայց այն բացառիկ արդյունք է տալիս ստարտափներում, քանի որ նրանք արագ են փոփոխություններ մտցնում:

Ցեխի մեծ գնդակ

Այս օրինաչափությունը կամ «հակաօրինաչափությունը» մղում է համակարգ կառուցել առանց որևէ ճարտարապետության: Չկան կանոններ, չկան սահմաններ և ռազմավարություն, թե ինչպես վերահսկել անխուսափելի աճող բարդությունը: Բարդությունն ամենասարսափելի թշնամին է ծրագրային համակարգեր կառուցելու ճանապարհին:

Նման տիպի համակարգ կառուցելուց խուսափելու համար մենք պետք է հետևենք հատուկ կանոններին և սահմանափակումներին:

Համակարգի ճարտարապետություն

Ծրագրային ճարտարապետության համար կան բազմաթիվ սահմանումներ: Ինձ դուր են գալիս նրանցից շատերը, քանի որ դրանք ընդգրկում են դրա տարբեր կողմերը: Այնուամենայնիվ, ճարտարապետության մասին տրամաբանելու համար մենք բնականաբար պետք է դրանցից մի քանիսը ձևավորենք մեր մտքում: Եվ ուշագրավ է ասել, որ այս սահմանումը կարող է զարգանալ։ Այնպես որ, գոնե առայժմ ինձ համար հետեւյալ նկարագրությունն ունեմ.

Software Architecture-ն ամեն օր կայացրած որոշումների և ընտրությունների մասին է, որոնք ազդում են կառուցված համակարգի վրա:

Որոշումներ կայացնելու համար, որոնք դուք պետք է ունենաք ձեր «պայուսակում» ծագող խնդիրների լուծման սկզբունքներն ու օրինաչափությունները, անհրաժեշտ է նաև նշել, որ պահանջների ըմբռնումը առանցքային է բիզնեսի կարիքները կառուցելու համար: Այնուամենայնիվ, երբեմն պահանջները թափանցիկ չեն կամ նույնիսկ սահմանված չեն, այս դեպքում ավելի լավ է սպասել ավելի շատ պարզաբանումներ ստանալու կամ ապավինել ձեր փորձին և վստահել ձեր ինտուիցիային: Բայց և այնպես, դուք չեք կարող ճիշտ որոշումներ կայացնել, եթե չունեք սկզբունքներ և օրինաչափություններ, որոնց վրա կարող եք ապավինել: Այստեղ ես գալիս եմ Ծրագրային ճարտարապետության ոճի սահմանմանը:

Software Architecture Style-ը սկզբունքների և օրինաչափությունների մի շարք է, որոնք սահմանում են, թե ինչպես ստեղծել ծրագրակազմ:

Կան բազմաթիվ տարբեր ճարտարապետական ոճեր, որոնք կենտրոնացած են պլանավորված ճարտարապետության տարբեր կողմերի վրա, և դրանցից մի քանիսը միանգամից կիրառելը նորմալ իրավիճակ է:

Օրինակ, ինչպիսիք են.

1. Միաձույլ ճարտարապետություն

2. Դոմենի վրա հիմնված դիզայն

3. Բաղադրիչի վրա հիմնված

4. Միկրոծառայություններ

5. Խողովակներ և ֆիլտրեր

6. Իրադարձությունների վրա հիմնված

7. Միկրոմիջուկ

8. Ծառայություններին ուղղված

   
   

և այլն…

Իհարկե, նրանք ունեն իրենց առավելություններն ու թերությունները, բայց ամենակարևորը, որ ես սովորել եմ, այն է, որ ճարտարապետությունը զարգանում է աստիճանաբար՝ կախված իրական խնդիրներից: Միաձույլ ճարտարապետությունից սկսելը հիանալի ընտրություն է գործառնական բարդությունները նվազեցնելու համար, շատ հավանական է, որ այս ճարտարապետությունը կհամապատասխանի ձեր կարիքներին նույնիսկ արտադրանքի կառուցման Product-market Fit (PMI) փուլին հասնելուց հետո: Մասշտաբով, դուք կարող եք դիտարկել շարժվել դեպի իրադարձությունների վրա հիմնված մոտեցում և միկրոծառայություններ՝ անկախ տեղակայման, տարասեռ տեխնոլոգիական փաթեթային միջավայրի և ավելի քիչ զուգակցված ճարտարապետության հասնելու համար (և միևնույն ժամանակ ավելի քիչ թափանցիկ՝ իրադարձությունների վրա հիմնված և pub-sub մոտեցումների բնույթի պատճառով, եթե դրանք ընդունված են): Պարզությունն ու արդյունավետությունը մոտ են և մեծ ազդեցություն ունեն միմյանց վրա։ Սովորաբար, բարդ ճարտարապետությունները ազդում են նոր առանձնահատկությունների զարգացման արագության վրա՝ աջակցելով և պահպանելով գոյություն ունեցողները և մարտահրավեր նետելով համակարգի բնական էվոլյուցիայի վրա:

Այնուամենայնիվ, բարդ համակարգերը հաճախ պահանջում են բարդ և համապարփակ ճարտարապետություն, ինչն անխուսափելի է:

Ճիշտ է, սա շատ լայն թեմա է, և կան բազմաթիվ հիանալի գաղափարներ այն մասին, թե ինչպես կառուցել և կառուցել համակարգեր բնական էվոլյուցիայի համար: Իմ փորձի հիման վրա ես մշակել եմ հետևյալ մոտեցումը.

1. Գրեթե միշտ սկսվում է մոնոլիտ ճարտարապետության ոճով, քանի որ այն վերացնում է բաշխված համակարգերի բնույթի պատճառով առաջացող խնդիրների մեծ մասը: Նաև իմաստ ունի հետևել մոդուլային մոնոլիտին՝ կենտրոնանալով հստակ սահմաններով շինարարական բաղադրիչների վրա: Բաղադրիչների վրա հիմնված մոտեցման կիրառումը կարող է օգնել նրանց շփվել միմյանց հետ՝ օգտագործելով իրադարձություններ, սակայն ուղղակի զանգեր ունենալը (aka RPC) սկզբում հեշտացնում է ամեն ինչ: Այնուամենայնիվ, կարևոր է հետևել բաղադրիչների միջև կախվածությանը, քանի որ եթե բաղադրիչը A-ն շատ բան գիտի բաղադրիչ B-ի մասին, գուցե իմաստ ունի դրանք միավորել մեկի մեջ:
2. Երբ դուք մոտենում եք այն իրավիճակին, երբ դուք պետք է մեծացնեք ձեր զարգացումը և համակարգը, կարող եք դիտարկել Stangler-ի օրինաչափությունը՝ աստիճանաբար դուրս հանելու բաղադրիչները, որոնք պետք է տեղակայվեն ինքնուրույն կամ նույնիսկ մասշտաբավորվեն հատուկ պահանջներով:
3. Այժմ, եթե դուք ունեք ապագայի հստակ տեսլական, որը մի փոքր անհավատալի հաջողություն է, կարող եք որոշել ցանկալի ճարտարապետությունը: Այս պահին դուք կարող եք որոշել շարժվել դեպի միկրոսերվիսների ճարտարապետություն՝ կիրառելով նաև Նվագախմբի և Խորեոգրաֆիայի մոտեցումները, ներառելով CQRS օրինաչափություն անկախ մասշտաբով գրելու և կարդալու գործողությունների համար, կամ նույնիսկ որոշելով հավատարիմ մնալ մոնոլիտ ճարտարապետությանը, եթե այն համապատասխանում է ձեր կարիքներին:

Կարևոր է նաև հասկանալ թվերն ու չափորոշիչները, ինչպիսիք են DAU (օրական ակտիվ օգտվողներ), MAU (ամսական ակտիվ օգտվողներ), RPC (խնդրանք մեկ վայրկյանում) և TPC (գործարք մեկ վայրկյանում), քանի որ դա կարող է օգնել ձեզ ընտրություն կատարել, քանի որ ճարտարապետությունը 100 ակտիվ օգտվողները և 100 միլիոն ակտիվ օգտվողները տարբեր են:

Որպես վերջնական նշում, ես կասեմ, որ ճարտարապետությունը էական ազդեցություն ունի արտադրանքի հաջողության վրա: Սանդղակավորման ժամանակ պահանջվում է արտադրանքի համար վատ մշակված ճարտարապետություն, ինչը, ամենայն հավանականությամբ, հանգեցնում է ձախողման, քանի որ հաճախորդները չեն սպասի, մինչև դուք մասշտաբեք համակարգը, նրանք կընտրեն մրցակից, ուստի մենք պետք է առաջ լինենք պոտենցիալ մասշտաբից: Թեև ես ընդունում եմ, որ երբեմն դա չի կարող նիհար մոտեցում լինել, գաղափարը մասշտաբային, բայց ոչ արդեն մասշտաբային համակարգ ունենալն է: Մյուս կողմից, շատ բարդ և արդեն մասշտաբային համակարգ ունենալը, առանց հաճախորդների կամ նրանցից շատերին ձեռք բերելու պլանների, ձեզ համար գումար կարժենա ձեր բիզնեսի վրա:

Տեխնոլոգիաների կույտի ընտրություն

Տեխնոլոգիաների կույտի ընտրությունը նաև մակրո մակարդակի որոշում է, քանի որ այն ազդում է աշխատանքի ընդունման, համակարգի բնական էվոլյուցիայի հեռանկարների, մասշտաբայնության և համակարգի կատարողականի վրա:

Ահա հիմնական նկատառումների ցանկը տեխնոլոգիական կույտ ընտրելու համար.

• Ծրագրի պահանջները և բարդությունը: Օրինակ, պարզ վեբ հավելվածը կարող է ստեղծվել Blazor շրջանակով, եթե ձեր մշակողները դրա հետ կապված փորձ ունեն, սակայն WebAssembly-ի հասունության բացակայության պատճառով React-ի և Typescript-ի ընտրությունը երկարաժամկետ հաջողության համար կարող է ավելի լավ որոշում լինել:
• Ընդարձակություն և կատարողականի կարիքներ: Եթե դուք ակնկալում եք ստանալ մեծ քանակությամբ տրաֆիկ, ապա Django-ի փոխարեն ASP.NET Core-ն ընտրելը կարող է խելամիտ ընտրություն լինել՝ շնորհիվ միաժամանակյա հարցումների հետ աշխատելու նրա գերազանց կատարողականության: Այնուամենայնիվ, այս որոշումը կախված է ձեր ակնկալվող երթևեկության մասշտաբից: Եթե Ձեզ անհրաժեշտ է կառավարել պոտենցիալ միլիարդավոր հարցումներ ցածր ուշացումով, Աղբի հավաքման առկայությունը կարող է մարտահրավեր լինել:
• Աշխատանքի ընդունման, զարգացման ժամանակը և ծախսերը: Շատ դեպքերում սրանք այն գործոններն են, որոնք մենք պետք է հոգ տանենք: Շուկա գնալու ժամանակը, սպասարկման ծախսերը և աշխատանքի ընդունման կայունությունը խթանում են ձեր բիզնեսի կարիքները առանց խոչընդոտների:
• Թիմի փորձաքննություն և ռեսուրսներ: Ձեր զարգացման թիմի հմտությունների փաթեթը կարևոր գործոն է: Ընդհանրապես ավելի արդյունավետ է օգտագործել տեխնոլոգիաներ, որոնց ձեր թիմն արդեն ծանոթ է, եթե չկա որևէ լուրջ պատճառ՝ ներդրումներ կատարելու նոր փաթեթ սովորելու համար:
• Հասունություն. Ուժեղ համայնքը և գրադարանների ու գործիքների հարուստ էկոհամակարգը կարող են մեծապես հեշտացնել զարգացման գործընթացը: Հանրաճանաչ տեխնոլոգիաները հաճախ ավելի լավ համայնքային աջակցություն ունեն, ինչը կարող է անգնահատելի լինել խնդիրների լուծման և ռեսուրսներ գտնելու համար: Այսպիսով, դուք կարող եք խնայել ռեսուրսները և կենտրոնանալ հիմնականում արտադրանքի վրա:
• Երկարաժամկետ սպասարկում և աջակցություն: Հաշվի առեք տեխնոլոգիայի երկարաժամկետ կենսունակությունը: Լայնորեն ընդունված և աջակցվող տեխնոլոգիաները ավելի քիչ հավանական է, որ հնանան և, ընդհանուր առմամբ, պարբերաբար թարմացումներ և բարելավումներ ստանան:

Ինչպե՞ս կարող է բազմաթիվ տեխնոլոգիական կույտեր ունենալը ազդել բիզնեսի աճի վրա:

Մի տեսանկյունից, ևս մեկ կույտ ներկայացնելը կարող է մեծացնել ձեր աշխատանքի ընդունումը, բայց մյուս կողմից, դա բերում է լրացուցիչ պահպանման ծախսեր, քանի որ դուք պետք է աջակցեք երկու կույտերին: Այսպիսով, ինչպես ես նախկինում ասացի, իմ տեսանկյունից, միայն լրացուցիչ կարիքը պետք է լինի ավելի շատ տեխնոլոգիական կույտեր ներառելու փաստարկ:

Բայց ի՞նչ է վերաբերում կոնկրետ խնդրի համար լավագույն գործիքն ընտրելու սկզբունքին:

Երբեմն դուք այլ ելք չեք ունենում, քան նոր գործիքներ բերել կոնկրետ խնդրի լուծման համար՝ հիմնվելով վերոհիշյալ նույն նկատառումների վրա, նման դեպքերում իմաստ ունի ընտրել լավագույն լուծումը:

Համակարգերի ստեղծումն առանց որոշակի տեխնոլոգիայի բարձր զուգակցման կարող է մարտահրավեր լինել: Այնուամենայնիվ, օգտակար է ձգտել այնպիսի վիճակի, որտեղ համակարգը սերտորեն կապված չէ տեխնոլոգիայի հետ, և այն չի մեռնի, եթե վաղը որոշակի շրջանակ կամ գործիք դառնա խոցելի կամ նույնիսկ հնացած:

Մեկ այլ կարևոր նկատառում կապված է բաց կոդով և սեփականության ծրագրային ապահովման կախվածության հետ: Գույքային ծրագրաշարը ձեզ ավելի քիչ ճկունություն և հարմարեցման հնարավորություն է տալիս: Այնուամենայնիվ, ամենավտանգավոր գործոնը վաճառողի կողպումն է, որտեղ դուք կախված եք վաճառողի արտադրանքից, գներից, պայմաններից և ճանապարհային քարտեզից: Սա կարող է ռիսկային լինել, եթե վաճառողը փոխի ուղղությունը, բարձրացնի գները կամ դադարեցնի արտադրանքը: Բաց կոդով ծրագրակազմը նվազեցնում է այս ռիսկը, քանի որ մեկ կազմակերպություն չի վերահսկում այն: Բոլոր մակարդակներում ձախողման մեկ կետի վերացումը կարևոր է աճի համար հուսալի համակարգեր կառուցելու համար:

Ձախողման մեկ կետ (SPOF)

Խափանման մեկ կետը (SPOF) վերաբերում է համակարգի ցանկացած մասի, որը, եթե այն ձախողվի, կհանգեցնի ամբողջ համակարգի աշխատանքի դադարեցմանը: SPOF-ների վերացումը բոլոր մակարդակներում կարևոր է ցանկացած համակարգի համար, որը պահանջում է բարձր հասանելիություն: Ամեն ինչ, ներառյալ գիտելիքները, անձնակազմը, համակարգի բաղադրիչները, ամպային մատակարարները և ինտերնետ մալուխները, կարող են ձախողվել:

Կան մի քանի հիմնական տեխնիկա, որոնք մենք կարող ենք կիրառել ձախողման առանձին կետերը վերացնելու համար.

1. Ավելորդություն. Իրականացնել ավելորդություն կարևոր բաղադրիչների համար: Սա նշանակում է ունենալ պահեստային բաղադրիչներ, որոնք կարող են տիրանալ, եթե առաջնային բաղադրիչը ձախողվի: Ավելորդությունը կարող է կիրառվել համակարգի տարբեր շերտերում, ներառյալ ապարատային (սերվերներ, սկավառակներ), ցանցեր (հղումներ, անջատիչներ) և ծրագրային ապահովում (տվյալների բազաներ, հավելվածների սերվերներ): Եթե դուք ամեն ինչ հյուրընկալում եք մեկ Cloud Provider-ում և նույնիսկ պահուստավորում ունեք այնտեղ, մտածեք հերթական լրացուցիչ կրկնօրինակում ստեղծելու մասին՝ աղետի դեպքում ձեր կորցրած ծախսերը նվազեցնելու համար:
2. Տվյալների կենտրոններ. Տարածեք ձեր համակարգը բազմաթիվ ֆիզիկական վայրերում, ինչպիսիք են տվյալների կենտրոնները կամ ամպային շրջանները: Այս մոտեցումը պաշտպանում է ձեր համակարգը տեղանքի հատուկ խափանումներից, ինչպիսիք են հոսանքի անջատումները կամ բնական աղետները:
3. Failover. Կիրառեք ձախողման մոտեցում ձեր բոլոր բաղադրիչների համար (DNS, CDN, Load balancers, Kubernetes, API Gateways և Databases): Քանի որ հարցերը կարող են անսպասելիորեն առաջանալ, շատ կարևոր է ունենալ պահեստային պլան՝ անհրաժեշտության դեպքում ցանկացած բաղադրիչ իր կլոնով արագ փոխարինելու համար:
4. Բարձր մատչելիության ծառայություններ. Համոզվեք, որ ձեր ծառայությունները կառուցված են այնպես, որ ի սկզբանե լինեն հորիզոնական մասշտաբային և բարձր հասանելի՝ հավատարիմ մնալով հետևյալ սկզբունքներին.
   • Զբաղվեք ծառայությունների քաղաքացիությունից և խուսափեք օգտատերերի նիստերը հիշողության քեշերում պահելուց: Փոխարենը, օգտագործեք բաշխված քեշ համակարգ, ինչպիսին է Redis-ը:
   • Խուսափեք տրամաբանություն մշակելիս հաղորդագրությունների սպառման ժամանակագրական կարգի վրա հույս դնելուց:
   • Նվազագույնի հասցրեք ընդհատվող փոփոխությունները՝ կանխելու API-ի սպառողների խանգարումները: Հնարավորության դեպքում ընտրեք հետընթաց-համատեղելի փոփոխություններ: Նաև հաշվի առեք ծախսերը, քանի որ երբեմն բեկումնային փոփոխության իրականացումը կարող է ավելի ծախսարդյունավետ լինել:
   • Ներառեք միգրացիայի կատարումը տեղակայման խողովակաշարում:
   • Ստեղծեք ռազմավարություն՝ միաժամանակյա հարցումների մշակման համար:
   • Իրականացնել ծառայության հայտնաբերում, մոնիտորինգ և գրանցում` հուսալիությունը և դիտելիությունը բարձրացնելու համար:
   • Զարգացրե՛ք բիզնեսի տրամաբանությունը՝ անզոր լինելու համար՝ ընդունելով, որ ցանցի խափանումներն անխուսափելի են:
5. Կախվածության վերանայում. Պարբերաբար վերանայել և նվազագույնի հասցնել արտաքին կախվածությունները: Յուրաքանչյուր արտաքին կախվածություն կարող է ներմուծել պոտենցիալ SPOF-ներ, ուստի կարևոր է հասկանալ և մեղմել այդ ռիսկերը:
6. Գիտելիքի կանոնավոր փոխանակում: Երբեք մի մոռացեք ձեր կազմակերպության ներսում գիտելիքների տարածման կարևորության մասին: Մարդիկ կարող են անկանխատեսելի լինել, և մեկ անհատի վրա հույս դնելը ռիսկային է: Խրախուսեք թիմի անդամներին թվայնացնել իրենց գիտելիքները փաստաթղթերի միջոցով: Այնուամենայնիվ, զգույշ եղեք չափից ավելի փաստաթղթավորումից: Օգտագործեք տարբեր AI գործիքներ այս գործընթացը պարզեցնելու համար:

Եզրակացություն

Այս հոդվածում մենք լուսաբանեցինք մի քանի հիմնական մակրո ասպեկտներ և ինչպես կարող ենք հաղթահարել դրանց բարդությունը:

Շնորհակալություն կարդալու համար: Կհանդիպենք հաջորդ անգամ: