Hey Habr!
Haqqında kitabı izlədiyini xatırladırıq kitabxana haqqında eyni dərəcədə maraqlı bir əsər dərc etmişik .
Hələlik cəmiyyət bu güclü alətin sərhədlərini öyrənir. Beləliklə, bu yaxınlarda bir məqalə dərc olundu, onun tərcüməsi ilə sizi tanış etmək istərdik. Müəllif öz təcrübəsindən Kafka Axınlarını paylanmış məlumat yaddaşına necə çevirəcəyini izah edir. Oxumaqdan həzz alın!
Apache kitabxanası Apache Kafka üzərində paylanmış axın emalı üçün bütün dünyada istifadə olunur. Bu çərçivənin təqdir olunmayan tərəflərindən biri odur ki, o, ip emalı əsasında istehsal edilmiş yerli vəziyyəti saxlamağa imkan verir.
Bu yazıda şirkətimizin bulud tətbiqi təhlükəsizliyi üçün məhsul hazırlayarkən bu fürsətdən necə sərfəli istifadə etməyi bacardığını sizə xəbər verəcəyəm. Kafka Streams-dən istifadə edərək, hər biri xətaya dözümlü və sistemdəki obyektlərin vəziyyəti haqqında etibarlı məlumat mənbəyi kimi xidmət edən paylaşılan dövlət mikroservisləri yaratdıq. Bizim üçün bu, həm etibarlılıq, həm də dəstək asanlığı baxımından irəliyə doğru bir addımdır.
Əgər obyektlərinizin formal vəziyyətini dəstəkləmək üçün vahid mərkəzi məlumat bazasından istifadə etməyə imkan verən alternativ yanaşma ilə maraqlanırsınızsa, oxuyun, maraqlı olacaq...
Niyə düşündük ki, paylaşılan dövlətlə işləmə tərzimizi dəyişməyin vaxtıdır
Biz agent hesabatlarına əsaslanaraq müxtəlif obyektlərin vəziyyətini saxlamalı idik (məsələn: sayt hücuma məruz qaldımı)? Kafka Axınlarına köçməzdən əvvəl biz dövlət idarəçiliyi üçün çox vaxt vahid mərkəzi verilənlər bazasına (+ xidmət API) etibar edirdik. Bu yanaşmanın çatışmazlıqları var: ardıcıllığı və sinxronizasiyanı qorumaq əsl problemə çevrilir. Verilənlər bazası darboğaza çevrilə və ya sona çata bilər və gözlənilməzlikdən əziyyət çəkir.
Şəkil 1: keçiddən əvvəl görülən tipik split-status ssenarisi
Kafka və Kafka axınları: agentlər öz fikirlərini API vasitəsilə ötürür, yenilənmiş vəziyyət mərkəzi verilənlər bazası vasitəsilə hesablanır
Paylaşılan dövlət mikroservislərini yaratmağı asanlaşdıran Kafka Axınları ilə tanış olun
Təxminən bir il əvvəl biz bu problemləri həll etmək üçün ortaq dövlət ssenarilərimizə ciddi nəzər salmaq qərarına gəldik. Biz dərhal Kafka Streams-i sınamaq qərarına gəldik - biz onun nə qədər genişlənə bilən, yüksək əlçatan və nasazlığa dözümlü olduğunu, hansı zəngin axın funksiyasına malik olduğunu bilirik (çevirmələr, o cümlədən statuslu olanlar). Məhz bizə lazım olan şey, Kafkada mesajlaşma sisteminin nə qədər yetkin və etibarlı hala gəldiyini demirəm.
Yaratdığımız statuslu mikroservislərin hər biri kifayət qədər sadə topologiyaya malik Kafka Streams instansiyası üzərində qurulmuşdur. O, 1) mənbədən 2) davamlı açar-dəyər anbarına malik prosessordan 3) sinkdən ibarət idi:
Şəkil 2: Vəziyyətli mikroservislər üçün axın nümunələrimizin standart topologiyası. Qeyd edək ki, burada planlaşdırma metadatasını ehtiva edən bir depo da var.
Bu yeni yanaşmada agentlər mənbə mövzusuna daxil olan mesajları tərtib edir və istehlakçılar, məsələn, poçt bildiriş xidməti, hesablanmış paylaşılan vəziyyəti sink (çıxış mövzusu) vasitəsilə alırlar.
Şəkil 3: Paylaşılan mikroxidmətləri olan ssenari üçün tapşırıq axınının yeni nümunəsi: 1) agent Kafka mənbə mövzusuna gələn mesaj yaradır; 2) paylaşılan vəziyyətə malik mikroservis (Kafka axınlarından istifadə etməklə) onu emal edir və hesablanmış vəziyyəti yekun Kafka mövzusuna yazır; bundan sonra 3) istehlakçılar yeni vəziyyəti qəbul edirlər
Hey, bu daxili əsas dəyər mağazası həqiqətən çox faydalıdır!
Yuxarıda qeyd edildiyi kimi, paylaşılan dövlət topologiyamız açar-dəyər anbarını ehtiva edir. Onu istifadə etmək üçün bir neçə variant tapdıq və onlardan ikisi aşağıda təsvir edilmişdir.
Seçim №1: Hesablamalar üçün əsas dəyər anbarından istifadə edin
İlk açar-dəyər anbarımız hesablamalar üçün lazım olan köməkçi məlumatları ehtiva edirdi. Məsələn, bəzi hallarda ortaq dövlət “səs çoxluğu” prinsipi ilə müəyyən edilirdi. Repozitoriya hansısa obyektin statusu haqqında ən son agent hesabatlarını saxlaya bilər. Sonra bu və ya digər agentdən yeni hesabat aldıqda, biz onu saxlaya, bütün digər agentlərdən eyni obyektin vəziyyəti ilə bağlı hesabatları anbardan götürə və hesablamağı təkrarlaya bildik.
Aşağıdakı Şəkil 4, yeni mesajın işlənməsi üçün açar/dəyər anbarını prosessorun emal metoduna necə məruz qoyduğumuzu göstərir.
Şəkil 4: Biz prosessorun emal metodu üçün açar-dəyər anbarına girişi açırıq (bundan sonra paylaşılan dövlətlə işləyən hər bir skript metodu tətbiq etməlidir. doProcess)
Seçim #2: Kafka Axınlarının üstündə CRUD API yaratmaq
Əsas tapşırıq axınımızı qurduqdan sonra biz paylaşılan dövlət mikroservislərimiz üçün RESTful CRUD API yazmağa başladıq. Biz bəzi və ya bütün obyektlərin vəziyyətini əldə etmək, həmçinin obyektin vəziyyətini təyin etmək və ya silmək (backend dəstəyi üçün faydalı) olmaq istəyirdik.
Bütün Get State API-lərini dəstəkləmək üçün, emal zamanı vəziyyəti yenidən hesablamağa ehtiyac duyduqda, biz onu uzun müddət daxili açar-dəyər anbarında saxladıq. Bu halda, aşağıdakı siyahıda göstərildiyi kimi, Kafka Streams-in tək bir nümunəsindən istifadə edərək belə bir API tətbiq etmək olduqca sadə olur:
Şəkil 5: Obyektin əvvəlcədən hesablanmış vəziyyətini əldə etmək üçün daxili açar-dəyər anbarından istifadə
API vasitəsilə obyektin vəziyyətini yeniləmək də asan həyata keçirilir. Əsasən, sizə lazım olan tək şey Kafka prodüseri yaratmaq və ondan yeni vəziyyəti ehtiva edən bir qeyd etmək üçün istifadə etməkdir. Bu, API vasitəsilə yaradılan bütün mesajların digər istehsalçılardan (məsələn, agentlərdən) alınan mesajlarla eyni şəkildə işlənməsini təmin edir.
Şəkil 6: Kafka prodüserindən istifadə edərək obyektin vəziyyətini təyin edə bilərsiniz
Kiçik mürəkkəblik: Kafkanın çoxlu bölmələri var
Sonra, hər bir ssenari üzrə paylaşılan dövlət mikroxidmətləri klasterini təmin etməklə emal yükünü paylamaq və əlçatanlığı yaxşılaşdırmaq istədik. Quraşdırma asan idi: biz bütün nümunələri eyni proqram ID (və eyni yükləmə serverləri) altında işləmək üçün konfiqurasiya etdikdən sonra, demək olar ki, hər şey avtomatik həyata keçirilirdi. Biz həmçinin qeyd etdik ki, hər bir mənbə mövzusu bir neçə bölmədən ibarət olacaq ki, hər bir nümunəyə belə bölmələrin alt dəsti təyin oluna bilsin.
Onu da qeyd edim ki, dövlət mağazasının ehtiyat nüsxəsini hazırlamaq adi bir təcrübədir ki, məsələn, nasazlıqdan sonra bərpa olunarsa, bu nüsxəni başqa bir nüsxəyə köçürün. Kafka Axınlarında hər bir dövlət mağazası üçün dəyişiklik jurnalı (yerli yeniləmələri izləyən) ilə təkrarlanan mövzu yaradılır. Beləliklə, Kafka daim dövlət mağazasını dəstəkləyir. Buna görə də, bu və ya digər Kafka Streams instansiyasının uğursuzluğu halında, dövlət mağazası müvafiq bölmələrin gedəcəyi başqa bir instansiyada tez bərpa edilə bilər. Testlərimiz göstərdi ki, mağazada milyonlarla qeyd olsa belə, bu, bir neçə saniyə ərzində edilir.
Paylaşılan vəziyyətə malik bir mikroservisdən mikroservislər klasterinə keçməklə, Get State API-ni tətbiq etmək daha az əhəmiyyət kəsb edir. Yeni vəziyyətdə, hər bir mikroxidmətin dövlət anbarı ümumi mənzərənin yalnız bir hissəsini (açarları müəyyən bir bölmə ilə əlaqələndirilmiş obyektlər) ehtiva edir. Hansı nümunənin bizə lazım olan obyektin vəziyyətini ehtiva etdiyini müəyyən etməli olduq və bunu aşağıda göstərildiyi kimi mövzu metadatasına əsaslanaraq etdik:
Şəkil 7: Axın metaməlumatlarından istifadə edərək, istədiyiniz obyektin vəziyyətini hansı instansiyadan sorğulayacağımızı müəyyən edirik; oxşar yanaşma GET ALL API ilə istifadə edilmişdir
Əsas tapıntılar
Kafka Streams-dəki dövlət mağazaları faktiki olaraq paylanmış verilənlər bazası kimi xidmət edə bilər,
- Kafkada daim təkrarlanır
- CRUD API asanlıqla belə bir sistemin üzərində qurula bilər
- Çoxlu arakəsmələri idarə etmək bir az daha mürəkkəbdir
- Köməkçi məlumatları saxlamaq üçün axın topologiyasına bir və ya bir neçə dövlət mağazası əlavə etmək də mümkündür. Bu seçim aşağıdakılar üçün istifadə edilə bilər:
- Axın emalı zamanı hesablamalar üçün lazım olan məlumatların uzunmüddətli saxlanması
- Növbəti dəfə axın nümunəsi təmin edildikdə faydalı ola biləcək məlumatların uzunmüddətli saxlanması
- daha çox...
Bu və digər üstünlüklər Kafka Streams-i bizim kimi paylanmış sistemdə qlobal vəziyyəti saxlamaq üçün yaxşı uyğunlaşdırır. Kafka Streams istehsalda çox etibarlı olduğunu sübut etdi (onu istifadə etdikdən sonra biz faktiki olaraq heç bir mesaj itkisi ilə üzləşməmişik) və onun imkanlarının bununla bitməyəcəyinə əminik!
Mənbə: www.habr.com