Նշում. թարգմ.Այս հոդվածի հեղինակը (Լյուկ Պերկինս) CNCF-ում մշակողների կողմնակից է, որը զբաղվում է այնպիսի բաց կոդով նախագծերով, ինչպիսիք են Linkerd-ը, SMI-ն (Service Mesh Interface) և Kuma-ն (ի դեպ, դուք էլ մտածե՞լ եք, թե ինչու Istio-ն այս ցանկում չէ։..): DevOps համայնքում «ծառայության ցանց» անվանումով նորաձև աղմուկը ավելի լավ հասկանալու մեկ այլ փորձ կատարելով՝ նա թվարկում է նման լուծումների 16 բնորոշ հնարավորություններ:
Այսօր ― ծրագրային ապահովման ճարտարագիտության ամենատաք թեմաներից մեկն է (և իրավացիորեն)։ Կարծում եմ՝ սա աներևակայելիորեն խոստումնալից տեխնոլոգիա է, և երազում եմ տեսնել դրա լայնորեն կիրառումը (երբ, իհարկե, իմաստ ունի)։ Այնուամենայնիվ, այն դեռևս առեղծվածի մի երանգ ունի մարդկանց մեծամասնության համար։ Նույնիսկ նրանք, ովքեր Ես նրան լավ եմ ճանաչում դրա հետ մեկտեղ, հաճախ դժվարանում են ձևակերպել դրա առավելությունները և թե ինչն է այն իրականում (ներառյալ ձեր խոնարհ ծառան): Այս հոդվածում ես կփորձեմ շտկել իրավիճակը՝ թվարկելով տարբեր օգտագործման սցենարներ «սպասարկման ցանցեր»*։
* Թարգմանչի նշում. այս հոդվածում այս թարգմանությունը («ծառայության ցանց») կօգտագործվի դեռևս նոր «ծառայության ցանց» տերմինի համար։
Բայց նախ ուզում եմ մի քանի մեկնաբանություն անել.
- Ես երբեք չեմ աշխատել կամ չեմ օգտագործել ծառայությունների ցանցեր՝ իմ սեփական կրթության համար իրականացված նախագծերից դուրս։ Մյուս կողմից, ես 2015 թվականին գրել եմ բազմաթիվ փաստաթղթեր Twitter-ի ներքին ծառայությունների ցանցի համար (այն ժամանակ այն նույնիսկ «ծառայության ցանց» չէր կոչվում) և ներդրում եմ ունեցել կայքի և փաստաթղթերի ստեղծման գործում։ , ուրեմն դա ինչ-որ բան է նշանակում։
- Իմ ցանկը նախնական է և թերի։ Հավանական է, որ կլինեն օգտագործման դեպքեր, որոնց մասին ես տեղյակ չեմ, և ժամանակի ընթացքում, տեխնոլոգիայի զարգացման և ավելի տարածված դառնալուն զուգընթաց, հավանաբար, կհայտնվեն նորերը։
- Միևնույն ժամանակ, ոչ բոլոր առկա service mesh իրականացումներն են աջակցում թվարկված բոլոր օգտագործման դեպքերին: Հետևաբար, իմ «service mesh-ը կարող է…» նման արտահայտությունները պետք է կարդալ որպես «որոշ, և գուցե բոլոր հայտնի service mesh իրականացումները կարող են…»:
- Օրինակների հերթականությունը նշանակություն չունի։
Կարճ ցուցակ.
- ծառայության հայտնաբերում;
- գաղտնագրում;
- նույնականացում և լիազորում;
- բեռի հավասարակշռում;
- շղթայի խափանում;
- ավտոմատ մասշտաբավորում;
- կանարյան տեղակայումներ;
- կապույտ-կանաչ տեղակայումներ;
- առողջության ստուգում;
- բեռի հեռացում;
- երթևեկության արտացոլում;
- մեկուսացում;
- հարցումների հաճախականության սահմանափակում, կրկնվող փորձեր և ժամկետանց ժամանակահատվածներ;
- հեռաչափություն;
- աուդիտ;
- վիզուալիզացիա։
1. Ծառայության հայտնաբերում
TL;DR: Միացեք ցանցի այլ ծառայություններին՝ օգտագործելով պարզ անուններ:
Ծառայությունները պետք է կարողանան ավտոմատ կերպով «գտնել» միմյանց՝ օգտագործելով համապատասխան անուններ, ինչպիսիք են՝ service.api.production, pets/staging կամ cassandraԱմպային միջավայրերը բնութագրվում են իրենց առաձգականությամբ, և մեկ անունը կարող է թաքցնել բազմաթիվ ծառայության օրինակներ։ Ակնհայտ է, որ նման իրավիճակում ֆիզիկապես անհնար է կոշտ կոդավորել բոլոր IP հասցեները։
Բացի այդ, երբ մեկ ծառայությունը գտնում է մեկ այլ ծառայություն, այն պետք է կարողանա հարցումներ ուղարկել այդ ծառայությանը՝ առանց վախենալու, որ դրանք կհայտնվեն իր չաշխատող օրինակի մուտքի մոտ։ Այլ կերպ ասած, ծառայության ցանցը պետք է վերահսկի բոլոր ծառայության օրինակների առողջությունը և հնարավորինս թարմացնի հոսթերի ցանկը։
Յուրաքանչյուր ծառայության ցանց տարբեր կերպ է իրականացնում ծառայության հայտնաբերումը։ Ներկայումս ամենատարածված ձևը արտաքին գործընթացներին, ինչպիսին է Kubernetes DNS-ը, լիազորելն է։ Անցյալում Twitter-ում մենք այս նպատակով օգտագործում էինք անունների համակարգ։ Բացի այդ, ծառայությունների ցանցային տեխնոլոգիան հնարավորություն է տալիս ստեղծել անվանակոչման մեխանիզմներ (չնայած ես դեռ չեմ հանդիպել նման ֆունկցիոնալությամբ որևէ SM իրականացման):
2. Գաղտնագրում
TL;DR: Ազատվեք ծառայությունների միջև չգաղտնագրված երթևեկությունից և դարձրեք այս գործընթացը ավտոմատացված և մասշտաբային։
Հաճելի է իմանալ, որ հարձակվողները չեն կարող մուտք գործել ձեր ներքին ցանց: Firewall-ները հիանալի աշխատանք են կատարում դա կանխելու համար: Բայց ի՞նչ է պատահում, եթե հաքերը ներխուժի: Արդյո՞ք նրանք կկարողանան անել այն, ինչ ուզում են ներքին երթևեկության հետ: Հուսանք, որ դա տեղի չի ունենա: Նման սցենարը կանխելու համար դուք պետք է ներդնեք զրոյական վստահության ցանց, որտեղ ծառայությունների միջև ամբողջ երթևեկությունը կոդավորված է: Ժամանակակից ծառայությունների ցանցերի մեծ մասը դա հասնում է փոխադարձ կապի միջոցով: (փոխադարձ TLS, mTLS): Որոշ դեպքերում mTLS-ը գործում է ամբողջական ամպերում և կլաստերներում (կարծում եմ՝ միջմոլորակային հաղորդակցությունները մի օր կկազմակերպվեն նմանատիպ կերպ):
Իհարկե, mTLS ծառայության ցանցի համար ըստ ցանկությանՅուրաքանչյուր ծառայություն կարող է հոգ տանել իր սեփական TLS-ի մասին, բայց դա նշանակում է գտնել միջոց՝ վկայագրեր ստեղծելու, դրանք ծառայության հոսթերի միջև բաշխելու, ծրագրում կոդ ներառելու համար, որը կբեռնի այս վկայագրերը ֆայլերից: Այո, և մի մոռացեք պարբերաբար թարմացնել այս վկայագրերը: Ծառայության ցանցերը ավտոմատացնում են mTLS-ը այնպիսի համակարգերի միջոցով, ինչպիսիք են՝ , որոնք, իրենց հերթին, ավտոմատացնում են վկայականների տրամադրման և ռոտացիայի գործընթացը։
3. Նույնականացում և լիազորում
TL;DR: Պարզեք, թե ով է նախաձեռնում հարցումը և ինչ են նրանք իրավունք ունեն անել նախքան հարցումը ծառայությանը հասնելը։
Ծառայությունները հաճախ ցանկանում են իմանալ, ով կատարում է հարցում (նույնականացում) և, օգտագործելով այս տեղեկատվությունը, որոշում է որ այս ենթակային թույլատրվում է անել (հավաստագրում): Այս դեպքում «ով» դերանունը կարող է թաքցնել.
- Այլ ծառայություններ։ Սա կոչվում է «հավաստագրում» պիր«Օրինակ՝ ծառայություն
webցանկանում է մուտք գործել ծառայությանըdbԾառայողական ցանցերը սովորաբար լուծում են նման խնդիրները՝ օգտագործելով mTLS. այս դեպքում վկայագրերը հանդես են գալիս որպես անհրաժեշտ նույնականացուցիչ։ - Որոշ մարդկային օգտատերեր։ Սա կոչվում է «նույնականացում» հարցումներ«Օրինակ՝ օգտատերը
haxor69ուզում է նոր լամպ գնել։ Սպասարկման ցանցերը ապահովում են տարբեր մեխանիզմներ, ինչպիսիք են՝ .Մեզանից շատերն են սա արել մեր ծրագրի կոդում։ Հարցումը գալիս է, մենք նայում ենք աղյուսակին։
users, գտեք օգտատիրոջը և համեմատեք գաղտնաբառը, այնուհետև ստուգեք սյունակըpermissionsև այլն։ Ծառայության ցանցի դեպքում սա տեղի է ունենում նույնիսկ նախքան հարցումը ծառայությանը հասնելը։
Երբ պարզենք, թե ումից է եկել հարցումը, պետք է որոշենք, թե ինչ է թույլատրվում անել այդ սուբյեկտին: Որոշ ծառայությունների ցանցեր թույլ են տալիս սահմանել հիմնական քաղաքականություններ (այն մասին, թե ով ինչ կարող է անել) որպես YAML ֆայլեր կամ հրամանի տողում, մինչդեռ մյուսները առաջարկում են ինտեգրացիա այնպիսի շրջանակների հետ, ինչպիսիք են՝ Վերջնական նպատակն այն է, որ ձեր ծառայությունները ընդունեն ցանկացած հարցում՝ վստահ լինելով, որ այն գալիս է վստահելի աղբյուրից։ и Այս գործողությունը թույլատրվում է։
4. Բեռի հավասարակշռում
TL;DR: Բաշխել բեռը ծառայության տարբեր օրինակների միջև՝ համաձայն որոշակի օրինաչափության։
«Ծառայություն» բաժնում շատ հաճախ բաղկացած է բազմաթիվ նույնական օրինակներից։ Օրինակ, այսօր ծառայությունը cache բաղկացած է 5 օրինակից, իսկ վաղը դրանց թիվը կարող է հասնել 11-ի։ Հարցումներն ուղարկվել են cache, պետք է բաշխվի որոշակի նպատակի համաձայն։ Օրինակ՝ նվազագույնի հասցնելու լատենտությունը կամ մեծացնելու աշխատող ինստանսին հասնելու հավանականությունը։ Առավել հաճախ օգտագործվող ալգորիթմը Round-robin ծառայության ալգորիթմն է, բայց կան շատ ուրիշներ, օրինակ՝ կշռված (կշռված) հարցումներ (կարող եք ընտրել նախընտրելի թիրախները), զանգահարեք (զանգ) հեշավորում (օգտագործել հետևողական հեշավորում վերին հոսթերի համար) կամ ամենաքիչ հարցումներով մեթոդ (նախապատվությունը տրվում է ամենաքիչ հարցումներով օրինակին):
Դասական բեռի հավասարակշռիչները ունեն այլ հնարավորություններ, ինչպիսիք են HTTP քեշավորումը և DDoS պաշտպանությունը, բայց դրանք շատ արդիական չեն արևելք-արևմուտք երթևեկության համար (ծառայության ցանցի տիպիկ կիրառումը): Իհարկե, բեռի հավասարակշռման համար պարտադիր չէ օգտագործել ծառայության ցանց, բայց այն թույլ է տալիս սահմանել և կառավարել բեռի հավասարակշռման քաղաքականությունները յուրաքանչյուր ծառայության համար կենտրոնացված կառավարման հարթությունից, այդպիսով վերացնելով ցանցային ստեկում առանձին բեռի հավասարակշռիչներ գործարկելու և կարգավորելու անհրաժեշտությունը:
5. Շղթայի խափանում
TL;DR: Դադարեցնել խնդրահարույց ծառայության երթևեկությունը և վերահսկել վնասը ամենավատ սցենարների դեպքում։
Եթե որևէ պատճառով ծառայությունը չի կարողանում կարգավորել երթևեկությունը, ծառայության ցանցը տրամադրում է մի քանի տարբերակ այս խնդիրը լուծելու համար (մյուսները կքննարկվեն համապատասխան բաժիններում): Էլեկտրամատակարարման խափանումը ծառայությունը երթևեկությունից անջատելու ամենածանր տարբերակն է: Այնուամենայնիվ, ինքնին դա իմաստ չունի. անհրաժեշտ է պահեստային պլան: Կարող է ապահովվել հետադարձ ճնշում: () հարցումներ կատարող ծառայություններին (պարզապես հիշեք դրա համար կարգավորել ձեր ծառայության ցանցը!), կամ, օրինակ, կարգավիճակի էջը կարմիր գույնով ներկելը և օգտատերերին վերահղելը «ընկնող կետ» գրությամբ էջի հաջորդ տարբերակին («Twitter-ը անջատված է»):
Ծառայողական ցանցերը ոչ միայն թույլ են տալիս որոշել, որտեղ կհետևի անջատում, և որ կհետևի։ Այս դեպքում «երբ»-ը կարող է ներառել նշված պարամետրերի ցանկացած համադրություն՝ որոշակի ժամանակահատվածի համար հարցումների ընդհանուր քանակը, զուգահեռ միացումների քանակը, սպասվող հարցումները, ակտիվ կրկնակի փորձերը և այլն։
Դուք հավանաբար չեք ցանկանա չափազանց շատ օգտագործել էլեկտրական սխեմայի անջատումը, բայց հաճելի է իմանալ, որ ունեք պահեստային ծրագիր արտակարգ իրավիճակների դեպքում:
6. Ավտոմատ մասշտաբավորում
TL;DR: Ավելացրեք կամ նվազեցրեք ծառայության օրինակների քանակը՝ հիմնվելով նշված չափանիշների վրա:
Ծառայության ցանցերը ժամանակացույցեր չեն, ուստի նրանք չեն իրականացնել ինքնուրույն մասշտաբավորվելով։ Այնուամենայնիվ, դրանք կարող են տրամադրել տեղեկատվություն, որը պլանավորողները կարող են օգտագործել որոշումներ կայացնելու համար։ Քանի որ ծառայությունների ցանցերը հասանելիություն ունեն ծառայությունների միջև եղած ամբողջ երթևեկությանը, նրանք ունեն մեծ քանակությամբ տեղեկատվություն այն մասին, թե ինչ է կատարվում. որ ծառայություններն են խնդիրներ ունենում, որոնք են թերօգտագործված (նրանց հատկացված հզորությունը վատնվում է) և այլն։
Օրինակ, Kubernetes-ը մասշտաբավորում է ծառայությունները pod-ների CPU-ի և հիշողության օգտագործման հիման վրա։ (Տեսեք մեր զեկույցը)- մոտ. թարգմ.), սակայն եթե որոշեք մասշտաբավորել որևէ այլ չափանիշի հիման վրա (մեր դեպքում՝ երթևեկության հետ կապված), ապա ձեզ անհրաժեշտ կլինի հատուկ չափանիշ։ ցույց է տալիս, թե ինչպես դա անել դրա հետ , и , սակայն գործընթացն ինքնին բավականին բարդ է։ Մենք կցանկանայինք, որ ծառայությունների ցանցը պարզեցներ այն՝ թույլ տալով մեզ պարզապես սահմանել պայմաններ, ինչպիսիք են՝ «ավելացնել ծառայությունների օրինակների քանակը» auth, եթե կատարման սպասող հարցումների քանակը մեկ րոպեով գերազանցում է շեմը։
7. Canary-ի տեղակայումներ
TL;DR: Փորձարկել ծառայության նոր գործառույթները կամ տարբերակները օգտատերերի ենթաբազմության վրա:
Ենթադրենք, որ դուք ստեղծում եք SaaS արտադրանք և պատրաստվում եք թողարկել նոր, հետաքրքիր տարբերակ։ Դուք փորձարկել եք այն փուլային տարբերակով, և այն հիանալի է աշխատում։ Սակայն դեռևս որոշ մտահոգություններ ունեք այն մասին, թե ինչպես այն կգործի իրական աշխարհի պայմաններում։ Այլ կերպ ասած, դուք ցանկանում եք փորձարկել նոր տարբերակը իրական աշխարհի առաջադրանքների վրա՝ առանց վտանգելու ձեր օգտատերերի վստահությունը։ Canary տեղակայումները հիանալի են դրա համար։ Դրանք թույլ են տալիս ցուցադրել նոր գործառույթ օգտատերերի ենթաբազմությանը։ Այս ենթաբազմությունը կարող է լինել ձեր ամենահավատարիմ օգտատերերը, կամ նրանք, ովքեր օգտագործում են արտադրանքի անվճար տարբերակը, կամ այն օգտատերերը, ովքեր կամավորագրվել են որպես «ծովախոզուկներ»։
Ծառայության ցանցերը դա անում են՝ թույլ տալով ձեզ նշել չափանիշներ, թե ով է տեսնում ձեր հավելվածի որ տարբերակը և համապատասխանաբար ուղղորդում են երթևեկությունը: Ծառայությունների համար ոչինչ չի փոխվում: Ծառայության 1.0 տարբերակը ենթադրում է, որ բոլոր հարցումները գալիս են այն օգտատերերից, ովքեր պետք է տեսնեն այն, իսկ 1.1 տարբերակը նույնը ենթադրում է իր օգտատերերի համար: Միևնույն ժամանակ, դուք կարող եք փոխել երթևեկության տոկոսը հին և նոր տարբերակների միջև՝ վերահղելով օգտատերերի աճող թվին դեպի նորը, եթե այն կայուն է, և ձեր «ծովախոզուկները» տալիս են թույլտվություն:
8. Կապույտ-կանաչ տեղակայումներ
TL;DR: Ներկայացրեք նոր հետաքրքիր գործառույթ, բայց պատրաստ եղեք անմիջապես այն վերականգնելու։
Իմաստը նոր «կապույտ» ծառայության ներդրումն է՝ այն զուգահեռաբար աշխատեցնելով հին, «կանաչ» ծառայության հետ։ Եթե ամեն ինչ հարթ ընթանա և նոր ծառայությունը լավ աշխատի, ապա հինը կարող է աստիճանաբար անջատվել։ (Ցավոք, մի օր այս նոր «կապույտ» ծառայությունը նույնպես նույն ճակատագրին կարժանանա, ինչ «կանաչը» և կանհետանա…) Կապույտ-կանաչ տեղակայումները տարբերվում են կանարյաններից նրանով, որ նոր հնարավորությունները ներառում են միանգամից օգտատերեր (ոչ մաս). այստեղ իմաստն այն է, որ պատրաստ լինի «պահեստային միացք», եթե ինչ-որ բան այնպես չգնա։
Ծառայողական ցանցերը շատ հարմար միջոց են «կապույտ» ծառայությունը փորձարկելու և խնդիրների դեպքում անմիջապես անցնելու աշխատող «կանաչ» ծառայությանը։ Անգամ չեմ խոսում այն մասին, որ դրանք նաև մեծ քանակությամբ տեղեկատվություն են տրամադրում (տե՛ս «Հեռաչափություն» բաժինը ստորև) «կապույտ» ծառայության աշխատանքի մասին, ինչը օգնում է հասկանալ, թե արդյոք այն պատրաստ է լիարժեք աշխատանքի։
Նշում. թարգմ.Դուք կարող եք ավելին կարդալ Kubernetes-ում տարբեր տեղակայման ռազմավարությունների մասին (ներառյալ նշված Canary, Blue/Green և այլն)՝ .
9. Առողջական ստուգում
TL;DR: Հետևել, թե որ ծառայության օրինակներն են առողջ և արձագանքել նրանց, որոնք այլևս առողջ չեն։
Առողջության ստուգում (առողջական ստուգում) օգնում է որոշել, թե արդյոք ծառայության օրինակները պատրաստ են ընդունել և մշակել երթևեկությունը: Օրինակ, HTTP ծառայությունների դեպքում, առողջության ստուգումը կարող է նման լինել վերջնակետին ուղղված GET հարցման: /healthՊատասխան 200 OK կնշանակի, որ օրինակը առողջ է, ցանկացած այլ՝ որ այն պատրաստ չէ երթևեկություն ընդունելու: Ծառայության ցանցերը թույլ են տալիս նշել ինչպես առողջության ստուգման եղանակը, այնպես էլ այդ ստուգման կատարման հաճախականությունը: Այս տեղեկատվությունը կարող է օգտագործվել այլ նպատակներով, օրինակ՝ բեռի հավասարակշռման և շղթայի անջատման համար:
Այսպիսով, առողջության ստուգումները առանձին օգտագործման դեպք չեն, այլ սովորաբար օգտագործվում են այլ նպատակներին հասնելու համար: Բացի այդ, առողջության ստուգումների արդյունքներից կախված, կարող են պահանջվել արտաքին (ծառայության ցանցի այլ նպատակների համեմատ) գործողություններ. օրինակ՝ կարգավիճակի էջի թարմացում, GitHub-ում խնդրի ստեղծում կամ JIRA տոմսի լրացում: Եվ ծառայության ցանցը առաջարկում է հարմար մեխանիզմ այս ամենը ավտոմատացնելու համար:
10. Բեռի հեռացում
Վերահղում կատարեք երթևեկության վերաուղղորդման հարցում՝ օգտագործման ժամանակավոր կտրուկ աճի դեպքում։
Եթե ծառայությունը գերծանրաբեռնված է երթևեկությամբ, դուք կարող եք ժամանակավորապես այդ երթևեկության մի մասը վերահասցեագրել այլ վայր (օրինակ՝ «գցել» կամ «լցնել» այն): (տուն) այն այնտեղ է): Օրինակ՝ պահուստային ծառայության կամ տվյալների կենտրոնի, կամ մշտական թեմա։ Արդյունքում, ծառայությունը կշարունակի մշակել որոշ հարցումներ՝ փոխարենը խափանվելու և ոչինչ չմշակելու։ Բեռնվածության կրճատումը նախընտրելի է շղթայի խզմանը, բայց միևնույն է, խորհուրդ չի տրվում չարաշահել այն։ Այն օգնում է կանխել կասկադային խափանումները, որոնք հանգեցնում են հոսանքն ի վար ծառայությունների խափանմանը։
11. Երթևեկության զուգահեռացում/հայելային արտացոլում
TL;DR: Ուղարկեք մեկ հարցում միաժամանակ մի քանի վայրեր:
Երբեմն անհրաժեշտություն է առաջանում միաժամանակ մի քանի ծառայություններին հարցում (կամ հարցումների որոշակի ընտրանի) ուղարկել: Տիպիկ օրինակ է արտադրական տրաֆիկի մի մասի ուղարկումը փուլային ծառայությանը: Հիմնական արտադրական վեբ սերվերը հարցում է ուղարկում ներքևի հոսանքի ծառայությանը: products.production և միայն դրան։ Եվ ծառայության ցանցը խելացիորեն պատճենում է այս հարցումը և ուղարկում այն products.staging, որի մասին վեբ սերվերը նույնիսկ չգիտի։
Ծառայողական ցանցի մեկ այլ հարակից օգտագործման դեպք, որը կարող է իրականացվել երթևեկության զուգահեռացման վերևում, հետևյալն է. Այն ենթադրում է նույն հարցումները ուղարկել ծառայության տարբեր տարբերակներին և ստուգել, թե արդյոք բոլոր տարբերակները նույն կերպ են գործում։ Ես դեռ չեմ տեսել ծառայությունների ցանցի իրականացում՝ ինտեգրված ռեգրեսիայի թեստավորման համակարգով, ինչպիսին է , բայց գաղափարն ինքնին խոստումնալից է թվում։
12. Մեկուսացում
TL;DR: Բաժանեք ձեր ծառայությունների ցանցը մինի ցանցերի:
Նաև հայտնի է որպես հատվածավորումը, մեկուսացումը ծառայությունների ցանցը տրամաբանորեն առանձին հատվածների բաժանելու արվեստ է, որոնք միմյանց մասին ոչինչ չգիտեն: Մեկուսացումը մի փոքր նման է վիրտուալ մասնավոր ցանցեր ստեղծելուն: Հիմնական տարբերությունն այն է, որ դուք դեռևս ստանում եք ծառայությունների ցանցի բոլոր առավելությունները (օրինակ՝ ծառայությունների հայտնաբերումը), բայց լրացուցիչ անվտանգությամբ: Օրինակ, եթե հարձակվողին հաջողվի ներթափանցել մեկ ենթացանցի ծառայություն, նա չի կարողանա տեսնել, թե որ ծառայություններն են աշխատում մյուս ենթացանցերում կամ ընդհատել դրանց երթևեկությունը:
Կարող են լինել նաև կազմակերպչական առավելություններ։ Դուք կարող եք ցանկանալ ծառայությունները բաժանել ենթացանցերի՝ հիմնվելով ձեր ընկերության կառուցվածքի վրա և ազատել մշակողներին ամբողջ ծառայությունների ցանցը հետևելու ճանաչողական բեռից։
13. Հարցումների հաճախականության սահմանափակում, կրկնությունների և ժամկետների սահմանափակում
TL;DR: Այլևս անհրաժեշտ չէ ձեր կոդային բազայում ներառել ժամանակատար հարցումների կառավարման առաջադրանքներ:
Այս բոլորը կարելի է համարել առանձին օգտագործման դեպքեր, բայց ես որոշեցի դրանք խմբավորել մեկ ընդհանուր բանի պատճառով. դրանք թեթևացնում են ծրագրային գրադարանների կողմից սովորաբար մշակվող հարցումների կյանքի ցիկլի կառավարման առաջադրանքները: Եթե դուք կառուցում եք Ruby on Rails վեբ սերվեր (չինտեգրված ծառայությունների ցանցի հետ), որը հարցումներ է ուղարկում backend ծառայություններին՝ , հավելվածը պետք է ինքնուրույն որոշի, թե ինչ անել, եթե N հարցումները ձախողվեն: Այն նաև պետք է պարզի, թե որքան երթևեկություն կարող են կարգավորել այս ծառայությունները և կոշտ կոդավորի այդ պարամետրերը՝ օգտագործելով հատուկ գրադարան: Բացի այդ, հավելվածը պետք է որոշի, թե երբ հրաժարվել և թույլ տալ, որ հարցումը վատանա (ժամանակի ավարտով): Եվ վերը նշված պարամետրերից որևէ մեկը փոխելու համար վեբ սերվերը պետք է կանգնեցվի, վերակազմավորվի և վերագործարկվի:
Այս առաջադրանքները ծառայությունների ցանցին պատվիրակելը ոչ միայն նշանակում է, որ ծառայությունների մշակողները պարտավոր չեն մտածել դրանց մասին, այլև որ դրանք կարող են դիտարկվել ավելի գլոբալ ձևով։ Եթե դուք ունեք ծառայությունների բարդ շղթա, ասենք՝ A –> B –> C –> D –> E, ապա պետք է հաշվի առնեք հարցման ամբողջ կյանքի ցիկլը։ Եթե անհրաժեշտ է երկարաձգել C ծառայության ժամկետները, ապա իմաստ ունի դա անել միանգամից, այլ ոչ թե մաս-մաս՝ թարմացնելով ծառայության կոդը և սպասելով, որ pull request-ը ընդունվի, և CI համակարգը տեղակայի թարմացված ծառայությունը։
14. Հեռաչափություն
TL;DR: Հավաքեք ծառայություններից բոլոր անհրաժեշտ (և ոչ այնքան անհրաժեշտ) տեղեկությունները:
Հեռաչափությունը ընդհանուր տերմին է, որը ներառում է չափանիշներ, բաշխված հետևում և գրանցամատյաններ: Ծառայողական ցանցերը առաջարկում են մեխանիզմներ բոլոր երեք տեսակի տվյալների հավաքագրման և մշակման համար: Այստեղ է, որ ամեն ինչ մի փոքր մշուշոտ է դառնում, քանի որ հնարավոր տարբերակների քանակը չափազանց մեծ է: Չափանիշների համար կան և այլ գործիքներ, որոնք կարող են օգտագործվել գրանցամատյաններ հավաքելու համար , , եւ այլն: (օրինակ՝ ClickHouse-ը մեր հետ K8-ների համար — թարգմանչի նշում), բաշխված հետևման համար կա և այլն: Յուրաքանչյուր սպասարկման ցանց կարող է աջակցել որոշ գործիքների, իսկ մյուսներին՝ ոչ: Հետաքրքիր կլինի տեսնել, թե արդյոք նախագիծը կարող է ապահովել որոշակի կոնվերգենցիա։
Այս դեպքում, սպասարկման ցանցի տեխնոլոգիայի առավելությունն այն է, որ կողային վագոնների կոնտեյներները, սկզբունքորեն, կարող են հավաքել վերը նշված բոլոր տվյալները իրենց ծառայություններից: Այլ կերպ ասած, դուք ձեր տրամադրության տակ եք ստանում մեկ հեռաչափման հավաքագրման համակարգ, և սպասարկման ցանցը կարող է մշակել այս ամբողջ տեղեկատվությունը տարբեր ձևերով: Օրինակ՝
- CLI-ում որոշակի ծառայության պոչային գրանցամատյաններ։
- հետևել հարցումների ծավալին ծառայության ցանցի վահանակից։
- հավաքել բաշխված հետքերը և ուղարկել դրանք Jaeger-ի նման համակարգին։
Ուշադրություն, սուբյեկտիվ դատողություն. Ընդհանուր առմամբ, հեռաչափությունը այն ոլորտն է, որտեղ դուք չեք ցանկանում մեծ քանակությամբ ծառայությունների ցանցային միջամտություն: Հիմնական տեղեկատվության հավաքագրումը և որոշ «ոսկե չափանիշների» արագ հետևումը, ինչպիսիք են հաջողության մակարդակը և լատենտությունը, նորմալ է, բայց հուսանք, որ չենք տեսնի Ֆրանկենշտեյնի կույտերի ի հայտ գալը, որոնք կփորձեն փոխարինել մասնագիտացված համակարգերին, որոնցից մի քանիսն արդեն իսկ լավ հաստատված և լավ հասկացված են:
15. Աուդիտ
TL;DR: Նրանք, ովքեր մոռանում են պատմության դասերը, դատապարտված են դրանք կրկնելուն։
Աուդիտը համակարգում կարևոր իրադարձությունների մոնիթորինգի արվեստ է: Ծառայողական ցանցի դեպքում սա կարող է նշանակել հետևել, թե ով է հարցումներ ուղարկել որոշակի ծառայությունների որոշակի վերջնակետերին կամ քանի անգամ է տեղի ունեցել որոշակի անվտանգության հետ կապված իրադարձություն վերջին ամսվա ընթացքում:
Ակնհայտ է, որ աուդիտը շատ սերտորեն կապված է հեռաչափման հետ։ Տարբերությունն այն է, որ հեռաչափումը սովորաբար կապված է այնպիսի բաների հետ, ինչպիսիք են կատարողականը և տեխնիկական պիտանիությունը, մինչդեռ աուդիտը կարող է վերաբերել իրավական և այլ հարցերի, որոնք դուրս են խիստ տեխնիկական ոլորտից (օրինակ՝ համապատասխանությունը ԵՄ տվյալների պաշտպանության ընդհանուր կանոնակարգին):
16. Պատկերացում
TL;DR: Կեցցե՛ React.js-ը՝ տարօրինակ ինտերֆեյսների աղբյուրը։
Հնարավոր է՝ ավելի լավ տերմին լինի, բայց ես չգիտեմ այն։ Ես պարզապես նկատի ունեմ ծառայությունների ցանցի կամ դրա որոշ բաղադրիչների գրաֆիկական ներկայացումը։ Այս վիզուալիզացիաները կարող են ներառել այնպիսի ցուցանիշներ, ինչպիսիք են միջին լատենտությունները, կողային կցորդի կոնտեյների կարգավորման տեղեկատվությունը, առողջության ստուգման արդյունքները և ահազանգերը։
Ծառայողական միջավայրում աշխատելը կապված է շատ ավելի բարձր ճանաչողական բեռի հետ՝ համեմատած Նորին Մեծություն Մոնոլիտի հետ։ Հետևաբար, ճանաչողական ճնշումը պետք է նվազեցվի ամեն գնով։ Ծառայողական ցանցի համար պարզ գրաֆիկական ինտերֆեյսը՝ կոճակը սեղմելու և ցանկալի արդյունքը ստանալու հնարավորությամբ, կարող է վճռորոշ լինել այս տեխնոլոգիայի աճի համար։
Ցուցակում չեն ընդգրկվել
Սկզբում ես մտադիր էի ցանկում ներառել ևս մի քանի օգտագործման դեպքեր, բայց հետո որոշեցի չանել դա։ Ահա դրանք՝ իմ որոշման պատճառների հետ միասին.
- Բազմա-տվյալների կենտրոնԻմ կարծիքով, սա այնքան օգտագործման դեպք չէ, որքան ծառայությունների ցանցերի նեղ և կոնկրետ կիրառություն կամ որոշ գործառույթների ամբողջություն, ինչպիսին է ծառայությունների հայտնաբերումը։
- Մուտք և ելքՍա կապված ոլորտ է, բայց ես սահմանափակվել եմ (գուցե արհեստականորեն) «արևելք-արևմուտք երթևեկության» կիրառման դեպքով։ Մուտքն ու ելքը արժանի են առանձին հոդվածի։
Ամփոփում
Այսքանը առայժմ։ Կրկին, այս ցանկը շատ պայմանական է և, ամենայն հավանականությամբ, թերի։ Եթե կարծում եք, որ ես ինչ-որ բան բաց եմ թողել կամ սխալ եմ թույլ տվել, կապվեք ինձ հետ Twitter-ում (Խնդրում ենք պահպանել քաղաքավարության կանոնները։
PS թարգմանչից
Հոդվածի հիմնական նկարազարդումը հիմնված է հոդվածից վերցված պատկերի վրա՝ ««(Գրեգորի Մակկինոնի կողմից) Այն ցույց է տալիս, թե ինչպես են հավելվածների որոշ ֆունկցիոնալություններ (կանաչով) տեղափոխվել ծառայությունների ցանց, որը ապահովում է դրանց միջև կապերը (կապույտով):»
Կարդացեք նաև մեր բլոգում.
- «";
- «";
- «.
Source: www.habr.com
