NGINX-ից ժամանակակից հավելվածներ մշակելու սկզբունքներ. Մաս 1

Բարև ընկերներ։ Դասընթացի մեկնարկին ընդառաջ «Հետին պլանի մշակող PHP-ում», ավանդաբար կիսվում ենք ձեզ հետ օգտակար նյութի թարգմանությամբ։

Ծրագրային ապահովումը լուծում է ավելի ու ավելի շատ առօրյա խնդիրներ՝ միաժամանակ դառնալով ավելի ու ավելի բարդ: Ինչպես մի անգամ ասել է Մարկ Անդրեսենը, այն սպառում է աշխարհը։

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

Սկզբունքները կարելի է ամփոփել հետևյալ կերպ. հավելվածը պետք է լինի փոքր, վեբ վրա հիմնված և ունենա մշակողակենտրոն ճարտարապետություն. Հիմնվելով այս երեք սկզբունքների վրա՝ դուք կարող եք ստեղծել ամուր, վերջնական հավելված, որը կարող է արագ և ապահով կերպով տրամադրվել վերջնական օգտագործողին և հեշտությամբ ընդլայնելի և ընդարձակելի:

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

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

Կիրառելով այս սկզբունքները, դուք կօգտվեք ծրագրային ապահովման մշակման վերջին միտումներից, ներառյալ DevOps հավելվածների մշակման և առաքման համար, կոնտեյներների օգտագործումը (օրինակ. դոկեր) և կոնտեյներային նվագախմբային շրջանակներ (օրինակ, Կուբերնետես), միկրոծառայությունների օգտագործումը (ներառյալ Microservice Architecture): NGINX- ը и ցանցային հաղորդակցության ճարտարապետություն միկրոսերվիսային հավելվածների համար:

Ի՞նչ է ժամանակակից հավելվածը:

Ժամանակակից հավելվածներ. Ժամանակակից կույտ. Ի՞նչ է նշանակում «ժամանակակից»:

Մշակողների մեծամասնությունը միայն հիմնական պատկերացում ունի, թե ինչից է բաղկացած ժամանակակից հավելվածը, ուստի անհրաժեշտ է հստակ սահմանել այս հայեցակարգը:

Ժամանակակից հավելվածն աջակցում է բազմաթիվ հաճախորդների՝ լինի դա React JavaScript գրադարանի օգտագործող ինտերֆեյս, Android-ի կամ iOS-ի բջջային հավելված, կամ API-ի միջոցով մյուսին միացող հավելված: Ժամանակակից հավելվածը ենթադրում է անորոշ թվով հաճախորդներ, որոնց համար այն տրամադրում է տվյալներ կամ ծառայություններ։

Ժամանակակից հավելվածը տրամադրում է API՝ պահանջվող տվյալներին և ծառայություններին մուտք գործելու համար: API-ն պետք է լինի անփոփոխ և հաստատուն, և ոչ թե գրված լինի հատուկ կոնկրետ հաճախորդի կոնկրետ հարցման համար: API-ն հասանելի է HTTP(S) միջոցով և ապահովում է մուտք դեպի GUI կամ CLI-ում հայտնաբերված բոլոր գործառույթները:

Տվյալները պետք է հասանելի լինեն ընդհանուր, փոխգործունակ ձևաչափով, ինչպիսին է JSON-ը: API-ն բացահայտում է օբյեկտները և ծառայությունները հստակ, կազմակերպված ձևով, օրինակ՝ RESTful API-ն կամ GraphQL-ն ապահովում են պատշաճ ինտերֆեյս:

Ժամանակակից հավելվածները կառուցված են ժամանակակից ստեկի վրա, իսկ ժամանակակից ստեկը համապատասխանաբար նման հավելվածներն աջակցող ստեկն է: Այս կույտը ծրագրավորողին թույլ է տալիս հեշտությամբ ստեղծել հավելված HTTP ինտերֆեյսով և մաքրել API-ի վերջնակետերը: Ձեր ընտրած մոտեցումը թույլ կտա ձեր հավելվածին հեշտությամբ ընդունել և ուղարկել տվյալները JSON ձևաչափով: Այլ կերպ ասած, ժամանակակից ստեկը համապատասխանում է Տասներկու գործոնային հավելվածի տարրերին միկրոծառայություններ.

Այս տեսակի կույտերի հանրաճանաչ տարբերակները հիմնված են Java, Python, Հանգույց, սուտակ, PHP и Go. Microservice ճարտարապետություն NGINX- ը ներկայացնում է ժամանակակից դարակի օրինակ, որն իրականացվել է նշված լեզուներից յուրաքանչյուրում:

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

Սկզբունքները

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

Սկզբունքներից մեկը «փոքր հավելվածների կառուցումն է», եկեք պարզապես այն անվանենք փոքրության սկզբունքը. Կան անհավանական բարդ հավելվածներ, որոնք ունեն շատ շարժվող մասեր: Իր հերթին, փոքր, դիսկրետ բաղադրիչներից հավելված կառուցելը հեշտացնում է այն նախագծել, պահպանել և օգտագործել ընդհանուր առմամբ: (Նկատի ունեցեք, որ մենք ասել ենք «դա պարզեցնում է» և ոչ թե «պարզեցնում է»):

Երկրորդ սկզբունքն այն է, որ մենք կարող ենք բարձրացնել ծրագրավորողների արտադրողականությունը՝ օգնելով նրանց կենտրոնանալ իրենց կողմից մշակվող հատկանիշների վրա՝ միաժամանակ ազատելով նրանց ենթակառուցվածքների և CI/CD-ի մասին անհանգստանալուց իրականացման ընթացքում: Այսպիսով, մի խոսքով, մեր մոտեցումը ծրագրավորող կողմնորոշված.

Վերջապես, ձեր հավելվածի մասին ամեն ինչ պետք է միացված լինի ցանցին: Վերջին 20 տարիների ընթացքում մենք մեծ առաջընթաց ենք գրանցել դեպի ցանցային ապագա, քանի որ ցանցերն ավելի արագ են դարձել, իսկ հավելվածները՝ ավելի բարդ: Ինչպես արդեն տեսանք, ժամանակակից հավելվածը պետք է օգտագործվի ցանցում բազմաթիվ տարբեր հաճախորդների կողմից: Ճարտարապետության մեջ ցանցային մտածողության կիրառումը զգալի առավելություններ ունի, որոնք լավ տեղավորվում են փոքրության սկզբունքը և մոտեցման հայեցակարգը, ծրագրավորող կողմնորոշված.

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

Եկեք նայենք այս երեք սկզբունքներին ավելի մանրամասն:

Փոքրության սկզբունքը

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

Դիմումները քայքայվում են հետևյալ պատճառներով.

• Մշակողների վրա ճանաչողական բեռի նվազեցում;
• Փորձարկման արագացում և պարզեցում;
• Դիմումի փոփոխությունների արագ առաքում:

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

Այսպիսով, ճանաչողական բեռը նվազեցնելու երեք եղանակ.

1. Կրճատեք այն ժամանակաշրջանը, որը նրանք պետք է հաշվի առնեն նոր հատկանիշ մշակելիս. որքան կարճ է ժամկետը, այնքան ցածր է ճանաչողական բեռը:
2. Նվազեցրեք կոդի քանակը, որը մշակվում է միաժամանակ՝ ավելի քիչ կոդ՝ ավելի քիչ բեռ:
3. Պարզեցրեք ձեր դիմումում աստիճանական փոփոխություններ կատարելու գործընթացը:

Զարգացման ժամկետների կրճատում

Վերադառնանք այն ժամանակներին, երբ մեթոդաբանությունը waterfall մշակման գործընթացի չափանիշն էր, և հավելվածի մշակման կամ թարմացման համար վեց ամսից մինչև երկու տարի ժամկետները սովորական պրակտիկա էին: Սովորաբար, ինժեներները նախ կարդում են համապատասխան փաստաթղթերը, ինչպիսիք են արտադրանքի պահանջները (PRD), համակարգի հղման փաստաթուղթը (SRD), ճարտարապետական ​​պլանը և սկսում են ինտեգրել այս ամենը միասին մեկ ճանաչողական մոդելի մեջ, ըստ որի նրանք գրել են կոդը: Քանի որ պահանջները և, հետևաբար, ճարտարապետությունը փոխվեցին, անհրաժեշտ էր զգալի ջանքեր գործադրել՝ ամբողջ թիմին տեղեկացված պահելու ճանաչողական մոդելի թարմացումների մասին: Վատագույն դեպքում այս մոտեցումը կարող է պարզապես կաթվածահար անել աշխատանքը:

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

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

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

Փոքր կոդերի բազաներ

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

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

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

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

Փոքր աստիճանական փոփոխություններ

Սկզբունքի վերջին տարրը մի քիչ փոփոխությունների կառավարումն է: Մշակողների համար հատկապես գայթակղիչ է նայել կոդերի բազան (նույնիսկ գուցե իրենց սեփական, ավելի հին ծածկագիրը) և ասել. «Սա հիմարություն է, մենք պետք է վերաշարադրենք այս ամբողջը»: Երբեմն դա ճիշտ որոշում է, իսկ երբեմն՝ ոչ: Այն գլոբալ մոդելի փոփոխությունների բեռը դնում է մշակողների թիմի վրա, որն իր հերթին հանգեցնում է զանգվածային ճանաչողական բեռի: Ավելի լավ է, որ ինժեներները կենտրոնանան այն փոփոխությունների վրա, որոնք կարող են կատարել սպրինտի ընթացքում, որպեսզի հետո կարողանան ժամանակին, թեև աստիճանաբար, գործարկել անհրաժեշտ ֆունկցիոնալությունը: Վերջնական արտադրանքը պետք է նմանի նախապես ծրագրվածին, բայց որոշ փոփոխություններով և փորձարկումներով՝ հաճախորդի կարիքներին համապատասխան:

Կոդի մեծ մասերը վերաշարադրելիս երբեմն անհնար է արագ փոփոխություն կատարել, քանի որ գործում են համակարգի այլ կախվածություններ: Փոփոխությունների հոսքը վերահսկելու համար կարող եք օգտագործել գործառույթների թաքցումը: Հիմնականում սա նշանակում է, որ ֆունկցիոնալությունը կա արտադրության մեջ, բայց այն հասանելի չէ շրջակա միջավայրի փոփոխական պարամետրերի (env-var) կամ այլ կազմաձևման մեխանիզմի միջոցով: Եթե ​​կոդը անցել է որակի վերահսկման բոլոր գործընթացները, այն կարող է հայտնվել թաքնված վիճակում: Այնուամենայնիվ, այս ռազմավարությունն աշխատում է միայն այն դեպքում, եթե հնարավորությունը ի վերջո միացված է: Հակառակ դեպքում, դա միայն կխեղաթյուրի կոդը և կավելացնի ճանաչողական բեռ, որի հետ մշակողը պետք է հաղթահարի արդյունավետ լինելու համար: Փոփոխությունների կառավարումը և աստիճանական փոփոխություններն ինքնին օգնում են մշակողների ճանաչողական բեռը հասանելի մակարդակի վրա պահել:

Ինժեներները պետք է հաղթահարեն բազմաթիվ դժվարություններ նույնիսկ լրացուցիչ գործառույթներ իրականացնելիս: Ղեկավարության համար խելամիտ կլինի նվազեցնել ավելորդ ծանրաբեռնվածությունը թիմի վրա, որպեսզի այն կարողանա կենտրոնանալ ֆունկցիոնալության հիմնական տարրերի վրա: Ձեր զարգացման թիմին օգնելու համար կարող եք անել երեք բան.

1. Օգտագործեք մեթոդաբանություն agile, սահմանափակելու ժամանակային շրջանակը, որի ընթացքում թիմը պետք է կենտրոնանա հիմնական հատկանիշների վրա:
2. Իրականացրեք ձեր դիմումը որպես մի քանի միկրոծառայություններ: Սա կսահմանափակի ներդրված գործառույթների քանակը և կամրապնդի այն սահմանները, որոնք պարունակում են ճանաչողական բեռ աշխատելիս:
3. Նախընտրեք աստիճանական փոփոխությունները մեծ, անվնաս փոփոխություններից, փոխեք կոդի փոքր կտորները: Փոփոխություններն իրականացնելու համար օգտագործեք թաքցման գործառույթը, նույնիսկ եթե դրանք տեսանելի չեն լինի դրանց ավելացումից անմիջապես հետո:

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

Առաջին մասի ավարտ.

Շուտով կհրապարակենք թարգմանության երկրորդ մասը, բայց այժմ սպասում ենք ձեր մեկնաբանություններին և հրավիրում ենք ձեզ բաց օր, որը տեղի կունենա այսօր ժամը 20.00-ին։

Source: www.habr.com