Բառը[Թաքցնել][Ցուցադրում]
- Ի՞նչ են միկրոծառայությունները:
- Ի՞նչ է առանց սերվերի մոդելը:
Ե՞րբ պետք է օգտագործեք միկրոծառայություններ ընդդեմ առանց սերվերի ճարտարապետության+-
- Microservices-ը լավագույն տարբերակն է, եթե գաղտնիությունը ձեր գլխավոր առաջնահերթությունն է
- Օգտագործեք միկրոծառայություններ, եթե ցանկանում եք, որ ձեր ժառանգությունը մնայ:
- Եթե դուք սկսնակ եք, ապա առանց սերվերի ընտրությունը գնալու ճանապարհ է:
- Եթե դուք սկսում եք զրոյից, պետք է օգտագործվեն առանց սերվերի և միկրոծառայությունների
- Եզրափակում
Նախկինում ճարտարապետական նախագծերը հաճախ մոնոլիտ էին և չունեին կառավարում, մասշտաբայնություն և ճարպկություն: Այս իրավիճակում ձեռնարկությունները պետք է տեղակայեն ամբողջական ծրագիրը միայնակ կիրառական սերվերում, որը գործում է միայնակ համակարգչի վրա:
Երբեմն ամբողջ տվյալների բազան կարող է նույնիսկ տեղադրվել նույն համակարգում: Նույնիսկ այս ամենը կատարելուց հետո խնդիրը պարզապես կհանգեցնի ծրագրի փակման՝ ընդհատելով բոլոր գործողությունները:
Արդյունքը եղավ կոդավորման, տեղակայման և անսարքությունների վերացման անվերջանալի ցիկլը, որը նվազեցրեց ձեռնարկությունների արտադրողականությունը:
Բայց երբ ճարտարապետական գաղափարները փոխվեցին, արդյունաբերությունը տեսավ դրամատիկ ցնցում, որը սկիզբ դրեց երկու հիմնական ճարտարապետություններին, որոնք հայտնի են որպես առանց սերվերների և միկրոծառայությունների: Երկուսն էլ ունեն ամուր պատյան, որն օգտագործվում է մասշտաբային և արագաշարժ համակարգերում:
Երկուսն էլ առաջնահերթություն են տալիս անվտանգությանը, բայց տարբեր մոտեցումներ են ցուցաբերում: Բիզնեսի սեփականատերերը պարբերաբար հարցնում են, թե արդյոք դրանք նույնն են, թե ոչ:
Ո՞ր մեկը պետք է ընտրել, եթե դրանք տարբեր են՝ ավելի զարմանալի օգուտներ ստանալու համար: Այս հոդվածը կօգնի մեզ պարզել.
Ի՞նչ են միկրոծառայությունները:
Ճարտարապետական դիզայնի օրինաչափությունը, որը հայտնի է որպես միկրոծառայություններ, ավելի մեծ հավելվածը բաժանում է մի շարք փոքրերի, հետևաբար անվանումը: Մոնոլիտ դիզայնը, որում ամբողջ ֆունկցիոնալությունը պարունակվում է մեկ միավորի մեջ, լիովին հակադրվում է դրան:
Եկեք օգտագործենք առցանց գնումների հավելվածի օրինակ՝ օգնելու մեր ըմբռնմանը: Իրենց ուզած ապրանք(ներ)ը գտնելուց հետո սպառողը դրանք ավելացնում է իր զամբյուղում և պատվիրում:
Application Programming Interfaces (API) միացնում են մի քանի ծառայություններ, որոնք գործում են միմյանցից անկախ (API): Միկրոծառայությունները տրամադրում են այնպիսի գործառույթներ, ինչպիսիք են գնումների զամբյուղը, վճարման գործընթացը և ապրանքը:
Միկրոծառայությունների իրականացումը կարող է իրականացվել տարբեր մեթոդներով: Յուրաքանչյուր միկրոսերվիս ունի այն հիմնական բաղադրիչները, որոնք անհրաժեշտ են ինքնուրույն գործելու համար, ներառյալ սեփական տվյալների բազան, գրադարանները և ձևանմուշները:
Այն, ըստ էության, հավատարիմ է SOA (Service Oriented Architecture) սկզբունքներին, որոնք օգտվողին հնարավորություն են տալիս ստեղծել նոր հավելվածներ և ինքնուրույն կատարել տարբեր հավելվածներ:
DevOps-ը հավելվածի բոլոր հնարավորությունները բաժանում է ավելի փոքր հավելվածների կամ ծառայությունների, որոնք կարող են ինքնուրույն գործել՝ միևնույն ժամանակ որպես ամբողջական հավելված: Նախքան տեղակայվելը, այս միկրոսերվիսային հավելվածներից յուրաքանչյուրը ստեղծվում և ֆունկցիոնալ փորձարկվում է:
Ի՞նչ է առանց սերվերի մոդելը:
Առանց սերվերի պարադիգմում արտաքին ամպային ծառայությունների մատակարարը պատասխանատու է սերվերի կառավարման համար: Մշակողները պարզապես պետք է անհանգստանան կոդի համար. ծառայության մատակարարը հոգ կտանի անվտանգության թարմացումների մասին, բեռի հավասարակշռումը, կարողությունների կառավարում, մասշտաբայնություն, անտառահատումներ և մոնիտորինգ:
Ամբողջ հավելվածը կարող է գործարկվել առանց սերվերի ճարտարապետության կամ դրա միայն ենթաբազմության: Հենց որ հավելվածի կոդը գործարկվի, սերվերը ռեսուրսներ է հատկացնում դրան և թողարկում դրանք, երբ հավելվածն այլևս չի օգտագործվում, հետևաբար այն պահանջվում է միայն այն ժամանակ, երբ հավելվածն ակտիվորեն օգտագործվում է:
Հավելվածի սեփականատիրոջից գանձվում է միայն հավելվածի օգտագործման ընթացքում: Ամպային ծառայություններ մատուցող ընկերությունները տրամադրում են Backend-as-a-Service (BaaS) և Function-as-a-Service (FaaS):
BaaS-ն առաջարկում է նախապես կառուցված գործառույթներ, այնպես որ մշակողը պետք է կենտրոնանա ճակատային մասի վրա: Այն հազվադեպ է օգտագործվում, քանի որ այն առաջարկում է սահմանափակ հարմարեցում և վերահսկում:
FaaS-ը, այնուամենայնիվ, ավելի ճկուն է, քանի որ ծրագրավորողները կարող են ստեղծել ինչպես առջևի, այնպես էլ հետևի ծայրերը, մինչդեռ դեռևս կատարում են հավելվածը հեռավոր սերվերի վրա: FaaS-ի միջոցով հավելվածը կարող է ստեղծվել որպես գործառույթների հավաքածու:
Յուրաքանչյուր գործառույթ ունի նպատակ և նախաձեռնող գործոն: Ֆունկցիան չի կարող անընդհատ գործել. այն սովորաբար ժամանակավոր է և դադարեցվում է հենց որ այլևս դրա կարիքը չկա:
Առանց սերվերի ընդդեմ միկրոծառայությունների
Ապակենտրոնացված ծրագիրը, որը բաժանվել է մի քանի փոքր բաղադրիչների, որոնք նաև հայտնի են որպես ծառայություններ, կոչվում է միկրոծառայության ճարտարապետություն: Նրանք բոլորը պատասխանատու են մեկ կոնկրետ առաջադրանքի կատարյալ իրականացման համար ապահովելու համար:
Միկրոծառայությունները շատ մասնագիտացված են և կարող են միայն մեկ բան անել անթերի: Յուրաքանչյուր ճարտարապետություն ունի խնդիրների լուծման տարբեր ռազմավարություն: Երկարաժամկետ շտկումները հասանելի են միկրոսերվիսներով:
Յուրաքանչյուր ծառայություն կարող է գործել անընդհատ և 24/7: Դա հիանալի երկարաժամկետ պատասխան է այն թիմերի համար, որոնք մեծանում են:
Մյուս կողմից, առանց սերվերի հավելվածների գործառույթները կենտրոնացած են կոդի արդյունավետության բարելավման վրա: Գործառույթները այնքան երկար չեն տևում, որքան միկրոսերվիսները: Նրանք սկսում են գործել միայն ի պատասխան որոշակի ներդրման կամ իրավիճակի:
Քանի որ առանց սերվերի ճարտարապետությունը հիմնված է իրադարձությունների վրա, գործառույթը չի գործարկվի, եթե չկա գործարկիչ: Ծրագիրը չի օգտագործում ավելի շատ պրոցեսոր, քան անհրաժեշտ է, և թիմերը կարող են գումար խնայել հաշվողական և պահեստային տարածքի վրա՝ շնորհիվ զարգացման արդյունավետ մեթոդաբանության:
Բացի այս հիմնական տատանումներից, երկու ձևավորումները տարբերվում են նաև այլ ձևերով:
Եկեք կենտրոնանանք մի քանի հիմնական նկատառումների վրա՝ որոշելով օգտագործել միկրոսերվիսներ, թե առանց սերվերի հաշվարկներ:
Ֆունկցիաներ
Գործառույթները անցողիկ են և կատարվում են միայն այն դեպքում, երբ որոշակի իրավիճակ է պահանջում: Նրանք ավելի կոմպակտ են և ավելի բարակ:
Միկրոսերվիսը կարող է կառավարել միանգամից մի քանի կապակցված գործողություններ, մինչդեռ գործառույթը բացառապես պատասխանատու է մեկ գործունեության համար:
Մեկ միկրոսերվիսը կարող է կատարել մի քանի գործառույթ:
Runtime
Գործառույթները, որոնք առանց սերվերի են, ունեն կարճ գործարկման ժամանակ: Որքանով կարող է գործել որոշակի գործառույթը, կախված է մատակարարից:
Օրինակ, գործառույթը կարող է աշխատել AWS Lambda-ում 15 րոպե: Դա պայմանավորված է այն հանգամանքով, որ գործառույթներն իրենց բնույթով կարճ ընթացակարգեր են, որոնք չպետք է շատ RAM սպառեն:
Գործարկման ժամանակի, պահեստավորման և RAM-ի վաճառողի բնութագրերը սահմանափակում չեն միկրոծառայությունների համար: Դրա պատճառով դրանք ավելի հարմար են բարդ, երկարաժամկետ գործունեության համար, որոնք պահանջում են տվյալների հսկայական ծավալի պահպանում և մշակում:
ՏՏ գործառնություններ
Միկրոծառայությունների համար անհրաժեշտ է թիմային ռեսուրսների ստեղծում։ Մոնիտորինգի, տեղակայման, աջակցության և պահպանման խնդիրներն իրականացվում են ներքին կամ արտաքին թիմի կողմից: Թիմը լիովին պատասխանատու է ճարտարապետությանն աջակցելու, դրա հաշվարկման և անվտանգության ապահովման համար:
Հակառակը, առանց սերվերի ճարտարապետությունը կախված է երրորդ կողմի մատակարարից: Բիզնեսը պարտավոր չէ ստեղծել, պաշտպանել և կառավարել իր սեփական սերվերի տարածքը: Բոլոր ներքին գործառույթները կառավարվում են ամպի մատակարարի կողմից:
Այս ռազմավարությունը կարող է նվազեցնել ծրագրի ծախսերը՝ միաժամանակ խուսափելով հավաքագրման և տեղակայման վճարներից, պահեստավորման վճարներից և սարքավորումների գնումներից:
Արժենալ
Միկրոծառայությունների ստեղծման սկզբնական արժեքը ավելի բարձր է։ Ծրագիրն ավարտելու համար մի քանի թիմ է պահանջվում, և տարբեր բաղադրիչների միջև հարաբերություններ հաստատելու համար ժամանակ և մանրակրկիտ նախապատրաստություն է պահանջվում:
Միկրոծառայությունների ստեղծումն ու սպասարկումն ավելի թանկ են՝ ներքին ռեսուրսների և օգնության վրա նրանց ապավինման հետևանքով:
Այնուամենայնիվ, այս ռազմավարությունն ունի առավելություններ: Բիզնեսը չի ապավինում արտաքին պլաններին և չի սպառնում վաճառողի արգելափակման վտանգին:
Ծախսերը կրճատելու ունակությունը առանց սերվերի ճարտարապետության առաջնային մրցակցային առավելությունն է: Բիզնեսները, որոնք օգտագործում են առանց սերվերի ճարտարապետություն, շահում են ռեսուրսների միավորումից:
Քանի որ նրանք կիսում են իրենց սերվերները մի քանի հաճախորդների միջև, երրորդ կողմի մատակարարները կարող են առաջարկել բաժանորդագրության ավելի ցածր գներ:
Բացի այդ, դուք խնայում եք HR ծախսերը, քանի որ ձեզ հարկավոր չէ հավաքագրել ապարատային և սերվերի փորձաքննություն:
Ե՞րբ պետք է օգտագործեք միկրոծառայություններ ընդդեմ առանց սերվերի ճարտարապետության
Microservices-ը լավագույն տարբերակն է, եթե գաղտնիությունը ձեր գլխավոր առաջնահերթությունն է
Առանց սերվերի ճարտարապետության ծառայությունները կարող են իդեալական ընտրություն չլինել, եթե դուք տեղեկատվություն փոխանակում եք: Հավելվածը կարող է լուրջ խնդիրներ ունենալ:
Կառավարվող կամ համօգտագործվող հոստինգի ձևը ամպային հոսթինգն է:
Այսպիսով, դուք կկարողանաք նկատել, որ դուք միակ մարդը չեք, որն օգտագործում է երրորդ կողմի վաճառողի ռեսուրսները: Քանի որ այս հանգամանքը ներառում է «բազմ վարձակալներ», ի տարբերություն «մեկ վարձակալների», ձեր տվյալները այս դեպքում լիովին պաշտպանված չեն:
Մեկ այլ վարձակալին պատկանող տեղեկատվությունը և տվյալները տեսանելի են և հասանելի են մեկ վարձակալին: Բացի այդ, քիչ հավանական է, որ դուք անընդհատ ռեսուրսներ սպառեք մեկ մատակարարից: Կարող է լինել մեծ թիվ։
Ամբողջ գործընթացը վերահսկելու և կազմաձևելու հնարավորությունը, հետևաբար, ավելի կբարդանա, քանի որ վաճառողը փոխվում է:
Օգտագործեք միկրոծառայություններ, եթե ցանկանում եք, որ ձեր ժառանգությունը մնայ:
Առանց սերվերի ճարտարապետության ծառայությունները չեն աշխատի, եթե հին համակարգի ենթակառուցվածքն առայժմ անհրաժեշտ լինի:
Արագությունը և արժեքը առանց սերվերի ճարտարապետության երկու ասպեկտներ են, որոնք լավ են գործում, բայց դրանք միակը չեն:
Չնայած սերվերազուրկը բավականին հատիկավոր է, այն անհամատեղելի է զգալի, գոյություն ունեցող կոդերի բազայի հետ՝ այս հստակության պատճառով:
Այլ կերպ ասած, դա չափազանց մեծ թռիչք է, երբ դուք ունեք ժառանգական համակարգ: Ուստի նախընտրելի է ընտրել Microservices ռազմավարություն:
Եթե դուք սկսնակ եք, ապա առանց սերվերի ընտրությունը գնալու ճանապարհ է:
Առանց սերվերի ճարտարապետության համար լավագույն ընտրությունն այն է, եթե դուք ստարտափի հիմնադիրն եք: Առանց սերվերի ճարտարապետությունը ձեզ կտրամադրի ամենաարագ և ամենաարագ արագությունները՝ անկախ ձեր նպատակից՝ արձագանքել ժամանակով սահմանափակ շուկային կամ անմիջապես գրավել շուկայի մասնաբաժինը ցանկացած միտումի սկզբում:
Բացի այդ, այն մատչելի տարբերակ կլինի ձեռնարկատերերի համար։ Սերվերը, որը չի օգտագործվում, ձեզ ոչինչ չի կարժենա: Հուսալի օգտագործման վիճակագրության բացակայության պատճառով ձեզ հաճախ անհրաժեշտ են հավելվածներ, որոնք չափազանց հարմարվող են:
Եթե դուք սկսում եք զրոյից, պետք է օգտագործվեն առանց սերվերի և միկրոծառայությունների
Նոր սկիզբը ձեզ հնարավորություն է տալիս ավելի արագ ստանալ առանց սերվերի ճարտարապետության մատակարարների առավելությունները, բայց ոչ անմիջապես: Օգտագործեք Microservices-ը բոլորովին նոր ճարտարապետություն նախագծելիս, բայց սպասեք, որ ավելի ուշ կանցնեք առանց սերվերի:
Առանց սերվերի ընդդեմ միկրոսերվիսների ճարտարապետություն. կողմ և դեմ
Ցավոք, ոչ մի տեխնոլոգիա կատարյալ չէ. եթե դա լիներ, աշխարհն արդեն գոհ, բարձր զարգացած վայր կլիներ:
Յուրաքանչյուր տեխնոլոգիա ներառում է առավելություններ, որոնք կարող եք օգտագործել ձեր նախագծի համար, ինչպես նաև թերություններ, որոնց հետ պետք է պատրաստ լինեք ապրել: Հիմա երկուսն էլ քննենք։
Microservices-ի առավելությունները
- Ավելի պարզ մասշտաբավորում. քանի որ ծառայություններն առանձին են, հնարավոր է ավելացնել կամ ջնջել գործառույթներ և մասշտաբավորել իրերը՝ նվազագույն աշխատանքով: Ի տարբերություն մոնոլիտ ծրագրերի, դուք պետք չէ հաշվի առնել ծածկագրի ամբողջական բազան:
- Ծրագրային ապահովման ավելի լավ ճկունություն. Քանի որ միկրոծառայություններն ավելի քիչ կախված են միմյանցից, մեկի ձախողումը չի տապալում ամբողջ հավելվածը: Այն հատկապես օգտակար է, երբ երթևեկությունը ծանրաբեռնված է:
- Տարբեր հարթակներ. Դուք կարող եք կապել մի քանի հարթակներում տեղակայված միկրոսերվիսները, ի լրումն լեզուների: Հավելվածի մի մասը կարող է նաև տեղակայվել նորմալ և առանց սերվերի:
- Թիմի ինքնավարություն. Մի քանի փոքր թիմեր կարող են միաժամանակ համագործակցել և աշխատել նախագծի վրա
- Բազմալեզու. API-ն թույլ է տալիս կապել մի քանի լեզուներով գրված միկրոծառայություններ: Դա օգտակար առավելություն է, քանի որ տարբեր տեխնոլոգիաներ ավելի արդյունավետ կերպով բավարարում են գործառույթի տարբեր պահանջները: Այնուամենայնիվ, չափազանց շատ լեզուների օգտագործումը կարող է հանգեցնել ամեն ինչ կապելու դժվարությունների, ուստի նախընտրելի է ամեն ինչ պարզ պահել:
- Տարածություն փորձերի համար. չնայած մեր հարուստ տվյալներին, մեր ենթադրությունները երբեմն սխալ են, և միկրոծառայությունները թույլ են տալիս ստուգել ամեն ինչ: Քանի որ միկրոսերվիսներով հավելվածները աներևակայելի հարմարվողական են, ինչպես մենք նախկինում քննարկել ենք, կարիք չկա հազարավոր դոլարներ ծախսել զուտ նոր գործառույթ ավելացնելու համար, որը կարող եք հետագայում վերացնել:
Միկրոծառայությունների թերությունները
- Անվտանգության խնդիրներ. Դուք պետք է ուշադիր հետևեք ձեր API-ներին, քանի որ դրանք հաճախ սխալ են ստեղծվում և հետևաբար ենթակա են:
- Կապի հետ կապված խնդիրներ. Դուք պետք է ուշադիր նախագծեք, թե ինչպես կապել բոլոր միկրոծառայությունները և տեղափոխել տվյալները մի վայրից մյուսը:
- Վրիպազերծումը դժվար է, քանի որ դուք պետք է ուսումնասիրեք յուրաքանչյուր միկրոծառայության տեղեկամատյանները:
- Դժվար թեստավորում. նախքան գլոբալ մասշտաբով կապը գնահատելը դուք պետք է փորձարկեք յուրաքանչյուր միկրոսերվիս առանձին:
Serverless-ի առավելությունները
- Անհեշտ մասշտաբավորում. սերվերն ավտոմատ կերպով կարգավորվում է վեր կամ վար:
- Շատ արագ տեղակայում. դուք կարող եք արագ ձևավորել նոր հնարավորություններ և փորձարկել ձեր գաղափարները:
- Սերվերի կառավարումը ձեր մտահոգությունը չէ. դուք կարող եք կենտրոնանալ ոչ թե սերվերի, այլ հավելվածի վրա:
- Pay-as-you-go. Դուք պարզապես վճարում եք ձեր օգտագործած սերվերի հզորության համար; կարիք չկա վճարել ոչ ակտիվ ժամանակի համար.
Անսերվերի թերությունները
- Դժվար թեստավորում. Թեև դուք չեք կարող ամբողջությամբ վերարտադրել առանց սերվերի միջավայրը, դժվար է հասկանալ, թե ինչպես կգործի կոդը այն տեղակայելուց հետո:
- Ցածր ճկունություն. Շատ անհատներ դժվարանում են երկարաժամկետ ժամանակով մեկ առանց սերվերի միջավայրի մատակարարին միանալու:
- Սառը մեկնարկ. այն մնում է քեշում, բայց միայն կարճ ժամանակով, երբ յուրաքանչյուր գործառույթ ավարտվի: Ֆունկցիան պետք է նորից արձագանքի կանչի խնդրանքին, ինչը ժամանակ է պահանջում, եթե այն նորից գործարկեք և այն քեշավորված չէ:
Եզրափակում
Առանց սերվերի և միկրոսերվիսները ճարտարապետական առնչվող տեխնոլոգիաներ են, որոնք օգտագործում են տարբեր տեխնիկա: Ե՛վ առանց սերվերի, և՛ միկրոսերվիսներն ընդգծում են մասշտաբայնությունը, հարմարվողականությունը, ծախսարդյունավետությունը և նոր հնարավորություններ ավելացնելու պարզությունը՝ ի տարբերություն մոնոլիտ դիզայնի:
Քանի որ յուրաքանչյուր ծառայություն գործում է որպես անկախ հավելված, երկարաժամկետ մասշտաբայնությունը միկրոծառայությունների հիմնական նպատակն է:
Կախված կազմակերպության արտադրանքի շրջանակից և առաջնահերթություններից, կարելի է ընտրել երկու ռազմավարությունների միջև:
Microservices-ը ձեզ կտրամադրի առանց սերվերի միկրոծառայությունների երկարաժամկետ լուծումներ, եթե դուք մտադիր եք կառուցել մի մեծ հարթակ, որը կարիք ունի շարունակական աճի:
Առանց սերվերի ճարտարապետությունը ֆանտաստիկ տարբերակ է, եթե ցանկանում եք տեղակայվել արագ և մատչելի գնով:
Թողնել գրառում