Համար. թարգմանություն.: Service mesh - այս երևույթը դեռևս չունի հաստատուն թարգմանություն ռուսերենում (երկու տարի առաջ առաջարկել էինք «ծառայությունների ցանց» տարբերակը, իսկ մի փոքր ուշ որոշ գործընկերներ սկսեցին ակտիվորեն տարածել «ծառայությունների լուծույթ» համադրությունը): Տեխնոլոգիայի շուրջ մշտական խոսակցությունները հանգեցրել են ցավալին, որ շատ մոտ է միմյանցMarketing-յան և տեխնիկական բաղադրիչները: Այս հրաշալի նյութը, որը ներկայացնում է հորինողներից մեկի մասին, նպատակ ունի պարզություն բերել ինժեներների և ոչ միայն նրանց համար.
Կոմիկս ան
Ներածություն
Եթե դուք ծրագրային ինժեներ եք, աշխատող որևէ տեղ հետևյալ բեքենդ համակարգերի շուրջ, «service mesh» տերմինը հավանական է, որ արդեն հաստատվել է ձեր գիտակցության մեջ վերջին երկու տարվա ընթացքում: Անբարենպաստ հանգամանքների պատճառով այս արտահայտությունը ավելի ու ավելի է գրավում արդյունաբերությունը, իսկ շղարշը և նրանով կապված գովազդային առաջարկները աճում են ինչպես ձյան գնդիկը, որը գլորվում է լանջից ներքև և որևէ նշան չի տալիս դանդաղելու.
Service mesh-ը ծնունդ է առել ամպային բնույթի էկոլոգիաների մութ, կասկածելի ջրերում: Ցավոք, սա նշանակում է, որ նրան առնչվող վեճերը տատանվում են «ցածր կալորիականության զրույցից» մինչև - եթե օգտագործենք 기술ական տերմին - հապշտուսություն: Սակայն, եթե հեռացնենք ողջ աղմուկը, կարող ենք բացահայտել, որ service mesh-ը ունի բավական իրական, որոշակի և կարևոր գործառույթ.
Այս հրապարակման մեջ ես փորձում եմ անել հենց դա: ներկայացնել ազնվական, խորացված, ինժեներների վրա կենտրոնացած ուղեցույց service mesh-ի վերաբերյալ: Ես պատրաստվում եմ պատասխանել ոչ միայն հարցին: «Ինչ է դա?», - բայց նաև «Ինչու՞», ինչպես նաև «Իրականում հիմա?». Մի վերջում, ես փորձելու եմ նկարագնել, թե ինչու (իմ կարծիքով) այս տեխնոլոգիան առաջացրել է այդքան մոլեգին աղմուկ, ինչը ինքնին հետաքրքիր պատմություն է.
Ո quién ինձ:
Ողջույն բոլորին! Իմ անունը . Ես являюсь одним из создателей - առաջին service mesh նախագծի և նախագծի, որը պատասխանատվություն է կրում տերմինի առաջացման համար սերվիսային ցանց ինչպես այդպիսին (ներեցեք, տղերք!). (Прим перев.: Ասելու համար, այս տերմինի ծագման սկզբում, ավելի քան 2.5 տարի առաջ, մենք արդեն թարգմանել էինք նույն հեղինակին պատկանող վաղ նյութը, կոչվում է «».) Ես նաև ղեկավարում եմ - ստարտափ, որը занимается созданием таких классных service mesh-штук, как Linkerd և .
Դուք, հավանաբար, ենթադրում եք, որ ես ունեմ բավականաչափ կողմնակալ և սուբյեկտիվ կարծիք այս հարցի շուրջ: Այնուամենայնիվ, ես փորձելու եմ նվազեցնել հակումները (բացառությամբ մեկ բաժնի: «Ինչու է service mesh-ի շուրջ tantas խոսակցություններ», — որտեղ կիսվելու եմ իմ կողմնակալ մտքերով): Երևի կունենամ ամբողջ ջանքը, որպեսզի այս ձեռնարկը դառնա հնարավոր ամենայն օբյեկտիվը: Կոնկրետ օրինակներում հիմնականում կհենվեմ Linkerd-ի փորձի վրա, միաժամանակ նշելով ինձ հայտնի տարբերությունները (եթե դրանք կան) այլ տեսակի service mesh-երի իրականացման մեջ։
Լավ, ժամանակն է անցնելու համեղ բաներին:
Ի՞նչ է service mesh-ը:
Գոնե հիպի միջավայրում, structure-wise service mesh-ը բավականին պարզ է: Սա ընդամենը մի խումբ userspace-պրոքսիներ են, որոնք «կողքին» են ծառայությունների (քանի որ հետո մի փոքր կխոսենք, թե ինչ է նշանակում «կողքին»), և մի շարք կառավարման գործընթացներ: Պրոքսիները միասին կոչվում են data plane, իսկ կառավարող գործընթացները կոչվում են control plane: Data plane-ը որսում է ծառայությունների միջև զանգերը և անում նրանց հետ «տարբեր բաներ»; control plane-ը, համապատասխանաբար, համակարգում է պրոքսիների վարքը և ապահովում է ձեզ համար, այսինքն՝ օպերատորին, մուտք դեպի API, հնարավորություն տալով տիրապետել ցանցին և չափել այն որպես ամբողջություն։
Ի՞նչ է այս պրոքսիները: Սա Layer 7-aware TCP պրոքսի է (այսինքն՝ «անդրադառնում» է OSI մոդելի 7-րդ մակարդակին) , օրինակ՝ HAProxy և NGINX: Կարող եք ընտրել պրոքսի ըստ ձեր համեղության; Linkerd-ը օգտագործում է պրոքսի Rust-ում, որը կոչվում է . Մենք դա հավաքել ենք հատուկ service mesh-ի համար: Այլ mesh-երը նախընտրում են այլ պրոքսիներ (Envoy-ը հաճախակի ընտրություն է): Սակայն պրոքսի ընտրությունը պարզապես իրականացման հարց է:
Ինչ են անում այս պրոքսի սերվերները? Անկասկած, նրանք պրոքսավորում են զանգերը ծառայությունների և դրանց հետ (աթռչում, նրանք կատարում են պրոքսի և հակադարձ պրոքսի ֆունկցիաներ, մշակելով ինչպես մուտքային, այնպես էլ ելքային զանգերը): Եվ նրանք իրականացնում են մի շարք ֆունկցիաներ, որոնք կենտրոնացած են զանգերի վրա ծառայությունների միջև: Այս ֆոկուսը ծառայությունների միջև երթևեկության վրա տարբերում է service mesh-պրոքսիները, օրինակ, API gateways կամ ingress-proxies (վերջիններս կենտրոնանում են փականի դեպի կլաստեր եկող զանգերի վրա): : Kubernetes-ի համար գոյություն ունեցող Ingress controllers-ի համեմատություն, որոնցից շատերը օգտագործում են արդեն նշված Envoy-ը, տես (Համար. թարգմանություն.Այդպիսով, մենք հասկացել ենք data plane-ը: Control plane-ը ավելի պարզ է կառուցված. դա բաղկացած է մի շարք բաղադրիչներից, որոնք ապահովում են անհրաժեշտ բոլոր մեխանիզմները, որպեսզի data plane-ը աշխատի համակարգված, ներառյալ ծառայությունների հայտնաբերում, TLS սերտիֆիկատների թողարկում, մետրիկների հավաքագրում և այլն: Data plane-ը տեղեկացնում է control plane-ին իր վարքի մասին; իր հերթին, control plane-ը տրամադրում է API, որը թույլ է տալիս փոխել և հետևել data plane-ի վարքին որպես մեկ ամբողջություն։ .)
Ահա ներքևում Linkerd-ի control plane-ի և data plane-ի սխեման: Ինչպես տեսնում եք, control plane-ը ներառում է մի քանի տարբեր բաղադրիչներ, այդ թվում՝ Prometheus-ի օրինակ, որը հավաքում է մետրիկներ պրոքսի սերվերներից, ինչպես նաև այլ բաղադրիչներ, ինչպիսիք են
(ծառայությունների հայտնաբերում), destination identity (սերտիֆիկացման կենտրոն, CA) և public-api public-api (web և CLI-ի համար endpoint-ներ). Ունկնդրել, data plane-ը պարզ linkerd-proxy է application's ամրակից: Սա պարզապես տրամաբանական սխեմա է; իրական աշխարհում տեղակայման ժամանակ կարող եք ունենալ control plane-ի յուրաքանչյուր բաղադրիչի երեք կրկնօրինակումներ և hundreds կամ հազարավոր proxies data plane-ում:
(Այս սխեմայում կապույտ ուղղանկյունները խորհրդանշում են Kubernetes pod-երի սահմանները: Հստակ երևում է, որ linkerd-proxy կոնտեյներները գտնվում են application's կոնտեյներների հետ միասին մի pod-ում: Այսպիսի սխեմատիկը հայտնի է որպես sidecar-container.)
service mesh- ի ճարտարապետությունը մի քանի կարևոր հետևանք ունի: Առաջին հերթին, քանի որ proxies- ի խնդիրը ծառայությունների միջև զանգեր գրավելն է, service mesh- ը իմաստ ունի միայն այն դեպքում, եթե ձեր applucation-ը ստեղծվել է որոշակի ծառայությունների հավաքածուի վրա: Mesh կարելի է պետք է օգտագործել մոնոլիտների հետ, սակայն սա ակնհայտորեն ավելորդ է միայն մեկ proxy-ի համար, և դրա ֆունկցիոնալությունը հազիվ թե պահանջ լինի:
Մյուս կարևոր հետևանքը դա է, որ service mesh-ը պահանջում է հսկայական համակարգիչների քանակ: Իրականում, Linkerd-ն բերում է linkerd-proxy-ն յուրաքանչյուր ծառայության յուրաքանչյուր օրինակին (այլ իրագործումները proxies-ները ավելացնում են յուրաքանչյուր հանգույցի/հոստի/անվերջաչափի: Ցանկացած դեպքում, սա ոչ քիչ չէ): Այսքան ակտիվ proxy-ների օգտագործումը ինքնին մի շարք լրացուցիչ բարդություններ է նշանակում:
- Data plane-ում proxies պետք է լինեն արագ, քանի որ յուրաքանչյուր զանգի համար լինում է proxy-ներին երկուսը հասանելիություն: մեկը հաճախորդի կողմից, մի ուրիշը՝ սերվերի կողմից:
- Նաեւ proxies-ը պետք է լինեն շնորհք և հեշտ. Յուրաքանչյուրն կօգտագործի հիշողության և CPU ռեսուրսներ, և այդ օգտագործումը կլինի գծային աճի հետ միասին application's:
- Դուք կպահանջեք մեխանիզմ տարբեր proxy-ների մեծ քանակության տեղադրմանը և թարմացմանը: Սա ձեռքով անելն աննվազելի է:
Ընդհանուր առմամբ, service mesh-ն այսպես է թվում (առանցք տարածքից): դուք տեղադրում եք մի քանի userspace proxies, որոնք «ինչ-որ բան անում են» ներքին, միջսարք հաղորդակցությունների հետ, և օգտագործում եք control plane-ը հետևող և կառավարելու համար:
Երեկվա հերթը հարցական է «Ինչու»:
Ինչի համար է service mesh-ը անհրաժեշտ:
Այն անձանց համար, ովքեր առաջին անգամ հանդիպում են service mesh գաղափարին, ընդունելի է զգալ մի փոքր վախ: Service mesh կառուցվածքը նշանակում է, որ այն ոչ միայն կավելացնի տեղափոխման ժամանակները, այլ նաև գտնում է էլ ավելի ռեսուրսներ և ավելացրած իրավունքներով նոր մեխանիզմներ: Թողնում եք service mesh, և հանկարծ հայտնաբերում եք, որ պետք է սպասարկել հարյուրներ (եթե ոչ հազարավոր) proxies: Հարցնում են, ով և ինչու պատրաստ կլինի դա անել:
Այս հարցի պատասխանն ունի երկու մաս: Առաջին հերթին, այս proxies-ի զարգացման հետ կապված գործողական ծախսերը կարող են զգալիորեն նվազեցնել որոշակի փոփոխություններով, որոնք տեղի են ունենում էկոհամակարգում (լրացուցիչ տեղեկություններ ավելի ուշ):
Երկրորդ, նման սարքը իսկապես գերազանց միջոց է համակարգում լրացուցիչ տրամաբանություն մտցնելու համար։ Սա տեղի է ունենում ոչ միայն այն պատճառով, որ service mesh-ի միջոցով հնարավոր է ավելացնել բազմաթիվ նոր գործառույթներ, այլև որովհետեւ դա կարելի է անել էկոհամակարգին միջամտելու առանց։ Իրականում service mesh մոդելի ամբողջ հիմքը հիմնված է այս ասույթի վրա՝ բազմաֆունկցիոնալ համակարգում, անկախ նրանից՝ ինչպես աշխատում են անձինց ծառայությունները, երթևեկությունը միջև նրանց
կազմում է կատարյալ կետ նոր գործառույթներ ավելացնելու համար։
- Օրինակ, Linkerd-ում (ինչպես և մեծ հաշվով բոլոր mesh-երում) գործառույթը առավելապես կենտրոնացված է HTTP կոչերի վրա, ներառյալ HTTP/2 և gRPC*։ Գործառույթը շատ հարուստ է՝ այն կարելի է հանել երեք դասերի։ Հուսալլիկությանառնչվող գործառույթներ։ Վերադարձումներ, ժամանակացույցեր, կարանտինային մոտեցում (երթևեկության բաժանում/վերադարձում) և այլն։
- Օրինակ, Linkerd-ում (ինչպես և մեծ հաշվով բոլոր mesh-երում) գործառույթը առավելապես կենտրոնացված է HTTP կոչերի վրա, ներառյալ HTTP/2 և gRPC*։ Գործառույթը շատ հարուստ է՝ այն կարելի է հանել երեք դասերի։ մոնիթորինգիգործառույթներ։ Յուրաքանչյուր ծառայության կամ առանձին ուղղությունների հաջողության, ուշացումի և հարցումների ծավալների ցուցանիշների համախմբում; ծառայությունների տոպոլոգիական քարտերի կառուցում և այլն։
- Օրինակ, Linkerd-ում (ինչպես և մեծ հաշվով բոլոր mesh-երում) գործառույթը առավելապես կենտրոնացված է HTTP կոչերի վրա, ներառյալ HTTP/2 և gRPC*։ Գործառույթը շատ հարուստ է՝ այն կարելի է հանել երեք դասերի։ անվտանգությանգործառույթներ։ Mutual TLS, մուտքի վերահսկում և այսպես далее։
* Linkerd-ի տեսանկյունից gRPC-ն գրեթե չի տարբերվում HTTP/2-ից. պարզապես օգտակար բեռը օգտագործում է protobuf։ Զարգացողների համար այս երկու բաները, բնականաբար, տարբերվում են։
Այս մեխանիզմներից շատերը աշխատում են հարցումների մակարդակում (այդ պատճառով էլ «L7-պրոքսի» արժեքագրման կարգ). Օրինակ, եթե Foo ծառայությունը HTTP-կոչում է Bar ծառայությանը, linkerd-proxy-ն Foo-ի կողմից կարող է իրականացնել ինտելեկտուալ բեռների բաշխում և ուղղել Foo-ի կոչերը Bar-ի օրինակներին՝ ուշադրության տակ պահած ուշացման հիման վրա; այն կարող է կրկնել հարցումը անհրաժեշտության դեպքում (և եթե այն իդեմպոտենտ է); կարող է գրանցել պատասխանային կոդը և սպասման ժամանակը և այլն։ Անալոգիկորեն linkerd-proxy-ն Bar-ի կողմից կարող է մերժել հարցումը, եթե այն թույլատրված չէ կամ հարցումների սահմանը գերազանցված է; կարող է ամրագրել ուշացումը իր կողմից և այլն։
Պրոքսիները կարող են "ինչ-որ բան անել" նաև միացման մակարդակում։ Օրինակ, linkerd-proxy-ն Foo-ի կողմից կարող է սկսել TLS-միացում, իսկ linkerd-proxy-ն Bar-ի կողմից կարող է այն կիսատ թողնել, և երկու կողմերն էլ կարող են ստուգել իրենց TLS- վկայականները*։ Սա ապահովում է ոչ միայն ծառայությունների միջև գաղտնագրում, այլև ծառայությունների ինքնության հաստատման համար քրիպտոգրաֆիկորեն անվտանգ եղանակ՝ Foo-ն և Bar-ը կարող են "հաստատել", որ նրանք նրանք են, ինչպիսին են ասում։
* "Մեկմեկու" նշանակում է, որ հաճախորդի վկայականը ևս ստուգվում է (mutual TLS)։ " cl-ըննների "TLS-ում, օրինակ, միջև բրաուզերի և սերվերի, սովորաբար ստուգվում է միայն մեկ կողմի (սերվերի) վկայականը։
Այն դեպքում, երբ նրանք աշխատում են հարցումների կամ միացման մակարդակում, կարևոր է նշել, որ service mesh-ի բոլոր գործառույթները գործիքային Linkerd-ն չի կարողանում փոխարկել բեռնափոխակման սեմանտիկան՝ օրինակ, JSON-պարունակության մեջ դաշտեր ավելացնել կամ protobuf-ում փոփոխություններ կատարել։ Այս կարևոր առանձնահատկության մասին մենք կխոսենք ավելի ուշ, երբ խոսքը գնա ESB-ի և միջգործառույթների շուրջ։
Եվ սա է սերվիսային ցանցի առաջարկած գործառույթների հավաքածուն։ Հարց է առաջանում՝ ինչու դրանք անմիջապես ծրագրային մեջ չիրագործել։ Եվ ինչու בכלל զբաղվել պրոքսիով։
Ինչու է սերվիսային ցանցը լավ գաղափար
Այնուամենայնիվ, սերվիսային ցանցի հնարավորությունները captivating են, դրա հիմնական արժեքն իրականում ոչ թե գործառույթներն են։ Ավելին, մենք կարող ենք իրագործել դրանք անմիջապես ծրագրային մեջ (ուշով մենք կտեսնենք, որ սերվիսային ցանցի ծագումը հենց այդպես է եղել)։ Եթե այս միտքը փորձենք արտահայտել մի նախադասությամբ, սերվիսային ցանցի արժեքը հետևյալում է. այն տրամադրում է հարկադիր գործառույթներ, որոնք կարևոր են ժամանակակից սերվերային ծրագրակազմի աշխատանքների համար, միատեսակ ամբողջ կույտի համար և անկախ ծրագրի կոդից։.
Ուղևորենք այս նախադասությունը։
«Հարկադիր գործառույթներ, որոնք կարևոր են ժամանակակից սերվերային ծրագրակազմի աշխատանքի համար։ Եթե դուք ստեղծում եք հերթական սերվերային ծրագիր, որն առնչվում է հանրային ինտերնետին, ընդունում է հարցումներ արտաքին աշխարհից և պատասխան գալիս է դրանց վրա կարճ ժամանակահատվածում՝ օրինակ՝ վեբ ծրագիր, API-սերվեր, կամ ընդհանուր մեծամասնություն այլ ժամանակակից ծրագրերի, եթե դուք իրականացնում եք այն որպես ծառայությունների հավաքածու, որոնք սինխրոն կերպով միմյանց հետ փոխազդում են և եթե դուք մշտապես արդիականացնում եք այդ ծրագրակազմը՝ ավելացնելով նոր հնարավորություններ, և եթե դուք ստիպված եք պահել այս համակարգը աշխատունակ վիճակում բարելավումների գործընթացում՝ այս դեպքում շնորհավորում եմ ձեզ, դուք զբաղվում եք ժամանակակից սերվերային ծրագրի ստեղծմամբ։ Եվ բոլորը այդ հրաշալի գործառույթները, որոնք վերոհիշյալ թվարկված էին, իրականում պարզվում են, որ կարևոր են ձեզ համար։ Ծրագրատեսակը պետք է լինի վստահելի, անվտանգ, և դուք պետք է ունեք կարողություն դիտելու, թե ինչ է անում այն։ Իհարկե այս հարցերը լուծելու մեջ օգնում է սերվիսային ցանցը։
(Լավ, նախորդ նախադասությունում իմ համոզմունքները, որ այս մոտեցումը ժամանակակից եղանակ է ստեղծելու սերվերային ծրագրերը, ինչ որ կերպ ներթափանցեցին։ Կան մարդիկ, ովքեր նախընտրում են մշակումներ անել մոնոլիթներ, «ռեակտիվ միկրոսերվիսներ» և այլ բաներ, որոնք չեն համապատասխանում վերևում ներկայացված սահմանմանը։ Այս մարդկանց, բնականաբար, կարող է լինել իր կարծիքը, որը տարբեր է իմ կարծիքից։ Եվ ես կարծում եմ, որ նրանք «չեն ճիշտ»՝ չնայած այն է, որ սերվիսային ցանցը նրանց համար այնքան էլ կօգնի։)
«Միատեսակ ամբողջ կույտի համար»Service mesh-ի կողմից տրամադրվող ֆունկցիաները ոչ միայն չափազանց կարևոր են։ Դրանք կիրառվում են բոլոր ծառայությունների վրա հավելվածում, անկախ նրանից, թե ինչ լեզվով են դրանք գրված, ինչ ֆրեյմվորկ են օգտագործում, ով է դրանք գրել, ինչպես են դրանք տեղադրվել և բոլոր մյուս细节երի վերաբերյալ:
«Դիտարկելով հավելվածի կոդի անկախությունը»Ավարտելով, service mesh-ը ոչ միայն տրամադրում է համահունչ գործառույթներ ողջ ստեկի համար, այլև դա իրականացվում է այնպես, որ հավելվածը չի պահանջում փոփոխություններ։ Service mesh-ի գործառույթների հիմքը, ներառյալ կարգավորում, թարմացում, շահագործում, սպասարկում և այլն, բացառապես գտնվում է платформայի մակարդակում և անկախ է հավելվածից։ Ավելացվածը կարող է փոխվել՝ չքանդելով service mesh-ը, իսկ service mesh-ը կարող է փոխվել՝ հավելվածի անմասնությամբ։
Հակիրճ ասած, service mesh-ը ոչ միայն տրամադրում է կենսական կարևոր ֆունկցիա, այլ նաև դա անում է գլոբալ, համահունչ և անկախ հավելվածից ձևով։ Եվ այդ պատճառով, չնայած service mesh-ի գործառույթները կարող են իրականացվել ծառայության կոդում (օրինակ, թե՛ գրադարանների տեսքով, որոնք ներառված են յուրաքանչյուր ծառայությունում), այս մոտեցումը չի ապահովի համաչափություն և անկախություն, որոնք որքան շատ արժեք են ներկայացնում service mesh-ի դեպքում։
Եվ ամեն ինչ, ինչ անհրաժեշտ է դրա համար,՝ ավելացնել մի շարք պրոքսիներ։ ՀPromises, շատ շուտով մենք կդիտարկենք այս պրոքսիների ավելացման հետ կապված գործառնության ծախսերը։ Բայց նախ թույլ տվեք կանգ առնել և նայել այս անկախության գաղափարին տարբեր տեսանկյուններից: լ mennesker.
Ովքե՞ր են օգնում service mesh-ին։
Որքան անխռով հայտարարություն լիներ դա, սակայն ինչ-որ տեխնոլոգիայի կարևորագույն մասը էկոհամակարգի անհրաժեշտություն է դարձել, այն պետք է ընդունվել մարդկանց կողմից։ Ուրիշ ով հետաքրքրված է service mesh-ով։ Ով է շահում դրա օգտագործումից։
Եթե դուք ստեղծում եք ժամանակակից սերվերային սո՞ւյց, ապա կարող եք մոտավորապես պատկերացնել ձեր թիմը որպես մի խումբ ծառայությունների սեփականատերեր,որոնք միասին մշակել և կիրառել են բիզնեսի տրամաբանությունը, և հարթակի սեփականատերեր,ովքեր զբաղվում են այդ ծառայությունների աշխատանքի գետնին платформայի մշակմամբ։ Փոքր կազմակերպություններում դա կարող են լինել одու ՝ նույն մարդիկ, սակայն ընկերության աճելու հետ, այս դերերը որպես կանոն ավելի ակնառու են դառնում և անգամ բաժանվում են ենթադրված դերերի… (Այստեղ կարող է շատ բան ասել devops-ի փոխվող բնույթի մասին, միկրոծառայությունների կազմակերպական ազդեցության և այլն։ Բայց մինչ այդ, եկեք ընդունենք այս նկարագրությունները որպես կաություն)։
Այս տեսանկյունից, ծառայության ցանցի ակնհայտ օգուտ beneficiaries-ներն են պլատֆորմի սեփականատերերը: Արդյունքում, պլատֆորմի թիմի նպատակն է ստեղծել ներքին պլատֆորմ, որտեղ ծառայությունների սեփականատերերը կարող են իրականացնել բիզնես տրամաբանությունը և անել դա այնպես, որ առավելագույնս անկախ լինեն նրա շահագործման մութ մանրամասներից: Ծառայության ցանցը ոչ միայն առաջարկում է տարբերակներ, որոնք կարևոր են այս նպատակին հասնելու համար, այլ նաև անում է դա կերպով, որը, իր հերթին, չի impose պարտավորություններ ծառայությունների սեփականատերերի նկատմամբ.
Ծառայությունների սեփականատերերը նույնպես օգուտ են ստանում, թեև ավելի միջին կերպով: Ծառայության սեփականատերերի նպատակն է առավելագույնս արդյունավետ լինել բիզնես գործընթացի տրամաբանության իրականացման մեջ, իսկ որքան քիչ են նրանք անհանգստանում շահագործության հարցերի մասին, այնքան ավելի լավ է: Փոխարենը, որ զբաղվեն, ասենք, նոր պահանջների քաղաքականությունների կամ TLS-ի իրականացմանը, նրանք կարող են կենտրոնանալ բացառապես բիզնեսի խնդիրների վրա և հուսալ, որ պլատֆորմը հոգ կտանի բոլոր մյուսի մասին: Դրանց համար դա մեծ առավելություն է.
Պլատֆորմի և ծառայությունների սեփականատերերի միջև նման բաժանման կազմակերպչական արժեքը դժվար է գերագնահատել: Կարծում եմ, որ այն ներդրում է հիմնական ծառայության ցանցի արժեքի մեջ.
Մենք սովորեցինք այս դասը, երբ Linkerd-ի առաջին սիրահարներից մեկը պատմեց մեզ,为什么他们选择了服务网：因为它让他们“把谈话降至最低”。 Вот немного подробностей: ребята из одной крупной компании мигрировали свою платформу в Kubernetes. Поскольку приложение работало с конфиденциальной информацией, они хотели зашифровать все коммуникации в кластерах. Однако ситуация осложнялась наличием сотен сервисов и сотен команд разработчиков. Перспектива связываться со всеми и убеждать внести поддержку TLS в свои планы совершенно их не радовала. Установив Linkerd, они перенесли պատասխանատվությունը մշակումներից (որը, ըստ նրանց, ավելորդ խնդիրներ էին) պլատֆորմի ներկայացուցիչներին, որոնց համար սա ավելի բարձր մակարդակի առաջնահերթություն էր: Առաջնեկերդ, Linkerd-ը նրանց համար լուծեց այնքան տեխնիկական, որքան կազմակերպչական խնդիր:
Կարճ ասած, ծառայության ցանցը հիմնականում լուծում է ոչ տեխնիկական, այլ սոցիո-տեխնիկական բարդության: (Շնորհակալություն այս տերմինի ծանոթացման համար.)
Խնդիրները լուծի՞ ծառայության ցանցը բոլորիս:
Այո: Քանի որ, ոչ!
Երբ նայում ենք վերևում նշված երեք գործառույթների դասարաններին՝ հուսալիություն, անվտանգություն և դիտարկելիություն, պարզ է, որ service mesh-ը լիարժեք լուծում չէ այս խնդիրների համար։ Չնայած որ Linkerd-ն կարող է կրկնել հարցումները (եթե գիտի, որ դրանք ընդհանրական են), այն չի կարող որոշել, թե ինչ վերադարձնել օգտվողին, երբ ծառայությունը վերջնականապես ընկնում է՝ նման որոշումները պետք է կայացնի ծրագիրը։ Linkerd-ն կարող է统计ացնել հաջող հարցումները, սակայն չի կարող տեսնել ծառայություն և տրամադրել դրա ներքին մետրիկաները՝ նման գործիքները պետք է լինի ծրագրի մատակարարման մեջ։ Չնայած որ Linkerd-ն կարող է կազմակերպել mTLS, ամենաերկարահասակը անվտանգության ապահովման մեջ պահանջում է շատ ավելի մեծ բաներ։
Այս ոլորտներում service mesh-ի կողմից առաջարկվող ֆունկցիաների ենթախումբը վերաբերում է պլատֆորմայի ֆունկցիաներին. Դրա տակ ես հասկանում եմ ֆունկցիաներ, որոնք՝
- Ամբողջովին անկախ են բիզնեսի տրամաբանությունից. Ինչպես կառուցվում են Foo և Bar միջեւ զանգերի հիստոգրամները, ընդհանրապես չի կախված նրանից, ինչու Foo-ն կանչում է Bar-ը։
- Դրանք ճիշտ իրականացնելու համար դժվար է. Linkerd-ում կրկնակի փորձերը պարամետրացվում են տարբեր մեծ բաներով, ինչպիսիք են կրկնակի փորձերի բյուջեները (-retry budgets-), քանի որ ուղղակի մոտեցումը նման բաների իրականացմանը, ամենայն հավանականությամբ, կհանգեցնի առկա լինելու «հարցումների դաշտում» (-retry storm-) և այլ խնդիրների, որոնք հատուկ են տարածված համակարգերին։
- Ամենաարդյունավետն են, երբ կիրառվում են հարամաչակողմանի. TLS մեխանիզմը իմաստ ունի միայն այն դեպքում, երբ այն կիրառվում է ամենուր։
Քանի որ այս ֆունկցիաները իրականացվում են պրոքսի մակարդակում (ոչ ծրագրի մակարդակում), service mesh-ը տրամադրում է դրանք պլատֆորմի մակարդակում, ոչ թե ծրագրի։ Таким образом, չի matter, թե ինչ լեզվով են գրվել ծառայությունները, որն է նրանց շրջանակը, ով է դրանք գրել և ինչու։ Պրոքսիները գործում են բոլոր այդ մանրամասներից դուրս, իսկ այս ֆունկցիայի հիմքը, քայլերի, թարմացման, սպասարկման, շահագործման և այլն խնդիրների շարքում, բացառապես գտնվում է պլատֆորմի մակարդակում։
Service mesh-ի հնարավորությունների օրինակներ
Ընդհանուր առմամբ, ցանկանում եմ ասել, որ service mesh-ը ամբողջական լուծում չէ հուսալիության, դիտարկելիության կամ անվտանգության ապահովման համար։ Յուրաքանչյուր այս ոլորտի ծավալը ենթադրում է՝ ծառայությունների սեփականատերերի, Ops/SRE թիմերի և այլի ներգրավվածությունը։ Service mesh-ը միայն տրամադրում է «մասնաճյուղ» պլատֆորմի մակարդակում այս ոլորտներից յուրաքանչյուրի համար։
Ինչու հենց հիմա service mesh-ը դարձավ հանրաճանաչ։
Դա, հավանաբար, հիմա հարցնում եք, եթե service mesh-ը այնքան լավ է, ապա ինչու չենք սկսել տարածել միլիոնավոր պրոքսիներ դարասկզբին։
Այս հարցի համար կա բացայայտ պատասխան. Десять лет назад все строили монолиты, и service mesh никому не была нужна. Это правда, но, по моему мнению, в таком ответе теряется суть. Даже десять лет назад концепция микросервисов как перспективного способа создания крупномасштабных систем широко обсуждалась и применялась в таких компаниях, как Twitter, Facebook, Google и Netflix. Общее представление — по крайней мере, в тех частях отрасли, с которыми я контактировал, — состояло в том, что микросервисы — это «правильный способ» создавать крупные системы, даже если это было чертовски трудно.
Конечно, хотя десять лет назад были компании, эксплуатирующие микросервисы, они вовсе не втыкали прокси везде где только можно, чтобы сформировать service mesh. Однако если присмотреться, они делали нечто подобное: во многих из этих компаний предписывалось использовать особую внутреннюю библиотеку для сетевого взаимодействия (иногда называемую библиотекой толстого клиента, fat client library).
У Netflix была Hysterix, у Google была Stubby, у Twitter — библиотека Finagle. Finagle, например, была обязательной для каждого нового сервиса в Twitter. Она обрабатывала как клиентскую, так и серверную часть соединений, позволяла выполнять повторные запросы, поддерживала маршрутизацию запросов, балансировку нагрузки и измерения. Она обеспечивала согласованный слой надежности и наблюдаемости для всего стека Twitter, независимо от того, чем именно занимался сервис. Конечно, она работала только для JVM-языков и основывалась на модели программирования, которую приходилось использовать для всего приложения. Однако ее функциональные возможности были почти такими же, как и у service mesh. (На самом деле первая версия Linkerd просто представляла собой Finagle, обернутый в форму прокси.)
Таким образом, десять лет назад существовали не только микросервисы, но и специальные прото-service-mesh библиотеки, решавшие те же самые проблемы, что service mesh решает сегодня. Однако самой service mesh тогда не было. Должен был произойти еще один сдвиг, прежде чем она появилась.
И именно здесь лежит более глубокий ответ, скрытый в другой перемене, случившейся за последние 10 лет: произошло резкое снижение стоимости развертывания микросервисов. Упомянутые выше компании, использовавшие микросервисы десять лет назад: Twitter, Netflix, Facebook, Google, — были компаниями огромного масштаба и огромных ресурсов. У них была не только потребность, но и возможность создавать, развертывать и эксплуатировать крупные приложения на основе микросервисов. Энергия и усилия, приложенные инженерами Twitter к переходу с монолитного на микросервисный подход, просто поражают воображение. (Честно говоря, как и тот факт, что это удалось.) Այս տեսակի ենթակառուցվածքային մանևրները չէր կարող տեղի ունենալ ավելի փոքր ընկերությունների համար:
Եկեք վերադառնանք ժամանակացույցին: Այժմ կան ստարտափներ, որտեղ միկրո서비스ների և մշակումների հարաբերակցությունը կազմում է 5:1 (կամ նույնիսկ ), և ավելին, նրանք հաջողությամբ հաղթահարում են դրանք: Եթե 5 հոգուց բաղկացած ստարտափն կարելի է 50 միկրո서비스 շահագործել առանց անհանգստանալու, ապա հստակ է, որ ինչ-որ բան նվազեցրել է դրանց ներդրման ծախսերը:
1500 միկրոサービス Monzo-ում; յուրաքանչյուր գիծ՝ կարելի է թույլատրել տրաֆիկը, որը սահմանափակված է ցանցային կանոններով:
Միկրո서비스ների շահագործման ծախսերի կտրուկ նվազումը մեկ գործընթացի արդյունք է. կոնտեյների տարածման աճը: և որկեստրատորների:. Այդ իսկ պատճառով է, որ ծագում է service mesh-ի վերաբերյալ խոր հարցի խոր պատասխան: Կուրբնեթսը և Докер-ը նույն տեխնոլոգիայի հաղորդաշարն են, որ կարող են դարձնել գրավիչ թե service mesh-ը, թե միկրո خدمتությունները:
Եվ ինչու՞: Դե, Docker-ն լուծում է մեկ մեծ խնդիրը՝ փաթեթավորման խնդիրը: Միասնելով գրանցված ծրագրակազմը և դրա (չընգրկվող) runtime-կախվածությունները կոնտեյներով, Docker-ը ծրագրակազմը դարձնում է փոխարինելի միավոր, որը կարելի է տեղադրել և գործարկել ցանկացած վայրում: Այն միևնույն ժամանակ պահանջում է պարզեցնել շահագործումը: բազմալեզվային: կույտ. քանի որ կոնտեյները՝ կատարման ատոմար միավոր, տեղադրման և շահագործման համար կարևոր չէ, թե ինչ կա ներսում, լինի դա JVM-ում, Node-ում, Go-ում, Python-ում կամ Ruby-ում ծրագիր: Դուք պարզապես սկսում եք այն, և թո՛ւյլ տվեք գան:
Kubernetes-ը բոլորին դուրս է թակում նոր մակարդակի: Այժմ, երբ բազմաթիվ «գործող բաներ» և բազմաթիվ մեքենաներ կան, որոնց վրա դրանք կարելի է սկսել, առաջանում է անհրաժեշտություն գործիքների, որոնք կարող են նրանց համադրել միմյանց: Ընդհանուր առմամբ, դուք Kubernetes-ին տալիս եք շատ կոնտեյներներ և շատ մեքենաներ, իսկ նա համադրում է նրանց միմյանց հետ (բնականաբար, սա դինամիկ ու մշտապես փոփոխվող գործընթաց է: նոր կոնտեյներները շարժվում են համակարգում, մեքենաները սկսվում ու կանգնեցնում են և այլն: Բայց Kubernetes-ը հաշվի է առնում բոլոր այսերը):
Kubernetes-ը կարգավորումից հետո ժամանակային ծախսերը մեկ ծառայություն տեղադրելու և շահագործելու համար քիչ են տարբերվում, քան տաս երկու ծառայություն տեղադրելու և շահագործելու ծախսերը (առանցքային կերպով, դրանք գրեթե նույնն են նաև 100 ծառայությունների համար): Ավելացրեք դրան կոնտեյները որպես փաթեթավորման մեխանիզմ, որը խրախուսում է բազմալեզվային պրակտիկա և կունենաք բազմաթիվ նոր ծրագրեր, որոնք իրականացվում են միկրո xidmətերի ձևով, որոնք գրվել են տարբեր լեզուներով՝ ինչպես անհրաժեշտ է service mesh-ի համար:
Այսպիսով, մենք հասնում ենք այն հարցի պատասխանին, թե pourquoi service mesh գաղափարը դառնում է հանրաճանաչ հենց հիմա. այն հոմոգենությունը, որը Kubernetes-ը ներմուծում է ծառայությունների համար, ուղղակի կիրառելի է service mesh-ի առջև ծառացած շահագործման խնդիրներին: Դուք փաթեթավորում եք պրօքսիներին կոնտեյներներում, տալիս եք Kubernetes-ին առաջադրանք, որ դրանք խցկի բոլոր հնարավոր տեղերը, և voilà! Վերջում ստանում եք service mesh, մինչդեռ ամբողջ դրա տեղաբաշխման մեխանիկան ղեկավարում է Kubernetes-ը. (Բարեպատճառ, թռչունի աչքերի բարձրությունից, իհարկե, այս գործընթացում բազմաթիվ նրբություններ կան.)
Վերջացնելու համար, պատճառը, թե ինչու service mesh-ն հանրաճանաչ դարձավ հենց հիմա, այլ ոչ թե տաս տարի առաջ, այն է, որ Kubernetes և Docker-ը նշանակալիորեն ավելացրել են պահանջարկը նրա նկատմամբ, պարզեցնելով ծրագրերի իրականացման գործընթացը որպես բազմալեզու միկրոծառայությունների համալիր, բայց նաև զգալիորեն նվազեցրել են ծախսերը նրա շահագործման համար, ապահովելով sidecar ծրագրային պրօքսիների տեղաբաշխման և աջակցության մեխանիզմներ.
Ինչու tantos խոսակցություններ service mesh-ի մասին?
Հոգադրություն: այս բաժնում ես դիմում եմ ամեն տեսակ ենթադրությունների, որսումների, երևակայությունների և ներքին տեղեկատվության.
Փոխանցելով «service mesh» արտահայտությամբ որոնում, դուք հանդիպում եք շատ վերամշակված ցածր կալորիական նյութերի, տարօրինակ նախագծերի և աղմկոտ խռովությունների էկոհամակարգերի: Այս բոլոր ժամանակակից նոր տեխնոլոգիաներին բնորոշ է այս, բայց service mesh-ի դեպքում խնդիրը հատկապես արտահայտված է: Ինչու?
Դա նաև մասամբ իմ մեղքն է. Ես տվել եմ ամեն ինչ, Աստված, որպեսզի խթանեմ Linkerd և service mesh ամեն հնարավոր պահի, անթիվ բլոգային գրառումների և նմանատիպ հոդվածների միջոցով: Բայց ես այնքան էլ հզոր չեմ: Իրականում այս հարցի պատասխանը այդքան պարզ չէ, պետք է մի փոքր խոսել ընդհանուր իրավիճակի մասին: Եվ դրա մասին խոսելը հնարավոր չէ, առանց հիշատակելու մեկ նախագիծ: — բաց աղբյուրով service mesh, որը համատեղ մշակվում է Google-ի, IBM-ի և Lyft-ի կողմից.
(Այս երեք ընկերությունների դերերը ամբողջությամբ տարբեր են. Lyft-ի մասնակցությունը, կարծես, նվիրված է միայն անվանը; նրանք Envoy-ի հեղինակներն են, բայց չեն օգտագործում Istio կամ մասնակցում դրա մշակմանը: IBM-ը մասնակցում է Istio-ի զարգացմանն ու օգտագործում է այն: Google-ը ակտիվորեն մասնակցում է Istio-ի զարգացմանն, բայց որքան պահանջվում է, իրականում այն չի օգտագործում.)
Istio նախագիծը առանձնանում է երկու հատկանիշով. Նախ, այն ահռելի մարկետինգի ջանքերով, որոնք Google-ը, մասնավորապես, ներդնում է նրա խթանման համար. իմ գնահատականներով, service mesh գաղափարի մասին իրազեկված շատ մարդիկ այսօր առաջին անգամ լսել են դրա մասին հենց Istio-ի շնորհիվ: Երկրորդ հատկանիշն այն է, թե որքան վատ է ընդունվել Istio-ն. Այս հարցում ես, անշուշտ, կողմ եմ, սակայն փորձում եմ մնալ հնարավորինս օբյեկտիվ, դեռ չեմ կարող այլևս չ , ոչ այնքան բնորոշ (հետևաբար ոչ սոսկ.unique: հիշողության մեջ գալիս է systemd, …) для Open Source-проекта.
(Практически, у Istio, похоже, есть проблемы не только со сложностью и UX, но и с производительностью. Например, во время , проведенной третьей стороной, специалисты обнаружили ситуации, в которых хвосты задержек (tail latency) Istio в 100 раз превышали аналогичный показатель для Linkerd, а также ситуации с недостатком ресурсов, когда Linkerd продолжал успешно функционировать, а Istio полностью прекращал работу.)
Оставляя в стороне свои теории о том, почему так произошло, я считаю, что чрезмерный ажиотаж вокруг service mesh объясняется как раз участием Google. А именно, комбинацией следующих трех факторов:
- настойчивое продвижение Istio со стороны Google;
- соответствующее неодобрительное, критическое отношение к проекту;
- недавний стремительный взлет популярности Kubernetes, воспоминания о котором всё ещё свежи.
Вместе эти факторы объединяются в некое дурманящее, бескислородное окружение, в котором способность к рациональному суждению ослабевает, и остается только чудная разновидность .
С точки зрения Linkerd это… я бы описал как неоднозначное благо. Я имею в виду, замечательно, что service mesh вошла в мейнстрим — чего не было в 2016-м, когда Linkerd только появился и было по-настоящему трудно привлечь внимание окружающих к проекту. Теперь такой проблемы нет! Но плохо то, что ситуация с service mesh сегодня настолько запутанная, что практически невозможно понять, какие проекты действительно относятся к категории service mesh (не говоря уже о том, чтобы понять, какой из них лучше всего подходит для конкретного варианта использования). Это, безусловно, мешает всем (и, определенно, в некоторых случаях Istio или другой проект подходит больше, чем Linkerd, поскольку последний все же не является универсальным решением).
Со стороны Linkerd наша стратегия заключалась в том, чтобы игнорировать шум, продолжать сосредоточиваться на решении реальных проблем сообщества и, по сути, ждать, когда ажиотаж утихнет. В конечном итоге хайп пойдет на убыль, и мы сможем продолжать спокойно работать.
Пока же нам всем придется немного потерпеть.
Нужна ли мне service mesh, скромному software engineer?
С ответом на этот вопрос поможет определиться следующий опросник:
Вы занимаетесь исключительно реализацией бизнес-логики? В этом случае service mesh вам не пригодится. То есть, конечно, вы можете ею заинтересоваться, но в идеале service mesh не должна прямым образом влиять на что-либо в вашем окружении. Продолжайте выполнять работу, за которую вам платят.
Вы поддерживаете платформу в компании, которая использует Kubernetes? Այո, այս դեպքում вам անհրաժեշտ է service mesh (Իհարկե, եթե դուք не օգտագործում եք K8s մոնոլիտ կամ բեռնափոխադրում իրականացման համար — բայց այդ դեպքում ես կցանկանամ հարցնել, ինչու եք ընդհանրապես K8s օգտագործում): Հավանաբար, դուք հայտնվելու եք մի իրավիճակում, որտեղ շատ միկրո ծառայություններ կան, որոնք գրեթե բոլորը գրել են տարբեր մարդիկ: Նրանք բոլորն էլ փոխհարաբերություն ունեն միմյանց հետ և կապված են runtime կախվածությունների խճճվածքի մեջ, իսկ դուք պետք է գտնեք մի միջոց, որ դասակարգել այս ամենը: Kubernetes կիրառումը թույլ կտա ընտրել service mesh «ձեր համար»: Դրա համար таныացեք նրանց հնարավորություններով և առանձնահատկություններով և պատասխանեք հարցին, արդյոք ձեզ בכלל համապատասխանում է որևէ ընթացիկ նախագիծ (առաջարկում եմ սկսել հետազոտությունը Linkerd-ից):
Դուք զբաղվում եք հարթակով ընկերությունում, որը НЕ օգտագործում է Kubernetes, բայց օգտագործում է միկրո ծառայություններ? Այս դեպքում service mesh ձեզ օգտակար կլինի, սակայն նրա օգտագործումը չի լինի պարզ: Իհարկե, դուք կարող եք մարդկանց մոտեցումները service mesh-ի աշխատանքը ներգրաված բազմաթիվ պրոքսիների միջոցով, սակայն Kubernetes-ի հիմնական առավելությունը հենց տեղադրման մոդելն է: Այս պրոքսիների սպասարկումը ձեռքով պահանջելու է շատ ավելի մեծ ժամանակ, ուժեր և ծախսեր:
Դուք պատասխանատու եք հարթակի համար ընկերությունում, որը աշխատում է մոնոլիտների հետ? Այս դեպքում service mesh ձեզ, ամենայն հավանականությամբ, անհրաժեշտ չէ: Եթե աշխատում եք մոնոլիտների (կամ նույնիսկ մոնոլիտների խումբների) հետ, որոնք ունեն հստակ սահմանված և հազվադեպ փոփոխվող փոխգործակցություն, ապա service mesh ձեզ շատ բան չի առաջարկի: Որպեսզի կարող եք պարզապես ուշադրություն չդարձնել նրա վրա և ակնկալել, որ դա կ disappear է՝ ինչպես սարսափելի երազում...
Ավարտ
Կարծում եմ, service mesh-ը դեռևս արժանի չէ «աշխարհի ամենահայտնի տեխնոլոգիա» անվանումին — այս կասկածելի պատիվը, հավանաբար, պատկանում է բիտքոինին կամ ԱՍՈՒՄ-ին: Միգուցե այն մտնում է առաջին հինգի մեջ: Բայց եթե անցնել վրդովմունքների և աղմուկի շերտերից, պարզ է, որ service mesh իրական օգուտներ է բերել նրանց, ովքեր ստեղծում են ծրագրեր Kubernetes-ի մեջ:
Ես կցանկանալին, որ դուք փորձեինք Linkerd — նրա տեղադրման գործընթացը Kubernetes-ի կլաստարում (կամ նույնիսկ Minikube-ում ձեր նոթբուքում) , և դուք հանգիստ կարող եք տեսնել, ինչի մասին եմ խոսում:
ՀՏՀ
— Եթե ես անտեսեմ service mesh-ը, այն կ disappear-ի?
— Ցավում եմ, ձեզ պետք է՝ service mesh-ը մեզ հետ է երկար ժամանակ:
— Բայց ես ՉԵՄ Ցանկանում օգտագործել service mesh!
— Դե, էլևս չպետք է: Միայն կարդացեք իմ հարցաթերթիկը վերևում, чтобы понять, следует ли ознакомиться хотя бы с ее азами.
— Разве это не старое доброе ESB/middleware под новым соусом?
— Service mesh-ը գտնվում է эксплуатационной логикой, а не смысловой: сервисной шины предприятия (). Այս բաժանման պահպանությունը օգնում է service mesh-ին խուսափել նույն դատապարտությունից:
— Чем service mesh отличается от API-шлюзов?
— Существует миллион статей на эту тему. Просто погуглите.
— Envoy — это service mesh?
— Ոչ, Envoy-ն service mesh չէ, դա որչար server է։ Այն կարելի է օգտագործել service mesh կազմակերպելու համար (և շատ այլ բաների համար — դա ընդհանուր նպատակային որչար է)։ Բայց ինքնին դա service mesh չի հանդիսանում։
— Network Service Mesh-ը service mesh է吗？
— Ոչ։ Վերնագրի համեմատ, սա service mesh չէ (ինչպես ձեզ շուկայավարման հրաշքները։)
— Կպա՞մ service mesh-ը իմ հաղորդագրությունների հերթի վրա հիմնված ռեակտիվ ասինխրոն համակարգին։
— Ոչ, service mesh-ը չի օգնի։
— Ինչ service mesh պետք է օգտագործեմ։
— , բոլորին հստակ է։
— Հ стать-вот прямо ужас! / Ավթի автора շեմերին։
— Խնդրում եմ, երեք առաջարկում եմ կիսվել հետևյալ հղով ձեր բոլոր ընկերների հետ, որպեսզի նրանք կարողանան համոզվել դրանում։
Նախշեր
Ինչպես կարող եք կանխատեսել անվանման պատճառով, այս հոդվածը ոգեշնչվել է Jay Kreps-ի «»։ Ես հանդիպեցի Jay-ին տասը տարի առաջ, երբ հարցազրույց էի տալիս Linked In-ում, և այդ ժամանակից ի վեր նա ինձ համար ոգեշնչում է ծառայել։
Պարզապես սիրում եմ ինձ անվանել «Linkerd-ի մշակող», սակայն իրականությունը փաստում է, որ ես ավելի շուտ README.md ֆայլի պահպանող եմ նախագծում։ Այսօր Linkerd պրոյեկտում աշխատում է , , մարդիկ, և այս նախագիծը չէր կայանա այս համայնքի հիանալի մասնակցության և օգտատերերի աջակցությամբ։
Եվ վերջում, հատուկ շնորհակալություն Linkerd-ի ստեղծողին, (primus inter pares), ով իմ հետ միասին շատ տարիներ առաջ խորապես ներգրավված էր այս service mesh մոլորության մեջ։
P.S. թարգմանչից
Նաեւ կարդացեք մեր բլոգում:
- «»;
- «»;
- «»;
- «»;
- «».
Ընտանիք: habr.com
