🥇Servis meshdan foydalanish holatlari

Eslatma. tarjima.: Ushbu maqola muallifi (Luc Perkins) Linkerd, SMI (Service Mesh Interface) va Kuma kabi Ochiq manbali loyihalarga mezbon bo'lgan CNCF tashkilotida ishlab chiquvchi advokatidir (Aytgancha, Istio nima uchun ekanligiga qiziqdingizmi? bu ro'yxatda emasmi? .). Yana bir bor DevOps hamjamiyatiga "xizmat tarmog'i" deb nomlangan zamonaviy shov-shuvni yaxshiroq tushunishga harakat qilib, u bunday echimlar taqdim etadigan 16 ta xarakterli imkoniyatlarni sanab o'tdi.

bugun xizmat ko'rsatish tarmog'i ― dasturiy ta'minot muhandisligi sohasidagi eng dolzarb mavzulardan biri (va haqli ravishda!). Menimcha, bu texnologiya nihoyatda istiqbolli va uning keng qo'llanilishini ko'rishni xohlayman (albatta, mantiqiy bo'lsa). Biroq, u hali ham ko'pchilik uchun sirli aura bilan o'ralgan. Shu bilan birga, hatto kim yaxshi tanilgan u bilan uning afzalliklarini va aniq nima ekanligini (jumladan, siznikiniki) ifodalash ko'pincha qiyin. Ushbu maqolada men turli xil narsalarni sanab, vaziyatni tuzatishga harakat qilaman foydalanish holatlari "xizmat tarmoqlari"*.

* Eslatma tarjima: bu yerda va maqolada aynan shu tarjima (“xizmat tarmog‘i”) hali yangi xizmat mesh atamasi uchun ishlatiladi.

Lekin birinchi navbatda men bir nechta sharhlarni aytmoqchiman:

Men hech qachon xizmat tarmoqlari bilan ishlamaganman yoki ularni o'z ta'limim uchun boshlangan loyihalardan tashqarida ishlatmaganman. Boshqa tomondan, men 2015-yilda Twitter-ning ichki xizmat koʻrsatish tarmogʻi uchun bir qancha hujjatlarni yozganman (u oʻsha paytda u hatto “xizmat tarmogʻi” ham deb atalmagan) va veb-sayt va hujjatlarni ishlab chiqishda ishtirok etganman. Linkerd, shuning uchun bu nimanidir anglatadi.
Mening ro'yxatim taxminiy va to'liq emas. Menga noma'lum foydalanish holatlari bo'lishi mumkin va texnologiya rivojlanishi va uning mashhurligi o'sishi bilan vaqt o'tishi bilan yangi variantlar paydo bo'lishi mumkin.
Shu bilan birga, har bir mavjud xizmat ko'rsatish tarmog'i ro'yxatga olingan barcha foydalanish holatlarini qo'llab-quvvatlamaydi. Shuning uchun, mening "xizmat tarmog'i mumkin ..." kabi so'zlarim "individual va, ehtimol, barcha mashhur xizmat ko'rsatish tarmog'ini amalga oshirishi mumkin ..." deb o'qilishi kerak.
Misollar tartibi hech qanday farq qilmaydi.

Qisqa ro'yxat:

xizmatlarni aniqlash;
shifrlash;
autentifikatsiya va avtorizatsiya;
yukni muvozanatlash;
elektron uzilish;
avtomatik masshtablash;
kanareykalarni joylashtirish;
ko'k-yashil joylashtirishlar;
salomatlik tekshiruvi;
yukni yo'qotish;
trafikni aks ettirish;
izolyatsiya;
so'rov tezligini cheklash, qayta urinishlar va kutish vaqti;
telemetriya;
audit;
vizualizatsiya.

1. Xizmatni aniqlash

TL;DR: Oddiy nomlar yordamida tarmoqdagi boshqa xizmatlarga ulaning.

Xizmatlar mos nomlar yordamida bir-birlarini avtomatik ravishda "topishi" kerak - masalan, service.api.production, pets/staging yoki cassandra. Bulutli muhitlar elastik va bitta nom xizmatning ko'p nusxalarini yashirishi mumkin. Bunday vaziyatda barcha IP manzillarni qattiq kodlash jismonan mumkin emasligi aniq.

Bundan tashqari, bir xizmat boshqasini topsa, u buzilgan namunasi kiritilishidan qo'rqmasdan ushbu xizmatga so'rovlar yuborishi kerak. Boshqacha qilib aytganda, xizmat ko'rsatish tarmog'i barcha xizmat ko'rsatish namunalarining sog'lig'ini kuzatishi va xostlar ro'yxatini iloji boricha yangilab turishi kerak.

Har bir xizmat tarmog'i xizmatni aniqlash mexanizmini boshqacha amalga oshiradi. Hozirgi vaqtda eng keng tarqalgan usul DNS Kubernetes kabi tashqi jarayonlarga vakolat berishdir. Ilgari Twitterda bu maqsadda nomlash tizimidan foydalanganmiz Finagle. Bundan tashqari, xizmat ko'rsatish tarmog'i texnologiyasi maxsus nomlash mexanizmlarini paydo bo'lishiga imkon beradi (garchi men hali bunday funksionallik bilan SM ilovasini ko'rmaganman).

2. Shifrlash

TL; DR: Xizmatlar orasidagi shifrlanmagan trafikdan xalos bo'ling va bu jarayonni avtomatlashtirilgan va kengaytirilishi mumkin.

Buzg'unchilar sizning ichki tarmog'ingizga kira olmasligini bilish juda yoqimli. Xavfsizlik devori bu vazifani juda yaxshi bajaradi. Ammo xaker ichkariga kirsa nima bo'ladi? U xizmat ichidagi trafik bilan xohlagan narsani qila oladimi? Umid qilamizki, bu sodir bo'lmaydi. Ushbu stsenariyni oldini olish uchun xizmatlar o'rtasidagi barcha trafik shifrlangan nol ishonch tarmog'ini joriy qilishingiz kerak. Aksariyat zamonaviy xizmat ko'rsatish tarmoqlari bunga o'zaro yordam orqali erishadilar TLS (o'zaro TLS, mTLS). Ba'zi hollarda mTLS butun bulutlar va klasterlarda ishlaydi (menimcha, sayyoralararo aloqalar bir kun kelib xuddi shunday tartibga solinadi).

Albatta, mTLS xizmat tarmog'i uchun ixtiyoriy. Har bir xizmat o'zining TLS-ga g'amxo'rlik qilishi mumkin, ammo bu sizga sertifikatlar yaratish, ularni xizmat hostlari bo'ylab tarqatish va ushbu sertifikatlarni fayllardan yuklaydigan dasturga kod kiritish yo'lini topishingiz kerakligini anglatadi. Ha, ushbu sertifikatlarni muntazam ravishda yangilashni unutmang. Xizmat tarmoqlari kabi tizimlar bilan mTLSni avtomatlashtiradi SPIFFE, bu esa, o'z navbatida, sertifikatlarni berish va aylantirish jarayonini avtomatlashtiradi.

3. Autentifikatsiya va avtorizatsiya

TL; DR: so'rovchi kimligini aniqlang va so'rov xizmatga yetib borgunga qadar ularga nima qilishiga ruxsat berilganligini aniqlang.

Xizmatlar ko'pincha bilishni xohlaydi kim? so'rovni (autentifikatsiyani) amalga oshiradi va ushbu ma'lumotlardan foydalanib, qaror qabul qiladi ekan berilgan sub'ektga ruxsat berilgan (avtorizatsiya). Bunday holda, "kim" olmoshi yashirishi mumkin:

Boshqa xizmatlar. Bu "autentifikatsiya" deb ataladi tengdosh" Masalan, xizmat web xizmatga kirishni xohlaydi db. Xizmat tarmoqlari odatda mTLS yordamida bunday muammolarni hal qiladi: bu holda sertifikatlar zarur identifikator sifatida ishlaydi.
Ba'zi inson foydalanuvchilari. Bu "autentifikatsiya" deb ataladi iltimos" Masalan, foydalanuvchi haxor69 yangi chiroq sotib olmoqchi. Xizmat ko'rsatish tarmoqlari turli mexanizmlarni ta'minlaydi, masalan. JSON veb-tokenlari.
Ko'pchiligimiz buni dastur kodida qilganmiz. So'rov keladi, biz jadvalni ko'rib chiqamiz users, foydalanuvchini toping va parolni solishtiring, so'ngra ustunni tekshiring permissions va hokazo. Xizmat ko'rsatish tarmog'i bo'lsa, bu so'rov xizmatga yetib bormasdan oldin sodir bo'ladi.

So'rov kimdan kelganini aniqlaganimizdan so'ng, biz ushbu shaxsga nima qilishga ruxsat berilganligini aniqlashimiz kerak. Ba'zi xizmat meshlari YAML fayllari yoki buyruq satrida asosiy siyosatlarni (kim nima qilishi mumkinligi haqida) o'rnatishga imkon beradi, boshqalari esa kabi ramkalar bilan integratsiyani taklif qiladi. Ochiq siyosat agenti. Yakuniy maqsad sizning xizmatlaringiz har qanday so'rovni ishonchli manbadan kelgan deb hisoblagan holda qabul qilishidir и bu harakatga ruxsat beriladi.

4. Yuklarni muvozanatlash

TL; DR: yukni ma'lum bir naqsh bo'yicha xizmat ko'rsatish misollari bo'ylab taqsimlang.

Xizmat bo'limidagi "Xizmat" ko'pincha bir xil misollardan iborat. Masalan, bugungi kunda xizmat cache 5 nusxadan iborat bo'lib, ertaga ularning soni 11 tagacha ko'payishi mumkin cache, ma'lum bir maqsadga muvofiq taqsimlanishi kerak. Masalan, kechikishni minimallashtiring yoki ishlaydigan misolga kirish ehtimolini oshiring. Eng ko'p ishlatiladigan algoritm Round-robin, ammo boshqalar ko'p - masalan, vaznli usul (vaznli) so'rovlar (siz afzal maqsadlarni tanlashingiz mumkin), jiringlash (ring) xeshlash (yuqoridagi xostlar bo'ylab izchil xeshlashdan foydalanish) yoki eng kam so'rov usuli (eng kam so'rovga ega misolga afzallik beriladi).

Klassik balanslashtirgichlar HTTP keshlash va DDoS himoyasi kabi boshqa funksiyalarga ham ega, biroq ular sharq-g‘arbiy trafik (ya’ni ma’lumotlar markazi ichida oqayotgan trafik uchun – taxminan transl.) uchun unchalik ahamiyatli emas (xizmat ko‘rsatish tarmog‘ining odatiy doirasi). Albatta, yukni muvozanatlash uchun xizmat ko'rsatish tarmog'idan foydalanish shart emas, lekin u markazlashtirilgan boshqaruv qatlamidan har bir xizmat uchun muvozanatlash siyosatini o'rnatish va boshqarish imkonini beradi, shu bilan tarmoq stekida alohida yuk balanslagichlarini ishga tushirish va sozlash zaruratini yo'q qiladi. .

5. Elektr zanjirining uzilishi

TL; DR: Muammoli xizmatga trafikni to'xtating va eng yomon stsenariylarda zararni boshqaring.

Agar biron sababga ko'ra xizmat tirbandlikka dosh bera olmasa, xizmat ko'rsatish tarmog'i ushbu muammoni hal qilish uchun bir nechta variantni taqdim etadi (boshqalar tegishli bo'limlarda muhokama qilinadi). O'chirish uzilishi xizmatni tirbandlikdan uzishning eng og'ir variantidir. Biroq, o'z-o'zidan bu mantiqiy emas - zaxira rejasi kerak. Orqa bosim ta'minlanishi mumkin (orqa bosim) so'rovlar yuboradigan xizmatlarga (shunchaki buning uchun xizmat ko'rsatish tarmog'ini sozlashni unutmang!) yoki, masalan, holat sahifasini qizil rangga bo'yash va foydalanuvchilarni "tushgan kit" bilan sahifaning boshqa versiyasiga yo'naltirish ("Twitter" pastga").

Xizmat meshlari nafaqat aniqlash imkonini beradi qachon o'chirish va ekan bu ergashadi. Bunday holda, "qachon" belgilangan parametrlarning har qanday kombinatsiyasini o'z ichiga olishi mumkin: ma'lum bir davr uchun so'rovlarning umumiy soni, parallel ulanishlar soni, kutilayotgan so'rovlar, faol qayta urinishlar va boshqalar.

Ehtimol, siz elektr tarmog'ining uzilishini suiiste'mol qilishni xohlamaysiz, ammo favqulodda vaziyatda zaxira rejangiz borligini bilish juda yoqimli.

6. Avtomatik masshtablash

TL; DR: Belgilangan mezonlarga qarab xizmat ko'rsatish nusxalari sonini ko'paytirish yoki kamaytirish.

Xizmat tarmoqlari rejalashtiruvchi emas, shuning uchun ular yo'q amalga oshirish o'zingizni masshtablash. Biroq, ular qaysi rejalashtiruvchilar o'z qarorlariga asoslanishi haqida ma'lumot berishlari mumkin. Xizmat ko'rsatish tarmoqlari xizmatlar o'rtasidagi barcha trafikka kirish imkoniga ega bo'lganligi sababli, ular nima sodir bo'layotgani haqida keng ma'lumotga ega: qaysi xizmatlarda muammolar mavjud, qaysi xizmatlar juda kam yuklangan (ularga ajratilgan sig'im isrof qilinadi) va hokazo.

Masalan, Kubernetes protsessor va xotiradan foydalanishga qarab xizmatlarni o'lchaydi (bizning hisobotimizga qarang"Kubernetesda avtomatik o'lchov va resurslarni boshqarish" - taxminan. tarjima.), lekin agar siz boshqa har qanday ko'rsatkich (bizning holatda, trafik bilan bog'liq) asosida o'lchashga qaror qilsangiz, sizga maxsus ko'rsatkich kerak bo'ladi. Boshqaruv shunga o'xshash bilan buni qanday qilishni ko'rsatadi elchisi, Istio и Prometheus, lekin jarayonning o'zi ancha murakkab. Biz xizmat ko'rsatish tarmog'i buni soddalashtirishini xohlaymiz, bu bizga oddiygina shartlarni o'rnatishga imkon beradi, masalan "xizmat ko'rsatkichlari sonini ko'paytirish" auth, agar kutilayotgan so'rovlar soni bir daqiqa ichida chegaradan oshsa."

7. Kanareykalarni joylashtirish

TL; DR: Yangi funksiyalar yoki xizmat versiyalarini foydalanuvchilarning kichik to‘plamida sinab ko‘ring.

Aytaylik, siz SaaS mahsulotini ishlab chiqmoqdasiz va uning yangi ajoyib versiyasini chiqarmoqchisiz. Siz uni sahnalashtirishda sinab ko'rdingiz va u juda yaxshi ishladi. Ammo haqiqiy sharoitda uning xatti-harakati haqida hali ham ma'lum tashvishlar mavjud. Boshqacha qilib aytganda, foydalanuvchi ishonchini xavf ostiga qo'ymasdan, yangi versiyani haqiqiy muammolar bo'yicha sinab ko'rishingiz kerak. Buning uchun kanareykalarni joylashtirish juda yaxshi. Ular foydalanuvchilarning bir qismiga yangi xususiyatni namoyish qilish imkonini beradi. Ushbu kichik to'plam eng sodiq foydalanuvchilar yoki mahsulotning bepul versiyasi bilan ishlaydiganlar yoki "gvineya cho'chqalari" bo'lish istagini bildirgan foydalanuvchilardan iborat bo'lishi mumkin.

Xizmat tarmoqlari buni ilovaning qaysi versiyasini kim ko'rishini aniqlaydigan mezonlarni belgilash va shunga mos ravishda trafikni yo'naltirish imkonini berish orqali amalga oshiradi. Biroq, xizmatlarning o'zlari uchun hech narsa o'zgarmaydi. Xizmatning 1.0 versiyasi barcha so'rovlar uni ko'rishi kerak bo'lgan foydalanuvchilardan keladi deb hisoblaydi va 1.1 versiyasi o'z foydalanuvchilari uchun xuddi shunday deb hisoblaydi. Shu bilan birga, siz eski va yangi versiyalar o'rtasidagi trafik foizini o'zgartirishingiz mumkin, agar u barqaror ishlayotgan bo'lsa va sizning "gvineya cho'chqalaringiz" oldinga siljish bersa, ko'payib borayotgan foydalanuvchilar sonini yangisiga yo'naltirishingiz mumkin.

8. Ko'k-yashil joylashtirishlar

TL; DR: Ajoyib yangi xususiyatni ishga tushiring, lekin darhol hamma narsani qaytarib olishga tayyor bo'ling.

Ma'nosi ko'k-yashil joylashtirishlar yangi "ko'k" xizmatni yo'lga qo'yish, uni eski, "yashil" bilan parallel ravishda ishga tushirish. Agar hamma narsa muammosiz bo'lsa va yangi xizmat yaxshi ishlayotgan bo'lsa, unda eskisini asta-sekin o'chirib qo'yish mumkin. (Afsuski, bir kun kelib bu yangi "ko'k" xizmat "yashil"ning taqdirini takrorlaydi va yo'qoladi...) Ko'k-yashil joylashuvlar kanareykalardan farq qiladi, chunki yangi funktsiya qamrab oladi. hamma bir vaqtning o'zida foydalanuvchilar (qism emas); Gap shundaki, agar biror narsa noto'g'ri bo'lsa, "xavfsiz bandargoh" tayyor bo'lishi kerak.

Xizmat tarmoqlari "ko'k" xizmatni sinab ko'rishning juda qulay usulini taklif qiladi va muammo yuzaga kelganda darhol ishlaydigan "yashil" ga o'tadi. Yo'l davomida ular "ko'k" ning ishi haqida juda ko'p ma'lumotlarni taqdim etishlarini (quyida "Telemetriya" ga qarang), bu uning to'liq ishlashga tayyor yoki yo'qligini tushunishga yordam beradi.

Eslatma. tarjima.: Kubernetes-da turli xil joylashtirish strategiyalari (jumladan, eslatib o'tilgan kanareyka, ko'k/yashil va boshqalar) haqida ko'proq ma'lumot olishingiz mumkin. Ushbu maqola.

9. Salomatlikni tekshirish

TL; DR: Qaysi xizmat misollari ishlayotganini kuzatib boring va endi ishlamayotganlariga javob bering.

Salomatlik tekshiruvi (sog'liqni tekshirish) xizmat namunalari trafikni qabul qilish va qayta ishlashga tayyormi yoki yo'qligini aniqlashga yordam beradi. Misol uchun, HTTP xizmatlarida sog'liqni tekshirish oxirgi nuqtaga GET so'rovi kabi ko'rinishi mumkin /health. Javob 200 OK misol sog'lom, boshqa har qanday - u trafikni qabul qilishga tayyor emasligini bildiradi. Xizmat ko'rsatish tarmoqlari sizga funksionallikni tekshirish usulini ham, ushbu tekshirishning chastotasini ham belgilash imkonini beradi. Keyinchalik bu ma'lumot boshqa maqsadlarda - masalan, yukni muvozanatlash va elektron uzilish uchun ishlatilishi mumkin.

Shunday qilib, sog'liqni saqlashni tekshirish mustaqil foydalanish holati emas, balki odatda boshqa maqsadlarga erishish uchun ishlatiladi. Shuningdek, sog'liqni tekshirish natijalariga qarab, boshqa xizmat ko'rsatish maqsadlaridan tashqari harakatlar talab qilinishi mumkin: masalan, holat sahifasini yangilash, GitHub-da muammo yaratish yoki JIRA chiptasini to'ldirish. Va servis tarmog'i bularning barchasini avtomatlashtirish uchun qulay mexanizmni taklif qiladi.

10. Yukni yo'qotish

TL; DR: Foydalanishning vaqtinchalik o'sishiga javoban trafikni qayta yo'naltirish.

Agar ma'lum bir xizmat trafik bilan haddan tashqari yuklangan bo'lsa, siz ushbu trafikning bir qismini vaqtincha boshqa joyga yo'naltirishingiz mumkin (ya'ni, "axlat", "o'tkazish" (to'kmoq) u erda). Masalan, zaxira xizmatiga yoki ma'lumotlar markaziga yoki doimiy Pulsar mavzu. Natijada, xizmat ishdan chiqish va hamma narsani qayta ishlashni to'xtatish o'rniga ba'zi so'rovlarni qayta ishlashni davom ettiradi. Yukni to'kish sxemani buzishdan afzalroqdir, ammo uni suiiste'mol qilish hali ham tavsiya etilmaydi. Bu quyi oqim xizmatlarining ishdan chiqishiga olib keladigan kaskadli nosozliklarni oldini olishga yordam beradi.

11. Trafikni parallellashtirish/aks ettirish

TL; DR: Bir vaqtning o'zida bir nechta joyga bitta so'rov yuboring.

Ba'zan bir vaqtning o'zida bir nechta xizmatlarga so'rovni (yoki so'rovlarning ma'lum bir tanlovini) yuborish kerak bo'ladi. Oddiy misol ishlab chiqarish trafigining bir qismini staging xizmatiga yuborishdir. Asosiy ishlab chiqarish veb-serveri quyi oqim xizmatiga so'rov yuboradi products.production va faqat unga. Va xizmat tarmog'i ushbu so'rovni aqlli ravishda nusxalaydi va uni yuboradi products.staging, bu haqda veb-server ham bilmaydi.

Trafikni parallellashtirishning yuqori qismida amalga oshirilishi mumkin bo'lgan yana bir tegishli xizmat tarmog'idan foydalanish holati regressiya testi. Bu xizmatning turli versiyalariga bir xil so'rovlarni yuborishni va barcha versiyalar bir xil ish tutishini tekshirishni o'z ichiga oladi. Men shunga o'xshash integratsiyalashgan regressiya test tizimiga ega bo'lgan xizmat mesh dasturini hali uchratmadim Diffy, lekin g'oyaning o'zi istiqbolli ko'rinadi.

12. Izolyatsiya

TL; DR: Xizmat ko'rsatish tarmog'ingizni mini-tarmoqlarga ajrating.

Shuningdek, nomi bilan tanilgan segmentatsiyaIzolyatsiya - bu xizmat ko'rsatish tarmog'ini bir-biri haqida hech narsa bilmaydigan mantiqiy jihatdan alohida segmentlarga bo'lish san'ati. Izolyatsiya virtual xususiy tarmoqlarni yaratishga o'xshaydi. Asosiy farq shundaki, siz hali ham xizmat ko'rsatish tarmog'ining barcha afzalliklaridan bahramand bo'lishingiz mumkin (masalan, xizmatni kashf qilish), lekin qo'shimcha xavfsizlik bilan. Misol uchun, agar tajovuzkor bitta quyi tarmoqdagi xizmatga kira olsa, u boshqa quyi tarmoqlarda qanday xizmatlar ishlayotganini ko'ra olmaydi yoki ularning trafigini to'xtata olmaydi.

Bundan tashqari, imtiyozlar tashkiliy bo'lishi mumkin. Siz o'zingizning kompaniyangiz tuzilmasi asosida o'z xizmatlaringizni subtarmoqqa kiritishni xohlashingiz va ishlab chiquvchilarni butun xizmat tarmog'ini yodda tutish kerak bo'lgan kognitiv yukdan xalos qilishingiz mumkin.

13. So'rov tezligini cheklash, qayta urinishlar va kutish vaqti

TL; DR: Endi siz kodlar bazasiga murakkab so'rovlarni boshqarish vazifalarini kiritishingiz shart emas.

Bularning barchasini alohida foydalanish holatlari deb hisoblash mumkin, lekin men ularni bir umumiy xususiyat tufayli birlashtirishga qaror qildim: ular odatda ilovalar kutubxonalari tomonidan bajariladigan so'rovning hayot aylanishini boshqarish vazifalarini o'z zimmalariga oladilar. Agar siz Ruby on Rails-da (xizmat tarmog'i bilan birlashtirilmagan) veb-serverni ishlab chiqayotgan bo'lsangiz, u orqali backend xizmatlariga so'rovlar yuboriladi. gRPC, agar N so'rov bajarilmasa, dastur nima qilish kerakligini hal qilishi kerak. Shuningdek, ushbu xizmatlar maxsus kutubxona yordamida ushbu parametrlarni qayta ishlash va qattiq kodlash imkoniyatiga ega bo'lgan trafikni aniqlashingiz kerak bo'ladi. Bundan tashqari, dastur qachon voz kechish vaqti kelganini hal qilishi va so'rovning bekor qilinishiga yo'l qo'yishi kerak (vaqt tugashi asosida). Va yuqoridagi parametrlardan birini o'zgartirish uchun veb-serverni to'xtatish, qayta sozlash va qayta ishga tushirish kerak bo'ladi.

Ushbu vazifalarni xizmat ko'rsatish tarmog'iga yuklash nafaqat xizmatni ishlab chiquvchilari ular haqida o'ylamasliklarini, balki ularni yanada globalroq ko'rish mumkinligini anglatadi. Agar murakkab xizmatlar zanjiri ishlatilsa, aytaylik A -> B -> C -> D -> E, so'rovning butun hayotiy tsikli hisobga olinishi kerak. Agar vazifa C xizmatida kutish vaqtini uzaytirish bo'lsa, buni qismlarga bo'lib emas, balki bir vaqtning o'zida bajarish mantiqan to'g'ri bo'ladi: xizmat kodini yangilash va tortish so'rovi qabul qilinishini kutish va CI tizimi yangilangan xizmatni ishga tushirish.

14. Telemetriya

TL; DR: xizmatlardan barcha kerakli (va unchalik emas) ma'lumotlarni to'plang.

Telemetriya umumiy atama bo'lib, o'lchovlar, taqsimlangan kuzatuv va jurnallarni o'z ichiga oladi. Xizmat tarmoqlari barcha uch turdagi ma'lumotlarni yig'ish va qayta ishlash mexanizmlarini taklif qiladi. Bu erda narsalar biroz xiralashadi, chunki mumkin bo'lgan variantlar soni juda katta. Ko'rsatkichlarni yig'ish uchun mavjud Prometheus va jurnallarni yig'ish uchun ishlatilishi mumkin bo'lgan boshqa vositalar ravon, Loki, vektor va boshq. (masalan, ClickHouse bilan bizning yog'och uy K8s uchun - taxminan. tarjima.), taqsimlangan kuzatish uchun mavjud Jaeger va h.k. Har bir xizmat ko'rsatish tarmog'i ba'zi vositalarni qo'llab-quvvatlashi mumkin, boshqalari emas. Loyihani amalga oshirish mumkinmi yoki yo'qligini bilish qiziqarli bo'ladi Telemetriyani oching bir oz konvergentsiyani ta'minlaydi.

Bunday holda, xizmat ko'rsatish tarmog'i texnologiyasining afzalligi shundaki, yonbosh konteynerlari, qoida tariqasida, yuqoridagi barcha ma'lumotlarni o'z xizmatlaridan to'plashi mumkin. Boshqacha qilib aytadigan bo'lsak, sizning ixtiyoringizda yagona telemetriya yig'ish tizimi mavjud va xizmat ko'rsatish tarmog'i bu barcha ma'lumotlarni turli usullar bilan qayta ishlashi mumkin. Masalan:

CLI-dagi ma'lum bir xizmatdan quyruq jurnallari;
xizmat ko'rsatish panelidan so'rovlar hajmini kuzatish;
taqsimlangan izlarni to'plang va ularni Jaeger kabi tizimga yuboring.

Diqqat, sub'ektiv hukm: Umuman olganda, telemetriya - bu xizmat ko'rsatish tarmog'ining kuchli aralashuvi istalmagan sohadir. Asosiy ma'lumotlarni to'plash va so'rovning muvaffaqiyat darajasi va kechikish kabi ba'zi oltin ko'rsatkichlarni kuzatib borish juda yaxshi, ammo keling, Frankenshteyn steklari paydo bo'lishini ko'rmaymiz, deb umid qilamizki, ba'zilari allaqachon o'zini isbotlagan va yaxshi o'rganilgan maxsus tizimlarni almashtirishga harakat qiladi. .

15. Audit

TL;DR: Tarix saboqlarini unutganlar ularni takrorlashga mahkum.

Audit - bu tizimdagi muhim voqealarni kuzatish san'ati. Xizmat tarmog'i bo'lsa, bu muayyan xizmatlar uchun ma'lum so'nggi nuqtalarga kim so'rov yuborganini yoki o'tgan oyda xavfsizlik bilan bog'liq hodisa necha marta sodir bo'lganligini kuzatishni anglatishi mumkin.

Audit telemetriya bilan juda chambarchas bog'liqligi aniq. Farqi shundaki, telemetriya odatda unumdorlik va texnik yaxlitlik kabi narsalar bilan bog'liq, audit esa qat'iy texnik sohadan tashqariga chiqadigan huquqiy va boshqa masalalar bilan bog'liq bo'lishi mumkin (masalan, GDPR - ma'lumotlarni himoya qilish bo'yicha Evropa Ittifoqining umumiy reglamentiga muvofiqlik).

16. Vizualizatsiya

TL;DR: Yashasin React.js - ajoyib interfeyslarning bitmas-tuganmas manbai.

Yaxshiroq atama bo'lishi mumkin, lekin men buni bilmayman. Men shunchaki xizmat ko'rsatish tarmog'i yoki uning ba'zi tarkibiy qismlarining grafik tasvirini nazarda tutyapman. Bu vizualizatsiya oʻrtacha kechikishlar, yon vagon konfiguratsiyasi maʼlumotlari, sogʻliqni tekshirish natijalari va ogohlantirishlarni oʻz ichiga olishi mumkin.

Xizmatga yo'naltirilgan muhitda ishlash Janobi Oliylari Monolit bilan solishtirganda ancha yuqori kognitiv yukni o'z ichiga oladi. Shuning uchun kognitiv bosim har qanday holatda ham kamayishi kerak. Bir tugmani bosish va kerakli natijani olish qobiliyatiga ega bo'lgan xizmat tarmog'i uchun oddiy grafik interfeys ushbu texnologiyaning mashhurligini oshirish uchun hal qiluvchi bo'lishi mumkin.

Ro'yxatga kiritilmagan

Men dastlab roʻyxatga yana bir nechta foydalanish holatlarini kiritish niyatida edim, lekin keyin qoʻymaslikka qaror qildim. Mana ular mening qarorim sabablari bilan birga:

Ko'p ma'lumotlar markazi. Menimcha, bu xizmat ko'rsatish tarmoqlarini qo'llashning tor va o'ziga xos sohasi yoki xizmatlarni topish kabi ba'zi funktsiyalar to'plami sifatida foydalanish holati emas.
Kirish va chiqish. Bu tegishli soha, lekin men o'zimni (ehtimol sun'iy ravishda) "sharq-g'arbiy transport" dan foydalanish holati bilan cheklab qo'ydim. Kirish va chiqish alohida maqolaga loyiqdir.

xulosa

Hozircha hammasi shu! Shunga qaramay, bu ro'yxat juda o'zboshimchalik va to'liq emas. Agar biror narsani o'tkazib yubordim yoki xato qildim deb o'ylasangiz, Twitter orqali men bilan bog'laning (@luckerkins). Iltimos, odob-axloq qoidalarini hurmat qiling.

Tarjimondan PS

Maqolaning sarlavhasi maqoladagi rasmga asoslangan "Xizmat tarmog'i nima (va uni qachon ishlatish kerak)?"(Gregori MakKinnon tomonidan). U ilovalarning ba'zi funksiyalari (yashil rangda) ular orasidagi o'zaro bog'lanishni ta'minlovchi xizmat ko'rsatish tarmog'iga qanday o'tganini ko'rsatadi (ko'k rangda).

Shuningdek, bizning blogimizda o'qing:

Manba: www.habr.com