Նշում. թարգմ.Ծառայության ցանցը մի երևույթ է, որը դեռևս չունի ռուսերեն կայուն թարգմանություն (ավելի քան 2 տարի առաջ մենք առաջարկեցինք «Ցանց ծառայությունների համար» տարբերակը, իսկ մի փոքր անց որոշ գործընկերներ սկսեցին ակտիվորեն խթանել «ծառայողական մաղ» համադրությունը): . Այս տեխնոլոգիայի մասին անընդհատ խոսակցությունները հանգեցրել են մի իրավիճակի, երբ շուկայավարման և տեխնիկական բաղադրիչները չափազանց սերտորեն փոխկապակցված են: Բնօրինակ տերմինի հեղինակներից մեկի այս հրաշալի նյութը նպատակ ունի պարզություն հաղորդել ինժեներներին և ոչ միայն:
Կատակերգություն-ից
Ներածություն
Եթե դուք ծրագրային ապահովման ինժեներ եք, աշխատում եք ինչ-որ տեղ backend համակարգերի ոլորտում, ապա «ծառայության ցանց» տերմինը հավանաբար արդեն ամուր արմատավորվել է ձեր մտքում վերջին մի քանի տարիների ընթացքում: Տարօրինակ զուգադիպության շնորհիվ այս արտահայտությունն ավելի ու ավելի է գրավում ոլորտը, և աղմուկը և դրա հետ կապված գովազդային առաջարկները ձնագնդի պես աճում են՝ թռչելով բլուրից ցած և դանդաղեցնելու նշաններ ցույց տալով:
Ծառայողական ցանցը ծնվել է ամպային հայրենի էկոհամակարգի պղտոր, միտումնավոր ջրերում: Ցավոք սրտի, դա նշանակում է, որ դրա շուրջ տարաձայնությունների մեծ մասը տատանվում է «ցածր կալորիականությամբ շաղակրատանքից» մինչև, եթե օգտագործենք տեխնիկական տերմինը, բացահայտ հիմարություն: Բայց եթե դուք զտեք ամբողջ աղմուկը, կարող եք պարզել, որ սպասարկման ցանցը շատ իրական, հստակ և կարևոր գործառույթ ունի:
Այս գրառման մեջ ես կփորձեմ անել հենց դա՝ տրամադրել ազնիվ, խորը, ինժեներական կողմնորոշված ուղեցույց սպասարկման ցանցի համար: Ես կպատասխանեմ ոչ միայն հարցին. "Ինչ է դա?", - Ինչպես նաեւ — Ինչո՞ւ։Իսկ — Ինչո՞ւ հիմա։. Վերջապես, ես կփորձեմ ուրվագծել, թե ինչու (իմ կարծիքով) այս կոնկրետ տեխնոլոգիան առաջացրել է նման խելահեղ աղմուկ, որն ինքնին հետաքրքիր պատմություն է:
Ով եմ ես
Բարեւ բոլորին! Իմ ԱՆՈՒՆՆ Է . Ես ստեղծագործողներից մեկն եմ - հենց առաջին սպասարկման ցանցի նախագիծը և նախագիծը, որը մեղավոր է տերմինի տեսքի համար սպասարկման ցանց որպես այդպիսին (ներողություն տղաներ): (Նշում թարգման.Ի դեպ, այս տերմինի ի հայտ գալու պահին, ավելի քան 2,5 տարի առաջ, մենք արդեն թարգմանել ենք նույն հեղինակի վաղ նյութը, որը կոչվում է ««.) Ես էլ եմ ղեկավարում նորաստեղծ ընկերություն է, որը ստեղծում է զովացուցիչ ծառայություններ, ինչպիսիք են Linkerd-ը և .
Երևի կարող եք կռահել, որ ես շատ կողմնակալ և սուբյեկտիվ կարծիք ունեմ այս հարցում։ Այնուամենայնիվ, ես կփորձեմ նվազագույնի հասցնել կողմնակալությունը (բացառությամբ մեկ բաժնի. «Ինչու՞ է այդքան շատ խոսվում սպասարկման ցանցի մասին»:, - որում, այնուամենայնիվ, կկիսվեմ իմ նախապես մտածված գաղափարներով)։ Ես նույնպես կանեմ ամեն ինչ այս ուղեցույցը հնարավորինս օբյեկտիվ դարձնելու համար: Կոնկրետ օրինակներում ես հիմնականում կհիմնվեմ Linkerd-ի փորձի վրա՝ միաժամանակ նշելով այն տարբերությունները (եթե այդպիսիք կան), որոնք ես գիտեմ սպասարկման ցանցերի այլ տեսակների իրականացման մեջ:
Լավ, ժամանակն է անցնել հյուրասիրություններին:
Ի՞նչ է սպասարկման ցանցը:
Չնայած բոլոր աղմուկին, ծառայության ցանցը կառուցվածքային առումով բավականին պարզ է: Դա պարզապես օգտվողների տարածքի վստահված սերվերների մի փունջ է, որոնք տեղակայված են ծառայությունների «կողքին» (ավելի ուշ կխոսենք «մոտ» մասին), գումարած մի շարք վերահսկման գործընթացներ: Վստահված անձինք կոչվում են հավաքական տվյալների հարթություն, և կառավարման գործընթացները կոչվում են կառավարման ինքնաթիռ. Տվյալների հարթությունը գաղտնալսում է ծառայությունների միջև զանգերը և նրանց հետ անում «տարբեր բան». Կառավարման հարթությունը, համապատասխանաբար, համակարգում է վստահված անձի վարքագիծը և ապահովում է ձեզ մուտք, այսինքն. օպերատորին, API-ին, որը թույլ է տալիս ցանցը մանիպուլյացիայի ենթարկել և չափել որպես ամբողջություն:
Ի՞նչ է այս վստահված անձը: Սա «Layer 7-aware» կատեգորիայի TCP վստահված անձ է (այսինքն՝ «հաշվի առնելով» OSI մոդելի 7-րդ շերտը) ինչպես HAProxy-ն և NGINX-ը: Դուք կարող եք ընտրել վստահված անձ ձեր ցանկությամբ; Linkerd-ն օգտագործում է Rust վստահված անձ, որը ոչ բարդ անվանմամբ . Մենք այն կազմել ենք հատուկ ծառայության ցանցի համար: Մյուս ցանցերը նախընտրում են այլ վստահված անձինք (Envoy-ը սովորական ընտրություն է): Այնուամենայնիվ, վստահված անձի ընտրությունը պարզապես իրականացման խնդիր է:
Ի՞նչ են անում այս պրոքսի սերվերները: Ակնհայտ է, որ նրանք պրոքսի զանգեր են կատարում դեպի ծառայություններ և դեպի ծառայություններ (խիստ ասած՝ նրանք հանդես են գալիս որպես վստահված անձ և հակադարձ վստահված անձինք՝ սպասարկելով ինչպես մուտքային, այնպես էլ ելքային զանգերը): Եվ նրանք իրականացնում են մի շարք գործառույթներ, որոնք կենտրոնանում են զանգերի վրա միջեւ ծառայություններ։ Ծառայությունների միջև տրաֆիկի վրա այս կենտրոնացումը այն է, ինչը տարբերում է սպասարկման ցանցի վստահված անձին, ասենք, API-ի դարպասներից կամ մուտքի վստահվածներից (վերջինս կենտրոնացած է արտաքին աշխարհից կլաստեր մուտք գործող զանգերի վրա): (Նշում. թարգմ.Գոյություն ունեցող Kubernetes Ingress կարգավորիչների համեմատության համար, որոնցից շատերն օգտագործում են արդեն նշված դեսպանորդը, տե՛ս. .)
Այսպիսով, մենք պարզեցինք տվյալների հարթությունը: Կառավարման հարթությունն ավելի պարզ է. այն բաղադրիչների մի շարք է, որն ապահովում է բոլոր մեխանիզմները, որոնք անհրաժեշտ են տվյալների հարթությանը համակարգված աշխատելու համար, ներառյալ ծառայության հայտնաբերումը, TLS վկայագրի թողարկումը, չափումների ագրեգացումը և այլն: Տվյալների հարթությունը տեղեկացնում է կառավարման հարթությանը: նրա վարքագիծը; իր հերթին, կառավարման հարթությունն ապահովում է API, որը թույլ է տալիս փոխել և հետևել տվյալների հարթության վարքագծին որպես ամբողջություն:
Ստորև բերված է Linkerd-ում կառավարման հարթության և տվյալների հարթության դիագրամ: Ինչպես տեսնում եք, կառավարման հարթությունը ներառում է մի քանի տարբեր բաղադրիչներ, ներառյալ Պրոմեթևսի օրինակը, որը հավաքում է չափումներ պրոքսի սերվերներից, ինչպես նաև այլ բաղադրիչներ, ինչպիսիք են. destination (ծառայության հայտնաբերում), identity (վկայական մարմին, CA) և public-api (վերջնակետեր վեբի և CLI-ի համար): Ի հակադրություն, տվյալների հարթությունը պարզ կապող-պրոքսի է հավելվածի օրինակի կողքին: Սա ընդամենը տրամաբանական դիագրամ է. Իրական աշխարհում տեղակայման դեպքում դուք կարող եք ունենալ յուրաքանչյուր կառավարման հարթության բաղադրիչի երեք կրկնօրինակ և տվյալների հարթությունում հարյուրավոր կամ հազարավոր վստահված անձեր:
(Այս գծապատկերի կապույտ տուփերը ներկայացնում են Kubernetes pods-ի սահմանները: Դուք կարող եք տեսնել, որ linkerd-proxy-ով բեռնարկղերը գտնվում են նույն պատիճում, ինչ հավելվածի բեռնարկղերը: Այս սխեման հայտնի է որպես sidecar կոնտեյներ.)
Ծառայության ցանցի ճարտարապետությունը մի քանի կարևոր հետևանքներ ունի: Նախ, քանի որ վստահված անձի գործը ծառայությունների միջև զանգերի գաղտնալսումն է, սպասարկման ցանցը իմաստ ունի միայն այն դեպքում, եթե ձեր հավելվածը ստեղծվել է մի շարք ծառայությունների համար: ցանց կարելի օգտագործել մոնոլիտներով, բայց դա ակնհայտորեն ավելորդ է մեկ վստահված անձի համար, և դրա ֆունկցիոնալությունը դժվար թե պահանջարկ ունենա:
Մեկ այլ կարևոր հետևանք այն է, որ սպասարկման ցանցը պահանջում է հսկայական վստահված անձանց թիվը. Իրականում, Linkerd-ը կապում է linkerd-proxy-ը յուրաքանչյուր ծառայության յուրաքանչյուր օրինակին (այլ իրականացումներն ավելացնում են վստահված անձի յուրաքանչյուր հանգույց/հոսթ/VM: Դա, այնուամենայնիվ, շատ է): Վստահված անձի նման ակտիվ օգտագործումն ինքնին կրում է մի շարք լրացուցիչ բարդություններ.
- Տվյալների հարթությունում վստահված անձինք պետք է լինեն արագ, քանի որ յուրաքանչյուր զանգի համար կան մի քանի զանգեր դեպի վստահված անձին՝ մեկը հաճախորդի կողմից, մեկը՝ սերվերի կողմից:
- Նաև վստահված անձինք պետք է լինեն փոքր и թեթև. Յուրաքանչյուրը կսպառի հիշողությունը և պրոցեսորի ռեսուրսները, և այս սպառումը գծային կերպով կաճի հավելվածի հետ:
- Ձեզ անհրաժեշտ կլինի մեխանիզմ՝ մեծ թվով վստահված սերվերներ տեղակայելու և թարմացնելու համար: Ձեռքով դա անելը տարբերակ չէ:
Ընդհանուր առմամբ, ծառայության ցանցն այսպիսի տեսք ունի (համենայն դեպս թռչնի հայացքից). դուք տեղակայում եք օգտվողների տարածքի վստահված սերվերներ, որոնք «ինչ-որ բան են անում» ներքին, միջսպասարկման տրաֆիկի հետ և օգտագործում են կառավարման հարթությունը՝ դրանք վերահսկելու և կառավարելու համար:
Եկել է «Ինչո՞ւ» հարցի ժամանակը.
Ինչի համար է սպասարկման ցանցը:
Նրանց համար, ովքեր առաջին անգամ հանդիպել են ծառայության ցանցի գաղափարին, ներելի է մի փոքր ակնածանք ունենալ: Ծառայության ցանցի դիզայնը նշանակում է, որ այն ոչ միայն կբարձրացնի կիրառման հետաձգումը, այլև կաճի սպառում ռեսուրսներ և կավելացնի ենթակառուցվածքում մի շարք նոր մեխանիզմներ. Սկզբում տեղադրում եք սպասարկման ցանց, իսկ հետո հանկարծ հայտնվում եք, որ հարյուրավոր (եթե ոչ հազարավոր) վստահված անձանց սպասարկելու կարիք ունեք: Հարցն այն է, թե ո՞վ է սրան կամավոր ներկայացնելու:
Այս հարցի պատասխանը բաղկացած է երկու մասից. Նախ, այս վստահված սարքերի տեղակայման հետ կապված գործարքի ծախսերը կարող են զգալիորեն կրճատվել էկոհամակարգում տեղի ունեցող որոշ փոփոխությունների պատճառով (այս մասին ավելի ուշ):
Երկրորդ, նման սարքը իրականում համակարգում լրացուցիչ տրամաբանություն մտցնելու հիանալի միջոց է: Եվ ոչ միայն այն պատճառով, որ շատ նոր հնարավորություններ կարող են ավելացվել ծառայության ցանցի միջոցով, այլ նաև այն պատճառով, որ դա կարելի է անել առանց էկոհամակարգի միջամտության: Իրականում, ամբողջ սպասարկման ցանցի մոդելը հիմնված է այս պոստուլատի վրա՝ բազմասերվիսային համակարգում՝ անկախ ամեն ինչից դարձնել անհատական ծառայություններ, երթեւեկություն նրանց միջեւ ֆունկցիոնալությունը ավելացնելու իդեալական կետն է:
Օրինակ, Linkerd-ում (ինչպես ցանցերի մեծ մասում) ֆունկցիոնալությունը կենտրոնացած է հիմնականում HTTP զանգերի վրա, ներառյալ HTTP/2 և gRPC*: Ֆունկցիոնալությունը բավականին հարուստ է. այն կարելի է բաժանել երեք դասի.
- Առնչվող հատկանիշներ հուսալիություն. Կրկին փորձեք հարցումներ, ժամանակի ընդհատումներ, դեղձանիկ մոտեցում (երթևեկության բաժանում/վերահղում) և այլն:
- Առնչվող հատկանիշներ մոնիտորինգ. Յուրաքանչյուր ծառայության կամ առանձին ուղղությունների համար հաջողության, ուշացումների և պահանջների ծավալների համախմբում. ծառայությունների տոպոլոգիական քարտեզների կառուցում և այլն։
- Առնչվող հատկանիշներ անվտանգություն. Փոխադարձ TLS, մուտքի վերահսկում և այլն:
* Linkerd-ի տեսանկյունից, gRPC-ն գործնականում չի տարբերվում HTTP/2-ից. այն պարզապես օգտագործում է պրոտոբուֆ բեռնվածքում: Մշակողի տեսանկյունից այս երկու բաները, իհարկե, տարբեր են:
Այս մեխանիզմներից շատերը գործում են հարցումների մակարդակով (հետևաբար՝ «L7 վստահված անձ»): Օրինակ, եթե Foo ծառայությունը HTTP զանգ է կատարում դեպի սպասարկման բար, Foo-ի կողմում գտնվող linkerd-proxy-ը կարող է խելամտորեն բեռնել հավասարակշռությունը և ուղղորդել զանգերը Foo-ից դեպի Bar օրինակներ՝ հիմնվելով դիտարկվող հետաձգման վրա. անհրաժեշտության դեպքում այն կարող է կրկնել հարցումը (և եթե այն անզոր է); նա կարող է ձայնագրել պատասխանի կոդը և ժամանակի ավարտը և այլն: Նմանապես, Bar-ի կողմում գտնվող linkerd-proxy-ը կարող է մերժել հարցումը, եթե դա թույլատրված չէ կամ եթե հարցման սահմանաչափը գերազանցված է. կարող է ուղղել ուշացումը իր կողմից և այլն:
Վստահված անձինք կարող են «ինչ-որ բան անել» նաև կապի մակարդակում: Օրինակ, Foo կողմում գտնվող linkerd-proxy-ը կարող է սկսել TLS կապը, իսկ Linkerd-proxy-ը Bar-ի կողմում կարող է դադարեցնել այն, և երկու կողմերն էլ կարող են ստուգել միմյանց TLS վկայականները*: Սա ապահովում է ոչ միայն գաղտնագրում ծառայությունների միջև, այլ նաև ծառայությունների նույնականացման գաղտնագրության ապահով եղանակ. Foo and Bar-ը կարող է «ապացուցել», որ իրենք իրենց ասածն են:
* «Ընկերոջ ընկեր» նշանակում է, որ հաճախորդի վկայականը նույնպես ստուգված է (փոխադարձ TLS): «Դասական» TLS-ում, օրինակ, բրաուզերի և սերվերի միջև, սովորաբար ստուգվում է միայն մեկ կողմի (սերվերի) վկայականը։
Անկախ նրանից, թե դրանք գործում են խնդրանքով կամ կապի մակարդակով, կարևոր է ընդգծել, որ սպասարկման ցանցի բոլոր հատկանիշներն են գործառնական բնավորություն. Linkerd-ը չի կարողանում փոխակերպել օգտակար բեռի իմաստաբանությունը, օրինակ՝ դաշտեր ավելացնելը JSON հատվածին կամ փոփոխություններ կատարել պրոտոբուֆում: Այս կարևոր հատկանիշի մասին մենք կխոսենք ավելի ուշ, երբ խոսենք ESB-ի և միջին ծրագրի մասին:
Սա այն հատկանիշների շարքն է, որն առաջարկում է սպասարկման ցանցը: Հարց է առաջանում՝ ինչո՞ւ դրանք ուղղակիորեն չներարկել հավելվածում։ Իսկ ինչու՞ ընդհանրապես խառնաշփոթ վստահված անձի հետ:
Ինչու է սպասարկման ցանցը լավ գաղափար
Թեև սպասարկման ցանցի հնարավորությունները գրավիչ են, դրա հիմնական արժեքը իրականում չի կայանում հատկությունների մեջ: Ի վերջո մենք Կարող իրականացնել դրանք անմիջապես հավելվածում (հետագայում մենք կտեսնենք, որ սա ծառայության ցանցի ծագումն է): Մեկ նախադասությամբ արտահայտելու համար սպասարկման ցանցի արժեքը հետևյալն է. այն ապահովում է ֆունկցիոնալությունը, որը կարևոր նշանակություն ունի ժամանակակից սերվերի ծրագրակազմը հետևողական, փաթեթի լայնածավալ, կիրառական կոդ-ագնոստիկ եղանակով գործարկելու համար.
Եկեք վերլուծենք այս առաջարկը։
«Գործառույթներ, որոնք կարևոր են ժամանակակից սերվերի ծրագրային ապահովման գործարկման համար«. Եթե դուք կառուցում եք հանրային ինտերնետին միացված գործարքային սերվերի հավելված, որն ընդունում է արտաքին աշխարհի հարցումները և կարճ ժամանակում պատասխանում դրանց, օրինակ՝ վեբ հավելված, API սերվեր և այլ ժամանակակից հավելվածների ճնշող մեծամասնությունը, և եթե դուք այն իրականացնում եք որպես ծառայությունների մի շարք, որոնք փոխազդում են միմյանց հետ համաժամանակյա, և եթե դուք անընդհատ արդիականացնում եք այս ծրագրաշարը, ավելացնում եք նոր հնարավորություններ, և եթե փոփոխման գործընթացում ստիպված եք այս համակարգը պահել աշխատանքային վիճակում, այս դեպքում, շնորհավորում եմ, դուք ստեղծում եք ժամանակակից սերվերային ծրագրակազմ: Եվ վերը թվարկված բոլոր այդ հիանալի հատկությունները իրականում կարևոր են ձեզ համար: Հավելվածը պետք է լինի հուսալի, ապահով, և դուք պետք է կարողանաք տեսնել, թե ինչ է այն անում: Հենց այս հարցերն է օգնում լուծել սպասարկման ցանցը։
(Լավ, իմ համոզմունքը, որ այս մոտեցումը սերվերի ծրագրակազմ ստեղծելու ժամանակակից միջոցն է, մտել է նախորդ պարբերություն: Մյուսները նախընտրում են զարգացնել մոնոլիտներ, «ռեակտիվ միկրոծառայություններ» և այլ բաներ, որոնք չեն պատկանում վերը նշված սահմանմանը: Այս մարդիկ հավանաբար ունեն կարծիք, որը տարբերվում է իմից, և իր հերթին ես կարծում եմ, որ դրանք «սխալ» են, թեև ամեն դեպքում սպասարկման ցանցը նրանց համար այնքան էլ օգտակար չէ):
«Միատեսակ ամբողջ կույտի համար«. Ծառայության ցանցի կողմից տրամադրված առանձնահատկությունները պարզապես կարևոր չեն: Նրանք դիմում են հավելվածի բոլոր ծառայություններին, անկախ նրանից, թե ինչ լեզվով են դրանք գրված, ինչ շրջանակ են օգտագործում, ով է դրանք գրել, ինչպես են դրանք տեղակայվել և դրանց մշակման և օգտագործման բոլոր նրբությունները:
«Անկախ հավելվածի կոդը«. Վերջապես, սպասարկման ցանցը ոչ միայն ապահովում է հետևողական գործառույթ ամբողջ կույտում, այլ դա անում է այնպես, որ չի պահանջում հավելվածի խմբագրում: Ծառայությունների ցանցի ֆունկցիոնալության հիմնարար հիմքը, ներառյալ կազմաձևման, թարմացման, շահագործման, պահպանման և այլնի առաջադրանքները, զուտ հարթակի մակարդակում են և անկախ են հավելվածից: Հավելվածը կարող է փոխվել՝ չազդելով ծառայության ցանցի վրա: Իր հերթին, սպասարկման ցանցը կարող է փոխվել առանց որևէ կիրառական միջամտության:
Մի խոսքով, ծառայության ցանցը ոչ միայն ապահովում է կենսական գործառույթներ, այլև դա անում է գլոբալ, միատեսակ և հավելվածից անկախ եղանակով: Եվ այսպես, թեև սպասարկման ցանցի ֆունկցիոնալությունը կարող է իրականացվել ծառայության կոդում (օրինակ՝ որպես գրադարան ներառված յուրաքանչյուր ծառայության մեջ), այս մոտեցումը չի ապահովի միատեսակ և անկախություն, որն այդքան արժեքավոր է ծառայության դեպքում։ սպասարկման ցանց:
Եվ այն ամենը, ինչ դուք պետք է անեք, ավելացնեք վստահված անձանց մի փունջ: Խոստանում եմ, շատ շուտով մենք կդիտարկենք այս վստահված ծառայությունների ավելացման հետ կապված գործառնական ծախսերը: Բայց նախ, եկեք կանգ առնենք և նայենք անկախության այս գաղափարին տարբեր տեսանկյունից ժողովուրդ.
Ո՞ւմ է օգնում սպասարկման ցանցը:
Որքան էլ անհարմար լինի, որպեսզի տեխնոլոգիան դառնա էկոհամակարգի կարևոր մաս, այն պետք է ընդունվի մարդկանց կողմից: Այսպիսով, ո՞վ է հետաքրքրված սպասարկման ցանցով: Ո՞ւմ է ձեռնտու դրա օգտագործումը:
Եթե դուք մշակում եք ժամանակակից սերվերային ծրագրակազմ, կարող եք մոտավորապես պատկերացնել ձեր թիմը որպես խումբ ծառայության սեփականատերերըովքեր միասին զարգացնում և իրականացնում են բիզնես տրամաբանությունը, և հարթակի սեփականատերերըներգրավված է ներքին հարթակի մշակման մեջ, որի վրա գործում են այդ ծառայությունները: Փոքր կազմակերպություններում սրանք կարող են լինել նույն մարդիկ, բայց քանի որ ընկերությունը մեծանում է, այդ դերերը հակված են դառնալու ավելի ընդգծված և նույնիսկ ենթադերի… (Այստեղ շատ բան կա ասելու devops-ի փոփոխվող բնույթի մասին, միկրոծառայությունների կազմակերպչական ազդեցությունը և այլն): n. Բայց առայժմ, եկեք այս նկարագրությունները որպես կանոն ընդունենք):
Այս տեսանկյունից սպասարկման ցանցի հստակ շահառուները հարթակի սեփականատերերն են։ Ի վերջո, պլատֆորմի թիմի վերջնական նպատակն է ստեղծել ներքին հարթակ, որի վրա ծառայությունների սեփականատերերը կարող են իրականացնել բիզնես տրամաբանությունը և դա անել այնպես, որ երաշխավորի իրենց առավելագույն անկախությունը դրա գործունեության մռայլ մանրամասներից: Ծառայությունների ցանցը ոչ միայն առաջարկում է այս նպատակին հասնելու համար կարևոր հնարավորություններ, այլև դա անում է այնպես, որ, իր հերթին, որևէ կախվածություն չի առաջացնում ծառայության սեփականատերերից:
Ծառայությունների սեփականատերերը նույնպես շահում են, թեև ավելի անուղղակի կերպով: Ծառայության սեփականատիրոջ նպատակն է հնարավորինս արդյունավետ լինել բիզնես գործընթացի տրամաբանության իրականացման հարցում, և որքան քիչ անհանգստանա գործառնական խնդիրներով, այնքան լավ։ Օրինակ՝ նորից փորձելու քաղաքականություն կամ TLS կիրառելու փոխարեն, նրանք կարող են կենտրոնանալ բացառապես բիզնեսի վրա և հուսալ, որ հարթակը հոգ կտանի մնացածի մասին: Նրանց համար սա մեծ առավելություն է։
Պլատֆորմների և ծառայությունների սեփականատերերի միջև նման բաժանման կազմակերպչական արժեքը չի կարող գերագնահատվել: Կարծում եմ, որ նա նպաստում է հիմնական ներդրում ծառայության ցանցի արժեքին:
Մենք սովորեցինք այս դասը, երբ Linkerd-ի վաղ երկրպագուներից մեկը մեզ ասաց, թե ինչու են ընտրել ծառայության ցանցը, քանի որ այն թույլ է տվել նրանց «շարունակել խոսել նվազագույնի մասին»: Ահա որոշ մանրամասներ. մեկ խոշոր ընկերության տղաները տեղափոխեցին իրենց հարթակը Kubernetes: Քանի որ հավելվածն աշխատում էր զգայուն տեղեկատվության հետ, նրանք ցանկանում էին գաղտնագրել բոլոր հաղորդակցությունները կլաստերներում: Այնուամենայնիվ, իրավիճակը բարդացավ հարյուրավոր ծառայությունների և զարգացման հարյուրավոր թիմերի առկայությամբ: Բոլորի հետ կապ հաստատելու և նրանց համոզելու հեռանկարը, որ իրենց ծրագրերում ներառեն TLS-ի աջակցությունը, նրանց բոլորովին հաճելի չէր: Տեղադրելով Linkerd-ը՝ նրանք գաղթեցին պատասխանատվություն ծրագրավորողներից (որոնց տեսանկյունից դա ավելորդ անախորժություն էր) մինչև պլատֆորմներ, որոնց համար սա վերին մակարդակի առաջնահերթություն էր: Այսինքն՝ Linkerd-ը նրանց համար ոչ այնքան տեխնիկական խնդիր էր լուծում, որքան կազմակերպչական։
Մի խոսքով, սպասարկման ցանցը, ավելի շուտ, ոչ թե տեխնիկական լուծում է, այլ սոցիալ-տեխնիկական Խնդիրներ. (Շնորհակալություն այս տերմինի ներդրման համար։
Արդյո՞ք սպասարկման ցանցը կլուծի իմ բոլոր խնդիրները:
Այո՛։ Այսինքն՝ ոչ։
Նայելով վերը նշված հատկանիշների երեք դասերին՝ հուսալիություն, անվտանգություն և դիտելիություն, պարզ է դառնում, որ սպասարկման ցանցը այս խնդիրներից որևէ մեկի ամբողջական լուծումը չէ: Թեև Linkerd-ը կարող է կրկնակի հարցումներ ուղարկել (եթե գիտի, որ դրանք անզոր են), այն ի վիճակի չէ որոշումներ կայացնել այն մասին, թե ինչ վերադարձնել օգտատիրոջը, եթե ծառայությունը վերջնականապես դադարել է. նման որոշումները պետք է կայացվեն հավելվածի կողմից: Linkerd-ը կարող է վիճակագրություն պահել հաջողված հարցումների վերաբերյալ, սակայն այն ի վիճակի չէ ուսումնասիրել ծառայությունը և տրամադրել դրա ներքին չափումները. հավելվածը պետք է ունենա նման գործիքակազմ: Եվ չնայած Linkerd-ն ի վիճակի է հոսթինգի mTLS, անվտանգության լիարժեք լուծումները պահանջում են շատ ավելին:
Ծառայությունների ցանցի կողմից առաջարկվող այս տարածքների առանձնահատկությունների ենթախումբը կապված է հարթակի առանձնահատկությունները. Սրանով ես նկատի ունեմ գործառույթներ, որոնք.
- Անկախ բիզնես տրամաբանությունից. Foo-ի և Bar-ի միջև կանչի հիստոգրամների կառուցման ձևը լիովին անկախ է նրանից ինչու Foo-ն զանգում է Բարին:
- Դժվար է ճիշտ իրականացնել. Linkerd-ում կրկնվող փորձերը պարամետրացված են բոլոր տեսակի շքեղ նյութերով, ինչպիսիք են կրկնակի բյուջեները: (կրկին փորձեք բյուջեները), քանի որ նման բաների իրականացման պարզամիտ մոտեցումը, անշուշտ, կհանգեցնի այսպես կոչված «խնդրանքների ավալանշի» առաջացմանը։ (կրկին փորձեք փոթորիկ) և բաշխված համակարգերին հատուկ այլ խնդիրներ:
- Առավել արդյունավետ, երբ կիրառվում է հետևողականորեն. TLS մեխանիզմը իմաստ ունի միայն այն դեպքում, եթե կիրառվում է ամենուր:
Քանի որ այս հատկանիշներն իրականացվում են պրոքսի շերտում (և ոչ կիրառական շերտում), ծառայության ցանցը դրանք բացահայտում է հարթակ, ոչ հավելվածներ։ Այսպիսով, կարևոր չէ, թե ծառայությունները ինչ լեզվով են գրված, ինչ շրջանակ են օգտագործում, ով և ինչու է դրանք գրել։ Պրոքսիներն աշխատում են այս բոլոր մանրամասներից դուրս, և այս ֆունկցիոնալության հիմնարար հիմքը, ներառյալ կազմաձևման, թարմացման, շահագործման, պահպանման և այլնի խնդիրները, գտնվում են բացառապես հարթակի մակարդակում:
Սպասարկման ցանցի հնարավորությունների օրինակներ
Ամփոփելով, սպասարկման ցանցը հուսալիության, դիտարկելիության կամ անվտանգության ամբողջական լուծում չէ: Այս ոլորտների շրջանակը ենթադրում է ծառայության սեփականատերերի, Ops/SRE թիմերի և ընկերության այլ շահագրգիռ կողմերի պարտադիր մասնակցությունը: Ծառայության ցանցը միայն «հատված» է տրամադրում հարթակի մակարդակով այս տարածքներից յուրաքանչյուրի համար:
Ինչու՞ է սպասարկման ցանցը դարձել հայտնի հենց հիմա:
Դուք, հավանաբար, հենց հիմա մտածում եք. Լավ, եթե ծառայության ցանցն այդքան լավն է, ինչո՞ւ մենք չսկսեցինք միլիոնավոր վստահված սերվերներ տեղակայել տասը տարի առաջ:
Այս հարցին մի բանական պատասխան կա՝ տասը տարի առաջ բոլորը մոնոլիտներ էին կառուցում, և ոչ մեկին սպասարկող ցանցի կարիք չկար։ Սա ճիշտ է, բայց, իմ կարծիքով, այս պատասխանը բաց է թողնում իմաստը: Նույնիսկ տասը տարի առաջ միկրոծառայությունների հայեցակարգը, որպես լայնածավալ համակարգեր ստեղծելու խոստումնալից միջոց, լայնորեն քննարկվում և կիրառվում էր այնպիսի ընկերություններում, ինչպիսիք են Twitter-ը, Facebook-ը, Google-ը և Netflix-ը: Ընդհանուր ընկալումը, գոնե արդյունաբերության այն հատվածներում, որոնց հետ ես շփվել եմ, այն էր, որ միկրոծառայությունների «ճիշտ ճանապարհը» մեծ համակարգեր կառուցելու համար, նույնիսկ եթե դա անիծյալ դժվար էր:
Իհարկե, թեև տասը տարի առաջ կային միկրոծառայություններ շահագործող ընկերություններ, նրանք ամեն տեղ չէին կպցնում վստահված անձիք՝ սպասարկման ցանց ստեղծելու համար: Այնուամենայնիվ, եթե ուշադիր նայեք, նրանք նման բան արեցին. այս ընկերություններից շատերը պարտադրեցին օգտագործել հատուկ ներքին գրադարան ցանցի համար (երբեմն կոչվում է ճարպային հաճախորդների գրադարան, գեր հաճախորդի գրադարան).
Netflix-ն ուներ Hysterix, Google-ը՝ Stubby, Twitter-ը՝ Finagle գրադարանը: Finagle-ը, օրինակ, պարտադիր է եղել Twitter-ի յուրաքանչյուր նոր ծառայության համար: Այն մշակում էր կապերի և՛ հաճախորդի, և՛ սերվերի կողմը, թույլ էր տալիս կրկնակի հարցումներ կատարել, աջակցում էր հարցումների երթուղին, բեռի հավասարակշռումը և չափումը: Այն ապահովում էր հուսալիության և դիտելիության հետևողական շերտ Twitter-ի ողջ փաթեթում՝ անկախ նրանից, թե ինչ էր անում ծառայությունը: Իհարկե, այն աշխատում էր միայն JVM լեզուների համար և հիմնված էր ծրագրավորման մոդելի վրա, որը պետք է օգտագործվեր ամբողջ հավելվածի համար: Այնուամենայնիվ, դրա ֆունկցիոնալությունը գրեթե նույնն էր, ինչ սպասարկման ցանցը: (Իրականում, Linkerd-ի առաջին տարբերակը պարզապես Finagle-ն էր՝ փաթաթված վստահված անձի տեսքով):
Այսպիսով, տասը տարի առաջ գոյություն ունեին ոչ միայն միկրոսերվիսներ, այլ նաև հատուկ պրոտո-սերվիս ցանցային գրադարաններ, որոնք լուծում էին նույն խնդիրները, որոնք այսօր լուծում է սպասարկման ցանցը: Այնուամենայնիվ, սպասարկման ցանցն ինքնին այն ժամանակ գոյություն չուներ: Մինչև նրա հայտնվելը պետք է մեկ այլ տեղաշարժ լիներ:
Եվ հենց այստեղ է ավելի խորը պատասխանը, որը թաքնված է մեկ այլ փոփոխության մեջ, որը տեղի է ունեցել վերջին 10 տարիների ընթացքում. գրանցվել է միկրոծառայությունների տեղակայման ծախսերի կտրուկ անկում: Վերը նշված ընկերությունները, որոնք օգտագործում էին միկրոսերվիսներ մեկ տասնամյակ առաջ՝ Twitter-ը, Netflix-ը, Facebook-ը, Google-ը, հսկայական մասշտաբի և հսկայական ռեսուրսների ընկերություններ էին: Նրանք ոչ միայն ունեին անհրաժեշտություն, այլև միկրոծառայությունների վրա հիմնված մեծ հավելվածներ ստեղծելու, տեղակայելու և գործարկելու հնարավորություն: Այն էներգիան և ջանքերը, որոնք ներդրել են Twitter-ի ինժեներները՝ մոնոլիտից միկրոծառայությունների մոտեցման անցնելու համար, զարմանալի է: (Անկեղծ ասած, ինչպես այն փաստը, որ այն աշխատեց): Ենթակառուցվածքի նման մանևրումն այն ժամանակ անհնար էր փոքր ընկերությունների համար:
Անցնենք ներկային։ Այսօր կան ստարտափներ, որտեղ միկրոծառայությունների և մշակողների հարաբերակցությունը 5:1 է (կամ նույնիսկ ), և ավելին, նրանք հաջողությամբ հաղթահարում են դրանք: Եթե 5 հոգուց բաղկացած ստարտափն ի վիճակի է աշխատել 50 միկրոսերվիսներ առանց լարվածության, ապա ինչ-որ բան ակնհայտորեն նվազեցրեց դրանց իրականացման արժեքը:
1500 միկրոծառայություններ Monzo-ում; յուրաքանչյուր տող ցանցի սահմանված կանոն է, որը թույլ է տալիս երթևեկությունը
Միկրոծառայությունների գործառնական արժեքի կտրուկ նվազումը մեկ գործընթացի արդյունք է. տարաների աճող ժողովրդականություն и նվագախմբեր. Սա հենց այն հարցի խորը պատասխանն է, թե ինչն է նպաստել սպասարկման ցանցի առաջացմանը: Նույն տեխնոլոգիան գրավիչ դարձրեց ինչպես սպասարկման ցանցը, այնպես էլ միկրոծառայությունները՝ Kubernetes-ը և Docker-ը:
Ինչո՞ւ։ Դե, Docker-ը լուծում է մեկ մեծ խնդիր՝ փաթեթավորման խնդիրը։ Փաթեթավորելով հավելվածը և դրա (ոչ ցանցային) գործարկման ժամանակի կախվածությունը կոնտեյներով՝ Docker-ը հավելվածը վերածում է փոխարինելի միավորի, որը կարող է տեղակայվել և գործարկվել ցանկացած վայրում: Միևնույն ժամանակ, դա մեծապես հեշտացնում է աշխատանքը: բազմալեզու stack. Քանի որ կոնտեյները կատարման ատոմային միավոր է, նշանակություն չունի, թե ինչ է ներսում՝ լինի դա JVM, Node, Go, Python կամ Ruby հավելված՝ տեղակայման և գործառնական նպատակներով: Դուք պարզապես վարում եք այն և վերջ:
Kubernetes-ը ամեն ինչ տեղափոխում է հաջորդ մակարդակ: Այժմ, երբ կան մի շարք «գործարկվող իրեր» և շատ մեքենաներ դրանք գործարկելու համար, կարիք կա մի գործիքի, որը կարող է դրանք համապատասխանեցնել միմյանց: Լայն իմաստով, դուք Kubernetes-ին տալիս եք բազմաթիվ բեռնարկղեր և շատ մեքենաներ, և դրանք համընկնում են միմյանց հետ (իհարկե, սա դինամիկ և անընդհատ փոփոխվող գործընթաց է. նոր կոնտեյներներ են շարժվում համակարգով, մեքենաները սկսում և կանգ են առնում և այլն: Այնուամենայնիվ, Kubernetes-ը հաշվի է առնում այս ամենը):
Երբ Kubernetes-ը ստեղծվի, մեկ ծառայության տեղակայման և գործարկման համար պահանջվող ժամանակը շատ չի տարբերվում տասը ծառայությունների տեղակայման և գործարկման արժեքից (իրականում, դա գրեթե նույնն է 100 ծառայության համար): Ավելացրե՛ք այս տարաներին որպես փաթեթավորման մեխանիզմ, որը խրախուսում է բազմալեզու ներդրումը, և դուք կունենաք մի տոննա նոր հավելվածներ, որոնք ներդրված են որպես բազմաթիվ լեզուներով գրված միկրոծառայություններ, հենց այնպիսի միջավայր, որին այնքան հարմար է սպասարկման ցանցը:
Այսպիսով, մենք գալիս ենք այն հարցի պատասխանին, թե ինչու է ծառայողական ցանցի գաղափարը հայտնի դարձել հենց հիմա. միատեսակությունը, որը Kubernetes-ը տրամադրում է ծառայությունների համար, ուղղակիորեն կիրառելի է սպասարկման ցանցի առջև ծառացած գործառնական խնդիրների համար: Դուք վստահված անձինք փաթեթավորում եք տարաներում, Kubernetes-ին տալիս եք դրանք հնարավորինս կպցնելու խնդիր, և voila: Արդյունքում, դուք ստանում եք ծառայության ցանց, մինչդեռ Kubernetes-ը վերահսկում է իր տեղակայման բոլոր մեխանիզմները: (Առնվազն թռչնի տեսանկյունից: Իհարկե, այս գործընթացում շատ նրբերանգներ կան):
Ամփոփելով. այն պատճառով, որ ծառայության ցանցը հայտնի դարձավ այժմ և ոչ տասը տարի առաջ, այն է, որ Kubernetes-ը և Docker-ը ոչ միայն զգալիորեն աճել են: կարիք դրանում պարզեցնելով հավելվածների իրականացումը որպես բազմալեզու միկրոծառայությունների հավաքածու, բայց նաև զգալիորեն կրճատվել է ծախսերը դրա գործունեության համար՝ ապահովելով կողային վագոնների վստահված պարկերի տեղակայման և պահպանման մեխանիզմներ:
Ինչու՞ է այդքան խոսվում սպասարկման ցանցի մասին:
ԶգուշացեքԱյս բաժնում ես դիմում եմ բոլոր տեսակի ենթադրությունների, ենթադրությունների, կեղծիքների և ներքին տեղեկատվության:
«Ծառայողական ցանց» փնտրելու դեպքում կհայտնվի մի շարք վերամշակված, ցածր կալորիականությամբ բովանդակություն, տարօրինակ նախագծեր և աղավաղման կալեիդոսկոպ, որը արժանի է արձագանքման խցիկին: Ցանկացած գերժամանակակից նոր տեխնոլոգիա ունի սա, սակայն սպասարկման ցանցի դեպքում խնդիրը հատկապես սուր է: Ինչո՞ւ։
Դե, դա մասամբ ես եմ մեղավոր: Ես արել եմ ամեն ինչ, որպեսզի խթանեմ Linkerd-ը և ծառայության ցանցը ամեն հնարավորության դեպքում՝ անթիվ բլոգային գրառումների և այս մեկի նման հոդվածների միջոցով: Բայց ես այդքան էլ հզոր չեմ: Այս հարցին իսկապես պատասխանելու համար պետք է մի փոքր խոսել ընդհանուր իրավիճակի մասին։ Եվ այդ մասին անհնար է խոսել առանց մեկ նախագիծ նշելու. բաց կոդով ծառայությունների ցանց է, որը մշակվել է Google-ի, IBM-ի և Lyft-ի կողմից համատեղ:
(Այդ երեք ընկերությունները շատ տարբեր դերեր ունեն. Lyft-ի ներգրավվածությունը կարծես սահմանափակված է միայն անուններով. նրանք հեղինակում են Envoy-ը, բայց չեն օգտագործում կամ ներգրավված են Istio-ի մշակման մեջ: IBM-ը ներգրավված է Istio-ի մշակման մեջ և օգտագործում է այն: Google-ը մեծապես ներգրավված է ներգրավված է Istio-ի զարգացման մեջ, բայց որքանով ես կարող եմ ասել, իրականում չի օգտագործում այն:)
Istio նախագիծը աչքի է ընկնում երկու բանով. Նախ, դա այն հսկայական մարքեթինգային ջանքերն են, որոնք Google-ը, մասնավորապես, ներդրում է իր առաջխաղացման համար: Կարծում եմ, որ մարդկանց մեծամասնությունը, ովքեր ներկայումս տեղյակ են ծառայության ցանցի հայեցակարգին, առաջին անգամ իմացել են դրա մասին Istio-ի շնորհիվ: Երկրորդ առանձնահատկությունն այն է, թե որքան վատ ընդունեցին Իստիոյին։ Այս հարցում ես, ակնհայտորեն, շահագրգիռ կողմ եմ, բայց փորձելով մնալ հնարավորինս օբյեկտիվ, այնուամենայնիվ չեմ կարող չանել. , ոչ շատ կոնկրետ (չնայած ոչ եզակի. systemd-ը գալիս է մտքին, ...) բաց կոդով նախագծի համար:
(Գործնականում Istio-ն կարծես թե խնդիրներ ունի ոչ միայն բարդության և UX-ի, այլև կատարողականի հետ կապված։ Օրինակ՝ ընթացքում Երրորդ կողմի կողմից անցկացված փորձագետները հայտնաբերել են իրավիճակներ, երբ Իստիոյի պոչը 100 անգամ ավելի բարձր է եղել, քան Linkerd-ը, ինչպես նաև ռեսուրսների պակասի հետ կապված իրավիճակներ, երբ Linkerd-ը շարունակել է հաջողությամբ գործել, և Istio-ն ամբողջությամբ դադարել է աշխատել:
Մի կողմ թողնելով իմ տեսությունները, թե ինչու է դա տեղի ունեցել, ես կարծում եմ, որ ծառայության ցանցի շուրջ լայնածավալ աղմուկը պայմանավորված է Google-ի ներգրավմամբ: Մասնավորապես, հետևյալ երեք գործոնների համադրություն.
- Google-ի կողմից Istio-ի մոլուցքային խթանում;
- նախագծի նկատմամբ պատշաճ հավանություն, քննադատական վերաբերմունք.
- Kubernetes-ի վերջին սրընթաց ժողովրդականությունը, որի հիշողությունը դեռ թարմ է:
Միասին այս գործոնները միավորվում են մի տեսակ արբեցնող, անօքսիկ միջավայրի մեջ, որտեղ ռացիոնալ դատողության կարողությունը թուլանում է՝ թողնելով միայն տարօրինակ բազմազանություն: .
Լինկերդի տեսանկյունից սա… Ես դա կբնութագրեի որպես խառը օրհնություն: Ես նկատի ունեմ, որ հիանալի է, որ ծառայության ցանցը մտել է հիմնական հոսք, ինչը այդպես չէր 2016 թվականին, երբ առաջին անգամ հայտնվեց Linkerd-ը, և իսկապես դժվար էր մարդկանց ուշադրությունը գրավել նախագծի վրա: Հիմա նման խնդիր չկա՛։ Բայց վատ նորությունն այն է, որ սպասարկման ցանցի իրավիճակն այսօր այնքան շփոթեցնող է, որ գրեթե անհնար է պարզել, թե իրականում որ նախագծերն են պատկանում սպասարկման ցանցի կատեգորիային (չխոսելով՝ պարզելու, թե որն է լավագույնը կոնկրետ օգտագործման դեպքում): Սա, անշուշտ, խանգարում է բոլորին (և հաստատ որոշ դեպքերում Istio-ն կամ մեկ այլ նախագիծ ավելի լավն է, քան Linkerd-ը, քանի որ վերջինս բոլորի համար հարմար լուծում չէ):
Linkerd-ի կողմից մեր ռազմավարությունը եղել է անտեսել աղմուկը, շարունակել կենտրոնանալ համայնքի իրական խնդիրների լուծման վրա և, ըստ էության, սպասել, որ աղմուկը թուլանա: Ի վերջո, աղմուկը կթուլանա, և մենք կարող ենք խաղաղությամբ շարունակել աշխատել:
Մինչ այդ, մենք բոլորս պետք է համբերատար լինենք:
Արդյո՞ք սպասարկման ցանցը օգտակար կլինի ինձ՝ համեստ ծրագրաշարի ինժեներիս:
Հետևյալ հարցաշարը կօգնի պատասխանել այս հարցին.
Զբաղվու՞մ եք բացառապես բիզնես տրամաբանության իրականացմամբ։ Այս դեպքում սպասարկման ցանցը ձեզ օգտակար չի լինի։ Դա, իհարկե, ձեզ կարող է հետաքրքրել, բայց իդեալականորեն, սպասարկման ցանցը չպետք է ուղղակիորեն ազդի ձեր միջավայրում որևէ բանի վրա: Շարունակեք աշխատել այն բանի վրա, ինչի համար վճարվում եք:
Դուք հարթակ պահու՞մ եք մի ընկերությունում, որն օգտագործում է Kubernetes-ը: Այո, այս դեպքում ձեզ անհրաժեշտ է սպասարկման ցանց (իհարկե, եթե դուք չեք օգտագործում K8-ները միայն մոնոլիտ կամ խմբաքանակային մշակում գործարկելու համար, բայց հետո ես կցանկանայի հարցնել, թե ինչու են ձեզ անհրաժեշտ K8-ները): Ամենայն հավանականությամբ, դուք կհայտնվեք տարբեր մարդկանց կողմից գրված բազմաթիվ միկրոծառայությունների հետ կապված իրավիճակում։ Նրանք բոլորը փոխազդում են միմյանց հետ և կապված են գործարկման ժամանակի կախվածությունների խճճվածքի մեջ, և դուք պետք է ճանապարհ գտնեք այս ամենի դեմ պայքարելու համար: Kubernetes-ի օգտագործումը թույլ է տալիս ընտրել «ինքներդ ձեզ համար» սպասարկման ցանց։ Դա անելու համար ծանոթացեք նրանց հնարավորություններին և առանձնահատկություններին և պատասխանեք այն հարցին, թե արդյոք առկա նախագծերից որևէ մեկը ձեզ հարմար է (խորհուրդ եմ տալիս սկսել ձեր հետազոտությունը Linkerd-ով):
Դուք հարթակ եք վարում մի ընկերության համար, որը ՉԻ օգտվում Kubernetes-ից, այլ օգտագործում է միկրոսերվիսներ: Այս դեպքում սպասարկման ցանցը օգտակար կլինի ձեզ, բայց դրա օգտագործումը կլինի ոչ տրիվիալ: Իհարկե, դուք կարող եք ընդօրինակել սպասարկման ցանց՝ հոսթինգով մի խումբ վստահված անձանց, սակայն Kubernetes-ի կարևոր առավելությունը հենց տեղակայման մոդելն է. այս վստահված սերվերների ձեռքով պահպանումը կպահանջի շատ ավելի շատ ժամանակ, ջանք և ծախսեր:
Դուք պլատֆորմի պատասխանատուն եք մի ընկերությունում, որն աշխատում է մոնոլիտներով: Այս դեպքում, հավանաբար, ձեզ հարկավոր չէ սպասարկման ցանց: Եթե դուք աշխատում եք մոնոլիտների (կամ նույնիսկ մոնոլիտների հավաքածուների) հետ, որոնք ունեն հստակ սահմանված և հազվադեպ փոփոխվող փոխազդեցության օրինաչափություններ, ապա ծառայության ցանցը ձեզ քիչ բան ունի առաջարկելու: Այսպիսով, դուք կարող եք պարզապես անտեսել այն և հուսալ, որ այն կվերանա վատ երազի պես...
Ամփոփում
Հավանաբար, սպասարկման ցանցը դեռևս չպետք է անվանել «աշխարհի ամենահայտնի տեխնոլոգիան». այս կասկածելի պատիվը, հավանաբար, պատկանում է բիթքոյինին կամ AI-ին: Միգուցե նա առաջին հնգյակում է: Բայց եթե դուք ճեղքեք աղմուկի և աղմուկի շերտերը, պարզ է դառնում, որ ծառայության ցանցը իրական օգուտներ է բերում նրանց, ովքեր հավելվածներ են ստեղծում Kubernetes-ում:
Ես կցանկանայի, որ դուք փորձեք Linkerd-ը՝ տեղադրելով այն Kubernetes կլաստերում (կամ նույնիսկ Minikube-ը նոութբուքի վրա) և դուք ինքներդ կարող եք տեսնել, թե ինչի մասին եմ խոսում:
FAQ
- Եթե ես անտեսեմ սպասարկման ցանցը, այն կվերանա:
- Պետք է հիասթափեցնեմ ձեզ. սպասարկման ցանցը մեզ մոտ վաղուց է։
— Բայց ես ՉԵՄ ՈՒԶՈՒՄ օգտագործել սպասարկման ցանց:
-Դե պետք չէ! Պարզապես կարդացեք իմ հարցաթերթիկը վերևում, որպեսզի տեսնեք, թե արդյոք պետք է գոնե ծանոթանաք դրա հիմունքներին:
— Հին լավ հին ESB/middleware չէ՞ նոր սոուսով:
- Ծառայությունների ցանցը վերաբերում է գործառնական տրամաբանությանը, ոչ թե իմաստային: ձեռնարկության սպասարկման ավտոբուս () Այս տարանջատումը պահելը օգնում է սպասարկման ցանցին խուսափել նույն ճակատագրից:
- Ինչպե՞ս է ծառայության ցանցը տարբերվում API դարպասներից:
Այս թեմայով միլիոն հոդված կա: Պարզապես google.
Արդյո՞ք Envoy-ը սպասարկման ցանց է:
- Ոչ, Envoy-ը սպասարկման ցանց չէ, այլ պրոքսի սերվեր է: Այն կարող է օգտագործվել սպասարկման ցանց կազմակերպելու համար (և շատ ավելին. դա ընդհանուր նշանակության վստահված անձ է): Բայց ինքնին դա սպասարկման ցանց չէ։
- Network Service Mesh - դա սպասարկման ցանց է:
- Ոչ: Չնայած անվանմանը, սա սպասարկման ցանց չէ (ինչպե՞ս եք սիրում մարքեթինգի հրաշքները):
- Արդյո՞ք ծառայության ցանցը կօգնի իմ ռեակտիվ ասինխրոն համակարգին, որը հիմնված է հաղորդագրությունների հերթի վրա:
- Ոչ, սպասարկման ցանցը ձեզ չի օգնի։
- Ո՞ր սպասարկման ցանցը պետք է օգտագործեմ:
- , ոչ մի խելացի։
- Հոդվածը խեղճ է: / Հեղինակը` օճառի վրա:
— Խնդրում եմ կիսվեք դրա հղումը ձեր բոլոր ընկերների հետ, որպեսզի նրանք համոզվեն դրանում:
Շնորհակալագրեր
Ինչպես կարող եք կռահել վերնագրից, այս հոդվածը ոգեշնչված է Ջեյ Կրեպսի ֆանտաստիկ տրակտատից.«. Ես հանդիպել եմ Ջեյին տասը տարի առաջ, երբ հարցազրույց էի տալիս Linked In-ում, և այդ ժամանակվանից նա ինձ համար ոգեշնչում է:
Թեև ես սիրում եմ ինձ անվանել «Linkerd ծրագրավորող», իրականությունն այն է, որ ես ավելի շատ README.md ֆայլի պահպանող եմ նախագծում: Այսօր աշխատում է Linkerd-ի վրա , , մարդիկ, և այս նախագիծը հնարավոր չէր լինի առանց ներդրողների և օգտատերերի զարմանալի համայնքի:
Եվ վերջապես, հատուկ շնորհակալություն Linkerd-ի ստեղծողին, (primus inter pares), ով տարիներ առաջ ինձ հետ միասին գլխապտույտ սուզվեց սպասարկման ցանցի հետ կապված այս ամբողջ աղմուկի մեջ։
PS թարգմանչից
Կարդացեք նաև մեր բլոգում.
- «";
- «";
- «";
- «";
- «.
Source: www.habr.com