Eslatma. tarjima.: Xizmat ko'rsatish tarmog'i - bu hali rus tiliga barqaror tarjimaga ega bo'lmagan hodisa (2 yildan ko'proq vaqt oldin biz "xizmatlar uchun to'r" variantini taklif qildik va birozdan keyin ba'zi hamkasblar "xizmat elak" kombinatsiyasini faol ravishda targ'ib qila boshladilar). Ushbu texnologiya haqida doimiy gapirish marketing va texnik komponentlar juda chambarchas bog'liq bo'lgan vaziyatga olib keldi. Asl atama mualliflaridan birining ushbu ajoyib materiali muhandislar va boshqalar uchun aniqlik kiritish uchun mo'ljallangan.
dan komiks
kirish
Agar siz dasturiy ta'minot bo'yicha muhandis bo'lsangiz, so'nggi bir necha yil ichida "xizmat tarmog'i" atamasi allaqachon ongingizga mustahkam o'rnashib olgan. G'alati tasodif tufayli bu ibora tobora ko'proq sohani egallab bormoqda va u bilan bog'liq shov-shuv va reklama takliflari pastdan uchib borayotgan qor to'pi kabi o'sib bormoqda va hech qanday sekinlashuv belgilarini ko'rsatmaydi.
Xizmat mesh bulutli mahalliy ekotizimning loyqa, noxush suvlarida tug'ilgan. Afsuski, bu uning atrofidagi bahs-munozaralarning ko'p qismi "past kaloriyali suhbat" dan - texnik atamani qo'llash - ochiq-oydin bema'nilikgacha ekanligini anglatadi. Ammo agar siz barcha shovqinlarni kesib o'tsangiz, xizmat ko'rsatish tarmog'i juda haqiqiy, aniq va muhim funktsiyaga ega ekanligini topasiz.
Ushbu postda men buni qilishga harakat qilaman: xizmat ko'rsatish tarmog'i bo'yicha halol, chuqur, muhandisga yo'naltirilgan qo'llanmani taqdim etaman. Men shunchaki savolga javob bermoqchi emasman: "Bu nima?", - Biroq shu bilan birga "Nega?", shuningdek — Nega endi?. Nihoyat, men nima uchun (mening fikrimcha) ushbu texnologiya bunday aqldan ozgan shov-shuvga sabab bo'lganini aytib berishga harakat qilaman, bu o'z-o'zidan qiziqarli voqea.
Kimman?
Hammaga salom! Ismim . Men ijodkorlardan biriman — eng birinchi xizmat mesh loyihasi va atama paydo bo'lishi uchun aybdor bo'lgan loyiha xizmat ko'rsatish tarmog'i shunday (kechirasiz, bolalar!). (Eslatma tarjimasi.: Aytgancha, ushbu atama paydo bo'lishining boshida, 2,5 yildan ko'proq vaqt oldin, biz o'sha muallifning "" nomli dastlabki materialini tarjima qilgan edik.".) Men ham boshlayman Linkerd va kabi ajoyib xizmat mesh narsalarni yaratadigan startap .
Ehtimol, bu masala bo'yicha men juda noxolis va sub'ektiv fikrga ega ekanligimni taxmin qilishingiz mumkin. Biroq, men tarafkashlikni minimal darajaga tushirishga harakat qilaman (bir bo'lim bundan mustasno: "Nega xizmat ko'rsatish tarmog'i haqida ko'p gapiriladi?", - unda men hali ham o'zimning oldindan o'ylagan g'oyalarimni baham ko'raman). Men ham ushbu qo'llanmani iloji boricha ob'ektiv qilish uchun qo'limdan kelganini qilaman. Aniq misollar uchun men birinchi navbatda Linkerdning tajribasiga tayanaman, shu bilan birga men boshqa xizmat turlarini amalga oshirishda biladigan farqlarni (agar mavjud bo'lsa) ko'rsataman.
Yaxshi, shirinliklarga o'tish vaqti keldi.
Xizmat ko'rsatish tarmog'i nima?
Barcha shov-shuvlarga qaramay, xizmat ko'rsatish tarmog'ining tuzilishi juda oddiy. Bu xizmatlarning "yonida" joylashgan foydalanuvchi proksi-serverlarining bir to'plami (keyinchalik "keyingi" nima haqida bir oz gaplashamiz), shuningdek, boshqaruv jarayonlari to'plami. Proksilar birgalikda chaqiriladi ma'lumotlar tekisligi, va boshqaruv jarayonlari deyiladi nazorat tekisligi. Ma'lumotlar tekisligi xizmatlar orasidagi qo'ng'iroqlarni ushlab turadi va ular bilan "har xil narsalarni" bajaradi; Boshqaruv tekisligi, shunga ko'ra, proksi-serverning xatti-harakatlarini muvofiqlashtiradi va siz uchun kirishni ta'minlaydi, ya'ni. operator, API uchun, tarmoqni manipulyatsiya qilish va umuman o'lchash imkonini beradi.
Bu qanday proksi-server? Bu Layer 7-dan xabardor TCP proksi-serveri (ya'ni, OSI modelining 7-qatlamini "hisobga olgan holda") HAProxy va NGINX kabi. O'zingizning xohishingizga ko'ra proksi-serverni tanlashingiz mumkin; Linkerd oddiygina nomlangan Rust proksi-serveridan foydalanadi . Biz uni maxsus xizmat ko'rsatish tarmog'i uchun birlashtirdik. Boshqa meshlar boshqa proksi-serverlarni afzal ko'radi (Elchi umumiy tanlovdir). Biroq, proksi-serverni tanlash faqatgina amalga oshirish masalasidir.
Ushbu proksi-serverlar nima qiladi? Shubhasiz, ular xizmatlarga va xizmatlardan proksi-server qo'ng'iroqlarini amalga oshiradilar (to'g'ri aytganda, ular proksi va teskari proksi sifatida ishlaydi, ham kiruvchi, ham chiquvchi qo'ng'iroqlarni boshqaradi). Va ular qo'ng'iroqlarga qaratilgan xususiyatlar to'plamini amalga oshiradilar o'rtasida xizmatlar. Xizmatlar o'rtasidagi trafikka bunday e'tibor xizmat mesh proksi-serverini, aytaylik, API shlyuzlari yoki kirish proksi-serverlaridan ajratib turadigan narsadir (oxirgisi tashqi dunyodan klasterga keladigan qo'ng'iroqlarga qaratilgan). (Eslatma. tarjima.: Kubernetes uchun mavjud Ingress kontrollerlarini taqqoslash uchun, ularning aksariyati yuqorida aytib o'tilgan Envoy-dan foydalanadi, qarang. .)
Shunday qilib, biz ma'lumotlar tekisligini saralab oldik. Boshqaruv tekisligi oddiyroq: bu ma'lumotlar tekisligi muvofiqlashtirilgan tarzda ishlashi uchun zarur bo'lgan barcha mexanikani ta'minlaydigan komponentlar to'plami, jumladan xizmatlarni aniqlash, TLS sertifikatlarini berish, metrik yig'ish va hokazo. Ma'lumotlar tekisligi boshqaruv tekisligiga ma'lumot beradi. uning xatti-harakati; o'z navbatida, boshqaruv tekisligi butun ma'lumotlar tekisligining xatti-harakatlarini o'zgartirish va kuzatish imkonini beruvchi APIni taqdim etadi.
Quyida Linkerddagi boshqaruv tekisligi va ma'lumotlar tekisligi diagrammasi keltirilgan. Ko'rib turganingizdek, boshqaruv tekisligi bir nechta turli komponentlarni, jumladan proksi-serverlardan ko'rsatkichlarni to'playdigan Prometey nusxasini, shuningdek, boshqa komponentlarni o'z ichiga oladi. destination (xizmat kashfiyoti), identity (sertifikat organi, CA) va public-api (veb va CLI uchun oxirgi nuqtalar). Bundan farqli o'laroq, ma'lumotlar tekisligi dastur namunasi yonidagi oddiy linkerd-proksi hisoblanadi. Bu shunchaki mantiqiy diagramma; Haqiqiy dunyoda tarqatishda siz har bir boshqaruv tekisligi komponentining uchta nusxasi va ma'lumotlar tekisligida yuzlab yoki minglab proksi-serverlarga ega bo'lishingiz mumkin.
(Ushbu diagrammadagi koʻk toʻrtburchaklar Kubernetes podalari chegaralarini bildiradi. Siz linkerd-proksi boʻlgan konteynerlar dastur konteynerlari bilan bir xil boʻlakda joylashganligini koʻrishingiz mumkin. Bu sxema shunday nomlanadi. yonbosh idish.)
Xizmat mesh arxitekturasi bir nechta muhim ta'sirlarga ega. Birinchidan, proksi-serverning vazifasi xizmatlar o'rtasidagi qo'ng'iroqlarni to'xtatish bo'lganligi sababli, sizning ilovangiz ma'lum xizmatlar to'plami uchun yaratilgan bo'lsa, xizmat tarmog'i mantiqiy bo'ladi. To'r mumkin monolitlar bilan foydalaning, ammo bu bitta proksi-server uchun ortiqcha bo'lishi aniq va uning funksionalligi talabga ega bo'lishi dargumon.
Yana bir muhim natija - xizmat ko'rsatish tarmog'i talab qiladi ulkan proksi-serverlar soni. Aslida, Linkerd har bir xizmatning har bir nusxasiga linkerd-proksi-serverni biriktiradi (boshqa ilovalar har bir tugun/host/virtual mashinaga proksi-server qo'shadi. Bu juda ko'p). Proksi-serverlardan bunday faol foydalanish o'z-o'zidan bir qator qo'shimcha asoratlarni keltirib chiqaradi:
- Ma'lumotlar tekisligidagi proksi-serverlar bo'lishi kerak tez, chunki har bir qo'ng'iroq uchun proksi-serverga bir nechta qo'ng'iroqlar mavjud: biri mijoz tomonida, biri server tomonida.
- Proksi-serverlar ham bo'lishi kerak kichik и engil vaznli. Har biri xotira va protsessor resurslarini iste'mol qiladi va bu iste'mol ilova bilan chiziqli ravishda o'sib boradi.
- Ko'p sonli proksi-serverlarni joylashtirish va yangilash uchun sizga mexanizm kerak bo'ladi. Buni qo'lda qilish variant emas.
Umuman olganda, xizmat ko'rsatish tarmog'i shunday ko'rinadi (hech bo'lmaganda qush nazarida): siz ichki, xizmatlararo trafik bilan "biror narsa qiladigan" foydalanuvchilar maydoni proksi-serverlarini joylashtirasiz va ularni kuzatish va boshqarish uchun boshqaruv tekisligidan foydalanasiz.
Endi "Nima uchun?" Degan savolni berish vaqti keldi.
Xizmat ko'rsatish tarmog'i nima uchun?
Xizmat ko'rsatish tarmog'i g'oyasiga birinchi marta duch kelganlar biroz qo'rqinchli his qilishlari uchun kechirilishi mumkin edi. Xizmat ko'rsatish tarmog'i dizayni nafaqat dasturda kechikish vaqtini oshirishini, balki uni ham oshiradi iste'mol resurslar va qo'shadi infratuzilmada bir qator yangi mexanizmlar. Avval siz xizmat ko'rsatish tarmog'ini o'rnatdingiz, so'ngra birdan yuzlab (agar minglab bo'lmasa) proksi-serverlarga xizmat ko'rsatishga ehtiyoj sezasiz. Savol tug'iladi, buni kim o'z ixtiyori bilan qiladi?
Bu savolga javob ikki qismdan iborat. Birinchidan, ushbu proksi-serverlarni joylashtirish bilan bog'liq tranzaksiya xarajatlari ekotizimda sodir bo'layotgan ba'zi o'zgarishlar tufayli sezilarli darajada kamayishi mumkin (bu haqda keyinroq).
Ikkinchidan, bunday qurilma aslida tizimga qo'shimcha mantiqni kiritishning ajoyib usuli. Xizmat ko'rsatish tarmog'i nafaqat ko'plab yangi funksiyalarni qo'shishi mumkin, balki u ekotizimga aralashmasdan amalga oshirilishi mumkinligi uchun ham. Aslida, butun xizmat ko'rsatish tarmog'i modeli shu asosga asoslangan: multiservis tizimida, nima bo'lishidan qat'iy nazar qil individual xizmatlar, trafik ular orasida funksionallikni qo'shish uchun ideal nuqta.
Misol uchun, Linkerd-da (ko'pgina tarmoqlarda bo'lgani kabi) funksionallik birinchi navbatda HTTP qo'ng'iroqlariga, jumladan HTTP/2 va gRPC*ga qaratilgan. Funktsionallik juda boy - uni uchta sinfga bo'lish mumkin:
- Tegishli xususiyatlar ishonchlilik. Takroriy so'rovlar, kutish vaqti, kanareyka yondashuvi (trafikni ajratish/yo'naltirish) va boshqalar.
- Tegishli xususiyatlar monitoring. Har bir xizmat yoki alohida yo'nalishlar bo'yicha muvaffaqiyat stavkalari, kechikishlar va so'rovlar hajmini yig'ish; xizmatlarning topologik xaritalarini tuzish va boshqalar.
- Tegishli xususiyatlar xavfsizlik. O'zaro TLS, kirishni boshqarish va boshqalar.
* Linkerd nuqtai nazaridan, gRPC deyarli HTTP/2 dan farq qilmaydi: u foydali yukda protobufdan foydalanadi. Ishlab chiquvchi nuqtai nazaridan, bu ikki narsa, albatta, bir-biridan farq qiladi.
Ushbu mexanizmlarning aksariyati so'rov darajasida ishlaydi (shuning uchun "L7 proksi"). Misol uchun, agar Foo xizmati Bar xizmatiga HTTP qo'ng'irog'ini qilsa, Foo tomonidagi linkerd-proksi aqlli yuk balansini amalga oshirishi va kuzatilgan kechikishlar asosida Foo-dan Bar misollariga qo'ng'iroqlarni yo'naltirishi mumkin; agar kerak bo'lsa (va agar u idempotent bo'lsa) so'rovni takrorlashi mumkin; u javob kodini va vaqt tugashini va hokazolarni yozishi mumkin. Xuddi shunday, agar ruxsat berilmagan bo'lsa yoki so'rov chegarasidan oshib ketgan bo'lsa, Bar tomonidagi linkerd-proksi so'rovni rad etishi mumkin; o'z tomonida kechikish qayd etishi mumkin va hokazo.
Proksi-serverlar ulanish darajasida ham "biror narsa qilishlari" mumkin. Masalan, Foo tomonidagi linkerd-proksi TLS ulanishini boshlashi mumkin, bar tomonidagi linkerd-proksi esa uni tugatishi mumkin va har ikki tomon bir-birining TLS sertifikatlarini tekshirishi mumkin*. Bu nafaqat xizmatlar o'rtasida shifrlashni, balki xizmatlarni aniqlashning kriptografik jihatdan xavfsiz usulini ham ta'minlaydi: Foo va Bar o'zlari aytgan kim ekanligini "isbotlashi" mumkin.
* "O'zaro do'st" mijoz sertifikati ham tasdiqlanganligini anglatadi (o'zaro TLS). "Klassik" TLSda, masalan, brauzer va server o'rtasida, odatda, faqat bir tomonning (server) sertifikati tekshiriladi.
Ular so'rov yoki ulanish darajasida ishlashidan qat'i nazar, barcha xizmat ko'rsatish tarmog'i funktsiyalari ekanligini ta'kidlash muhimdir. operativ xarakter. Linkerd foydali yukning semantikasini o'zgartira olmaydi - masalan, JSON fragmentiga maydonlar qo'shish yoki protobufga o'zgartirishlar kiritish. Bu muhim xususiyat haqida keyinroq ESB va o'rta dastur haqida gapirganda gaplashamiz.
Bu xizmat ko'rsatish tarmog'i taklif qiladigan xususiyatlar to'plamidir. Savol tug'iladi: nega ularni to'g'ridan-to'g'ri dasturda amalga oshirmaslik kerak? Va nima uchun proksi-server bilan umuman bezovta qilasiz?
Nima uchun xizmat tarmog'i yaxshi fikr
Xizmat ko'rsatish tarmog'ining imkoniyatlari hayajonli bo'lsa-da, uning asosiy qiymati aslida uning xususiyatlarida yotmaydi. Oxirida biz Mumkin ularni to'g'ridan-to'g'ri ilovada amalga oshiring (bu xizmat tarmog'ining kelib chiqishi ekanligini keyinroq bilib olamiz). Buni bir jumla bilan ifodalash uchun, xizmat ko'rsatish tarmog'ining qiymati quyidagicha: u zamonaviy server dasturiy ta'minotini butun stek bo'ylab izchil va dastur kodidan mustaqil ravishda ishga tushirish uchun muhim xususiyatlarni taqdim etadi.
Keling, ushbu taklifni tahlil qilaylik.
«Zamonaviy server dasturlarini ishga tushirish uchun muhim xususiyatlar" Agar siz umumiy Internetga ulangan tranzaktsion server dasturini yaratayotgan bo'lsangiz, tashqi dunyodan so'rovlarni qabul qilsangiz va ularga qisqa vaqt ichida javob bersangiz - masalan, veb-ilova, API-server va boshqa zamonaviy ilovalarning aksariyati - va agar siz uni bir-biri bilan sinxron o'zaro ta'sir qiluvchi xizmatlar to'plami sifatida amalga oshirsangiz va agar siz ushbu dasturiy ta'minotni doimiy ravishda yangilab, yangi xususiyatlar qo'shsangiz va modifikatsiya jarayonida ushbu tizimni ish holatida saqlashga majbur bo'lsangiz - bunda hol, tabriklaymiz, siz zamonaviy server dasturiy ta'minotini yaratyapsiz. Va yuqorida sanab o'tilgan barcha ajoyib xususiyatlar siz uchun juda muhim bo'lib chiqadi. Ilova ishonchli, xavfsiz bo'lishi kerak va siz nima qilayotganini kuzatishingiz kerak. Aynan shu savollarga xizmat ko'rsatish tarmog'i yordam beradi.
(Xo'sh, oldingi paragraf hali ham bu yondashuv server dasturiy ta'minotini yaratishning zamonaviy usuli ekanligiga ishonchimni o'z ichiga oladi. Boshqalar monolitlar, "reaktiv mikroservislar" va yuqorida keltirilgan ta'rifga kirmaydigan boshqa narsalarni ishlab chiqishni afzal ko'radi. Bu odamlar, ehtimol, o'zlarining O'z navbatida, menimcha, ular "noto'g'ri" - garchi har qanday holatda ham xizmat ko'rsatish tarmog'i ular uchun unchalik foydali emas).
«Butun stek uchun yagona" Xizmat tarmog'i tomonidan taqdim etilgan funksionallik nafaqat muhim vazifadir. Ular ilovadagi barcha xizmatlarga, ular qaysi tilda yozilganligidan, qaysi ramkadan foydalanishidan, ularni kim yozganidan, qanday joylashtirilganidan va ularni ishlab chiqish va ishlatishning boshqa nozikliklaridan qat'i nazar, amal qiladi.
«Ilova kodidan mustaqil" Va nihoyat, xizmat ko'rsatish tarmog'i nafaqat butun stek bo'ylab izchil funksionallikni ta'minlaydi, balki dasturni tahrirlashni talab qilmaydigan tarzda amalga oshiradi. Konfiguratsiya, yangilash, ishlatish, texnik xizmat ko'rsatish va hokazo vazifalarni o'z ichiga olgan xizmat ko'rsatish tarmog'i funksionalligining asosiy asosi butunlay platforma darajasida joylashgan va ilovadan mustaqildir. Ilova xizmat ko'rsatish tarmog'iga ta'sir qilmasdan o'zgarishi mumkin. O'z navbatida, xizmat ko'rsatish tarmog'i ilovaning ishtirokisiz o'zgarishi mumkin.
Muxtasar qilib aytganda, xizmat ko'rsatish tarmog'i nafaqat hayotiy funksionallikni ta'minlabgina qolmay, balki global, yagona va dasturdan mustaqil ravishda ham buni amalga oshiradi. Shunday qilib, xizmat ko'rsatish tarmog'ining funksionalligi xizmat kodida (masalan, har bir xizmatga kiritilgan kutubxona sifatida) amalga oshirilishi mumkin bo'lsa-da, bu yondashuv xizmat ko'rsatish tarmog'ida juda qimmatli bo'lgan bir xillik va mustaqillikni ta'minlamaydi.
Va faqat bir nechta proksi-serverlarni qo'shish kifoya! Tez orada ushbu proksi-serverlarni qo'shish bilan bog'liq operatsion xarajatlarni ko'rib chiqamiz. Lekin, keling, avval to'xtab, bu mustaqillik g'oyasiga turli nuqtai nazardan qaraylik. odamlar.
Xizmat mesh kimga yordam beradi?
Qanchalik noqulay bo'lmasin, texnologiya ekotizimning muhim qismiga aylanishi uchun u odamlar tomonidan qabul qilinishi kerak. Xo'sh, kim xizmat ko'rsatish tarmog'iga qiziqadi? Undan foydalanish kimga foyda keltiradi?
Agar siz zamonaviy server dasturiy ta'minotini ishlab chiqayotgan bo'lsangiz, jamoangizni taxminan bir guruh sifatida tasavvur qilishingiz mumkin xizmat egalaribirgalikda biznes mantig'ini ishlab chiqadigan va amalga oshiradigan va platforma egalari, ushbu xizmatlar ishlaydigan ichki platformani ishlab chiqish. Kichkina tashkilotlarda bu bir xil odamlar bo'lishi mumkin, ammo kompaniya o'sishi bilan bu rollar yanada aniqroq bo'lib, hatto pastki rollarga bo'linadi... (Bu erda devoplarning o'zgaruvchan tabiati haqida ko'p gapirish mumkin, mikroservislarning tashkiliy ta'siri va boshqalar) n. Lekin hozircha bu tavsiflarni berilgandek qabul qilaylik).
Shu nuqtai nazardan, xizmat ko'rsatish tarmog'ining aniq benefitsiarlari platforma egalaridir. Oxir oqibat, platforma jamoasining maqsadi xizmat egalari biznes mantig'ini amalga oshirishi mumkin bo'lgan ichki platformani yaratish va buni uning faoliyatining noaniq tafsilotlaridan iloji boricha mustaqil bo'lishini ta'minlaydigan tarzda amalga oshirishdir. Xizmat ko'rsatish tarmog'i nafaqat ushbu maqsadga erishish uchun muhim bo'lgan imkoniyatlarni taqdim etadi, balki u buni o'z navbatida xizmat egalariga qaramlikni yuklamaydigan tarzda amalga oshiradi.
Xizmat egalari ham ko'proq bilvosita tarzda foyda ko'radilar. Xizmat egasining maqsadi biznes-jarayon mantig'ini amalga oshirishda imkon qadar samarali bo'lishdir va u operatsion muammolar haqida qanchalik kamroq tashvishlansa, shuncha yaxshi bo'ladi. Aytaylik, siyosat yoki TLSni amalga oshirish bilan shug'ullanish o'rniga, ular faqat biznes maqsadlariga e'tibor qaratishlari mumkin va platforma qolganlari bilan shug'ullanishiga umid qilishlari mumkin. Bu ular uchun katta afzallik.
Platformalar va xizmatlar egalari o'rtasidagi bunday bo'linishning tashkiliy qiymatini ortiqcha baholab bo'lmaydi. Menimcha, u hissa qo'shadi asosiy xizmat mesh qiymatiga hissa.
Biz bu saboqni Linkerdning dastlabki muxlisi bizga nima uchun xizmat ko'rsatish tarmog'ini tanlaganliklarini aytganida bilib oldik: chunki bu ularga "gapirish do'konini minimal darajada ushlab turish" imkonini berdi. Mana ba'zi tafsilotlar: bitta yirik kompaniyaning yigitlari o'z platformalarini Kubernetesga ko'chirishdi. Ilova nozik ma'lumotlarni qayta ishlaganligi sababli, ular klasterlar bo'ylab barcha aloqalarni shifrlashni xohlashdi. Biroq, vaziyat yuzlab xizmatlar va yuzlab ishlab chiqish guruhlari mavjudligi bilan murakkablashdi. Hamma bilan bog'lanish va ularni TLS yordamini o'z rejalariga kiritishga ishontirish istiqboli ularni umuman xursand qilmadi. Linkerdni o'rnatgandan so'ng, ular o'tkazishdi majburiyat ishlab chiquvchilardan (bu keraksiz muammo bo'lgan nuqtai nazardan) platformachilargacha, ular uchun bu eng yuqori darajadagi ustuvorlik edi. Boshqacha qilib aytganda, Linkerd ular uchun texnik muammoni emas, balki tashkiliy muammoni hal qildi.
Muxtasar qilib aytganda, xizmat ko'rsatish tarmog'i texnik emas, balki ko'proq yechimdir ijtimoiy-texnik Muammolar. (Rahmat Ushbu atamani kiritish uchun.)
Xizmat tarmog'i barcha muammolarimni hal qiladimi?
Ha. Aytmoqchimanki, yo'q!
Agar siz yuqorida tavsiflangan xususiyatlarning uchta sinfiga qarasangiz - ishonchlilik, xavfsizlik va kuzatuvchanlik - xizmat ko'rsatish tarmog'i ushbu muammolarning hech biriga to'liq yechim emasligi ayon bo'ladi. Linkerd so'rovlarni qayta chiqarishi mumkin bo'lsa-da (agar u idempotent ekanligini bilsa), agar xizmat doimiy ravishda ishlamay qolsa, foydalanuvchiga nima qaytarish kerakligi haqida qaror qabul qila olmaydi - bu qarorlar ilova tomonidan qabul qilinishi kerak. Linkerd muvaffaqiyatli so'rovlar statistikasini yuritishi mumkin, ammo u xizmatni ko'rib chiqa olmaydi va uning ichki ko'rsatkichlarini taqdim eta olmaydi - ilovada bunday vositalar bo'lishi kerak. Linkerd mTLS-ni tashkil etishga qodir bo'lsa-da, to'liq huquqli xavfsizlik echimlari ko'proq narsani talab qiladi.
Ushbu sohalarda xizmat ko'rsatish tarmog'i tomonidan taqdim etilgan xususiyatlarning bir qismi tegishli platforma xususiyatlari. Bu bilan men quyidagi funktsiyalarni nazarda tutyapman:
- Biznes mantiqidan mustaqil. Foo va Bar o'rtasidagi qo'ng'iroq gistogrammalarini qurish usuli butunlay mustaqildir nima uchun Foo Barni chaqiradi.
- To'g'ri amalga oshirish qiyin. Linkerd-da qayta urinishlar qayta urinish byudjetlari kabi har xil ajoyib narsalar bilan parametrlangan (byudjetlarni qaytadan sinab ko'ring), chunki bunday narsalarni amalga oshirishga murakkab bo'lmagan yondashuv, albatta, "so'rovlar ko'chkisi" paydo bo'lishiga olib keladi. (bo'ronni qaytadan urinish) va taqsimlangan tizimlarga xos bo'lgan boshqa muammolar.
- Bir xilda qo'llanilganda eng samarali. TLS mexanizmi faqat hamma joyda qo'llanilsa mantiqiy bo'ladi.
Ushbu funktsiyalar proksi-server darajasida (ilova darajasida emas) amalga oshirilganligi sababli, xizmat ko'rsatish tarmog'i ularni quyidagi manzilda ta'minlaydi platforma, ilovalar emas. Shunday qilib, xizmatlar qaysi tilda yozilganligi, qaysi ramkadan foydalanishi, ularni kim va nima uchun yozganligi muhim emas. Proksi-serverlar ushbu barcha tafsilotlardan tashqarida ishlaydi va ushbu funksionallikning asosiy asosi, jumladan, konfiguratsiya, yangilash, ishlatish, texnik xizmat ko'rsatish va hokazo vazifalari faqat platforma darajasida yotadi.
Xizmat mesh imkoniyatlariga misollar
Xulosa qilib aytganda, xizmat ko'rsatish tarmog'i ishonchlilik, kuzatuvchanlik yoki xavfsizlik uchun to'liq yechim emas. Ushbu sohalarning ko'lami xizmat egalari, Ops/SRE guruhlari va kompaniyaning boshqa sub'ektlari ishtirokini talab qiladi. Xizmat ko'rsatish tarmog'i faqat ushbu sohalarning har biri uchun platforma darajasidagi "bo'lak" ni taqdim etadi.
Nima uchun xizmat tarmog'i hozir mashhur bo'ldi?
Hozirgacha siz hayron bo'layotgandirsiz: agar xizmat ko'rsatish tarmog'i juda yaxshi bo'lsa, nega biz o'n yil oldin stekga millionlab proksi-serverlarni joylashtirishni boshlamadik?
Bu savolga oddiy javob bor: o'n yil oldin hamma monolitlar qurgan va hech kimga xizmat ko'rsatish tarmog'i kerak emas edi. Bu to'g'ri, lekin mening fikrimcha, bu javob nuqtani o'tkazib yuboradi. Hatto o'n yil oldin mikroservislar kontseptsiyasi keng ko'lamli tizimlarni qurishning istiqbolli usuli sifatida Twitter, Facebook, Google va Netflix kabi kompaniyalarda keng muhokama qilingan va qo'llanilgan. Umumiy nuqtai nazar - hech bo'lmaganda men aloqada bo'lgan sanoat qismlarida - mikroservislar katta tizimlarni qurishning "to'g'ri yo'li" edi, garchi bu juda qiyin bo'lsa ham.
Albatta, o'n yil oldin mikroservislar bilan ishlaydigan kompaniyalar mavjud bo'lsa-da, ular xizmat ko'rsatish tarmog'ini yaratish uchun proksi-serverlarni hamma joyda yopishtirmagan. Ammo, agar diqqat bilan qarasangiz, ular shunga o'xshash ishni qilishgan: bu kompaniyalarning ko'pchiligi tarmoq aloqasi uchun maxsus ichki kutubxonadan foydalanishni talab qilishgan (ba'zan qalin mijozlar kutubxonasi deb ataladi, semiz mijozlar kutubxonasi).
Netflix-da Hysterix, Google-da Stubby, Twitter-da Finagle kutubxonasi bor edi. Masalan, Finagle Twitterdagi har bir yangi xizmat uchun majburiy edi. U ulanishlarning mijoz va server tomonini ko'rib chiqdi, takroriy so'rovlarga ruxsat berdi, so'rovlarni yo'naltirishni qo'llab-quvvatladi, yukni muvozanatlash va o'lchash. Bu xizmat nima qilayotganidan qat'i nazar, butun Twitter stekida barqaror ishonchlilik va kuzatuvchanlik darajasini ta'minladi. Albatta, u faqat JVM tillari uchun ishlagan va butun dastur uchun ishlatilishi kerak bo'lgan dasturlash modeliga asoslangan edi. Biroq, uning funksionalligi deyarli xizmat ko'rsatish tarmog'i bilan bir xil edi. (Aslida, Linkerdning birinchi versiyasi proksi-server shaklida o'ralgan Finagle edi.)
Shunday qilib, o'n yil oldin nafaqat mikroservislar, balki bugungi kunda xizmat ko'rsatish tarmog'i hal qiladigan muammolarni hal qiladigan maxsus proto-servis-mesh kutubxonalari ham mavjud edi. Biroq, xizmat ko'rsatish tarmog'ining o'zi o'sha paytda mavjud emas edi. U paydo bo'lishidan oldin yana bir smena bo'lishi kerak edi.
Va bu erda chuqurroq javob so'nggi 10 yil ichida sodir bo'lgan yana bir o'zgarishda yashiringan: mikroservislarni joylashtirish narxi keskin kamaydi. O'n yil oldin mikroservislardan foydalangan yuqorida tilga olingan kompaniyalar - Twitter, Netflix, Facebook, Google - ulkan miqyosdagi va ulkan resurslarga ega kompaniyalar edi. Ular nafaqat ehtiyojga, balki mikroservislarga asoslangan yirik ilovalarni yaratish, joylashtirish va boshqarish qobiliyatiga ham ega edilar. Twitter muhandislarining monolitik yondashuvdan mikroservislar yondashuviga o'tish uchun sarflagan energiya va sa'y-harakatlari hayratlanarli. (Adolatli bo'lsak, bu muvaffaqiyatga erishdi.) Bunday infratuzilma manevrlari o'sha paytda kichik kompaniyalar uchun imkonsiz edi.
Hozirgacha tez oldinga. Bugungi kunda mikroservislarning ishlab chiquvchilarga nisbati 5:1 (yoki hatto ), va bundan tashqari, ular ular bilan muvaffaqiyatli kurashishadi! Agar 5 kishilik startap 50 ta mikroxizmatni bemalol boshqara olsa, demak, biror narsa ularni amalga oshirish xarajatlarini aniq pasaytirgan.
Monzoda 1500 ta mikroservis; har bir satr trafikka ruxsat beruvchi belgilangan tarmoq qoidasidir
Mikroservislarni ishlatish narxining keskin pasayishi bitta jarayonning natijasidir: konteynerlarning tobora ommalashib borishi и orkestrlar. Bu xizmat tarmog'ining paydo bo'lishiga nima yordam berdi degan savolga aniq javobdir. Xuddi shu texnologiya xizmat tarmoqlarini ham, mikroservislarni ham jozibador qildi: Kubernetes va Docker.
Nega? Xo'sh, Docker bitta katta muammoni - qadoqlash muammosini hal qiladi. Ilova va uning (tarmoq bo'lmagan) ish vaqtiga bog'liqliklarini konteynerga o'rash orqali Docker ilovani istalgan joyda joylashtirish va ishga tushirish mumkin bo'lgan almashtiriladigan birlikka aylantiradi. Shu bilan birga, bu operatsiyani sezilarli darajada osonlashtiradi ko'p tilli Stack: Konteyner ishga tushirishning atom birligi bo'lganligi sababli, joylashtirish va operatsion maqsadlarda JVM, Node, Go, Python yoki Ruby ilovasi bo'ladimi, ichida nima borligi muhim emas. Siz uni ishga tushirasiz va hammasi shu.
Kubernetes hamma narsani keyingi bosqichga olib chiqadi. Endi minglab "ishlash uchun narsalar" va ularni ishlatish uchun tonna mashinalar mavjud bo'lsa, ularni bir-biri bilan bog'laydigan vositaga ehtiyoj bor. Keng ma'noda siz Kubernetesga juda ko'p konteynerlar va ko'plab mashinalarni berasiz va u ularni bir-biriga qarama-qarshi qo'yadi (albatta, bu dinamik va doimiy o'zgaruvchan jarayon: yangi konteynerlar tizim bo'ylab harakatlanadi, mashinalar ishga tushadi va to'xtaydi. , va hokazo. Biroq, Kubernetes bularning barchasini hisobga oladi ).
Kubernetes sozlangandan so'ng, bitta xizmatni o'rnatish va ishlatish uchun sarflanadigan vaqt o'nta xizmatni joylashtirish va ishlatish narxidan unchalik farq qilmaydi (aslida 100 ta xizmat uchun deyarli bir xil). Ushbu konteynerlarga ko'p tillarda amalga oshirishni rag'batlantiradigan qadoqlash mexanizmi sifatida qo'shing va siz turli tillarda yozilgan mikroservislar ko'rinishida amalga oshirilgan ko'plab yangi ilovalarga ega bo'lasiz - aynan shunday muhit turi xizmat ko'rsatish tarmog'i uchun juda mos keladi.
Shunday qilib, biz xizmat ko'rsatish tarmog'i g'oyasi nima uchun hozir mashhur bo'ldi degan savolga javobga keldik: Kubernetes xizmatlar uchun taqdim etadigan bir xillik to'g'ridan-to'g'ri xizmat ko'rsatish tarmog'i oldida turgan operatsion muammolarga taalluqlidir. Siz proksi-serverlarni konteynerlarga joylaysiz, Kubernetesga ularni imkoni boricha yopishtirish vazifasini berasiz va voila! Natijada siz xizmat ko'rsatish tarmog'iga ega bo'lasiz, shu bilan birga uni joylashtirishning barcha mexanikasi Kubernetes tomonidan boshqariladi. (Hech bo'lmaganda qush nigohi bilan. Albatta, bu jarayonda juda ko'p nuanslar mavjud).
Xulosa qilib aytadigan bo'lsak: xizmat tarmoqlarining o'n yil oldin emas, balki hozir mashhur bo'lishining sababi shundaki, Kubernetes va Docker nafaqat sezilarli darajada oshgan. kerak unda ko'p tilli mikroservislar to'plami sifatida ilovalarni amalga oshirishni soddalashtirdi, lekin ayni paytda sezilarli darajada qisqartirildi. xarajatlar uning ishlashi uchun, proksi-server parklarini joylashtirish va qo'llab-quvvatlash mexanizmlarini taqdim etadi.
Nega xizmat ko'rsatish tarmog'i haqida ko'p gapiriladi?
ogohlantirish: Ushbu bo'limda men har qanday taxminlar, taxminlar, uydirmalar va ichki ma'lumotlardan foydalanaman.
"Xizmat to'ri" ni qidirib toping va siz bir tonna qayta ishlangan past kaloriya tarkibini, g'alati loyihalarni va aks-sado kamerasiga loyiq bo'lgan buzuqlik kaleydoskopini uchratasiz. Har qanday ajoyib yangi texnologiya buni amalga oshiradi, ammo xizmat ko'rsatish tarmog'ida muammo ayniqsa keskin. Nega?
Xo'sh, uning bir qismi mening aybim. Men Linkerd va xizmat ko'rsatish tarmog'ini targ'ib qilish uchun har safar ko'p ishladim va shunga o'xshash son-sanoqsiz blog postlari va maqolalari orqali erishdim. Lekin men unchalik kuchli emasman. Bu savolga haqiqatan ham javob berish uchun biz umumiy vaziyat haqida bir oz gapirishimiz kerak. Va bitta loyihani eslatmasdan bu haqda gapirish mumkin emas: Google, IBM va Lyft tomonidan birgalikda ishlab chiqilgan ochiq manbali xizmat tarmog'idir.
(Uch kompaniya bir-biridan juda farq qiladi: Lyftning ishtiroki faqat nomiga o'xshab ko'rinadi; ular Envoy mualliflaridir, lekin Istio'ning rivojlanishida foydalanmaydi yoki ishtirok etmaydi. IBM Istio'ning rivojlanishida ishtirok etadi va undan foydalanadi. Google Istio'ning rivojlanishida faol ishtirok etadi. rivojlantirish , lekin men ayta olamanki, undan foydalanmaydi.)
Istio loyihasi ikki narsa bilan ajralib turadi. Birinchidan, Google, xususan, uni targ'ib qilish uchun juda katta marketing sa'y-harakatlari mavjud. Bugungi kunda xizmat ko'rsatish tarmog'i kontseptsiyasidan xabardor bo'lgan ko'pchilik bu haqda birinchi marta Istio orqali bilishgan deb taxmin qilgan bo'lardim. Ikkinchisi, Istioni qanchalik yomon qabul qilgani. Shubhasiz, men bu masalada manfaatdor tomonman, lekin iloji boricha ob'ektiv bo'lishga harakat qilsam ham, yordam berolmayman , unchalik o'ziga xos emas (garchi noyob bo'lmasa ham: systemd aqlga keladi, ...) Ochiq manba loyihasi uchun.
(Amalda Istio nafaqat murakkablik va UX, balki unumdorlik bilan ham muammolarga duch kelganga o'xshaydi. Masalan, davomida Uchinchi tomon tomonidan o'tkazilgan tadqiqotda tadqiqotchilar Istio-ning dumining kechikishi Linkerdnikiga qaraganda 100 baravar yuqori bo'lgan vaziyatlarni, shuningdek, Istio to'liq ishlashni to'xtatgan holda Linkerd muvaffaqiyatli ishlashda davom etgan resurslardan mahrum bo'lgan vaziyatlarni aniqladilar.)
Nima uchun bu sodir bo'lganligi haqidagi nazariyalarimni chetga surib, men ishonamanki, xizmat tarmog'idagi haddan tashqari hayajon Google ishtiroki bilan izohlanadi. Ya'ni, quyidagi uchta omilning kombinatsiyasi:
- Google-ning Istio-ni intruziv reklamasi;
- loyihaga nisbatan norozi, tanqidiy munosabat;
- So'nggi paytlarda Kubernetes mashhurligining meteorik o'sishi, uning xotiralari hali ham yangi.
Bu omillar birgalikda aql bovar qilmaydigan, kislorodsiz muhitni yaratadi, unda oqilona fikr yuritish qobiliyati zaiflashadi va faqat g'alati xilma-xillik qoladi. .
Linkerd nuqtai nazaridan, bu... men aralash ne'mat sifatida tasvirlagan bo'lardim. Aytmoqchimanki, xizmat ko‘rsatish tarmog‘i 2016-yilda Linkerd birinchi marta ishga tushganda bo‘lmaganidek, asosiy oqimga kirib kelgani juda yaxshi va odamlarni loyihaga e’tibor qaratishlari juda qiyin edi. Endi bunday muammo yo'q! Ammo yomon xabar shundaki, bugungi kunda xizmat ko'rsatish tarmog'i landshafti shunchalik chalkashki, qaysi loyihalar aslida xizmat ko'rsatish tarmog'iga tegishli ekanligini tushunish deyarli mumkin emas (qaysi biri ma'lum bir foydalanish holati uchun eng mos ekanligini tushunish u yoqda tursin). Bu, albatta, hamma uchun kelishuvni buzuvchi (va Istio yoki boshqa loyiha Linkerdga qaraganda yaxshiroq mos keladigan ba'zi holatlar mavjud, chunki ikkinchisi hali ham universal echim emas).
Linkerd tomonida, bizning strategiyamiz shov-shuvga e'tibor bermaslik, jamiyatning haqiqiy muammolarini hal qilishga e'tibor berishni davom ettirish va mohiyatan shov-shuv so'nishini kutish edi. Oxir oqibat, shov-shuv susayadi va biz xotirjam ishlashda davom etishimiz mumkin.
Bu orada hammamiz biroz sabr qilishimiz kerak.
Xizmat tarmog'i men uchun, kamtar dasturiy ta'minot muhandisi uchun foydali bo'ladimi?
Quyidagi anketa bu savolga javob berishga yordam beradi:
Siz faqat biznes mantig'ini amalga oshirishda ishtirok etasizmi? Bunday holda, xizmat ko'rsatish tarmog'i siz uchun foydali bo'lmaydi. Ya'ni, albatta, sizni qiziqtirishi mumkin, lekin ideal holda xizmat ko'rsatish tarmog'i sizning muhitingizda hech narsaga bevosita ta'sir qilmasligi kerak. Nima qilish uchun to'lanadigan ish ustida ishlashda davom eting.
Siz Kubernetes-dan foydalanadigan kompaniyada platformani qo'llab-quvvatlaysizmi? Ha, bu holda sizga xizmat ko'rsatish tarmog'i kerak bo'ladi (agar siz K8-dan faqat monolit yoki partiyaviy ishlov berish uchun foydalanmasangiz, lekin keyin nima uchun sizga K8 kerakligi haqida so'ramoqchiman). Siz turli odamlar tomonidan yozilgan ko'plab mikroservislarga ega bo'lishingiz mumkin. Ularning barchasi bir-biri bilan o'zaro ta'sir qiladi va ish vaqtiga bog'liqliklar chigaliga bog'langan va siz bularning barchasini hal qilish yo'lini topishingiz kerak. Kubernetes-dan foydalanish sizga "o'zingiz uchun" xizmat ko'rsatish tarmog'ini tanlash imkonini beradi. Buni amalga oshirish uchun ularning imkoniyatlari va xususiyatlari bilan tanishib chiqing va mavjud loyihalardan qaysi biri sizga mos keladimi degan savolga javob bering (tadqiqotingizni Linkerd bilan boshlashni tavsiya etaman).
Siz Kubernetesdan foydalanmaydigan, lekin mikroservislardan foydalanadigan kompaniyaning platformasimisiz? Bunday holda, xizmat ko'rsatish tarmog'i siz uchun foydali bo'ladi, lekin undan foydalanish ahamiyatsiz bo'ladi. Albatta mumkin taqlid qilish bir nechta proksi-serverlarni joylashtirish orqali xizmat ko'rsatish tarmog'i, lekin Kubernetes-ning muhim afzalligi - bu joylashtirish modeli: ushbu proksi-serverlarni qo'lda saqlash ko'proq vaqt, kuch va xarajatlarni talab qiladi.
Monolitlar bilan ishlaydigan kompaniyada platforma uchun javobgarmisiz? Bunday holda, sizga xizmat ko'rsatish tarmog'i kerak emas. Agar siz monolitlar (yoki hatto monolitlar to'plamlari) bilan ishlayotgan bo'lsangiz, ular yaxshi aniqlangan va kamdan-kam o'zgaruvchan shovqin naqshlariga ega bo'lsa, unda xizmat ko'rsatish tarmog'i sizga juda oz narsa taklif qiladi. Shunday qilib, siz shunchaki e'tiborsiz qoldirishingiz va yomon tush kabi yo'qolishiga umid qilishingiz mumkin ...
xulosa
Ehtimol, xizmat ko'rsatish tarmog'ini hali ham "dunyodagi eng shov-shuvli texnologiya" deb atash mumkin emas - bu shubhali sharaf, ehtimol, Bitcoin yoki AIga tegishli. Ehtimol, u kuchli beshlikka kiradi. Ammo shovqin qatlamlarini kesib o'tsangiz, xizmat ko'rsatish tarmog'i Kubernetes-da ilovalar yaratuvchilarga haqiqiy foyda keltirishi aniq bo'ladi.
Linkerd-ni sinab ko'rishingizni xohlayman - uni Kubernetes klasteriga o'rnatish (yoki hatto noutbukda Minikube) , va men nima haqida gapirayotganimni o'zingiz ko'rishingiz mumkin.
FAQ
— Agar men xizmat ko'rsatish tarmog'iga e'tibor bermasam, u yo'qoladimi?
— Sizni hafsalangiz pir bo'lishi kerak: xizmat ko'rsatish tarmog'i uzoq vaqt biz bilan.
- Lekin men xizmat to'ridan foydalanishni HOXLAMAYMAN!
- Xo'sh, kerak emas! Hech bo'lmaganda uning asoslari bilan tanishishingiz kerakligini tushunish uchun yuqoridagi so'rovnomamni o'qing.
- Bu yaxshi eski ESB / yangi sousli o'rta dastur emasmi?
— Xizmat tarmog'i semantik emas, balki operatsion mantiq bilan shug'ullanadi. korporativ xizmat avtobusi (). Ushbu ajralishni saqlab qolish xizmat tarmog'iga bir xil taqdirdan qochishga yordam beradi.
— Xizmat ko'rsatish tarmog'i API shlyuzlaridan nimasi bilan farq qiladi?
— Bu mavzuda millionlab maqolalar bor. Shunchaki Google.
— Elchi xizmat tarmog‘imi?
- Yo'q, Elchi xizmat tarmog'i emas, bu proksi-server. U xizmat ko'rsatish tarmog'ini tashkil qilish uchun ishlatilishi mumkin (va yana ko'p - bu umumiy maqsadli proksi-server). Ammo o'z-o'zidan bu xizmat ko'rsatish tarmog'i emas.
— Tarmoq xizmati tarmog‘i xizmat tarmog‘imi?
- Yo'q. Nomiga qaramay, bu xizmat ko'rsatish tarmog'i emas (sizga marketing mo''jizalari qanday yoqadi?).
— Xizmat tarmog'i xabarlar navbatiga asoslangan reaktiv asinxron tizimimda yordam beradimi?
- Yo'q, xizmat ko'rsatish tarmog'i sizga yordam bermaydi.
— Qaysi xizmat tarmog'idan foydalanishim kerak?
- , aql yo'q.
- Maqola yomon! / Muallif xush kelibsiz!
— Iltimos, unga havolani barcha doʻstlaringizga koʻrishlari uchun ulashing!
Rahmatlar
Sarlavhadan taxmin qilganingizdek, ushbu maqola Jey Krepsning fantastik risolasidan ilhomlangan "" Men Jey bilan o'n yil oldin Linked Inda suhbatlashganimda tanishganman va o'shandan beri u menga ilhom berib kelmoqda.
Men o'zimni "Linkerd dasturchisi" deb atashni yaxshi ko'raman, haqiqat shundaki, men ko'proq loyihada README.md faylining saqlovchisiman. Linkerd bugun ustida ishlamoqda , , odamlar va bu loyiha ajoyib hissa qo'shuvchilar va foydalanuvchilar hamjamiyatining ishtirokisiz sodir bo'lmasdi.
Va nihoyat, Linkerd yaratuvchisiga alohida rahmat, (primus inter pares)Ko'p yillar oldin men bilan birga xizmat tarmog'i bilan bu shov-shuvga sho'ng'igan.
Tarjimondan PS
Shuningdek, bizning blogimizda o'qing:
- «";
- «";
- «";
- «";
- «".
Manba: www.habr.com