Serverless-ը սերվերների ֆիզիկական բացակայության մասին չէ: Սա կոնտեյներային մարդասպան կամ անցողիկ միտում չէ: Սա ամպի մեջ համակարգեր կառուցելու նոր մոտեցում է: Այսօրվա հոդվածում մենք կանդրադառնանք Serverless հավելվածների ճարտարապետությանը, տեսնենք, թե ինչ դեր ունեն առանց սերվերի ծառայություններ մատուցողը և բաց կոդով նախագծերը: Վերջում անդրադառնանք Serverless-ի օգտագործման խնդիրներին։
Ես ուզում եմ գրել հավելվածի սերվերային մաս (կամ նույնիսկ առցանց խանութ): Սա կարող է լինել զրույց, բովանդակության հրապարակման ծառայություն կամ բեռի հավասարակշռող սարք: Ամեն դեպքում, գլխացավերը շատ կլինեն՝ դուք պետք է պատրաստեք ենթակառուցվածքը, որոշեք հավելվածների կախվածությունը, մտածեք հոսթ օպերացիոն համակարգի մասին։ Այնուհետև ձեզ հարկավոր է թարմացնել փոքր բաղադրիչները, որոնք չեն ազդում մնացած մոնոլիտի աշխատանքի վրա: Դե, եկեք չմոռանանք ծանրաբեռնվածության տակ մասշտաբի մասին:
Իսկ եթե վերցնենք ժամանակավոր կոնտեյներներ, որոնցում արդեն նախապես տեղադրված են անհրաժեշտ կախվածությունները, իսկ բեռնարկղերն իրենք մեկուսացված են միմյանցից և ընդունող ՕՀ-ից: Մենք մոնոլիտը կբաժանենք միկրոսերվիսների, որոնցից յուրաքանչյուրը կարող է թարմացվել և մասշտաբավորվել՝ անկախ մյուսներից։ Կոդը տեղադրելով նման կոնտեյների մեջ, ես կարող եմ այն գործարկել ցանկացած ենթակառուցվածքի վրա։ Արդեն ավելի լավ:
Ի՞նչ անել, եթե չե՞ք ցանկանում կարգավորել կոնտեյներները: Ես չեմ ուզում մտածել հավելվածի մասշտաբի մասին: Ես չեմ ուզում վճարել անգործուն բեռնարկղերի համար, երբ ծառայության վրա բեռը նվազագույն է: Ես ուզում եմ կոդ գրել. Կենտրոնացեք բիզնեսի տրամաբանության վրա և ապրանքները շուկա բերեք լույսի արագությամբ:
Նման մտքերը ինձ հանգեցրին առանց սերվերի հաշվողական աշխատանքի: Serverless այս դեպքում նշանակում է ոչ թե սերվերների ֆիզիկական բացակայությունը, այլ ենթակառուցվածքի կառավարման գլխացավերի բացակայությունը։
Գաղափարն այն է, որ կիրառական տրամաբանությունը բաժանվում է անկախ գործառույթների: Նրանք ունեն միջոցառումների կառուցվածք։ Յուրաքանչյուր գործառույթ կատարում է մեկ «microtask»: Մշակողից պահանջվում է միայն բեռնել գործառույթները ամպային մատակարարի կողմից տրամադրված վահանակում և դրանք կապել իրադարձությունների աղբյուրների հետ: Կոդը կկատարվի ըստ պահանջի ավտոմատ պատրաստված կոնտեյներով, և ես կվճարեմ միայն կատարման ժամանակի համար։
Տեսնենք, թե ինչպիսին կլինի հավելվածի մշակման գործընթացը հիմա։
Մշակողի կողմից
Ավելի վաղ մենք սկսել էինք խոսել առցանց խանութի հավելվածի մասին։ Ավանդական մոտեցման դեպքում համակարգի հիմնական տրամաբանությունը կատարվում է մոնոլիտ կիրառմամբ։ Իսկ հավելվածով սերվերը անընդհատ աշխատում է, նույնիսկ եթե բեռ չկա։
Առանց սերվերի անցնելու համար մենք հավելվածը բաժանում ենք միկրոխնդիրների: Նրանցից յուրաքանչյուրի համար մենք գրում ենք մեր գործառույթը: Գործառույթները միմյանցից անկախ են և չեն պահում պետական տեղեկատվությունը (քաղաքացիություն չունեցող): Դրանք կարող են նույնիսկ գրված լինել տարբեր լեզուներով։ Եթե դրանցից մեկը «ընկնի», ապա ամբողջ հավելվածը չի կանգնի: Հավելվածի ճարտարապետությունը կունենա հետևյալ տեսքը.
Serverless-ում գործառույթների բաժանումը նման է միկրոծառայությունների հետ աշխատելուն: Բայց միկրոսերվիսը կարող է կատարել մի քանի առաջադրանք, և ֆունկցիան իդեալականորեն պետք է կատարի մեկը: Եկեք պատկերացնենք, որ խնդիրը վիճակագրություն հավաքելն ու օգտագործողի ցանկությամբ ցուցադրելն է։ Միկրոծառայության մոտեցման դեպքում առաջադրանքը կատարում է մեկ ծառայություն՝ երկու մուտքի կետով՝ գրել և կարդալ: Առանց սերվերի հաշվարկման դեպքում դրանք կլինեն երկու տարբեր գործառույթներ, որոնք կապված չեն միմյանց հետ: Մշակողը խնայում է հաշվողական ռեսուրսները, եթե, օրինակ, վիճակագրությունը թարմացվում է ավելի հաճախ, քան ներբեռնվում է:
Առանց սերվերի գործառույթները պետք է կատարվեն կարճ ժամանակահատվածում (թայմուտ), որը որոշվում է ծառայության մատակարարի կողմից: Օրինակ, AWS-ի համար ժամկետը 15 րոպե է: Սա նշանակում է, որ երկարատև գործառույթները պետք է փոխվեն՝ համապատասխանելու պահանջներին. սա է այն, ինչը տարբերում է Serverless-ը մեր օրերում հայտնի տեխնոլոգիաներից (կոնտեյներներ և պլատֆորմ որպես ծառայություն):
Մենք յուրաքանչյուր ֆունկցիային հատկացնում ենք իրադարձություն: Իրադարձությունը գործողության խթան է.
Իրադարձություն
Գործողությունը, որը կատարում է գործառույթը
Ապրանքի պատկերը վերբեռնվել է պահեստ:
Սեղմեք պատկերը և վերբեռնեք գրացուցակ
Ֆիզիկական խանութի հասցեն թարմացվել է տվյալների բազայում
Բեռնել նոր տեղանք քարտեզներում
Հաճախորդը վճարում է ապրանքների համար
Սկսեք վճարումների մշակումը
Իրադարձությունները կարող են լինել HTTP հարցումներ, հոսքային տվյալներ, հաղորդագրությունների հերթեր և այլն: Իրադարձությունների աղբյուրները տվյալների փոփոխություններն են կամ երևույթները: Բացի այդ, գործառույթները կարող են գործարկվել ժմչփի միջոցով:
Ճարտարապետությունը մշակվեց, և հավելվածը գրեթե դարձավ առանց սերվերի: Հաջորդը մենք գնում ենք ծառայության մատակարարին:
Պրովայդերի կողմից
Սովորաբար, առանց սերվերի հաշվարկն առաջարկվում է ամպային ծառայություններ մատուցողների կողմից: Դրանք այլ կերպ են կոչվում՝ Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions։
Մենք կօգտագործենք ծառայությունը մատակարարի վահանակի կամ անձնական հաշվի միջոցով: Ֆունկցիոնալ կոդը կարելի է ներբեռնել հետևյալ եղանակներից մեկով.
- գրել կոդը ներկառուցված խմբագրիչներում վեբ վահանակի միջոցով,
- ներբեռնեք արխիվը ծածկագրով,
- աշխատել հանրային կամ մասնավոր git պահեստների հետ:
Այստեղ մենք կարգավորում ենք այն իրադարձությունները, որոնք կոչում են գործառույթը: Միջոցառումների հավաքածուները կարող են տարբեր լինել տարբեր մատակարարների համար:
Մատակարարն իր ենթակառուցվածքում կառուցել և ավտոմատացրել է «Function as a Service» (FaaS) համակարգը.
- Գործառույթի կոդը հայտնվում է մատակարարի կողմից պահեստում:
- Երբ իրադարձություն է տեղի ունենում, պատրաստված միջավայրով կոնտեյներները ավտոմատ կերպով տեղադրվում են սերվերի վրա: Յուրաքանչյուր ֆունկցիայի օրինակ ունի իր առանձնացված կոնտեյները:
- Պահոցից ֆունկցիան ուղարկվում է կոնտեյներ, հաշվարկվում և վերադարձնում է արդյունքը։
- Զուգահեռ իրադարձությունների թիվն աճում է. աճում է բեռնարկղերի թիվը: Համակարգը ավտոմատ կերպով մեծանում է: Եթե օգտատերերը մուտք չունենան գործառույթը, այն անգործուն կլինի:
- Մատակարարը սահմանում է բեռնարկղերի համար անգործության ժամանակը. եթե այս ընթացքում գործառույթները չեն հայտնվում կոնտեյների մեջ, այն ոչնչացվում է:
Այս կերպ մենք տուփից դուրս ենք բերում Serverless: Ծառայության համար մենք վճարելու ենք վճարովի մոդելի միջոցով և միայն այն գործառույթների համար, որոնք օգտագործվում են, և միայն այն ժամանակի համար, երբ դրանք օգտագործվել են:
Ծառայությանը ծրագրավորողներին ծանոթացնելու համար մատակարարներն առաջարկում են մինչև 12 ամիս անվճար փորձարկում, սակայն սահմանափակում են ընդհանուր հաշվարկի ժամանակը, ամսական հարցումների քանակը, միջոցները կամ էներգիայի սպառումը:
Պրովայդերի հետ աշխատելու հիմնական առավելությունը ենթակառուցվածքների (սերվերներ, վիրտուալ մեքենաներ, կոնտեյներներ) համար չանհանգստանալու հնարավորությունն է: Իր հերթին, մատակարարը կարող է իրականացնել FaaS ինչպես իր սեփական զարգացումները, այնպես էլ օգտագործելով բաց կոդով գործիքներ: Եկեք խոսենք դրանց մասին հետագա:
Բաց աղբյուրի կողմից
Բաց կոդով համայնքը վերջին մի քանի տարիների ընթացքում ակտիվորեն աշխատում է առանց սերվերի գործիքների վրա: Շուկայի խոշորագույն խաղացողները նույնպես նպաստում են առանց սերվերի հարթակների զարգացմանը.
- Google ծրագրավորողներին առաջարկում է իր բաց կոդով գործիքը. . Դրա մշակմանը մասնակցել են IBM, RedHat, Pivotal և SAP;
- IBM աշխատել է առանց սերվերի հարթակում , որն այնուհետև դարձավ Apache հիմնադրամի նախագիծը;
- Microsoft մասամբ բացեց հարթակի կոդը .
Զարգացումներ են ընթանում նաև առանց սերվերների շրջանակների ուղղությամբ։ и տեղակայված նախապես պատրաստված Kubernetes կլաստերների ներսում, աշխատում է ինչպես Kubernetes-ի, այնպես էլ Docker Swarm-ի հետ: Framework-ը գործում է որպես մի տեսակ վերահսկիչ. ըստ պահանջի, այն պատրաստում է գործարկման միջավայր կլաստերի ներսում, այնուհետև գործարկում է այնտեղ գործառույթը:
Շրջանակները տեղ են թողնում գործիքը ձեր կարիքներին համապատասխան կարգավորելու համար: Այսպիսով, Kubeless-ում ծրագրավորողը կարող է կարգավորել ֆունկցիայի կատարման ժամանակի վերջը (կանխադրված արժեքը 180 վայրկյան է): Fission-ը, փորձելով լուծել սառը մեկնարկի խնդիրը, առաջարկում է որոշ կոնտեյներներ անընդհատ աշխատել (չնայած դա ենթադրում է ռեսուրսների պարապուրդի ծախսեր): Եվ OpenFaaS-ն առաջարկում է գործարկիչների մի շարք յուրաքանչյուր ճաշակի և գույնի համար՝ HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs և այլն:
Սկսելու հրահանգները կարելի է գտնել շրջանակների պաշտոնական փաստաթղթերում: Նրանց հետ աշխատելը պահանջում է մի փոքր ավելի շատ հմտություններ ունենալ, քան մատակարարի հետ աշխատելիս. սա առնվազն Kubernetes կլաստեր գործարկելու ունակությունն է CLI-ի միջոցով: Առավելագույնը ներառեք բաց կոդով այլ գործիքներ (օրինակ՝ Kafka queue manager):
Անկախ նրանից, թե ինչպես ենք մենք աշխատում Serverless-ի հետ՝ պրովայդերի միջոցով կամ օգտագործելով բաց կոդով, մենք կստանանք Serverless մոտեցման մի շարք առավելություններ և թերություններ:
Առավելությունների և թերությունների տեսակետից
Serverless-ը զարգացնում է կոնտեյներային ենթակառուցվածքի և միկրոսերվիսային մոտեցման գաղափարները, որոնցում թիմերը կարող են աշխատել բազմալեզու ռեժիմով՝ առանց կապվելու մեկ հարթակին: Համակարգի կառուցումը պարզեցված է, և սխալներն ավելի հեշտ են ուղղվում: Microservice-ի ճարտարապետությունը թույլ է տալիս համակարգին նոր գործառույթներ ավելացնել շատ ավելի արագ, քան մոնոլիտ հավելվածի դեպքում:
Անսերվերն էլ ավելի է նվազեցնում զարգացման ժամանակը, թույլ տալով ծրագրավորողին կենտրոնանալ բացառապես հավելվածի բիզնես տրամաբանության և կոդավորման վրա: Արդյունքում կրճատվում է զարգացումների շուկայավարման ժամանակը:
Որպես բոնուս, մենք ստանում ենք ավտոմատ մասշտաբավորում բեռի համար, և մենք վճարում ենք միայն օգտագործված ռեսուրսների համար և միայն այն ժամանակ, երբ դրանք օգտագործվում են:
Ինչպես ցանկացած տեխնոլոգիա, Serverless-ն էլ ունի թերություններ.
Օրինակ, նման թերություն կարող է լինել սառը մեկնարկի ժամանակը (միջինում մինչև 1 վայրկյան այն լեզուների համար, ինչպիսիք են JavaScript, Python, Go, Java, Ruby):
Մի կողմից, իրականում սառը մեկնարկի ժամանակը կախված է բազմաթիվ փոփոխականներից՝ լեզուն, որով գրված է ֆունկցիան, գրադարանների քանակը, կոդերի քանակը, հավելյալ ռեսուրսների հետ շփումը (նույն տվյալների բազաները կամ վավերացման սերվերները): Քանի որ մշակողը վերահսկում է այս փոփոխականները, նա կարող է նվազեցնել գործարկման ժամանակը: Բայց մյուս կողմից, մշակողը չի կարող վերահսկել կոնտեյների գործարկման ժամանակը. ամեն ինչ կախված է մատակարարից:
Սառը մեկնարկը կարող է վերածվել տաք մեկնարկի, երբ ֆունկցիան նորից օգտագործում է նախորդ իրադարձության կողմից գործարկված կոնտեյները: Այս իրավիճակը կառաջանա երեք դեպքում.
- եթե հաճախորդները հաճախ օգտվում են ծառայությունից, և ֆունկցիային զանգերի թիվը մեծանում է.
- եթե մատակարարը, պլատֆորմը կամ շրջանակը թույլ են տալիս անընդհատ աշխատել որոշ կոնտեյներներ.
- եթե մշակողը գործարկում է գործառույթները ժամանակաչափով (ասենք 3 րոպեն մեկ):
Շատ ծրագրերի համար սառը մեկնարկը խնդիր չէ: Այստեղ դուք պետք է հիմնվեք ծառայության տեսակի և խնդիրների վրա: Մեկ վայրկյանի մեկնարկի ուշացումը միշտ չէ, որ կարևոր է բիզնես հավելվածի համար, սակայն այն կարող է կարևոր դառնալ բժշկական ծառայությունների համար: Այս դեպքում, առանց սերվերի մոտեցումը, հավանաբար, այլևս հարմար չի լինի:
Serverless-ի հաջորդ թերությունը ֆունկցիայի կարճ ժամկետն է (թայմուտ, որի ընթացքում ֆունկցիան պետք է կատարվի):
Բայց, եթե դուք պետք է աշխատեք երկարատև առաջադրանքների հետ, կարող եք օգտագործել հիբրիդային ճարտարապետություն՝ միավորել Serverless-ը մեկ այլ տեխնոլոգիայի հետ:
Ոչ բոլոր համակարգերը կկարողանան աշխատել առանց սերվերի սխեմայի:
Որոշ հավելվածներ դեռևս կպահեն տվյալները և դրվեն կատարման ընթացքում: Որոշ ճարտարապետություններ կմնան միաձույլ, իսկ որոշ առանձնահատկություններ՝ երկարակյաց: Այնուամենայնիվ (ինչպես ամպային տեխնոլոգիաները և հետո բեռնարկղերը), Serverless-ը մեծ ապագա ունեցող տեխնոլոգիա է:
Այս առումով, ես կցանկանայի սահուն անցնել «Serverless» մոտեցման օգտագործման հարցին:
Դիմումի կողմից
2018 թվականի համար՝ առանց սերվերի օգտագործման տոկոսը . Այն ընկերությունների թվում, որոնք արդեն ներդրել են տեխնոլոգիան իրենց ծառայություններում, կան շուկայի այնպիսի հսկաներ, ինչպիսիք են Twitter-ը, PayPal-ը, Netflix-ը, T-Mobile-ը, Coca-Cola-ն։ Միևնույն ժամանակ, դուք պետք է հասկանաք, որ Serverless-ը համադարման միջոց չէ, այլ որոշակի շարք խնդիրների լուծման գործիք.
- Կրճատել ռեսուրսների պարապուրդը: Կարիք չկա անընդհատ վիրտուալ մեքենա պահել այն ծառայությունների համար, որոնք քիչ զանգեր ունեն։
- Գործընթացի տվյալները թռչելիս: Սեղմեք նկարները, կտրեք ֆոնը, փոխեք վիդեո կոդավորումը, աշխատեք IoT սենսորների հետ, կատարեք մաթեմատիկական գործողություններ:
- «Սոսնձեք» մյուս ծառայությունները միասին: Git պահոց ներքին ծրագրերով, չաթ բոտ Slack-ում Jira-ով և օրացույցով:
- Հավասարակշռել բեռը. Եկեք մանրամասն նայենք այստեղ:
Ասենք կա մի ծառայություն, որը գրավում է 50 հոգու։ Դրա տակ կա վիրտուալ մեքենա՝ թույլ ապարատով։ Ժամանակ առ ժամանակ ծառայության վրա ծանրաբեռնվածությունը զգալիորեն մեծանում է։ Այդ դեպքում թույլ սարքավորումները չեն կարող հաղթահարել:
Դուք կարող եք համակարգում ներառել հավասարակշռող, որը կբաշխի բեռը, ասենք, երեք վիրտուալ մեքենաների վրա: Այս փուլում մենք չենք կարող ճշգրիտ կանխատեսել բեռը, ուստի մենք որոշակի քանակությամբ ռեսուրսներ ենք պահում «պահուստում»: Եվ մենք գերվճարում ենք պարապուրդի համար:
Նման իրավիճակում մենք կարող ենք օպտիմիզացնել համակարգը հիբրիդային մոտեցման միջոցով. մենք թողնում ենք մեկ վիրտուալ մեքենա ծանրաբեռնվածության հավասարակշռողի հետևում և հղում ենք անում առանց սերվերի վերջնակետին՝ ֆունկցիաներով: Եթե բեռը գերազանցում է շեմը, հավասարակշռողը գործարկում է գործառույթների օրինակներ, որոնք ստանձնում են հարցումների մշակման մի մասը:
Այսպիսով, Serverless-ը կարող է օգտագործվել այնտեղ, որտեղ անհրաժեշտ է ոչ այնքան հաճախ, այլ ինտենսիվ մշակել մեծ թվով հարցումներ։ Այս դեպքում 15 րոպեով մի քանի գործառույթ գործարկելն ավելի շահավետ է, քան վիրտուալ մեքենայի կամ սերվերի անընդհատ պահպանումը։
Առանց սերվերի հաշվարկման բոլոր առավելություններով, նախքան ներդրումը, նախ պետք է գնահատեք հավելվածի տրամաբանությունը և հասկանաք, թե կոնկրետ դեպքում ինչ խնդիրներ կարող է լուծել Serverless-ը:
Անսերվեր և Ընտրել
Selectel-ում մենք արդեն մեր կառավարման վահանակի միջոցով: Այժմ մենք կառուցում ենք մեր սեփական FaaS հարթակը: Մենք ցանկանում ենք, որ ծրագրավորողները կարողանան լուծել իրենց խնդիրները՝ օգտագործելով Serverless՝ հարմար, ճկուն ինտերֆեյսի միջոցով:
Եթե ունեք գաղափարներ այն մասին, թե ինչպիսին պետք է լինի իդեալական FaaS հարթակը և ինչպես եք ցանկանում օգտագործել Serverless-ը ձեր նախագծերում, կիսվեք դրանք մեկնաբանություններում: Մենք հաշվի կառնենք ձեր ցանկությունները հարթակը մշակելիս։
Հոդվածում օգտագործված նյութեր.
Source: www.habr.com