Monolit tətbiqdən mikroservis arxitekturasına keçdikcə yeni problemlərlə qarşılaşırıq.
Monolitik bir tətbiqdə səhvin sistemin hansı hissəsində baş verdiyini müəyyən etmək adətən olduqca asandır. Çox güman ki, problem monolitin kodunda və ya verilənlər bazasındadır. Ancaq mikroservis arxitekturasında problem axtarmağa başlayanda artıq hər şey o qədər də aydın görünmür. Sorğunun başdan sona qədər keçdiyi bütün yolu tapmalı və onu yüzlərlə mikroservis arasından seçməliyik. Üstəlik, onların bir çoxunun öz saxlama yerləri də var ki, bu da məntiqi səhvlərə, həmçinin performans və nasazlığa dözümlülük problemlərinə səbəb ola bilər.
Mən uzun müddətdir ki, bu cür problemlərin öhdəsindən gəlməyə kömək edəcək bir vasitə axtarırdım (bu barədə Habré-də yazdım: , ), amma sonda öz açıq mənbə həllimi yaratdım. Bu yazıda xidmət mesh yanaşmasının üstünlükləri haqqında danışıram və onun həyata keçirilməsi üçün yeni bir alət paylaşıram.
Paylanmış izləmə paylanmış sistemlərdə səhvlərin tapılması probleminin ümumi həllidir. Bəs şəbəkə qarşılıqlı əlaqəsi haqqında məlumat toplamaq üçün bu yanaşma sistemdə hələ tətbiq olunmayıbsa və ya daha da pisi, sistemin bir hissəsində artıq düzgün işləyir, lakin köhnə xidmətlərə əlavə olunmadığı üçün qismən işləmirsə? ? Problemin dəqiq kök səbəbini müəyyən etmək üçün sistemdə baş verənlər haqqında tam təsəvvürə sahib olmaq lazımdır. Əsas biznes üçün kritik yollarda hansı mikroservislərin iştirak etdiyini başa düşmək xüsusilə vacibdir.
Burada xidmət şəbəkəsi yanaşması köməyimizə gələ bilər ki, bu da şəbəkə məlumatlarının toplanması üçün xidmətlərin özlərinin işlədiyi səviyyədən aşağı səviyyədə olan bütün mexanizmlərlə məşğul olacaq. Bu yanaşma bizə bütün trafikin qarşısını almağa və onu anında təhlil etməyə imkan verir. Üstəlik, tətbiqlərin bu barədə heç nə bilməsi lazım deyil.
Xidmət şəbəkəsinə yanaşma
Xidmət şəbəkəsi yanaşmasının əsas ideyası şəbəkə üzərində başqa bir infrastruktur qatının əlavə edilməsidir ki, bu da bizə xidmətlərarası qarşılıqlı əlaqə ilə istənilən işi görməyə imkan verəcəkdir. Əksər tətbiqetmələr aşağıdakı kimi işləyir: hər bir mikroservisə şəffaf proxy ilə əlavə bir yan qutu əlavə olunur, onun vasitəsilə xidmətin bütün daxil olan və gedən trafiki ötürülür. Və bu, müştəri balansını həyata keçirə biləcəyimiz, təhlükəsizlik siyasətlərini tətbiq edə biləcəyimiz, sorğuların sayına məhdudiyyətlər qoya biləcəyimiz və istehsalda xidmətlərin qarşılıqlı əlaqəsi haqqında vacib məlumatları toplaya biləcəyimiz yerdir.
Çözümlər
Bu yanaşmanın artıq bir neçə tətbiqi var: и . Qutudan kənarda bir çox xüsusiyyətləri təmin edirlər. Ancaq eyni zamanda, resurslara böyük yük düşür. Üstəlik, belə bir sistemin fəaliyyət göstərdiyi klaster nə qədər böyükdürsə, yeni infrastrukturu saxlamaq üçün bir o qədər çox resurs tələb olunacaq. Avito-da biz minlərlə xidmət nümunəsini ehtiva edən kubernet klasterlərini idarə edirik (və onların sayı sürətlə artmaqda davam edir). Hazırkı tətbiqində Istio hər bir xidmət nümunəsi üçün ~ 300 Mb RAM istehlak edir. Çox sayda imkanlar sayəsində şəffaf balanslaşdırma xidmətlərin ümumi cavab müddətinə də təsir edir (10 ms-ə qədər).
Nəticə etibarı ilə biz hazırda hansı imkanlara ehtiyacımız olduğuna baxdıq və qərara gəldik ki, bu cür həlləri tətbiq etməyə başlamağımızın əsas səbəbi bütün sistemdən şəffaf şəkildə izləmə məlumatlarını toplamaq qabiliyyətidir. Biz həmçinin xidmətlərin qarşılıqlı əlaqəsinə nəzarət etmək və xidmətlər arasında ötürülən başlıqlarla müxtəlif manipulyasiyalar etmək istəyirdik.
Nəticədə qərarımıza gəldik: .
Netramesh
sistemdəki xidmətlərin sayından asılı olmayaraq, sonsuz miqyaslandırma qabiliyyətinə malik yüngül xidmət şəbəkəsi həllidir.
Yeni həllin əsas məqsədləri aşağı resurs xərcləri və yüksək performans idi. Əsas xüsusiyyətlərdən, biz dərhal Jaeger sistemimizə izləmə məsafələrini şəffaf şəkildə göndərə bilmək istədik.
Bu gün əksər bulud həlləri Golanqda həyata keçirilir. Və təbii ki, bunun səbəbləri var. Qolanqda I/O ilə asinxron işləyən və lazım olduqda nüvələr arasında miqyas alan şəbəkə proqramlarının yazılması rahat və olduqca sadədir. Və çox vacib olan odur ki, performans bu problemi həll etmək üçün kifayətdir. Ona görə də biz də Qolanqı seçdik.
Məhsuldarlıq
Biz səylərimizi maksimum məhsuldarlığa nail olmağa yönəltmişik. Xidmətin hər bir nümunəsinin yanında yerləşdirilən bir həll üçün RAM və CPU vaxtının kiçik bir istehlakı tələb olunur. Və təbii ki, cavab gecikməsi də kiçik olmalıdır.
Görək hansı nəticələr əldə etdik.
RAM
Netramesh trafiksiz ~10Mb və bir nümunə üçün 50 RPS-ə qədər yüklə maksimum 10000Mb istehlak edir.
Istio envoy proxy həmişə minlərlə nümunəsi olan klasterlərimizdə ~300Mb istehlak edir. Bu, onun bütün klasterə miqyaslanmasına imkan vermir.
Netramesh ilə yaddaş istehlakında ~ 10x azalma əldə etdik.
CPU
CPU istifadəsi yük altında nisbətən bərabərdir. Bu, yan arabaya vaxt vahidinə düşən sorğuların sayından asılıdır. Ən yüksək nöqtədə saniyədə 3000 sorğuda dəyərlər:
Daha bir vacib məqam var: Netramesh - idarəetmə təyyarəsi olmayan və yükü olmayan bir həll CPU vaxtını sərf etmir. Istio ilə yan arabalar həmişə xidmətin son nöqtələrini yeniləyir. Nəticədə bu şəkli yüksüz görə bilərik:
Xidmətlər arasında əlaqə üçün HTTP/1 istifadə edirik. Elçi vasitəsilə proxy göndərərkən Istio üçün cavab müddətinin artması 5-10 ms-ə qədər idi ki, bu da bir millisaniyədə cavab verməyə hazır olan xidmətlər üçün kifayət qədər çoxdur. Netramesh ilə bu müddət 0.5-2 ms-ə qədər azaldı.
Ölçeklenebilirlik
Hər bir proxy tərəfindən istehlak edilən az miqdarda resurs onu hər bir xidmətin yanında yerləşdirməyə imkan verir. Netramesh qəsdən hər bir yan arabanın yüngül çəkisini saxlamaq üçün idarəetmə təyyarəsi komponenti olmadan yaradılmışdır. Tez-tez xidmət şəbəkəsi həllərində idarəetmə təyyarəsi hər bir yan arabaya xidmət kəşf məlumatını paylayır. Bununla yanaşı, fasilələr və balanslaşdırma parametrləri haqqında məlumat gəlir. Bütün bunlar sizə bir çox faydalı şeylər etməyə imkan verir, lakin təəssüf ki, yan arabaları ölçüdə şişirdir.
Xidmət kəşfi
Netramesh xidmət kəşfi üçün heç bir əlavə mexanizm əlavə etmir. Bütün trafik şəffaf şəkildə netra yan avtomobil vasitəsilə idarə olunur.
Netramesh HTTP/1 proqram protokolunu dəstəkləyir. Onu müəyyən etmək üçün konfiqurasiya edilə bilən port siyahısı istifadə olunur. Tipik olaraq, sistem HTTP rabitəsinin baş verdiyi bir neçə porta malikdir. Məsələn, biz xidmətlər və xarici sorğular arasında qarşılıqlı əlaqə üçün 80, 8890, 8080 istifadə edirik. Bu halda, onlar mühit dəyişənindən istifadə etməklə təyin edilə bilər. NETRA_HTTP_PORTS.
Əgər siz Kubernetes-dən xidmətlər arasında çoxluqdaxili əlaqə üçün bir orkestrator və onun Xidmət obyekti mexanizmindən istifadə edirsinizsə, onda mexanizm tam olaraq eyni qalır. Birincisi, mikroservis kube-dns istifadə edərək xidmət IP ünvanını əldə edir və ona yeni bir əlaqə açır. Bu əlaqə əvvəlcə yerli netra-sidecar ilə qurulur və bütün TCP paketləri əvvəlcə netraya çatır. Sonra, netra-sidecar orijinal təyinat yeri ilə əlaqə qurur. Düyündəki pod IP-də NAT, netra olmadan eyni olaraq qalır.
Paylanmış izləmə və kontekst yönləndirmə
Netramesh HTTP qarşılıqlı əlaqəsi haqqında izləmə aralıqlarını göndərmək üçün lazım olan funksionallığı təmin edir. Netra-sidecar HTTP protokolunu təhlil edir, sorğu gecikmələrini ölçür və HTTP başlıqlarından lazımi məlumatları çıxarır. Nəhayət, biz tək Jaeger sistemində bütün izləri əldə edirik. İncə konfiqurasiya üçün rəsmi kitabxana tərəfindən təmin edilən mühit dəyişənlərindən də istifadə edə bilərsiniz .
Amma bir problem var. Xidmətlər xüsusi uber başlığı yaradana və göndərənə qədər sistemdə əlaqəli izləmə aralıqlarını görməyəcəyik. Problemlərin səbəbini tez tapmaq üçün bizə lazım olan budur. Burada yenə Netramesh-in bir həlli var. Proksilər HTTP başlıqlarını oxuyur və əgər onlarda uber iz id-si yoxdursa, onu yaradın. Netramesh həmçinin gələn və gedən sorğular haqqında məlumatları yan arabada saxlayır və onları lazımi gedən sorğu başlıqları ilə zənginləşdirməklə onlara uyğunlaşdırır. Xidmətlərdə etməniz lazım olan tək şey yalnız bir başlıq göndərməkdir X-Request-Idmühit dəyişəni ilə konfiqurasiya edilə bilər NETRA_HTTP_REQUEST_ID_HEADER_NAME. Netramesh-də kontekstin ölçüsünü idarə etmək üçün aşağıdakı mühit dəyişənlərini təyin edə bilərsiniz: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (kontekstin saxlanacağı vaxt) və NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (kontekstin təmizlənməsinin tezliyi).
Sisteminizdə bir çox yolu xüsusi seans nişanı ilə qeyd etməklə birləşdirmək də mümkündür. Netra quraşdırmağa imkan verir HTTP_HEADER_TAG_MAP HTTP başlıqlarını müvafiq izləmə span teqlərinə çevirmək. Bu test üçün xüsusilə faydalı ola bilər. Funksional testdən keçdikdən sonra müvafiq seans açarı ilə süzülərək sistemin hansı hissəsinə təsir etdiyini görə bilərsiniz.
Sorğu mənbəyinin müəyyən edilməsi
Sorğunun haradan gəldiyini müəyyən etmək üçün mənbə ilə avtomatik başlıq əlavə etmək funksiyasından istifadə edə bilərsiniz. Bir mühit dəyişəninin istifadəsi NETRA_HTTP_X_SOURCE_HEADER_NAME Siz avtomatik quraşdırılacaq başlıq adını təyin edə bilərsiniz. İstifadə etməklə NETRA_HTTP_X_SOURCE_VALUE bütün gedən sorğular üçün X-Source başlığının təyin ediləcəyi dəyəri təyin edə bilərsiniz.
Bu, bu faydalı başlığın paylanmasının bütün şəbəkədə bərabər paylanmasına imkan verir. Sonra onu xidmətlərdə istifadə edə və qeydlərə və ölçülərə əlavə edə bilərsiniz.
Trafik marşrutu və Netramesh daxili elementləri
Netramesh iki əsas komponentdən ibarətdir. Birincisi, netra-init, trafikin qarşısını almaq üçün şəbəkə qaydalarını təyin edir. O istifadə edir Netramesh-in ikinci əsas komponenti olan yan vaqonda trafikin hamısını və ya bir hissəsini kəsmək. Gələn və gedən TCP seansları üçün hansı portların tutulması lazım olduğunu konfiqurasiya edə bilərsiniz: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
Alətin maraqlı bir xüsusiyyəti də var - ehtimal marşrutlaşdırma. Netramesh-dən yalnız izləmə aralığını toplamaq üçün istifadə edirsinizsə, istehsal mühitində siz resurslara qənaət edə və dəyişənlərdən istifadə edərək ehtimal marşrutunu aktivləşdirə bilərsiniz. NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0-dan 1-ə qədər). Varsayılan dəyər 1-dir (bütün trafik kəsilir).
Uğurlu ələ keçirdikdən sonra netra sidecar yeni əlaqəni qəbul edir və istifadə edir SO_ORIGINAL_DST orijinal təyinatı əldə etmək üçün rozetka seçimi. Daha sonra Netra orijinal IP ünvanına yeni bir əlaqə açır və keçən bütün trafiki dinləməklə tərəflər arasında ikitərəfli TCP rabitəsi qurur. Port HTTP kimi müəyyən edilirsə, Netra onu təhlil etməyə və izləməyə çalışır. HTTP təhlili uğursuz olarsa, Netra TCP-yə qayıdır və baytları şəffaf şəkildə proksiləşdirir.
Asılılıq qrafikinin qurulması
Jaeger-də böyük miqdarda izləmə məlumatı aldıqdan sonra sistemdəki qarşılıqlı əlaqənin tam qrafikini əldə etmək istəyirəm. Ancaq sisteminiz kifayət qədər yüklənirsə və gündə milyardlarla izləmə aralığı toplanırsa, onları toplamaq o qədər də asan məsələ deyil. Bunu etmək üçün rəsmi bir yol var: . Bununla belə, tam qrafikin qurulması saatlar çəkəcək və sizi son XNUMX saat ərzində Jaeger-dən bütün məlumat dəstini endirməyə məcbur edəcək.
İzləmə aralığını saxlamaq üçün Elasticsearch istifadə edirsinizsə, istifadə edə bilərsiniz , Elasticsearch-in xüsusiyyətləri və imkanlarından istifadə edərək bir neçə dəqiqə ərzində eyni qrafiki quracaq.
Netramesh-dən necə istifadə etmək olar
Netra asanlıqla hər hansı bir orkestrlə işləyən istənilən xidmətə əlavə edilə bilər. Bir nümunə görə bilərsiniz .
Hazırda Netra-nın xidmətlərə yan avtomobilləri avtomatik tətbiq etmək imkanı yoxdur, lakin həyata keçirilməsi üçün planlar var.
Netramesh-in gələcəyi
Əsas məqsəd minimum resurs məsrəflərinə və yüksək performansa nail olmaq, xidmətlərarası rabitənin müşahidə oluna bilməsi və nəzarəti üçün əsas imkanları təmin etməkdir.
Gələcəkdə Netramesh HTTP-dən başqa tətbiq səviyyəsinin digər protokollarını da dəstəkləyəcək. L7 marşrutu yaxın gələcəkdə əlçatan olacaq.
Bənzər problemlərlə qarşılaşdığınız zaman Netramesh-dən istifadə edin və sual və təkliflərinizlə bizə yazın.
Mənbə: www.habr.com