Կրկին բարև.. Դասընթացի մեկնարկի նախօրեին Մենք պատրաստել ենք ևս մեկ օգտակար թարգմանություն։
Ծառայության ցանցը կարգավորելի, ցածր լատենտ ենթակառուցվածքային շերտ է, որն անհրաժեշտ է կիրառական ծրագրավորման միջերեսների (API-ների) միջև ցանցի վրա հիմնված միջգործընթացային հաղորդակցությունների մեծ ծավալների համար: Service Mesh-ը հնարավորություն է տալիս արագ, հուսալի և անվտանգ հաղորդակցություն կոնտեյներային և հաճախ ժամանակավոր կիրառական ենթակառուցվածքային ծառայությունների միջև: Service Mesh-ը տրամադրում է այնպիսի հնարավորություններ, ինչպիսիք են ծառայության հայտնաբերումը, բեռնվածության հավասարակշռումը, կոդավորումը, թափանցիկությունը, հետագծելիությունը, իսկությունը և թույլտվությունը, ինչպես նաև ավտոմատ անջատման օրինաչափության աջակցություն (անջատիչ).
Ծառայությունների ցանցը սովորաբար իրականացվում է՝ յուրաքանչյուր ծառայության օրինակ տրամադրելով վստահված անձի օրինակ, որը կոչվում է Կողային մեքենա: Կողային մեքենա կարգավորել ծառայությունների միջև հաղորդակցությունը, վերահսկել և լուծել անվտանգության խնդիրները, այսինքն՝ այն ամենը, ինչ կարելի է վերացնել առանձին ծառայություններից: Այս կերպ մշակողները կարող են գրել, պահպանել և սպասարկել հավելվածի կոդը ծառայություններում, իսկ համակարգի ադմինիստրատորները կարող են աշխատել Service Mesh-ի հետ և գործարկել հավելվածը:
Google-ի, IBM-ի և Lyft-ի Istio-ն ներկայումս ամենահայտնի ծառայությունների ցանցային ճարտարապետությունն է: Իսկ Kubernetes-ը, որն ի սկզբանե մշակվել էր Google-ում, այժմ միակ կոնտեյներային նվագախմբային շրջանակն է, որն աջակցում է Istio-ն: Վաճառողները փորձում են ստեղծել Istio-ի կոմերցիոն աջակցվող տարբերակները: Հետաքրքիր կլինի տեսնել, թե ինչ նոր բաներ նրանք կարող են բերել բաց կոդով նախագծին:
Այնուամենայնիվ, Istio-ն միակ տարբերակը չէ, քանի որ մշակվում են Service Mesh-ի այլ ծրագրեր: Կաղապար sidecar proxy ամենահայտնի իրականացումն է, ինչի մասին կարելի է դատել Buoyant, HashiCorp, Solo.io և այլ նախագծերով: Կան նաև այլընտրանքային ճարտարապետություններ. Netflix տեխնոլոգիական գործիքակազմն այն մոտեցումներից մեկն է, որտեղ Service Mesh գործառույթն իրականացվում է Ribbon, Hysterix, Eureka, Archaius գրադարանների, ինչպես նաև այնպիսի հարթակների, ինչպիսին է Azure Service Fabric-ը:
Service Mesh-ն ունի նաև սպասարկման բաղադրիչների և գործառույթների իր տերմինաբանությունը.
- Կոնտեյներային նվագախմբի շրջանակ. Քանի որ ավելի ու ավելի շատ կոնտեյներներ են ավելացվում հավելվածների ենթակառուցվածքին, անհրաժեշտություն է առաջանում բեռնարկղերի մոնիտորինգի և կառավարման առանձին գործիքի` կոնտեյներների նվագախմբային շրջանակ: Kubernetes-ը ամուր զբաղեցրել է այս տեղը, այնքան, որ նույնիսկ նրա հիմնական մրցակիցները Docker Swarm-ը և Mesosphere DC/OS-ն առաջարկում են ինտեգրում Kubernetes-ի հետ որպես այլընտրանք:
- Ծառայություններ և օրինակներ (Kubernetes Pods). Օրինակը միկրոսերվիսի մեկ գործող պատճենն է: Երբեմն մեկ օրինակը մեկ կոնտեյներ է: Kubernetes-ում օրինակը բաղկացած է անկախ բեռնարկղերի փոքր խմբից, որը կոչվում է pod: Հաճախորդները հազվադեպ են ուղղակիորեն մուտք գործում օրինակ կամ pod, ավելի հաճախ նրանք մուտք են գործում ծառայություն, որը միանման, մասշտաբային և սխալ հանդուրժող օրինակների կամ պատյանների (կրկնօրինակներ) մի շարք է:
- Sidecar վստահված անձ. Sidecar Proxy-ն աշխատում է մեկ օրինակով կամ pod-ով: Sidecar Proxy-ի նպատակն է երթուղղել կամ վստահված անձի երթևեկությունը, որը գալիս է այն կոնտեյներից, որի հետ նա աշխատում է և վերադարձնում երթևեկությունը: Sidecar-ը փոխազդում է այլ Sidecar Proxies-ի հետ և կառավարվում է նվագախմբային շրջանակով: Շատ Service Mesh-ի ներդրումներն օգտագործում են Sidecar Proxy-ը` ընդհատելու և կառավարելու ամբողջ երթևեկությունը օրինակից կամ պատից ներս և դուրս:
- Ծառայության բացահայտում. Երբ օրինակը պետք է շփվի մեկ այլ ծառայության հետ, նա պետք է գտնի (բացահայտի) մյուս ծառայության առողջ և հասանելի օրինակը: Սովորաբար, օրինակը կատարում է DNS որոնումներ: Կոնտեյներների կազմակերպման շրջանակը պահպանում է այն դեպքերի ցանկը, որոնք պատրաստ են հարցումներ ընդունելու և տրամադրում է միջերես DNS հարցումների համար:
- Բեռների հավասարակշռում. Կոնտեյներների նվագախմբային շրջանակների մեծ մասը ապահովում է բեռի հավասարակշռում 4-րդ շերտում (տրանսպորտ): Service Mesh-ն իրականացնում է ավելի բարդ բեռների հավասարակշռում 7-րդ շերտում (կիրառման մակարդակ), որը հարուստ է ալգորիթմներով և ավելի արդյունավետ երթևեկության կառավարման համար: Բեռնվածության հավասարակշռման կարգավորումները կարող են փոխվել API-ի միջոցով՝ թույլ տալով կազմակերպել կապույտ-կանաչ կամ դեղձանիկի տեղակայումները:
- Կոդավորումը. Service Mesh-ը կարող է գաղտնագրել և վերծանել հարցումներն ու պատասխանները՝ հեռացնելով այդ բեռը ծառայություններից: Service Mesh-ը կարող է նաև բարելավել աշխատանքը՝ առաջնահերթություն տալով կամ վերօգտագործելով գոյություն ունեցող մշտական կապերը՝ նվազեցնելով նոր կապեր ստեղծելու համար թանկարժեք հաշվարկների անհրաժեշտությունը: Երթևեկության կոդավորման ամենատարածված իրականացումն է փոխադարձ TLS (mTLS), որտեղ հանրային բանալին ենթակառուցվածքը (PKI) ստեղծում և բաշխում է վկայագրեր և բանալիներ՝ Sidecar Proxy-ի կողմից օգտագործելու համար:
- Նույնականացում և լիազորում. Ծառայության ցանցը կարող է լիազորել և վավերացնել հավելվածի դրսից կամ ներսից արված հարցումները՝ ուղարկելով միայն վավերացված հարցումներ օրինակներին:
- Ավտոմատ անջատման օրինակի աջակցություն. Ծառայության ցանցը աջակցում է , որը մեկուսացնում է անառողջ դեպքերը և այնուհետև անհրաժեշտության դեպքում աստիճանաբար դրանք վերադարձնում առողջ դեպքերի ավազան։
Service Mesh հավելվածի այն մասը, որը կառավարում է ցանցային տրաֆիկը օրինակների միջև, կոչվում է Տվյալների հարթություն. Ստեղծեք և գործարկեք կոնֆիգուրացիա, որը վերահսկում է վարքը Տվյալների հարթություն, կատարվում է առանձին օգտագործելով Կառավարման ինքնաթիռ. Կառավարման ինքնաթիռ սովորաբար ներառում է կամ նախատեսված է API-ին, CLI-ին կամ GUI-ին միանալու համար՝ հավելվածը կառավարելու համար:
Կառավարման հարթությունը ծառայության ցանցում բաշխում է կոնֆիգուրացիան Sidecar Proxy-ի և Data Plane-ի միջև:
Service Mesh ճարտարապետությունը հաճախ օգտագործվում է բարդ գործառնական խնդիրներ լուծելու համար՝ օգտագործելով կոնտեյներներ և միկրոծառայություններ: Պիոներներ ոլորտում այնպիսի ընկերություններ են, ինչպիսիք են Lyft-ը, Netflix-ը և Twitter-ը, որոնք կայուն ծառայություններ են մատուցում միլիոնավոր օգտատերերի ամբողջ աշխարհում: () Ավելի քիչ պահանջկոտ ծրագրերի համար, հավանաբար, ավելի պարզ ճարտարապետությունը բավական կլինի:
Ծառայության ցանցի ճարտարապետությունը դժվար թե երբևէ լինի հավելվածի շահագործման և առաքման բոլոր խնդիրների պատասխանը: Ճարտարապետներն ու մշակողները գործիքների հսկայական զինանոց ունեն, և դրանցից միայն մեկն է մուրճը, որը, ի թիվս բազմաթիվ խնդիրների, պետք է լուծի միայն մեկը՝ մեխերը մուրճը: Օրինակ, ներառում է մի քանի տարբեր մոդելներ, որոնք ապահովում են միկրոծառայությունների միջոցով խնդիրների լուծման մոտեցումների շարունակականություն:
Այն տարրերը, որոնք միավորվում են Service Mesh ճարտարապետության մեջ, ինչպիսիք են NGINX-ը, կոնտեյներները, Kubernetes-ը և միկրոսերվիսները որպես ճարտարապետական մոտեցում, կարող են հավասարապես արդյունավետ լինել ոչ ծառայողական ցանցի ներդրումներում: Օրինակ, Istio-ն նախագծվել է որպես ամբողջական սպասարկման ցանցային ճարտարապետություն, սակայն դրա մոդուլյարությունը նշանակում է, որ մշակողները կարող են ընտրել և իրականացնել միայն իրենց անհրաժեշտ տեխնոլոգիական բաղադրիչները: Սա նկատի ունենալով, կարևոր է հստակ պատկերացում կազմել Service Mesh-ի հայեցակարգի մասին, նույնիսկ եթե վստահ չեք, որ երբևէ կկարողանաք ամբողջությամբ կիրառել այն ձեր հավելվածում:
Source: www.habr.com