Ինչու՞ ենք մենք ստեղծում Enterprise Service Mesh-ը:

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

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

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

Վստահված անձի մակարդակում (տվյալների հարթություն).

• Երթուղային և երթևեկության հավասարակշռման քաղաքականությունների նշանակում և բաշխում
• Բանալիների, վկայագրերի, նշանների բաշխում
• Հեռաչափության հավաքածու, մոնիտորինգի չափումների ստեղծում
• Ինտեգրում անվտանգության և մոնիտորինգի ենթակառուցվածքի հետ

Կառավարման հարթության մակարդակում.

• Երթուղային և երթևեկության հավասարակշռման քաղաքականության կիրառում
• Կրկնակի փորձերի և ժամկետների կառավարում, «մեռած» հանգույցների հայտնաբերում (շղթայի խզում), ներարկման անսարքությունների կառավարում և այլ մեխանիզմների միջոցով ծառայության դիմացկունության ապահովում
• Զանգի նույնականացում/լիազորում
• Նվազման չափումներ (դիտելիություն)

Այս տեխնոլոգիայի մշակմամբ հետաքրքրված օգտատերերի շրջանակը շատ լայն է՝ փոքր ստարտափներից մինչև խոշոր ինտերնետային կորպորացիաներ, օրինակ՝ PayPal:

Ինչու՞ է անհրաժեշտ Service Mesh-ը կորպորատիվ հատվածում:

Ծառայության ցանց օգտագործելը շատ հստակ առավելություններ ունի: Նախ, դա ուղղակի հարմար է մշակողների համար՝ կոդ գրելու համար հայտնվում է տեխնոլոգիական հարթակ, ինչը զգալիորեն հեշտացնում է ինտեգրումը ամպային ենթակառուցվածքին, քանի որ տրանսպորտային շերտը լիովին մեկուսացված է կիրառական տրամաբանությունից։

Բացի այդ, Service Mesh-ը պարզեցնում է մատակարարների և սպառողների միջև հարաբերությունները: Այսօր API մատակարարների և սպառողների համար շատ ավելի հեշտ է ինքնուրույն պայմանավորվել ինտերֆեյսների և պայմանագրերի շուրջ՝ առանց ինտեգրման հատուկ միջնորդի և արբիտրի՝ ձեռնարկությունների սպասարկման ավտոբուսի ներգրավման: Այս մոտեցումը զգալիորեն ազդում է երկու ցուցանիշների վրա. Նոր ֆունկցիոնալությունը շուկա բերելու արագությունը (ժամանակից դեպի շուկա) մեծանում է, բայց միևնույն ժամանակ մեծանում է լուծման արժեքը, քանի որ ինտեգրումը պետք է իրականացվի ինքնուրույն: Բիզնեսի ֆունկցիոնալության զարգացման թիմերի կողմից Service Mesh-ի օգտագործումն օգնում է այստեղ հավասարակշռություն պահպանել: Արդյունքում, API մատակարարները կարող են կենտրոնանալ բացառապես իրենց ծառայության հավելվածի բաղադրիչի վրա և պարզապես հրապարակել այն Service Mesh-ում. API-ն անմիջապես հասանելի կդառնա բոլոր հաճախորդների համար, իսկ ինտեգրման որակը պատրաստ կլինի արտադրությանը և չի պահանջի մեկ անգամ: լրացուցիչ ծածկագրի տող:

Հաջորդ առավելությունն այն է մշակողը, օգտագործելով Service Mesh-ը, կենտրոնանում է բացառապես բիզնեսի ֆունկցիոնալության վրա — արտադրանքի, այլ ոչ թե դրա ծառայության տեխնոլոգիական բաղադրիչի վրա: Օրինակ, դուք այլևս չպետք է մտածեք այն փաստի մասին, որ մի իրավիճակում, երբ ծառայությունը կանչվում է ցանցի միջոցով, ինչ-որ տեղ կապի խափանում կարող է տեղի ունենալ: Բացի այդ, Service Mesh-ն օգնում է հավասարակշռել երթևեկությունը նույն ծառայության պատճենների միջև. եթե պատճեններից մեկը «մեռնում է», ապա համակարգը կփոխանցի ողջ երթևեկությունը մնացած կենդանի պատճեններին:

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

Հարկ է նշել, որ Բաշխված հավելվածների թարմացումը ծառայության ցանցային միջավայրում դառնում է ավելի հեշտ: Օրինակ՝ կապույտ/կանաչ տեղակայում, որտեղ տեղադրման համար հասանելի են երկու կիրառական միջավայրեր, որոնցից մեկը թարմացված չէ և գտնվում է սպասման ռեժիմում։ Անհաջող թողարկման դեպքում վերադարձը նախորդ տարբերակին իրականացվում է հատուկ երթուղիչով, որի դերը լավ է հաղթահարում Service Mesh-ը:. Նոր տարբերակը փորձարկելու համար կարող եք օգտագործել դեղձանիկի ազատում — անցնել նոր տարբերակին տրաֆիկի միայն 10%-ը կամ հաճախորդների փորձնական խմբի հարցումները: Հիմնական տրաֆիկը գնում է դեպի հին տարբերակը, ոչինչ չի կոտրվում։

Նույնպես Service Mesh-ը մեզ տալիս է իրական ժամանակի SLA հսկողություն. Բաշխված վստահված անձի համակարգը թույլ չի տա, որ ծառայությունը ձախողվի, երբ հաճախորդներից մեկը գերազանցի իրեն հատկացված քվոտան: Եթե ​​API-ի թողունակությունը սահմանափակ է, ոչ ոք չի կարողանա այն ծանրաբեռնել մեծ թվով գործարքներով. Service Mesh-ը կանգնած է ծառայության դիմաց և թույլ չի տալիս ավելորդ երթևեկություն: Այն ուղղակի կպայքարի ինտեգրացիոն շերտում, իսկ ծառայություններն իրենք կշարունակեն աշխատել՝ չնկատելով դա։

Եթե ​​ընկերությունը ցանկանում է նվազեցնել ինտեգրացիոն լուծումների մշակման ծախսերը, Service Mesh-ը նաև օգնում է. Դուք կարող եք անցնել դրա բաց կոդով տարբերակին առևտրային արտադրանքներից. Մեր Enterprise Service Mesh-ը հիմնված է Service Mesh-ի բաց կոդով տարբերակի վրա:

Մեկ այլ առավելություն - ինտեգրացիոն ծառայությունների միասնական ամբողջական փաթեթի առկայությունը. Քանի որ ամբողջ ինտեգրումը կառուցված է այս միջին ծրագրի միջոցով, մենք կարող ենք կառավարել ամբողջ ինտեգրացիոն տրաֆիկը և հավելվածների միջև կապերը, որոնք կազմում են ընկերության բիզնես միջուկը: Շատ հարմարավետ է։

Եվ վերջապես Service Mesh-ը խրախուսում է ընկերությանը անցնել դինամիկ ենթակառուցվածք: Այժմ շատերը նայում են կոնտեյներացմանը: Մոնոլիտը միկրոսերվիսների կտրում, այս ամենի գեղեցիկ իրականացում - թեման աճում է: Բայց երբ փորձում ես երկար տարիներ արտադրվող համակարգը տեղափոխել նոր հարթակ, անմիջապես բախվում ես մի շարք խնդիրների. այն ամենը բեռնարկղերի մեջ մղելը և հարթակի վրա տեղակայելը հեշտ չէ: Եվ այս բաշխված բաղադրիչների իրականացումը, համաժամացումը և փոխազդեցությունը մեկ այլ շատ բարդ թեմա է: Ինչպե՞ս են նրանք շփվելու միմյանց հետ։ Կլինե՞ն կասկադային ձախողումներ: Service Mesh-ը թույլ է տալիս լուծել այս խնդիրների մի մասը և հեշտացնել միգրացիան հին ճարտարապետությունից դեպի նորը, քանի որ դուք կարող եք մոռանալ ցանցի փոխանակման տրամաբանության մասին:

Ինչու՞ է ձեզ անհրաժեշտ Service Mesh-ի հարմարեցում:

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

Միջոցառումների մշակման ծառայություն

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

Բավական տարօրինակ է, որ Remote Procedure Call-ը (RPC) աջակցվում է Service Mesh-ի բոլոր տարբերակների կողմից, բայց դրանք բարեկամական չեն EDA-ի հետ: Քանի որ Service Mesh-ը մի տեսակ ժամանակակից բաշխված ինտեգրում է, և EDA-ն շատ համապատասխան ճարտարապետական ​​օրինաչափություն է, որը թույլ է տալիս եզակի բաներ անել հաճախորդների փորձի առումով:

Մեր Enterprise Service Mesh-ը պետք է լուծի այս խնդիրը: Բացի այդ, մենք ցանկանում ենք դրանում տեսնել երաշխավորված առաքման, հոսքի և իրադարձությունների բարդ մշակման իրականացում` օգտագործելով տարբեր զտիչներ և կաղապարներ:

Ֆայլերի փոխանցման ծառայություն

Բացի EDA-ից, լավ կլինի, որ կարողանանք ֆայլեր փոխանցել. Enterprise մասշտաբով, շատ հաճախ հնարավոր է միայն ֆայլերի ինտեգրում: Մասնավորապես, օգտագործվում է ETL (Extract, Transform, Load) ճարտարապետական ​​նախշը: Դրանում, որպես կանոն, բոլորը փոխանակում են բացառապես ֆայլեր. օգտագործվում են մեծ տվյալներ, ինչը անիրագործելի է առանձին հարցումներ մղել։ Enterprise Service Mesh-ում ֆայլերի փոխանցումները բնօրինակ կերպով աջակցելու հնարավորությունը ձեզ տալիս է ձեր բիզնեսի կարիքների ճկունությունը:

Նվագախմբի ծառայություն

Խոշոր կազմակերպությունները գրեթե միշտ ունեն տարբեր թիմեր, որոնք արտադրում են տարբեր ապրանքներ: Օրինակ՝ բանկում որոշ թիմեր աշխատում են ավանդներով, իսկ մյուսները՝ վարկային պրոդուկտներով, և նման դեպքերը բավականին շատ են։ Սրանք տարբեր մարդիկ են, տարբեր թիմեր, ովքեր պատրաստում են իրենց արտադրանքը, զարգացնում են իրենց API-ները և տրամադրում դրանք ուրիշներին: Եվ շատ հաճախ անհրաժեշտություն է առաջանում կազմել այս ծառայությունները, ինչպես նաև իրականացնել բարդ տրամաբանություն API-ների մի շարք հաջորդաբար կանչելու համար: Այս խնդիրը լուծելու համար ձեզ անհրաժեշտ է լուծում ինտեգրման շերտում, որը կպարզեցնի այս ամբողջ բաղադրյալ տրամաբանությունը (զանգահարել մի քանի API, նկարագրել հարցումների երթուղին և այլն): Սա Enterprise Service Mesh-ի նվագախմբային ծառայությունն է:

AI և ML

Երբ միկրոծառայությունները հաղորդակցվում են մեկ ինտեգրացիոն շերտի միջոցով, Ծառայության ցանցը բնականաբար գիտի ամեն ինչ յուրաքանչյուր ծառայության զանգերի մասին: Մենք հավաքում ենք հեռաչափություն՝ ով ում է զանգահարել, երբ, ինչքան ժամանակ, քանի անգամ և այլն։ Երբ կան հարյուր հազարավոր այդ ծառայությունները, և միլիարդավոր զանգերը, ապա այս ամենը կուտակվում և ձևավորվում է Big Data: Այս տվյալները կարելի է վերլուծել՝ օգտագործելով AI, մեքենայական ուսուցում և այլն, այնուհետև վերլուծության արդյունքների հիման վրա կարող են որոշ օգտակար բաներ անել: Նպատակահարմար կլինի գոնե մասամբ փոխանցել այս ամբողջ ցանցային երթևեկի և կիրառական զանգերի կառավարումը, որոնք ինտեգրված են Service Mesh-ին արհեստական ​​ինտելեկտին:

API Gateway ծառայություն

Սովորաբար, Service Mesh-ն ունի վստահված անձեր և ծառայություններ, որոնք միմյանց հետ խոսում են վստահելի պարագծում: Բայց կան նաև արտաքին գործընկերներ։ Սպառողների այս խմբին ենթարկվող API-ների նկատմամբ պահանջները շատ ավելի խիստ են: Մենք այս առաջադրանքը բաժանում ենք երկու հիմնական մասի.

• Безопасность. ddos-ի հետ կապված խնդիրներ, արձանագրությունների, հավելվածների, օպերացիոն համակարգերի խոցելիություն և այլն:
• Սանդղակ. Երբ API-ների թիվը, որոնք պետք է սպասարկվեն հաճախորդներին, հասնում է հազարների կամ նույնիսկ հարյուր հազարների, այս API-ների համար որոշակի կառավարման գործիքի կարիք կա: Պետք է անընդհատ վերահսկել API-ն՝ աշխատում են, թե ոչ, ինչ կարգավիճակ ունեն, ինչ տրաֆիկ է հոսում, ինչ վիճակագրություն և այլն։ API gateway-ը պետք է կարգավորի այս խնդիրը՝ միաժամանակ դարձնելով ամբողջ գործընթացը կառավարելի և անվտանգ: Այս բաղադրիչի շնորհիվ Enterprise Service Mesh-ը սովորում է հեշտությամբ հրապարակել ինչպես ներքին, այնպես էլ արտաքին API-ներ:

Աջակցման ծառայություն հատուկ արձանագրությունների և տվյալների ձևաչափերի համար (AS gateway)

Ներկայումս Service Mesh լուծումների մեծ մասը կարող է աշխատել միայն HTTP և HTTP2 տրաֆիկի հետ կամ TCP/IP մակարդակի կրճատված ռեժիմով: Ձեռնարկությունների սպասարկման ցանցը առաջանում է տվյալների փոխանցման շատ այլ շատ հատուկ արձանագրություններով: Որոշ համակարգեր կարող են օգտագործել հաղորդագրությունների բրոքերներ, մյուսները ինտեգրված են տվյալների բազայի մակարդակում: Եթե ​​ընկերությունն ունի SAP, ապա կարող է նաև օգտագործել սեփական ինտեգրացիոն համակարգը։ Ավելին, այս ամենը գործում է և բիզնեսի կարևոր մասն է։

Դուք պարզապես չեք կարող ասել. «Եկեք թողնենք ժառանգությունը և ստեղծենք նոր համակարգեր, որոնք կարող են օգտագործել Service Mesh»: Բոլոր հին համակարգերը նորերի հետ միացնելու համար (միկրոսերվիսային ճարտարապետության վրա), համակարգերին, որոնք կարող են օգտագործել Service Mesh-ը, անհրաժեշտ կլինի ինչ-որ ադապտեր, միջնորդ, դարպաս: Համաձայնեք, լավ կլիներ ծառայության հետ միասին տուփով էլ լիներ։ AC դարպասը կարող է աջակցել ցանկացած ինտեգրման տարբերակ: Պարզապես պատկերացրեք, դուք պարզապես տեղադրում եք Enterprise Service Mesh-ը և այն պատրաստ է փոխազդելու ձեզ անհրաժեշտ բոլոր արձանագրությունների հետ: Այս մոտեցումը մեզ համար շատ կարևոր է։

Մոտավորապես այսպես ենք պատկերացնում Service Mesh-ի կորպորատիվ տարբերակը (Enterprise Service Mesh): Նկարագրված հարմարեցումը լուծում է այն խնդիրների մեծ մասը, որոնք առաջանում են ինտեգրացիոն հարթակի պատրաստի բաց կոդով տարբերակներն օգտագործելու ժամանակ: Ընդամենը մի քանի տարի առաջ ներկայացված Service Mesh ճարտարապետությունը շարունակում է զարգանալ, և մենք ոգևորված ենք, որ կարող ենք նպաստել դրա զարգացմանը: Հուսով ենք, որ մեր փորձը օգտակար կլինի ձեզ համար:

Source: www.habr.com