Համացանցում կուչա Հոդվածներ о սպասարկման ցանց (սպասարկման ցանց), և ահա ևս մեկը: Ուռա՜ Բայց ինչու? Այնուհետև ես ուզում եմ իմ կարծիքը հայտնել, որ ավելի լավ կլիներ, եթե սպասարկման ցանցերը հայտնվեին 10 տարի առաջ, մինչև բեռնարկղային հարթակների հայտնվելը, ինչպիսիք են Docker-ը և Kubernetes-ը: Ես չեմ ասում, որ իմ տեսակետն ավելի լավն է կամ վատը, քան մյուսները, բայց քանի որ սպասարկման ցանցերը բավականին բարդ կենդանիներ են, բազմաթիվ տեսակետներ կօգնեն ավելի լավ հասկանալ դրանք:

Ես կխոսեմ dotCloud պլատֆորմի մասին, որը ստեղծվել է ավելի քան հարյուր միկրոծառայությունների վրա և աջակցում է հազարավոր կոնտեյներային հավելվածների: Ես կբացատրեմ այն ​​մարտահրավերները, որոնց բախվել ենք այն մշակելիս և գործարկելիս, և թե ինչպես կարող են (կամ չեն կարող) օգնել սպասարկման ցանցերը:

dotCloud-ի պատմություն

Ես գրել եմ dotCloud-ի պատմության և այս հարթակի ճարտարապետության ընտրության մասին, բայց շատ չեմ խոսել ցանցային շերտի մասին: Եթե ​​դուք չեք ցանկանում սուզվել ընթերցանության մեջ վերջին հոդվածը dotCloud-ի մասին, ահա հիմնականը հակիրճ. դա PaaS հարթակ է որպես ծառայություն, որը թույլ է տալիս հաճախորդներին գործարկել հավելվածների լայն շրջանակ (Java, PHP, Python...), տվյալների լայն շրջանակի աջակցությամբ: ծառայություններ (MongoDB, MySQL, Redis...) և Հերոկուի նման աշխատանքային հոսք.

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

Հոսթավորված հավելվածների երթևեկության երթուղիավորում

DotCloud-ի հավելվածները կարող են բացահայտել HTTP և TCP վերջնակետերը:

HTTP վերջնակետեր դինամիկ կերպով ավելացվել է բեռի հավասարակշռման կլաստերի կազմաձևին Հիպաչե. Սա նման է նրան, ինչ այսօր անում են ռեսուրսները Մուտք Kubernetes-ում և բեռի հավասարակշռման նման Թրաեֆիկ.

Հաճախորդները միանում են HTTP վերջնակետերին համապատասխան տիրույթների միջոցով, պայմանով, որ տիրույթի անունը մատնանշում է dotCloud բեռների հավասարակշռողներին: Առանձնապես ոչինչ.

TCP վերջնակետեր կապված պորտի համարի հետ, որն այնուհետև փոխանցվում է այդ փաթեթի բոլոր կոնտեյներներին՝ շրջակա միջավայրի փոփոխականների միջոցով:

Հաճախորդները կարող են միանալ TCP վերջնակետերին՝ օգտագործելով համապատասխան հոսթի անունը (ինչ-որ բան, ինչպիսին է gateway-X.dotcloud.com) և պորտի համարը:

Այս հոսթի անունը վերաբերվում է «nats» սերվերի կլաստերին (կապված չէ NATS), որը մուտքային TCP կապերը կուղղորդի դեպի ճիշտ կոնտեյներ (կամ, բեռի հավասարակշռված ծառայությունների դեպքում՝ դեպի ճիշտ կոնտեյներներ):

Եթե ​​դուք ծանոթ եք Kubernetes-ին, ապա սա ձեզ հավանաբար կհիշեցնի Ծառայությունների մասին NodePort.

DotCloud հարթակում համարժեք ծառայություններ չկային ClusterIPՊարզության համար ծառայություններին հասանելի էին նույն կերպ ինչպես հարթակի ներսից, այնպես էլ դրսից:

Ամեն ինչ կազմակերպված էր բավականին պարզ. HTTP և TCP երթուղիչ ցանցերի սկզբնական ներդրումը հավանաբար ընդամենը մի քանի հարյուր տող էր Python-ից յուրաքանչյուրը: Պարզ (ես կասեի՝ միամիտ) ալգորիթմներ, որոնք կատարելագործվեցին, քանի որ հարթակը մեծացավ և հայտնվեցին լրացուցիչ պահանջներ։

Գոյություն ունեցող կոդի լայնածավալ վերամշակում չի պահանջվում: Մասնավորապես, 12 գործոնային հավելվածներ կարող է ուղղակիորեն օգտագործել շրջակա միջավայրի փոփոխականների միջոցով ստացված հասցեն:

Ինչո՞վ է սա տարբերվում ժամանակակից սպասարկման ցանցից:

Սահմանափակ տեսանելիությունը. TCP երթուղային ցանցի համար մենք ընդհանրապես չափումներ չունեինք: Ինչ վերաբերում է HTTP երթուղղմանը, ավելի ուշ տարբերակները ներկայացրեցին մանրամասն HTTP չափումներ՝ սխալի կոդերով և արձագանքման ժամանակներով, սակայն ժամանակակից սպասարկման ցանցերն ավելի հեռուն են գնում՝ ապահովելով ինտեգրում չափումների հավաքագրման համակարգերի հետ, օրինակ՝ Պրոմեթևսը:

Տեսանելիությունը կարևոր է ոչ միայն գործառնական տեսանկյունից (խնդիրները լուծելու համար), այլև նոր գործառույթներ թողարկելու ժամանակ: Խոսքն ապահովի մասին է կապույտ-կանաչ տեղակայում и դեղձանիկի տեղակայում.

Երթուղիների արդյունավետություն նույնպես սահմանափակ է։ DotCloud երթուղային ցանցում ամբողջ տրաֆիկը պետք է անցներ հատուկ երթուղային հանգույցների կլաստերով: Սա նշանակում էր հնարավոր հատել AZ-ի (Հասանելիության գոտի) մի քանի սահմանները և զգալիորեն մեծացնել ուշացումը: Ես հիշում եմ անսարքությունների վերացման կոդը, որը յուրաքանչյուր էջի վրա հարյուրից ավելի SQL հարցումներ էր կատարում և յուրաքանչյուր հարցման համար նոր կապ բացում SQL սերվերի հետ: Տեղական աշխատանքի ժամանակ էջը բեռնվում է ակնթարթորեն, բայց dotCloud-ում բեռնումը տևում է մի քանի վայրկյան, քանի որ յուրաքանչյուր TCP միացում (և հետագա SQL հարցում) տևում է տասնյակ միլիվայրկյաններ: Կոնկրետ այս դեպքում մշտական ​​կապերը լուծեցին խնդիրը։

Ժամանակակից սպասարկման ցանցերն ավելի լավ են լուծում նման խնդիրներին: Առաջին հերթին նրանք ստուգում են, որ կապերը ուղղորդված են սկզբնաղբյուրում. Տրամաբանական հոսքը նույնն է. клиент → меш → сервис, բայց այժմ ցանցը աշխատում է տեղական և ոչ հեռավոր հանգույցների վրա, ուստի կապը клиент → меш տեղական է և շատ արագ (միկրովայրկյան՝ միլիվայրկյանների փոխարեն):

Ժամանակակից սպասարկման ցանցերը նաև կիրառում են բեռի հավասարակշռման ավելի խելացի ալգորիթմներ: Մշտադիտարկելով հետին պլանների առողջությունը՝ նրանք կարող են ավելի շատ տրաֆիկ ուղարկել ավելի արագ հետին պլաններ, ինչը հանգեցնում է ընդհանուր կատարողականի բարելավմանը:

Безопасность ավելի լավ էլ. DotCloud երթուղային ցանցն ամբողջությամբ աշխատում էր EC2 Classic-ով և չէր գաղտնագրում երթևեկությունը (հիմնվելով այն ենթադրության վրա, որ եթե ինչ-որ մեկին հաջողվի EC2 ցանցի երթևեկության վրա տեղադրել sniffer, դուք արդեն մեծ դժվարությունների մեջ էիք): Ժամանակակից սպասարկման ցանցերը թափանցիկորեն պաշտպանում են մեր ողջ երթևեկությունը, օրինակ՝ փոխադարձ TLS նույնականացման և հետագա գաղտնագրման միջոցով:

Երթուղիների երթուղիներ հարթակի ծառայությունների համար

Լավ, մենք քննարկել ենք երթևեկությունը հավելվածների միջև, բայց ինչ վերաբերում է հենց dotCloud պլատֆորմին:

Պլատֆորմն ինքնին բաղկացած էր մոտ հարյուր միկրոսերվիսներից, որոնք պատասխանատու էին տարբեր գործառույթների համար։ Ոմանք ընդունում էին մյուսների հարցումները, իսկ ոմանք նախկինում աշխատող աշխատողներ էին, որոնք միացել էին այլ ծառայություններին, բայց իրենք չէին ընդունում կապերը: Ամեն դեպքում, յուրաքանչյուր ծառայություն պետք է իմանա այն հասցեների վերջնակետերը, որոնց պետք է միանա:

Շատ բարձր մակարդակի ծառայություններ կարող են օգտագործել վերը նկարագրված երթուղային ցանցը: Փաստորեն, dotCloud-ի հարյուրից ավելի միկրոծառայություններից շատերը տեղակայվել են որպես կանոնավոր հավելվածներ հենց dotCloud հարթակում: Սակայն ցածր մակարդակի ծառայությունների մի փոքր մասը (հատկապես նրանք, որոնք իրականացնում են այս երթուղային ցանցը) ավելի պարզ բանի կարիք ուներ՝ ավելի քիչ կախվածություններով (քանի որ նրանք չէին կարող իրենց վրա կախված աշխատել. հին լավ հավի և ձվի խնդիրը):

Այս ցածր մակարդակի, առաքելության համար կարևոր ծառայությունները տեղակայվել են կոնտեյներների միջոցով ուղղակիորեն մի քանի հիմնական հանգույցների վրա: Այս դեպքում ստանդարտ հարթակի ծառայություններ չեն օգտագործվել՝ կապող, ժամանակացույց և վազող։ Եթե ​​ցանկանում եք համեմատվել ժամանակակից կոնտեյներային հարթակների հետ, ապա դա նման է կառավարման ինքնաթիռին docker run ուղղակիորեն հանգույցների վրա՝ առաջադրանքը Kubernetes-ին պատվիրակելու փոխարեն: Դա բավականին նման է հայեցակարգով ստատիկ մոդուլներ (pods), որն օգտագործում է kubeadm կամ bootkube ինքնուրույն կլաստեր բեռնելիս:

Այս ծառայությունները բացահայտվեցին պարզ և կոպիտ ձևով. YAML ֆայլում նշված էին նրանց անուններն ու հասցեները. և յուրաքանչյուր հաճախորդ պետք է վերցներ այս YAML ֆայլի պատճենը տեղակայման համար:

Մի կողմից, այն չափազանց հուսալի է, քանի որ այն չի պահանջում արտաքին բանալիների/արժեքների պահեստի աջակցություն, ինչպիսին Zookeeper-ն է (հիշեք, և այլն կամ Consul այն ժամանակ գոյություն չունեին): Մյուս կողմից՝ դժվարացնում էր ծառայությունների տեղափոխումը։ Ամեն անգամ, երբ որևէ քայլ կատարվեր, բոլոր հաճախորդները կստանան թարմացված YAML ֆայլ (և հնարավոր է վերագործարկվեն): Ոչ շատ հարմարավետ!

Այնուհետև մենք սկսեցինք իրականացնել նոր սխեմա, որտեղ յուրաքանչյուր հաճախորդ միանում էր տեղական պրոքսի սերվերին: Հասցեի և պորտի փոխարեն պետք է միայն իմանալ ծառայության պորտի համարը և միանալ միջոցով localhost. Տեղական վստահված անձը կարգավորում է այս կապը և այն փոխանցում է իրական սերվերին: Այժմ, երբ հետնամասը տեղափոխում եք մեկ այլ մեքենա կամ մասշտաբում, բոլոր հաճախորդները թարմացնելու փոխարեն, ձեզ հարկավոր է միայն թարմացնել այս բոլոր տեղական վստահվածները. և վերագործարկումն այլևս չի պահանջվում:

(Նախատեսվում էր նաև ընդգրկել երթևեկությունը TLS կապերում և տեղադրել այլ պրոքսի սերվեր ստացող կողմում, ինչպես նաև ստուգել TLS վկայականները առանց ստացող ծառայության մասնակցության, որը կազմաձևված է միացումներ ընդունել միայն localhost. Այս մասին ավելի ուշ):

Սա շատ նման է SmartStack Airbnb-ից, սակայն էական տարբերությունն այն է, որ SmartStack-ը ներդրվում և տեղադրվում է արտադրության մեջ, մինչդեռ dotCloud-ի ներքին երթուղային համակարգը դադարեցվել է, երբ dotCloud-ը դարձավ Docker:

Ես անձամբ SmartStack-ը համարում եմ Istio-ի, Linkerd-ի և Consul Connect-ի նման համակարգերի նախորդներից մեկը, քանի որ դրանք բոլորն էլ հետևում են նույն օրինակին.

• Գործարկեք վստահված անձ յուրաքանչյուր հանգույցի վրա:
• Հաճախորդները միանում են վստահված անձին:
• Կառավարման հարթությունը թարմացնում է պրոքսիի կոնֆիգուրացիան, երբ հետին պլանները փոխվում են:
• ... Շահույթ!

Սպասարկման ցանցի ժամանակակից ներդրում

Եթե ​​այսօր մեզ անհրաժեշտ լիներ նմանատիպ ցանց իրականացնել, մենք կարող էինք կիրառել նմանատիպ սկզբունքներ: Օրինակ, կարգավորեք ներքին DNS գոտին՝ քարտեզագրելով ծառայությունների անունները տարածության հասցեներին 127.0.0.0/8. Այնուհետև գործարկեք HAProxy-ը կլաստերի յուրաքանչյուր հանգույցի վրա՝ ընդունելով կապեր յուրաքանչյուր ծառայության հասցեով (այդ ենթացանցում 127.0.0.0/8) և բեռը վերահղելով/հավասարակշռելով համապատասխան հետին մասեր: HAProxy-ի կոնֆիգուրացիան կարող է վերահսկվել confd, որը թույլ է տալիս Ձեզ պահել backend-ի տեղեկատվությունը etcd-ում կամ Consul-ում և անհրաժեշտության դեպքում ավտոմատ կերպով նորացված կոնֆիգուրացիան տեղափոխել HAProxy:

Istio-ն մոտավորապես այսպես է աշխատում: Բայց որոշ տարբերություններով.

• Օգտագործումներ Բանագնաց վստահված անձ HAProxy-ի փոխարեն:
• Պահպանում է backend-ի կոնֆիգուրացիան Kubernetes API-ի միջոցով etcd-ի կամ Consul-ի փոխարեն:
• Ծառայություններին տրամադրվում են հասցեներ ներքին ենթացանցում (Kubernetes ClusterIP հասցեներ)՝ 127.0.0.0/8-ի փոխարեն:
• Ունի լրացուցիչ բաղադրիչ (Citadel)՝ հաճախորդի և սերվերների միջև փոխադարձ TLS վավերացում ավելացնելու համար:
• Աջակցում է նոր հնարավորություններ, ինչպիսիք են միացումների անջատումը, բաշխված հետագծումը, դեղձանիկների տեղակայումը և այլն:

Եկեք արագ նայենք որոշ տարբերություններին:

Բանագնաց վստահված անձ

Envoy Proxy-ը գրել է Lyft-ը [Uber-ի մրցակիցը տաքսիների շուկայում՝ մոտ. գոտի]: Այն շատ առումներով նման է այլ պրոքսիներին (օրինակ՝ HAProxy, Nginx, Traefik...), բայց Lyft-ը գրել է իրենցը, քանի որ նրանց պետք էին այնպիսի հնարավորություններ, որոնք բացակայում էին մյուս պրոքսիներից, և ավելի խելացի էր թվում նորը ստեղծելը, քան գոյություն ունեցողը երկարաձգելը:

Պատգամավորը կարող է օգտագործվել ինքնուրույն: Եթե ​​ես ունեմ կոնկրետ ծառայություն, որը պետք է միանա այլ ծառայությունների, ես կարող եմ կարգավորել այն, որպեսզի միանա Envoy-ին, այնուհետև դինամիկ կարգավորել և վերակազմավորել Envoy-ը այլ ծառայությունների գտնվելու վայրի հետ՝ միաժամանակ ստանալով շատ մեծ լրացուցիչ գործառույթներ, ինչպիսիք են տեսանելիությունը: Հաճախորդի հատուկ գրադարանի կամ կոդի մեջ զանգերի հետքեր ներարկելու փոխարեն, մենք ուղարկում ենք երթևեկություն Envoy-ին, և նա մեզ համար չափումներ է հավաքում:

Բայց բանագնացը նույնպես ընդունակ է աշխատել որպես տվյալների հարթություն (տվյալների հարթություն) սպասարկման ցանցի համար: Սա նշանակում է, որ Envoy-ն այժմ կազմաձևված է այս ծառայության ցանցի համար կառավարման ինքնաթիռ (կառավարման հարթություն):

Կառավարման ինքնաթիռ

Կառավարման ինքնաթիռի համար Istio-ն հենվում է Kubernetes API-ի վրա: Սա շատ չի տարբերվում confd-ի օգտագործումից, որը հիմնված է etcd-ի կամ Consul-ի վրա՝ տվյալների պահեստում ստեղների հավաքածուն դիտելու համար: Istio-ն օգտագործում է Kubernetes API-ը՝ Kubernetes-ի ռեսուրսների մի շարք դիտելու համար:

Այս և այն ժամանակվա միջևԱնձամբ ես սա օգտակար գտա Kubernetes API-ի նկարագրությունորը կարդում է.

Kubernetes API սերվերը «համր սերվեր» է, որն առաջարկում է պահեստավորում, տարբերակում, վավերացում, թարմացում և իմաստաբանություն API ռեսուրսների համար:

Istio-ն նախատեսված է Kubernetes-ի հետ աշխատելու համար; և եթե ցանկանում եք այն օգտագործել Kubernetes-ից դուրս, ապա պետք է գործարկեք Kubernetes API սերվերի (և etcd օգնական ծառայության) օրինակ:

Ծառայությունների հասցեները

Istio-ն հենվում է ClusterIP հասցեների վրա, որոնք հատկացնում է Kubernetes-ը, ուստի Istio ծառայությունները ստանում են ներքին հասցե (ոչ տիրույթում 127.0.0.0/8).

Առանց Istio-ի Kubernetes կլաստերի հատուկ ծառայության ClusterIP հասցեի երթևեկությունը կալանվում է kube-proxy-ի կողմից և ուղարկվում է այդ վստահված անձի հետադարձ կապ: Եթե ​​ձեզ հետաքրքրում են տեխնիկական մանրամասները, ապա kube-proxy-ը սահմանում է iptables կանոնները (կամ IPVS բեռնվածության հավասարակշռիչներ՝ կախված այն բանից, թե ինչպես է այն կազմաձևված)՝ ClusterIP հասցե գնացող կապերի նպատակային IP հասցեները վերագրելու համար:

Երբ Istio-ն տեղադրվի Kubernetes կլաստերի վրա, ոչինչ չի փոխվում, քանի դեռ այն հստակորեն միացված չէ տվյալ սպառողի կամ նույնիսկ ամբողջ անվանատարածքի համար՝ ներմուծելով կոնտեյներ: sidecar մաքսային պատյանների մեջ: Այս կոնտեյները կվերածի Envoy-ի օրինակը և կսահմանի iptables կանոնների մի շարք՝ այլ ծառայություններ գնացող երթևեկությունը կասեցնելու և այդ երթևեկությունը Envoy-ին վերահղելու համար:

Երբ ինտեգրված է Kubernetes DNS-ին, դա նշանակում է, որ մեր կոդը կարող է միանալ ծառայության անունով և ամեն ինչ «ուղղակի աշխատում է»: Այլ կերպ ասած, մեր կոդը հարցեր է տալիս, ինչպիսիք են http://api/v1/users/4242ապա api լուծել հարցումը 10.97.105.48, iptables-ի կանոնները կխոչընդոտեն կապերը 10.97.105.48-ից և կուղարկեն դրանք տեղական Envoy վստահված անձին, և այդ տեղական վստահված անձը հարցումը կուղարկի իրական backend API-ին: Ֆու՜

Լրացուցիչ նրբերանգներ

Istio-ն նաև տրամադրում է ծայրից ծայր կոդավորում և նույնականացում mTLS-ի միջոցով (փոխադարձ TLS): Բաղադրիչ, որը կոչվում է Միջնաբերդ.

Կա նաև բաղադրիչ Խառնիչ, որը Բանագնացը կարող է խնդրել յուրաքանչյուր խնդրում ենք այդ հարցման վերաբերյալ հատուկ որոշում կայացնել՝ կախված տարբեր գործոններից, ինչպիսիք են վերնագրերը, հետևի բեռնվածությունը և այլն... (մի անհանգստացեք. Mixer-ը գործարկելու շատ եղանակներ կան, և նույնիսկ եթե այն խափանվի, Envoy-ը կշարունակի աշխատել տուգանք որպես վստահված անձ):

Եվ, իհարկե, մենք նշեցինք տեսանելիությունը. Envoy-ը հավաքում է հսկայական չափումներ՝ միաժամանակ տրամադրելով բաշխված հետագծում: Միկրոծառայությունների ճարտարապետության մեջ, եթե API-ի մեկ հարցումը պետք է անցնի A, B, C և D միկրոծառայությունների միջով, ապա մուտք գործելիս բաշխված հետագծումը կավելացնի հարցումին եզակի նույնացուցիչ և կպահի այս նույնացուցիչը ենթախնդրանքների միջոցով այս բոլոր միկրոծառայությունների համար՝ թույլ տալով. բոլոր առնչվող զանգերը պետք է ֆիքսվեն, ուշացումները և այլն:

Մշակել կամ գնել

Իստիոն բարդույթավոր լինելու համբավ ունի: Ի հակադրություն, երթուղային ցանցի կառուցումը, որը ես նկարագրեցի այս գրառման սկզբում, համեմատաբար պարզ է՝ օգտագործելով գոյություն ունեցող գործիքները: Այսպիսով, իմաստ ունի՞ փոխարենը ստեղծել ձեր սեփական սպասարկման ցանցը:

Եթե ​​մենք ունենք համեստ կարիքներ (մեզ պետք չէ տեսանելիություն, անջատիչ և այլ նրբություններ), ապա մտքերը գալիս են մեր սեփական գործիքը մշակելու մասին: Բայց եթե մենք օգտագործում ենք Kubernetes-ը, դա կարող է նույնիսկ անհրաժեշտ չլինել, քանի որ Kubernetes-ն արդեն տրամադրում է հիմնական գործիքներ՝ ծառայության հայտնաբերման և բեռի հավասարակշռման համար:

Բայց եթե մենք ունենք առաջադեմ պահանջներ, ապա սպասարկման ցանց «գնելն» ավելի լավ տարբերակ է թվում: (Սա միշտ չէ, որ «գնել» է, քանի որ Istio-ն բաց կոդով է, բայց մենք դեռ պետք է ինժեներական ժամանակ ներդնենք՝ այն հասկանալու, տեղակայելու և կառավարելու համար:)

Արդյո՞ք պետք է ընտրեմ Istio, Linkerd կամ Consul Connect:

Մինչ այժմ մենք խոսել ենք միայն Istio-ի մասին, բայց սա միակ սպասարկման ցանցը չէ: Հանրաճանաչ այլընտրանք - Linkerd, և կա ավելին Հյուպատոս Կապ.

Ինչ է ընտրել:

Անկեղծ ասած՝ չգիտեմ։ Այս պահին ես ինձ բավարար կոմպետենտ չեմ համարում այս հարցին պատասխանելու համար։ Կան մի քանիսը հետաքրքիր է Հոդվածներ այս գործիքների համեմատությամբ և նույնիսկ հենանիշներ.

Խոստումնալից մոտեցումներից մեկը նման գործիք օգտագործելն է SuperGloo. Այն իրականացնում է աբստրակցիոն շերտ՝ ծառայության ցանցերով բացահայտված API-ները պարզեցնելու և միավորելու համար: Տարբեր սպասարկման ցանցերի հատուկ (և, իմ կարծիքով, համեմատաբար բարդ) API-ները սովորելու փոխարեն, մենք կարող ենք օգտագործել SuperGloo-ի ավելի պարզ կառուցվածքները և հեշտությամբ անցնել մեկից մյուսին, ասես ունենք միջանկյալ կազմաձևման ձևաչափ, որը նկարագրում է HTTP ինտերֆեյսները և հետադարձ կապերը, որոնք ունակ են: Nginx-ի, HAProxy-ի, Traefik-ի, Apache-ի համար իրական կոնֆիգուրացիան ստեղծելու համար:

Ես մի փոքր շփվել եմ Istio-ի և SuperGloo-ի հետ, և հաջորդ հոդվածում ուզում եմ ցույց տալ, թե ինչպես ավելացնել Istio կամ Linkerd գոյություն ունեցող կլաստերին՝ օգտագործելով SuperGloo-ն, և ինչպես է վերջինս կատարում աշխատանքը, այսինքն՝ թույլ է տալիս անցնել մի ծառայության ցանցը մյուսին առանց կոնֆիգուրացիաների վերագրման:

Source: www.habr.com