🥇Xidmət şəbəkəsindən istifadə halları

Qeyd. tərcümə.: Bu məqalənin müəllifi (Luc Perkins) Linkerd, SMI (Service Mesh Interface) və Kuma kimi Açıq Mənbəli layihələrə ev sahibliyi edən CNCF təşkilatında inkişaf etdirici müdafiəçisidir (yeri gəlmişkən, Istio-nun niyə belə olduğunu merak etdinizmi? bu siyahıda yoxdu?.). Bir daha DevOps cəmiyyətinə "xidmət şəbəkəsi" adlanan moda şırınganı daha yaxşı başa düşməyə çalışaraq, bu cür həllərin təmin etdiyi 16 xarakterik imkanları sadalayır.

Hazırda xidmət mesh ― proqram mühəndisliyi sahəsində ən isti mövzulardan biri (və haqlı olaraq belədir!). Düşünürəm ki, bu texnologiya inanılmaz dərəcədə perspektivlidir və onun geniş şəkildə mənimsənilməsini görmək istərdim (təbii ki, məntiqli olduqda). Bununla belə, əksər insanlar üçün hələ də sirr aurası ilə əhatə olunur. Eyni zamanda, hətta edənlər də yaxşı tanınır onunla, onun üstünlüklərini və dəqiq nə olduğunu (həqiqətən sizin də daxil olmaqla) ifadə etmək çox vaxt çətindir. Bu yazıda müxtəlif sadalayaraq vəziyyəti düzəltməyə çalışacağam istifadə halları "xidmət şəbəkələri"*.

* Qeyd tərcümə: burada və daha sonra məqalədə məhz bu tərcümə (“xidmət şəbəkəsi”) hələ yeni “servis mesh” termini üçün istifadə olunacaq.

Ancaq əvvəlcə bir neçə şərh vermək istəyirəm:

Mən heç vaxt xidmət şəbəkələri ilə işləməmişəm və ya öz təhsilim üçün başladığım layihələrdən kənar istifadə etməmişəm. Digər tərəfdən, mən 2015-ci ildə Twitter-in daxili xidmət şəbəkəsi üçün bir dəstə sənəd yazmışam (o vaxtlar hətta “xidmət şəbəkəsi” də deyilmirdi) və veb-saytın və sənədlərin hazırlanmasında iştirak etmişəm. Linkerd, belə ki, bir şey deməkdir.
Mənim siyahım təxmini və natamamdır. Mənə məlum olmayan istifadə halları ola bilər və texnologiya inkişaf etdikcə və onun populyarlığı artdıqca zamanla yeni variantlar ortaya çıxacaq.
Eyni zamanda, hər bir mövcud xidmət şəbəkəsi tətbiqi sadalanan bütün istifadə hallarını dəstəkləmir. Buna görə də, "xidmət şəbəkəsi edə bilər ..." kimi ifadələrim "fərdi və bəlkə də bütün populyar xidmət şəbəkəsi tətbiqləri edə bilər ..." kimi oxunmalıdır.
Nümunələrin ardıcıllığı heç bir fərq yaratmır.

Qısa siyahı:

xidmət kəşfi;
şifrələmə;
autentifikasiya və avtorizasiya;
yük balansı;
dövrə kəsilməsi;
avtomatik miqyaslama;
kanareyka yerləşdirmələri;
mavi-yaşıl yerləşdirmələr;
sağlamlıq yoxlaması;
yük atma;
trafikin əks olunması;
izolyasiya;
sorğu sürətinin məhdudlaşdırılması, təkrar cəhdlər və fasilələr;
telemetriya;
audit;
vizuallaşdırma.

1. Xidmət kəşfi

TL;DR: Sadə adlardan istifadə edərək şəbəkədəki digər xidmətlərə qoşulun.

Xidmətlər adekvat adlardan istifadə etməklə avtomatik olaraq bir-birini “tapmağı” bacarmalıdır - məsələn, service.api.production, pets/staging və ya cassandra. Bulud mühitləri elastikdir və bir ad xidmətin bir çox nümunəsini gizlədə bilər. Aydındır ki, belə bir vəziyyətdə bütün IP ünvanlarını sərt kodlaşdırmaq fiziki olaraq mümkün deyil.

Üstəlik, bir xidmət digərini tapdıqda, onun pozulmuş instansiyasının girişində bitəcəyindən qorxmadan həmin xidmətə sorğu göndərə bilməlidir. Başqa sözlə, xidmət şəbəkəsi bütün xidmət instansiyalarının sağlamlığına nəzarət etməli və hostların siyahısını mümkün qədər yeni saxlamalıdır.

Hər bir xidmət şəbəkəsi xidmət kəşf mexanizmini fərqli şəkildə həyata keçirir. Hazırda ən çox yayılmış yol Kubernetes DNS kimi xarici proseslərə həvalə etməkdir. Əvvəllər Twitter-də bu məqsədlə bir ad sistemindən istifadə etdik Finagle. Bundan əlavə, xidmət şəbəkəsi texnologiyası xüsusi adlandırma mexanizmlərinin yaranmasına imkan yaradır (baxmayaraq ki, mən hələ belə funksionallıqla heç bir SM tətbiqini görməmişəm).

2. Şifrələmə

TL;DR: Xidmətlər arasında şifrələnməmiş trafikdən xilas olun və bu prosesi avtomatlaşdırılmış və miqyaslana bilən hala gətirin.

Təcavüzkarların daxili şəbəkənizə nüfuz edə bilməyəcəyini bilmək xoşdur. Firewalllar bu işdə əla iş görür. Bəs haker içəri girərsə nə olar? O, xidmətdaxili trafiklə istədiyi hər şeyi edə biləcəkmi? Ümid edək ki, bu baş verməyəcək. Bu ssenarinin qarşısını almaq üçün xidmətlər arasında bütün trafikin şifrələndiyi sıfır etibar şəbəkəsi tətbiq etməlisiniz. Müasir xidmət şəbəkələrinin əksəriyyəti buna qarşılıqlı şəkildə nail olur TLS (qarşılıqlı TLS, mTLS). Bəzi hallarda, mTLS bütün buludlarda və klasterlərdə işləyir (məncə, planetlərarası əlaqə nə vaxtsa oxşar şəkildə qurulacaq).

Əlbəttə ki, mTLS xidmət şəbəkəsi üçün isteğe bağlıdır. Hər bir xidmət öz TLS-nin qayğısına qala bilər, lakin bu o deməkdir ki, siz sertifikatlar yaratmaq, onları xidmət hostları arasında yaymaq və bu sertifikatları fayllardan yükləyən proqrama kodu daxil etmək üçün bir yol tapmalı olacaqsınız. Bəli, bu sertifikatları müntəzəm olaraq yeniləməyi unutmayın. Xidmət şəbəkələri kimi sistemlərlə mTLS-ni avtomatlaşdırır SPIFFE, bu da öz növbəsində sertifikatların verilməsi və fırlanması prosesini avtomatlaşdırır.

3. Doğrulama və Avtorizasiya

TL; DR: Müraciət edənin kim olduğunu müəyyənləşdirin və sorğu hətta xidmətə çatmazdan əvvəl onlara nə etməyə icazə verildiyini müəyyənləşdirin.

Xidmətlər tez-tez bilmək istəyirlər kim sorğunu həyata keçirir (autentifikasiya) və bu məlumatlardan istifadə edərək qərar verir o müəyyən bir quruma icazə verilir (icazə verilir). Bu vəziyyətdə "kim" əvəzliyi gizlənə bilər:

Digər xidmətlər. Buna "identifikasiya" deyilir həmyaşıd" Məsələn, xidmət web xidmətə daxil olmaq istəyir db. Xidmət şəbəkələri adətən mTLS-dən istifadə edərək belə problemləri həll edir: bu halda sertifikatlar zəruri identifikator kimi çıxış edir.
Bəzi insan istifadəçiləri. Buna "identifikasiya" deyilir istək" Məsələn, istifadəçi haxor69 yeni lampa almaq istəyir. Xidmət şəbəkələri müxtəlif mexanizmləri təmin edir, məs. JSON Veb Nişanlar.
Bir çoxumuz bunu proqram kodunda etdik. Bir sorğu gəlir, cədvələ baxırıq users, istifadəçini tapın və parolu müqayisə edin, sonra sütunu yoxlayın permissions və s. Xidmət şəbəkəsi vəziyyətində, bu, sorğu hətta xidmətə çatmazdan əvvəl baş verir.

Sorğunun kimdən gəldiyini müəyyən etdikdən sonra bu qurumun nə etməyə icazə verildiyini müəyyən etməliyik. Bəzi xidmət şəbəkələri YAML faylları və ya əmr satırında əsas siyasətləri (kim nə edə biləcəyi haqqında) təyin etməyə imkan verir, digərləri isə kimi çərçivələrlə inteqrasiya təklif edir. Açıq Siyasət Agenti. Yekun məqsəd xidmətlərinizin hər hansı sorğunun etibarlı mənbədən gəldiyini güman edərək qəbul etməsidir и bu hərəkətə icazə verilir.

4. Yük balansı

TL; DR: Yükü xidmət nümunələri arasında xüsusi nümunəyə görə paylayın.

Xidmət bölməsindəki "Xidmət" çox vaxt bir çox eyni nümunələrdən ibarətdir. Məsələn, bu gün xidmət cache 5 nüsxədən ibarətdir və sabah onların sayı 11-ə yüksələ bilər cache, müəyyən məqsədə uyğun olaraq paylanmalıdır. Məsələn, gecikməni minimuma endirin və ya işləyən nüsxəyə çatma ehtimalını maksimuma çatdırın. Ən çox istifadə olunan alqoritm Round-robin-dir, lakin bir çox başqaları var - məsələn, çəkili üsul (çəkili) sorğular (siz üstünlük verilən hədəfləri seçə bilərsiniz), zəng edin (üzük) hashing (yuxarıdakı hostlar arasında ardıcıl hashing istifadə edərək) və ya ən az sorğu metodu (ən az sorğu ilə nümunəyə üstünlük verilir).

Klassik balanslaşdırıcıların HTTP keşləmə və DDoS mühafizəsi kimi digər funksiyaları da var, lakin onlar şərq-qərb trafiki üçün (yəni, məlumat mərkəzi daxilində axan trafik üçün - təqribən tərcümə) (xidmət şəbəkəsinin tipik əhatə dairəsi) üçün çox aktual deyildir. Əlbəttə ki, yük balansı üçün xidmət şəbəkəsindən istifadə etmək lazım deyil, lakin o, hər bir xidmət üçün mərkəzləşdirilmiş idarəetmə səviyyəsindən balanslaşdırma siyasətlərini təyin etməyə və idarə etməyə imkan verir, bununla da şəbəkə yığınında ayrıca yük balanslaşdırıcılarını işə salmaq və konfiqurasiya etmək ehtiyacını aradan qaldırır. .

5. Dövrün qırılması

TL;DR: Problemli xidmətə gedən trafiki dayandırın və ən pis ssenarilərdə zərərə nəzarət edin.

Əgər nədənsə xidmət trafikin öhdəsindən gələ bilmirsə, xidmət şəbəkəsi bu problemi həll etmək üçün bir neçə variant təqdim edir (digərləri müvafiq bölmələrdə müzakirə olunacaq). Dövrün qırılması xidməti trafikdən ayırmaq üçün ən çətin seçimdir. Ancaq özlüyündə bunun mənası yoxdur - ehtiyat plan lazımdır. Arxa təzyiq təmin edilə bilər (arxa təzyiq) sorğular göndərən xidmətlərə (bunun üçün xidmət şəbəkənizi konfiqurasiya etməyi unutmayın!) və ya məsələn, status səhifəsini qırmızı rəngə boyayın və istifadəçiləri “düşən balina” ilə səhifənin başqa versiyasına yönləndirin (“Twitter aşağı").

Xidmət şəbəkələri yalnız müəyyən etməyə imkan vermir zaman bağlanma izlənəcək və o bunun ardınca gələcək. Bu halda, "nə vaxt" müəyyən edilmiş parametrlərin istənilən kombinasiyasını əhatə edə bilər: müəyyən bir müddət üçün sorğuların ümumi sayı, paralel qoşulmaların sayı, gözlənilən sorğular, aktiv təkrar cəhdlər və s.

Siz yəqin ki, elektrik dövrəsinin pozulmasından sui-istifadə etmək istəmirsiniz, lakin fövqəladə hallarda ehtiyat planınızın olduğunu bilmək xoşdur.

6. Avtomatik miqyaslama

TL;DR: Göstərilən meyarlardan asılı olaraq xidmət nümunələrinin sayını artırın və ya azaldın.

Xidmət şəbəkələri planlaşdırıcı deyil, ona görə də yoxdur həyata keçirmək özünüzü ölçmək. Bununla belə, onlar hansı planlaşdırıcıların qərarlarını əsas götürəcəkləri barədə məlumat verə bilərlər. Xidmət şəbəkələrinin xidmətlər arasında bütün trafikə çıxışı olduğundan, onlar baş verənlər haqqında geniş məlumata malikdirlər: hansı xidmətlərdə problemlər yaşanır, hansı xidmətlər çox yüngül yüklənir (onlara ayrılan tutum sərf olunur) və s.

Məsələn, Kubernetes podların CPU və yaddaş istifadəsinə əsasən xidmətləri ölçür (hesabatımıza baxın "Kubernetes-də avtomatik miqyaslama və resursların idarə edilməsi"- təqribən. tərcümə.), lakin hər hansı digər metrik (bizim vəziyyətimizdə trafiklə əlaqəli) əsasında miqyasını miqyasına salmaq qərarına gəlsəniz, sizə xüsusi metrik lazımdır. İdarəetmə bunun kimi ilə bunu necə edəcəyini göstərir elçi, İstio и Prometey, lakin prosesin özü olduqca mürəkkəbdir. Biz istərdik ki, xidmət şəbəkəsi bunu sadələşdirsin və bizə sadəcə olaraq “xidmət nümunələrinin sayını artırın” kimi şərtləri təyin etməyə imkan versin. auth, gözləyən sorğuların sayı bir dəqiqə ərzində həddi aşarsa."

7. Kanareyka yerləşdirmələri

TL;DR: İstifadəçilərin alt çoxluğunda yeni funksiyaları və ya xidmət versiyalarını sınaqdan keçirin.

Tutaq ki, siz SaaS məhsulu hazırlayırsız və onun yeni gözəl versiyasını təqdim etmək niyyətindəsiniz. Siz onu səhnələşdirmədə sınaqdan keçirdiniz və əla alındı. Lakin onun real şəraitdə davranışı ilə bağlı hələ də müəyyən narahatlıqlar var. Başqa sözlə, istifadəçi etibarını riskə atmadan yeni versiyanı real problemlər üzərində sınaqdan keçirməlisiniz. Kanarya yerləşdirmələri bunun üçün əladır. Onlar istifadəçilərin bir hissəsinə yeni bir xüsusiyyət nümayiş etdirməyə imkan verir. Bu alt qrup ən sadiq istifadəçilərdən və ya məhsulun pulsuz versiyası ilə işləyənlərdən və ya “qvineya donuzları” olmaq arzusunu bildirmiş istifadəçilərdən ibarət ola bilər.

Xidmət şəbəkələri bunu tətbiqin hansı versiyasını kimin görəcəyini müəyyən edən kriteriyaları müəyyən etməyə və müvafiq olaraq trafiki yönləndirməyə imkan verməklə həyata keçirir. Bununla belə, xidmətlərin özləri üçün heç nə dəyişmir. Xidmətin 1.0 versiyası hesab edir ki, bütün sorğular onu görməli olan istifadəçilərdən gəlir, 1.1 versiyası isə istifadəçiləri üçün də buna inanır. Eyni zamanda, köhnə və yeni versiyalar arasında trafikin faizini dəyişə bilərsiniz, əgər sabit işləyirsə və “qvineya donuzlarınız” davam edərsə, artan sayda istifadəçini yenisinə yönləndirə bilərsiniz.

8. Mavi-yaşıl yerləşdirmələr

TL; DR: Gözəl yeni funksiyanı təqdim edin, lakin hər şeyi dərhal geri almağa hazır olun.

Məna mavi-yaşıl yerləşdirmələr köhnə, “yaşıl” xidmətlə paralel olaraq yeni “mavi” xidməti yaymaqdır. Hər şey qaydasında gedirsə və yeni xidmət yaxşı işləyirsə, köhnəsini tədricən söndürmək olar. (Təəssüf ki, nə vaxtsa bu yeni “mavi” xidmət “yaşıl”ın taleyini təkrarlayacaq və yox olacaq...) Mavi-yaşıl yerləşdirmələr kanareykalardan yeni funksiyanın əhatə etdiyinə görə fərqlənir. hamı birdən istifadəçilər (hissə deyil); Burada əsas məsələ nə isə səhv olarsa, “təhlükəsiz limanın” hazır olmasıdır.

Xidmət şəbəkələri “mavi” xidməti sınamaq və problem yarandıqda dərhal işləyən “yaşıl” xidmətə keçmək üçün çox rahat üsul təklif edir. Yol boyu "mavi" nin işi haqqında çoxlu məlumat (aşağıdakı "Telemetriya"ya baxın) təqdim etdiklərini söyləmək olmaz ki, bu da onun tam işləməyə hazır olub olmadığını anlamağa kömək edir.

Qeyd. tərcümə.: Kubernetes-də müxtəlif yerləşdirmə strategiyaları (o cümlədən qeyd olunan kanareyka, mavi/yaşıl və digərləri) haqqında ətraflı oxuya bilərsiniz. Bu məqalə.

9. Sağlamlıq yoxlaması

TL; DR: Hansı xidmət nümunələrinin işlək olduğunu izləyin və artıq işlək olmayanlara cavab verin.

Sağlamlıq yoxlaması (sağlamlıq yoxlanışı) xidmət nümunələrinin trafiki qəbul etməyə və emal etməyə hazır olub-olmamasına qərar verməyə kömək edir. Məsələn, HTTP xidmətləri vəziyyətində sağlamlıq yoxlanışı son nöqtəyə GET sorğusu kimi görünə bilər /health... Cavab 200 OK nümunənin sağlam olduğunu, hər hansı digərinin - trafik qəbul etməyə hazır olmadığını ifadə edəcək. Xidmət şəbəkələri həm funksionallığın yoxlanılması üsulunu, həm də bu yoxlamanın aparılma tezliyini müəyyən etməyə imkan verir. Bu məlumat daha sonra digər məqsədlər üçün istifadə edilə bilər - məsələn, yükün balanslaşdırılması və dövrələrin kəsilməsi üçün.

Beləliklə, sağlamlığın yoxlanılması müstəqil istifadə halı deyil, adətən başqa məqsədlərə nail olmaq üçün istifadə olunur. Həmçinin, sağlamlıq yoxlamalarının nəticələrindən asılı olaraq, digər xidmət şəbəkəsi hədəflərindən kənar hərəkətlər tələb oluna bilər: məsələn, status səhifəsini yeniləmək, GitHub-da problem yaratmaq və ya JIRA biletini doldurmaq. Və servis şəbəkəsi bütün bunları avtomatlaşdırmaq üçün əlverişli mexanizm təklif edir.

10. Yük atma

TL;DR: İstifadədə müvəqqəti artıma cavab olaraq trafiki yönləndirin.

Müəyyən bir xidmət trafiklə həddən artıq yüklənirsə, siz bu trafikin bir hissəsini müvəqqəti olaraq başqa yerə yönləndirə bilərsiniz (yəni “zibil”, “köçürmə”) (tökmək) onu orada). Məsələn, ehtiyat nüsxə xidmətinə və ya məlumat mərkəzinə və ya daimi mətbuat mövzu. Nəticədə, xidmət qəzaya uğramaq və hər şeyin emalını tamamilə dayandırmaq əvəzinə bəzi sorğuları emal etməyə davam edəcək. Yük atma dövrəni pozmaqdan daha üstündür, lakin bundan sui-istifadə etmək hələ də məsləhət görülmür. Bu, aşağı axın xidmətlərin sıradan çıxmasına səbəb olan sıralamalı uğursuzluqların qarşısını almağa kömək edir.

11. Trafik paralelləşdirilməsi/yansıtma

TL;DR: Eyni anda bir neçə yerə bir sorğu göndərin.

Bəzən bir sorğunun (və ya müəyyən bir sorğu seçimi) bir neçə xidmətə göndərilməsinə ehtiyac var. Tipik bir nümunə istehsal trafikinin bir hissəsini bir quruluş xidmətinə göndərməkdir. Əsas istehsal veb serveri aşağı axın xidmətinə sorğu göndərir products.production və yalnız ona. Və xidmət şəbəkəsi bu sorğunu ağıllı surətdə köçürür və göndərir products.staging, veb-serverin belə xəbəri yoxdur.

Trafik paralelləşdirilməsi üzərində həyata keçirilə bilən digər əlaqəli xidmət şəbəkəsindən istifadə halıdır reqressiya testi. Bu xidmətin müxtəlif versiyalarına eyni sorğuların göndərilməsini və bütün versiyaların eyni davranıb-yaxmadığını yoxlamağı əhatə edir. kimi inteqrasiya olunmuş reqressiya test sistemi ilə xidmət şəbəkəsi tətbiqinə hələ rast gəlməmişəm Fərqli, lakin ideyanın özü perspektivli görünür.

12. İzolyasiya

TL; DR: Xidmət şəbəkənizi mini şəbəkələrə bölün.

Başqa adla seqmentasiyaİzolyasiya xidmət şəbəkəsini bir-biri haqqında heç nə bilməyən məntiqi olaraq fərqli seqmentlərə bölmək sənətidir. İzolyasiya bir az virtual özəl şəbəkələr yaratmağa bənzəyir. Əsas fərq ondan ibarətdir ki, siz hələ də əlavə təhlükəsizliklə xidmət şəbəkəsinin bütün üstünlüklərindən (xidmət kəşfi kimi) istifadə edə bilərsiniz. Məsələn, təcavüzkar bir alt şəbəkədə xidmətə daxil ola bilsə, o, digər alt şəbəkələrdə hansı xidmətlərin işlədiyini görə bilməyəcək və ya onların trafikinə müdaxilə edə bilməyəcək.

Bundan əlavə, faydalar təşkilati də ola bilər. Siz şirkət strukturunuza əsaslanaraq xidmətlərinizi alt şəbəkəyə qurmaq və tərtibatçıları bütün xidmət şəbəkəsini yadda saxlamaq məcburiyyətində olan koqnitiv yükdən azad etmək istəyə bilərsiniz.

13. Sorğu dərəcəsinin məhdudlaşdırılması, təkrar cəhdlər və fasilələr

TL; DR: Siz artıq kod bazanıza kiçik tələblərin idarə edilməsi tapşırıqlarını daxil etməyə ehtiyac yoxdur.

Bütün bunları ayrı-ayrı istifadə halları hesab etmək olar, lakin mən bir ümumi xüsusiyyətə görə onları birləşdirməyə qərar verdim: onlar adətən tətbiq kitabxanaları tərəfindən idarə olunan sorğunun həyat dövrünün idarə edilməsi tapşırıqlarını öz üzərinə götürürlər. Əgər siz Ruby on Rails-də (xidmət şəbəkəsi ilə inteqrasiya olunmamış) veb server inkişaf etdirirsinizsə, o, vasitəsilə backend xidmətlərinə müraciət edir. gRPC, N sorğu uğursuz olarsa, tətbiq nə edəcəyinə qərar verməli olacaq. Siz həmçinin bu xidmətlərin xüsusi kitabxanadan istifadə edərək bu parametrləri emal edə və kodlaşdıra biləcək trafikin nə qədər olacağını öyrənməli olacaqsınız. Üstəlik, ərizə nə vaxt imtina etmə vaxtı olduğuna qərar verməli və sorğunun yerinə yetirilməsinə icazə verməli olacaq (taym-aut əsasında). Və yuxarıda göstərilən parametrlərdən hər hansı birini dəyişdirmək üçün veb server dayandırılmalı, yenidən konfiqurasiya edilməli və yenidən işə salınmalıdır.

Bu tapşırıqların xidmət şəbəkəsinə yüklənməsi təkcə o deməkdir ki, xidmət tərtibatçıları onlar haqqında düşünmək məcburiyyətində qalmayacaq, həm də onlara daha qlobal şəkildə baxıla bilər. Mürəkkəb xidmətlər silsiləsi istifadə olunursa, deyək ki, A -> B -> C -> D -> E, sorğunun bütün həyat dövrü nəzərə alınmalıdır. Tapşırıq C xidmətində fasilələri uzatmaqdırsa, bunu hissə-hissə deyil, birdən-birə etmək məntiqlidir: xidmət kodunu yeniləyərək və çəkmə sorğusu qəbul olunana və CI sistemi yenilənmiş xidməti yerləşdirənə qədər gözləyin.

14. Telemetriya

TL; DR: Xidmətlərdən bütün lazımi (və tam deyil) məlumatları toplayın.

Telemetriya ölçüləri, paylanmış izləmə və qeydləri ehtiva edən ümumi bir termindir. Xidmət şəbəkələri hər üç növ məlumatın toplanması və emalı üçün mexanizmlər təklif edir. Mümkün variantların sayı çox böyük olduğundan işlər bir az bulanıqlaşır. Metrikləri toplamaq üçün var Prometey və logları toplamaq üçün istifadə edilə bilən digər alətlər səlis, Loki, Vektor və s. (məsələn, ClickHouse ilə bizim log ev K8s üçün - təqribən. tərcümə.), paylanmış izləmə üçün var Jaeger və s. Hər bir xidmət şəbəkəsi bəzi alətləri dəstəkləyə bilər, digərlərini dəstəkləyə bilməz. Layihənin edə biləcəyini görmək maraqlı olacaq Telemetriyanı açın müəyyən yaxınlaşma təmin edir.

Bu halda, xidmət şəbəkəsi texnologiyasının üstünlüyü ondan ibarətdir ki, yan vaqon konteynerləri, prinsipcə, yuxarıda göstərilən bütün məlumatları öz xidmətlərindən toplaya bilər. Başqa sözlə, sizin ixtiyarınızda vahid telemetriya toplama sistemi var və xidmət şəbəkəsi bütün bu məlumatları müxtəlif yollarla emal edə bilər. Misal üçün:

CLI-də müəyyən bir xidmətdən quyruq qeydləri;
xidmət mesh tablosundan sorğuların həcminə nəzarət etmək;
paylanmış izləri toplayın və onları Jaeger kimi bir sistemə göndərin.

Diqqət, subyektiv mühakimə: Ümumiyyətlə, telemetriya xidmət şəbəkəsindən güclü müdaxilənin arzuolunmaz olduğu bir sahədir. Əsas məlumatların toplanması və sorğunun müvəffəqiyyət dərəcəsi və gecikmə müddəti kimi bəzi qızıl göstəriciləri izləmək yaxşıdır, lakin ümid edək ki, bəziləri artıq özünü sübut etmiş və yaxşı öyrənilmiş xüsusi sistemləri əvəz etməyə çalışan Frankenstein yığınlarının ortaya çıxdığını görməyəcəyik. .

15. Audit

TL;DR: Tarixin dərslərini unudanlar onları təkrarlamağa məhkumdurlar.

Audit bir sistemdəki mühüm hadisələri müşahidə etmək sənətidir. Xidmət şəbəkəsi vəziyyətində, bu, konkret xidmətlər üçün xüsusi son nöqtələrə kimin müraciət etdiyini və ya təhlükəsizliklə bağlı bəzi hadisənin son ayda neçə dəfə baş verdiyini izləmək demək ola bilər.

Aydındır ki, audit telemetriya ilə çox sıx bağlıdır. Fərq ondadır ki, telemetriya adətən məhsuldarlıq və texniki bütövlük kimi şeylərlə əlaqələndirilir, audit isə ciddi texniki sahədən kənara çıxan hüquqi və digər məsələlərə aid ola bilər (məsələn, GDPR - məlumatların qorunması üzrə Aİ Ümumi Qaydasına uyğunluq).

16. Vizuallaşdırma

TL;DR: Yaşasın React.js - dəbdəbəli interfeyslərin tükənməz mənbəyidir.

Daha yaxşı bir termin ola bilər, amma mən onu bilmirəm. Mən sadəcə olaraq xidmət şəbəkəsinin və ya onun bəzi komponentlərinin qrafik təsvirini nəzərdə tuturam. Bu vizualizasiyalara orta gecikmələr, yan vaqon konfiqurasiyası məlumatı, sağlamlıq yoxlaması nəticələri və xəbərdarlıqlar kimi göstəricilər daxil ola bilər.

Xidmət yönümlü mühitdə işləmək Əlahəzrət Monolitlə müqayisədə daha yüksək idrak yükünü ehtiva edir. Buna görə də, idrak təzyiqi nəyin bahasına olursa olsun azaldılmalıdır. Bir düyməyə basmaq və istədiyiniz nəticəni əldə etmək imkanı olan xidmət şəbəkəsi üçün sadə qrafik interfeys bu texnologiyanın populyarlığının artması üçün həlledici ola bilər.

Siyahıya daxil edilməyib

Əvvəlcə siyahıya daha bir neçə istifadə halını daxil etmək niyyətində idim, lakin sonra etməməyə qərar verdim. Budur, qərarımın səbəbləri ilə birlikdə:

Çox məlumat mərkəzi. Fikrimcə, bu, xidmət şəbəkələrinin dar və xüsusi tətbiq sahəsi və ya xidmət kəşfi kimi bəzi funksiyalar dəsti kimi istifadə halı deyil.
Giriş və çıxış. Bu, əlaqəli sahədir, lakin mən özümü (bəlkə də süni şəkildə) "şərq-qərb trafiki" ilə məhdudlaşdırmışam. Giriş və çıxış ayrıca məqaləyə layiqdir.

Nəticə

Hələlik bu qədər! Yenə də bu siyahı çox ixtiyari və çox güman ki, natamamdır. Nəyisə qaçırdığımı və ya səhv etdiyimi düşünürsünüzsə, Twitter-də mənimlə əlaqə saxlayın (@luckerkins). Zəhmət olmasa ədəb qaydalarına hörmət edin.

Tərcüməçidən PS

Məqalənin başlıq illüstrasiyası məqalədəki şəkilə əsaslanır "Xidmət Mesh nədir (və nə vaxt istifadə edilməlidir)?"(Qreqori MakKinnon tərəfindən). Tətbiqlərdən bəzi funksionallığın (yaşıl rəngdə) onlar arasında qarşılıqlı əlaqəni təmin edən xidmət şəbəkəsinə necə keçdiyini göstərir (mavi).

Bloqumuzda da oxuyun:

Mənbə: www.habr.com