սեպտեմբերի 19-ին Մոսկվայում առաջին թեմատիկ հանդիպումը HUG (Highload++ User Group), որը նվիրված էր միկրոսերվիսներին։ Տեղի ունեցավ «Գործող միկրոսերվիսներ. չափը կարևոր է, նույնիսկ եթե ունես Kubernetes» շնորհանդեսը, որում մենք կիսվեցինք միկրոսերվիսային ճարտարապետությամբ նախագծեր գործարկելու Flant-ի մեծ փորձով: Առաջին հերթին, դա օգտակար կլինի բոլոր մշակողների համար, ովքեր մտածում են այս մոտեցումն օգտագործել իրենց ընթացիկ կամ ապագա նախագծում:
Ներկայացնելով (50 րոպե, շատ ավելի տեղեկատվական, քան հոդվածը), ինչպես նաև դրա հիմնական քաղվածքը տեքստային տեսքով:
NB: Տեսանյութը և ներկայացումը հասանելի են նաև այս գրառման վերջում:
Ներածություն
Սովորաբար լավ պատմությունն ունի սկիզբ, հիմնական սյուժե և լուծում: Այս զեկույցն ավելի շուտ նախերգանքի է նման, ընդ որում՝ ողբերգական։ Կարևոր է նաև նշել, որ այն ապահովում է միկրոծառայությունների արտաքին տեսքը: շահագործման.
Ես կսկսեմ այս գրաֆիկից, որի հեղինակը (2015 թ.) Մարտին Ֆաուլեր.
Այն ցույց է տալիս, թե ինչպես է որոշակի արժեքի հասնող մոնոլիտ հավելվածի դեպքում արտադրողականությունը սկսում է նվազել։ Միկրոծառայությունները տարբերվում են նրանով, որ դրանց հետ նախնական արտադրողականությունն ավելի ցածր է, բայց բարդության աճի հետ արդյունավետության անկումը նրանց համար այնքան էլ նկատելի չէ:
Ես կավելացնեմ այս գրաֆիկին Kubernetes-ի օգտագործման դեպքի համար.
Ինչու՞ է ավելի լավ միկրոծառայությունների հետ հավելվածը: Որովհետև նման ճարտարապետությունը լուրջ պահանջներ է առաջադրում ճարտարապետությանը, որոնք իրենց հերթին հիանալի ծածկված են Kubernetes-ի հնարավորություններով։ Մյուս կողմից, այս ֆունկցիոնալության մի մասը օգտակար կլինի մոնոլիտի համար, հատկապես այն պատճառով, որ այսօր բնորոշ մոնոլիտը հենց այնպես մոնոլիտ չէ (մանրամասները կներկայացվեն ավելի ուշ զեկույցում):
Ինչպես տեսնում եք, վերջնական գրաֆիկը (երբ և՛ մոնոլիտ, և՛ միկրոսերվիսային հավելվածները գտնվում են ենթակառուցվածքում Kubernetes-ի հետ) շատ չի տարբերվում սկզբնականից։ Հաջորդիվ կխոսենք Kubernetes-ի միջոցով գործարկվող հավելվածների մասին։
Օգտակար և վնասակար միկրոծառայություններ
Եվ ահա հիմնական գաղափարը.
Ինչ է նորմալ միկրոսպասարկման ճարտարապետություն? Այն պետք է ձեզ իրական օգուտներ բերի՝ բարձրացնելով ձեր աշխատանքի արդյունավետությունը։ Եթե վերադառնանք գրաֆիկին, ահա այն.
Եթե զանգես նրան օգտակար, ապա գրաֆիկի մյուս կողմում կլինի վնասակար միկրոծառայություններ (խոչընդոտում է աշխատանքին).
Վերադառնալով «հիմնական գաղափարին». ընդհանրապես պետք է վստահե՞մ իմ փորձին: Այս տարվա սկզբից ես նայեցի 85 նախագիծ. Դրանցից ոչ բոլորն էին միկրոսերվիսներ (նրանց մոտ մեկ երրորդից կեսն ուներ նման ճարտարապետություն), բայց դա դեռ մեծ թիվ է։ Մենք (Flant ընկերությունը), որպես աութսորսորներ, կարողանում ենք տեսնել հավելվածների լայն տեսականի, որոնք մշակվել են ինչպես փոքր ընկերություններում (5 ծրագրավորողներով), այնպես էլ խոշոր ընկերություններում (~500 ծրագրավորողներ): Լրացուցիչ առավելությունն այն է, որ մենք տեսնում ենք, որ այս հավելվածները ապրում և զարգանում են տարիների ընթացքում:
Ինչու՞ միկրոծառայություններ:
Միկրոծառայությունների առավելությունների մասին հարցին կա արդեն հիշատակված Մարտին Ֆաուլերից.
- մոդուլյարության հստակ սահմաններ;
- անկախ տեղակայում;
- տեխնոլոգիաների ընտրության ազատություն.
Ես շատ եմ խոսել ծրագրային ապահովման ճարտարապետների և ծրագրավորողների հետ և հարցրել եմ, թե ինչու են նրանց միկրոծառայությունների կարիքը: Եվ ես կազմեցի նրանց ակնկալիքների իմ ցուցակը։ Ահա թե ինչ է տեղի ունեցել.
Եթե նկարագրենք որոշ կետեր «սենսացիաներում», ապա.
- մոդուլների հստակ սահմաններ. այստեղ մենք ունենք սարսափելի մոնոլիտ, և այժմ ամեն ինչ կկազմավորվի Git պահեստներում, որոնցում ամեն ինչ «դարակների վրա է», տաքն ու փափուկը չեն խառնվում.
- տեղակայման անկախություն. մենք կկարողանանք ծառայություններ մատուցել ինքնուրույն, որպեսզի զարգացումն ավելի արագ ընթանա (զուգահեռաբար հրապարակել նոր գործառույթներ);
- զարգացման անկախություն. մենք կարող ենք այս միկրոսերվիսը տալ մեկ թիմին/մշակողին, իսկ մյուսը՝ մյուսին, ինչի շնորհիվ մենք կարող ենք ավելի արագ զարգանալ.
- боավելի մեծ հուսալիություն. եթե տեղի է ունենում մասնակի դեգրադացիա (20-ից մեկ միկրոսերվիս ընկնում է), ապա միայն մեկ կոճակը կդադարի աշխատել, և համակարգն ամբողջությամբ կշարունակի գործել:
Տիպիկ (վնասակար) միկրոծառայության ճարտարապետություն
Բացատրելու համար, թե ինչու իրականությունն այն չէ, ինչ մենք ակնկալում ենք, կներկայացնեմ կոլեկտիվ միկրոծառայությունների ճարտարապետության պատկեր՝ հիմնված բազմաթիվ տարբեր նախագծերի փորձի վրա:
Օրինակ կարող է լինել վերացական առցանց խանութը, որը պատրաստվում է մրցակցել Amazon-ի կամ առնվազն OZON-ի հետ: Նրա միկրոսերվիսային ճարտարապետությունն ունի հետևյալ տեսքը.
Պատճառների համակցությամբ այս միկրոծառայությունները գրված են տարբեր հարթակներում.
Քանի որ յուրաքանչյուր միկրոսերվիս պետք է ունենա ինքնավարություն, նրանցից շատերին անհրաժեշտ է իրենց տվյալների բազան և քեշը: Վերջնական ճարտարապետությունը հետևյալն է.
Որո՞նք են դրա հետևանքները:
Ֆաուլերն ունի նաև սա — միկրոծառայությունների օգտագործման «վճարի» մասին.
Եվ մենք կտեսնենք, թե արդյոք մեր սպասելիքները արդարացվեցին:
Մաքրել մոդուլների սահմանները...
Սակայն քանի՞ միկրոսպասարկում իրականում պետք է ուղղենք:փոխել փոփոխությունը. Կարո՞ղ ենք նույնիսկ պարզել, թե ինչպես է ամեն ինչ աշխատում առանց բաշխված հետագծողի (ի վերջո, ցանկացած հարցում մշակվում է միկրոծառայությունների կեսի կողմից):
Կա մի օրինաչափություն»«, և այստեղ պարզվեց, որ դա բաշխված կեղտի կտոր է: Սա հաստատելու համար, ահա մոտավոր նկարազարդում, թե ինչպես են ընթանում հարցումները.
Տեղակայման անկախությունը...
Տեխնիկապես դա ձեռք է բերվել. մենք կարող ենք յուրաքանչյուր միկրոսերվիս գործարկել առանձին: Բայց գործնականում պետք է հաշվի առնել, որ այն միշտ դուրս է գալիս բազմաթիվ միկրոծառայություններ, և մենք պետք է հաշվի առնենք դրանց թողարկման կարգը. Լավ իմաստով, մենք ընդհանուր առմամբ պետք է փորձարկենք առանձին շղթայում, թե արդյոք մենք թողարկում ենք ճիշտ հերթականությամբ:
Տեխնոլոգիաների ընտրության ազատություն...
Նա է. Պարզապես հիշեք, որ ազատությունը հաճախ սահմանակից է անօրինականությանը: Այստեղ շատ կարևոր է տեխնոլոգիաներ չընտրել միայն դրանցով «խաղալու» համար։
Զարգացման անկախություն...
Ինչպե՞ս ստեղծել փորձարկման օղակ ամբողջ հավելվածի համար (այդքան բաղադրիչներով): Բայց դուք դեռ պետք է թարմացնեք այն: Այս ամենը հանգեցնում է նրան, որ փորձարկման սխեմաների իրական թիվը, որը մենք կարող ենք սկզբունքորեն պարունակել, պարզվում է, որ նվազագույն է.
Ինչ կասեք այս ամենը տեղակայելու մասին... Պարզվում է, որ հաճախ ծրագրավորողն իր աշխատանքը կատարում է ինքնուրույն, բայց «պատահական», քանի որ նա ստիպված է սպասել, մինչև սխեման ազատվի փորձարկման համար:
Առանձին մասշտաբում...
Այո, բայց այն սահմանափակված է օգտագործվող DBMS-ի տարածքում: Տվյալ ճարտարապետության օրինակում Cassandra-ն խնդիրներ չի ունենա, բայց կունենան MySQL-ը և PostgreSQL-ը:
Боավելի մեծ հուսալիություն...
Իրականում մեկ միկրոծառայության ձախողումը ոչ միայն հաճախ խախտում է ամբողջ համակարգի ճիշտ գործունեությունը, այլև կա մի նոր խնդիր. յուրաքանչյուր միկրոսերվիս անսարքության հանդուրժող դարձնելը շատ դժվար է. Քանի որ միկրոսերվիսներն օգտագործում են տարբեր տեխնոլոգիաներ (memcache, Redis և այլն), յուրաքանչյուրի համար պետք է ամեն ինչ մտածել և իրականացնել, ինչը, իհարկե, հնարավոր է, բայց պահանջում է հսկայական ռեսուրսներ։
Բեռի չափելիություն...
Սա իսկապես լավ է:
Միկրոծառայությունների «թեթևությունը»...
Մենք ոչ միայն ունենք հսկայական ցանցի գլխավերեւում (DNS-ի հարցումները բազմապատկվում են և այլն), բայց նաև մեր կողմից սկսված բազմաթիվ ենթապայմանների պատճառով կրկնօրինակել տվյալները (խանութների պահոցներ), ինչը հանգեցրեց զգալի քանակությամբ պահեստի:
Եվ ահա մեր սպասելիքները բավարարելու արդյունքը.
Բայց սա դեռ ամենը չէ։
Որովհետև.
- Ամենայն հավանականությամբ մեզ պետք կլինի հաղորդագրությունների ավտոբուս:
- Ինչպե՞ս ստեղծել հետևողական կրկնօրինակում ճիշտ պահին: Միակը реальный տարբերակը դրա համար երթևեկությունն անջատելն է: Բայց ինչպե՞ս դա անել արտադրության մեջ:
- Եթե խոսքը մի քանի մարզերի աջակցության մասին է, ապա դրանցից յուրաքանչյուրում կայունության կազմակերպումը շատ աշխատատար խնդիր է։
- Կենտրոնացված փոփոխություններ կատարելու խնդիր է առաջանում։ Օրինակ, եթե մենք պետք է թարմացնենք PHP տարբերակը, մենք պետք է հավատարիմ մնանք յուրաքանչյուր պահեստին (և կան տասնյակ այդպիսիք):
- Գործառնական բարդության աճը անսպասելի է, էքսպոնենցիալ:
Ի՞նչ անել այս ամենի հետ:
Սկսեք մոնոլիտ հավելվածից. Ֆաուլերի փորձը որ գրեթե բոլոր հաջողված միկրոսերվիսային հավելվածները սկսվել են որպես մոնոլիտ, որը դարձել է չափազանց մեծ և հետո կոտրվել: Միևնույն ժամանակ, ի սկզբանե որպես միկրոսերվիսներ կառուցված գրեթե բոլոր համակարգերը վաղ թե ուշ լուրջ խնդիրներ են ունեցել։
Մեկ այլ արժեքավոր միտք այն է, որ միկրոսերվիսային ճարտարապետությամբ նախագիծը հաջողակ լինելու համար դուք պետք է շատ լավ իմանաք և առարկայական ոլորտ, և ինչպես կատարել միկրոծառայություններ. Իսկ առարկայական տարածք սովորելու լավագույն միջոցը մոնոլիտ պատրաստելն է:
Բայց ի՞նչ, եթե մենք արդեն այս իրավիճակում ենք։
Ցանկացած խնդրի լուծման առաջին քայլը դրա հետ համաձայնվելն ու հասկանալն է, որ դա խնդիր է, որ մենք այլևս չենք ուզում տառապել։
Եթե գերաճած մոնոլիտի դեպքում (երբ մենք սպառել ենք դրա համար լրացուցիչ ռեսուրսներ գնելու հնարավորությունը), կտրում ենք այն, ապա այս դեպքում ստացվում է հակառակ պատմությունը. կտրել ավելցուկը և մեծացնել!
Օրինակ՝ վերը քննարկված հավաքական կերպարի համար...
Ազատվեք առավել կասկածելի միկրոծառայություններից.
Միավորել բոլոր միկրոծառայությունները, որոնք պատասխանատու են frontend-ի արտադրության համար.
... մեկ միկրոծառայության մեջ՝ գրված մեկ (ժամանակակից և նորմալ, ինչպես ինքներդ եք կարծում) լեզվով/շրջանակով.
Այն կունենա մեկ ORM (մեկ DBMS) և նախ մի քանի հավելված.
... բայց ընդհանուր առմամբ այնտեղ կարող եք շատ ավելին փոխանցել՝ ստանալով հետևյալ արդյունքը.
Ավելին, Kubernetes-ում մենք այս ամենը գործարկում ենք առանձին օրինակներով, ինչը նշանակում է, որ մենք դեռ կարող ենք չափել բեռը և չափել դրանք առանձին։
Ամփոփելով
Նայեք ավելի մեծ պատկերին: Շատ հաճախ միկրոսերվիսների հետ կապված այս բոլոր խնդիրները ծագում են այն պատճառով, որ ինչ-որ մեկը վերցրել է իր խնդիրը, բայց ցանկացել է «խաղալ միկրոսերվիսների հետ»:
«Միկրոծառայություններ» բառում «միկրո» մասը ավելորդ է։. Նրանք «միկրո» են միայն այն պատճառով, որ ավելի փոքր են, քան հսկայական մոնոլիտը: Բայց մի մտածեք նրանց մասին որպես փոքր բան:
Եվ վերջնական մտքի համար վերադառնանք սկզբնական աղյուսակին.
Դրա վրա գրված գրություն (վերևի աջ) հանգում է նրան, որ Ձեր նախագիծը կերտող թիմի հմտությունները միշտ առաջնային են — դրանք առանցքային դեր կխաղան միկրոծառայությունների և մոնոլիտի միջև ձեր ընտրության հարցում: Եթե թիմը չունենա բավարար հմտություններ, բայց սկսի միկրոսերվիսներ պատրաստել, պատմությունը հաստատ ճակատագրական կլինի։
Տեսանյութեր և սլայդներ
Տեսանյութ ելույթից (~50 րոպե, ցավոք, այն չի փոխանցում այցելուների բազմաթիվ հույզերը, որոնք մեծապես պայմանավորում էին ռեպորտաժի տրամադրությունը, բայց դա այդպես է).
Զեկույցի ներկայացում.
PS
Այլ զեկույցներ մեր բլոգում.
- «» (Դմիտրի Ստոլյարով; մայիսի 28, 2018 RootConf-ում);
- «» (Դմիտրի Ստոլյարով; նոյեմբերի 7, 2017 HighLoad++-ում);
- «» (Դմիտրի Ստոլյարով; 6 թվականի հունիսի 2017-ին RootConf-ում);
- «» (Դմիտրի Ստոլյարով; նոյեմբերի 8, 2016 HighLoad++-ում);
- «» (Դմիտրի Ստոլյարով; մայիսի 31, 2016 RootConf-ում).
Ձեզ կարող են հետաքրքրել նաև հետևյալ հրապարակումները.
- «";
- «";
- «.
Source: www.habr.com