Hamıya salam! Əla xəbərimiz var, OTUS iyun ayında yenidən kursa başlayır , bununla əlaqədar olaraq ənənəvi olaraq sizinlə faydalı material paylaşırıq.
Heç bir kontekst olmadan bu mikroservislər məsələsinə rast gəlsəniz, bunun bir az qəribə olduğunu düşündüyünüz üçün bağışlanarsınız. Tətbiqin şəbəkə ilə əlaqəli fraqmentlərə bölünməsi mütləq nəticədə paylanmış sistemə mürəkkəb nasazlığa dözümlülük rejimlərinin əlavə edilməsi deməkdir.
Baxmayaraq ki, bu yanaşma onun bir çox müstəqil xidmətlərə bölünməsini nəzərdə tutur, son məqsəd sadəcə bu xidmətlərin müxtəlif maşınlarda işlədilməsindən daha çoxdur. Burada söhbət xarici dünya ilə qarşılıqlı təsirdən gedir ki, bu da öz mahiyyətinə görə paylanır. Texniki mənada yox, daha çox insanlardan, komandalardan, proqramlardan ibarət olan və bu hissələrin hər birinin bir növ öz işini görməsi lazım olan bir ekosistem mənasında.
Şirkətlər, məsələn, müəyyən məqsədə nail olmaq üçün kollektiv şəkildə töhfə verən paylanmış sistemlər toplusudur. Biz onilliklər ərzində bu fakta məhəl qoymamışıq, faylları FTP üzərindən ötürməklə və ya müəssisə inteqrasiyası vasitələrindən istifadə etməklə birləşməyə nail olmağa çalışırıq, eyni zamanda öz ayrı-ayrı məqsədlərimizə diqqət yetirmişik. Ancaq xidmətlərin meydana gəlməsi ilə hər şey dəyişdi. Xidmətlər bizə üfüqdən kənara baxmağa və birlikdə işləyən qarşılıqlı asılı proqramlar dünyasını görməyə kömək etdi. Bununla belə, müvəffəqiyyətlə işləmək üçün iki əsaslı fərqli dünyanı tanımaq və dizayn etmək lazımdır: bir çox digər xidmətlərin ekosistemində yaşadığımız xarici dünya və təkbaşına hökmranlıq etdiyimiz şəxsi, daxili dünyamız.
Bu paylanmış dünya bizim böyüdüyümüz və öyrəşdiyimiz dünyadan fərqlidir. Ənənəvi monolit memarlığın qurulması prinsipləri tənqidə tab gətirmir. Beləliklə, bu sistemləri düzgün əldə etmək sərin lövhə diaqramı və ya konsepsiyanın gözəl sübutu yaratmaqdan daha çox şeydir. Məsələ belə bir sistemin uzun müddət ərzində uğurla işləməsini təmin etməkdir. Xoşbəxtlikdən, xidmətlər fərqli görünsələr də, kifayət qədər uzun müddətdir mövcuddur. hələ də aktualdır, hətta Docker, Kubernetes və bir qədər köhnəlmiş hipster saqqalları ilə təcrübəlidir.
Beləliklə, bu gün biz qaydaların necə dəyişdiyini, niyə xidmətlərə və onların bir-birlərinə ötürdüyü məlumatlara yanaşma tərzimizi yenidən düşünməli olduğumuzu və bunu etmək üçün nə üçün tamamilə fərqli vasitələrə ehtiyac duyacağımıza baxacağıq.
Encapsulation həmişə sizin dostunuz olmayacaq
Mikroservislər bir-birindən asılı olmayaraq fəaliyyət göstərə bilər. Onlara ən böyük dəyəri verən də bu əmlakdır. Bu eyni əmlak xidmətlərin miqyasını artırmağa və böyüməyə imkan verir. Kvadrilyon istifadəçiyə və ya petabayt məlumatlara miqyas vermək mənasında deyil (baxmayaraq ki, bunlar orada da kömək edə bilər), lakin komandalar və təşkilatlar davamlı olaraq böyüdükcə insanlar baxımından miqyaslandırma mənasında.
Halbuki müstəqillik iki ağızlı qılıncdır. Yəni xidmətin özü asanlıqla və təbii şəkildə işləyə bilər. Lakin funksiya başqa bir xidmətdən istifadəni tələb edən xidmət daxilində həyata keçirilirsə, demək olar ki, eyni vaxtda hər iki xidmətdə dəyişiklik etməli oluruq. Monolitdə bunu etmək asandır, sadəcə dəyişiklik edirsiniz və onu buraxmağa göndərirsiniz, lakin müstəqil xidmətlərin sinxronizasiyası vəziyyətində daha çox problem olacaq. Komandalar və buraxılış dövrləri arasında koordinasiya çevikliyi məhv edir.
Standart yanaşmanın bir hissəsi olaraq, onlar sadəcə olaraq xidmətlər arasında funksionallığı aydın şəkildə bölərək, zəhlətökən başdan-başa dəyişikliklərdən qaçmağa çalışırlar. Tək giriş xidməti burada yaxşı nümunə ola bilər. Onu digər xidmətlərdən fərqləndirən aydın şəkildə müəyyən edilmiş rolu var. Bu aydın ayrılıq o deməkdir ki, ətrafdakı xidmətlərə olan tələblərin sürətlə dəyişən dünyasında tək giriş xidmətinin dəyişmə ehtimalı azdır. O, ciddi şəkildə məhdud kontekstdə mövcuddur.
Problem ondadır ki, real dünyada biznes xidmətləri həmişə rolların eyni saf ayrılmasını saxlaya bilməz. Məsələn, eyni biznes xidmətləri digər oxşar xidmətlərdən gələn məlumatlarla daha çox işləyir. Əgər siz onlayn pərakəndə satışla məşğul olursunuzsa, o zaman sifariş axınının, məhsul kataloqunun və ya istifadəçi məlumatlarının işlənməsi bir çox xidmətləriniz üçün tələb olacaq. Xidmətlərin hər birinin işləməsi üçün bu məlumatlara giriş tələb olunacaq.
Əksər biznes xidmətləri eyni məlumat axınını paylaşır, buna görə də onların işi həmişə bir-birinə bağlıdır.
Beləliklə, danışmağa dəyər vacib bir məqama gəldik. Xidmətlər əsasən təcrid olunmuş şəkildə fəaliyyət göstərən infrastruktur komponentləri üçün yaxşı işləsə də, əksər biznes xidmətləri bir-birinə daha sıx bağlıdır.
Məlumat dixotomiyası
Xidmət yönümlü yanaşmalar artıq mövcud ola bilər, lakin onlar hələ də xidmətlər arasında böyük həcmdə məlumatların necə paylaşılacağına dair fikirlərə malik deyillər.
Əsas problem data və xidmətlərin ayrılmaz olmasıdır. Bir tərəfdən, inkapsulyasiya bizi məlumatları gizlətməyə sövq edir ki, xidmətlər bir-birindən ayrılsın və onların böyüməsini və sonrakı dəyişikliklərini asanlaşdırsın. Digər tərəfdən, hər hansı digər məlumatlar kimi, paylaşılan məlumatları sərbəst şəkildə bölməyi və fəth etməyi bacarmalıyıq. Məsələ ondadır ki, hər hansı digər informasiya sistemlərində olduğu kimi sərbəst şəkildə dərhal işə başlaya bilməkdir.
Bununla belə, informasiya sistemlərinin inkapsulyasiya ilə heç bir əlaqəsi yoxdur. Əslində isə bunun tam əksidir. Verilənlər bazaları saxladıqları məlumatlara girişi təmin etmək üçün əllərindən gələni edirlər. Onlar sizə lazım olan məlumatları dəyişdirməyə imkan verən güclü deklarativ interfeys ilə gəlir. Bu cür funksionallıq ilkin tədqiqat mərhələsində vacibdir, lakin daim inkişaf edən xidmətin artan mürəkkəbliyini idarə etmək üçün deyil.
Və burada bir dilemma yaranır. Ziddiyyət. Dixotomiya. Axı, informasiya sistemləri məlumatların təmin edilməsindən, xidmətlər isə gizlədilməsindən ibarətdir.
Bu iki qüvvə əsasdır. Onlar qurduğumuz sistemlərdə mükəmməllik üçün daim mübarizə apararaq, işimizin çox hissəsini təşkil edir.
Xidmət sistemləri böyüdükcə və təkamül etdikcə, biz bir çox cəhətdən məlumat dixotomiyasının nəticələrini görürük. Ya xidmət interfeysi getdikcə daha geniş funksionallıq təmin etmək üçün böyüyəcək və çox dəbdəbəli yerli verilənlər bazası kimi görünməyə başlayacaq, ya da biz məyus olacaq və kütləvi şəkildə bütün məlumat dəstlərini xidmətdən xidmətə köçürmək üçün hansısa üsul tətbiq edəcəyik.
Öz növbəsində, dəbdəbəli yerli məlumat bazası kimi görünən bir şey yaratmaq bir çox problemə səbəb olacaqdır. Bunun niyə təhlükəli olduğu barədə təfərrüatlara girməyəcəyik paylaşılan verilənlər bazası, deyək ki, bu, əhəmiyyətli dərəcədə bahalı mühəndislik və əməliyyatları təmsil edir istifadə etməyə çalışan şirkət üçün.
Ən pisi odur ki, məlumat həcmləri xidmət sərhədləri ilə bağlı problemləri artırır. Xidmət daxilində nə qədər çox paylaşılan məlumat olarsa, interfeys bir o qədər mürəkkəbləşəcək və müxtəlif xidmətlərdən gələn məlumat dəstlərini birləşdirmək bir o qədər çətinləşəcək.
Bütün məlumat dəstlərinin çıxarılması və daşınmasına alternativ yanaşmanın da öz problemləri var. Bu suala ümumi yanaşma, sadəcə olaraq bütün məlumat dəstini əldə etmək və saxlamaq və sonra onu hər bir istehlakçı xidmətdə yerli olaraq saxlamaq kimi görünür.
Problem ondadır ki, müxtəlif xidmətlər istehlak etdikləri məlumatları fərqli şəkildə şərh edir. Bu məlumatlar həmişə əlinizdədir. Onlar yerli olaraq dəyişdirilir və işlənir. Çox tez mənbədəki məlumatlarla ortaq bir şeyə sahib olmağı dayandırırlar.
Nüsxələr nə qədər dəyişkəndirsə, verilənlər zamanla bir o qədər çox dəyişəcək.
Vəziyyəti daha da pisləşdirmək üçün, bu cür məlumatları retrospektivdə düzəltmək çətindir ( Bu, həqiqətən xilasetməyə gələ biləcəyi yerdir). Əslində, müəssisələrin üzləşdiyi bəzi həlledilməz texnoloji problemlər, tətbiqdən tətbiqə çoxalan fərqli məlumatlardan yaranır.
Bu problemin həllini tapmaq üçün paylaşılan məlumatlar haqqında fərqli düşünməliyik. Onlar qurduğumuz memarlıqlarda birinci dərəcəli obyektlərə çevrilməlidir. belə məlumatları “xarici” adlandırır və bu, çox vacib xüsusiyyətdir. Xidmətin daxili xüsusiyyətlərini ifşa etməmək üçün inkapsulyasiyaya ehtiyacımız var, lakin xidmətlərin paylaşılan məlumatlara daxil olmasını asanlaşdırmalıyıq ki, onlar öz işlərini düzgün yerinə yetirə bilsinlər.
Problem ondadır ki, bu gün nə yanaşma aktual deyil, çünki nə xidmət interfeysləri, nə mesajlaşma, nə də Paylaşılan verilənlər bazası xarici məlumatlarla işləmək üçün yaxşı bir həll təklif etmir. Xidmət interfeysləri istənilən miqyasda məlumat mübadiləsi üçün zəif uyğundur. Mesajlaşma məlumatları köçürür, lakin onun tarixini saxlamır, buna görə də zaman keçdikcə məlumatlar korlanır. Paylaşılan verilənlər bazaları bir nöqtəyə çox diqqət yetirir ki, bu da irəliləyişi dayandırır. Biz istər-istəməz məlumat çatışmazlığı dövründə ilişib qalırıq:
Məlumat çatışmazlığı dövrü
Axınlar: məlumat və xidmətlərə mərkəzləşdirilməmiş yanaşma
İdeal olaraq, xidmətlərin paylaşılan məlumatlarla işləmə üsulunu dəyişdirməliyik. Bu nöqtədə, hər iki yanaşma yuxarıda qeyd olunan dixotomiya ilə üzləşir, çünki onu yox etmək üçün üzərinə səpilə bilən sehrli toz yoxdur. Bununla belə, biz problemi yenidən nəzərdən keçirib kompromis əldə edə bilərik.
Bu kompromis müəyyən dərəcədə mərkəzləşməni nəzərdə tutur. Biz paylanmış log mexanizmindən istifadə edə bilərik, çünki o, etibarlı, genişlənə bilən axınları təmin edir. Biz indi xidmətlərin bu paylaşılan mövzulara qoşulub fəaliyyət göstərə bilməsini istəyirik, lakin bu emal edən kompleks mərkəzləşdirilmiş Tanrı Xidmətlərindən qaçmaq istəyirik. Buna görə də, ən yaxşı seçim hər bir istehlakçı xidmətində axın emalını qurmaqdır. Beləliklə, xidmətlər müxtəlif mənbələrdən məlumat dəstlərini birləşdirə və onlarla lazım olan şəkildə işləyə biləcəklər.
Bu yanaşmaya nail olmağın bir yolu axın platformasından istifadə etməkdir. Bir çox variant var, lakin bu gün biz Kafkaya baxacağıq, çünki onun Stateful Stream Processing istifadəsi təqdim olunan problemi effektiv şəkildə həll etməyə imkan verir.
Paylanmış giriş mexanizmindən istifadə bizə yaxşı keçilmiş yolu izləməyə və işləmək üçün mesajlaşmadan istifadə etməyə imkan verir. . Bu yanaşma sorğu-cavab mexanizmindən daha yaxşı miqyaslama və bölmə təmin edir, çünki o, axının idarəsini göndərənə deyil, alıcıya verir. Bununla belə, bu həyatda hər şey üçün pul ödəməlisən və burada bir broker lazımdır. Lakin böyük sistemlər üçün mübadilə buna dəyərdir (bu, orta veb tətbiqiniz üçün belə olmaya bilər).
Əgər broker ənənəvi mesajlaşma sistemindən daha çox paylanmış girişə cavabdehdirsə, siz əlavə funksiyalardan istifadə edə bilərsiniz. Nəqliyyat demək olar ki, paylanmış fayl sistemi kimi xətti olaraq miqyaslaya bilər. Məlumatlar kifayət qədər uzun müddət loglarda saxlanıla bilər, buna görə də biz yalnız mesaj mübadiləsini deyil, həm də məlumat saxlamalarını əldə edirik. Dəyişən paylaşılan vəziyyət qorxusu olmadan genişlənə bilən yaddaş.
Daha sonra istehlakçı xidmətlərə deklarativ verilənlər bazası alətləri əlavə etmək üçün statuslu axın emalından istifadə edə bilərsiniz. Bu, çox vacib bir fikirdir. Məlumatlar bütün xidmətlərin daxil ola biləcəyi paylaşılan axınlarda saxlansa da, xidmətin etdiyi toplama və emal özəldir. Onlar özlərini ciddi məhdud kontekstdə təcrid olunmuş vəziyyətdə tapırlar.
Dəyişməz vəziyyət axınını ayırmaqla məlumat dixotomiyasını aradan qaldırın. Sonra bu funksiyanı Stateful Stream Processing istifadə edərək hər bir xidmətə əlavə edin.
Beləliklə, əgər xidmətinizin sifarişlər, məhsul kataloqu, anbarla işləməsi lazımdırsa, onun tam çıxışı olacaq: hansı məlumatların birləşdiriləcəyinə, harada emal ediləcəyinə və zamanla necə dəyişəcəyinə yalnız siz qərar verəcəksiniz. Məlumatların paylaşılmasına baxmayaraq, onunla işləmək tamamilə mərkəzləşdirilməmişdir. Hər bir xidmət daxilində, hər şeyin sizin qaydalarınıza uyğun getdiyi bir dünyada istehsal olunur.
Məlumatların bütövlüyünü pozmadan paylaşın. Lazım olan hər bir xidmətdə mənbəni deyil, funksiyanı əhatə edin.
Belə olur ki, məlumatların kütləvi şəkildə köçürülməsi lazımdır. Bəzən xidmət seçilmiş verilənlər bazası mühərrikində yerli tarixi verilənlər toplusunu tələb edir. Məsələ ondadır ki, lazım gələrsə, paylanmış giriş mexanizminə daxil olaraq bir nüsxənin mənbədən bərpa oluna biləcəyinə zəmanət verə bilərsiniz. Kafkadakı konnektorlar bunun üçün əla iş görür.
Beləliklə, bu gün müzakirə olunan yanaşma bir sıra üstünlüklərə malikdir:
- Məlumatlar uzun müddət jurnallarda saxlanıla bilən ümumi axınlar şəklində istifadə olunur və ümumi məlumatlarla işləmə mexanizmi hər bir fərdi kontekstdə bərkidilir ki, bu da xidmətlərin asan və tez işləməsinə imkan verir. Bu yolla, məlumatların dixotomiyası balanslaşdırıla bilər.
- Müxtəlif xidmətlərdən gələn məlumatlar asanlıqla dəstlərə birləşdirilə bilər. Bu, paylaşılan məlumatlar ilə qarşılıqlı əlaqəni asanlaşdırır və verilənlər bazasında yerli verilənlər toplusunu saxlamaq ehtiyacını aradan qaldırır.
- Stateful Stream Processing yalnız məlumatları keşləyir və həqiqətin mənbəyi ümumi qeydlər olaraq qalır, ona görə də zamanla məlumatların korlanması problemi o qədər də kəskin deyil.
- Əsas etibarı ilə xidmətlər dataya əsaslanır, yəni getdikcə artan məlumat həcminə baxmayaraq, xidmətlər hələ də biznes hadisələrinə tez cavab verə bilir.
- Ölçeklenebilirlik problemləri xidmətlərə deyil, brokerə düşür. Bu, yazı xidmətlərinin mürəkkəbliyini əhəmiyyətli dərəcədə azaldır, çünki genişlənmə haqqında düşünməyə ehtiyac yoxdur.
- Yeni xidmətlərin əlavə edilməsi köhnələrin dəyişdirilməsini tələb etmir, ona görə də yeni xidmətlərin qoşulması asanlaşır.
Gördüyünüz kimi, bu sadəcə REST-dən daha çox şeydir. Paylaşılan məlumatlarla mərkəzləşdirilməmiş şəkildə işləməyə imkan verən bir sıra alətlər əldə etdik.
Bugünkü məqalədə bütün aspektlər əhatə olunmadı. Biz hələ də sorğu-cavab paradiqması ilə hadisəyə əsaslanan paradiqma arasında tarazlığın necə qurulacağını anlamalıyıq. Ancaq növbəti dəfə bununla məşğul olacağıq. Daha yaxşı tanış olmağınız lazım olan mövzular var, məsələn, Stateful Stream Processing niyə bu qədər yaxşıdır. Bu barədə üçüncü məqalədə danışacağıq. Digər güclü konstruksiyalar da var ki, onlardan istifadə etsək, məsələn, . O, paylanmış biznes sistemləri üçün oyun dəyişdiricisidir, çünki o, əməliyyat təminatı verir miqyaslı formada. Bu, dördüncü məqalədə müzakirə olunacaq. Nəhayət, bu prinsiplərin həyata keçirilməsi təfərrüatlarını nəzərdən keçirməliyik.
Ancaq hələlik bunu xatırlayın: məlumat dixotomiyası biznes xidmətləri qurarkən qarşılaşdığımız bir qüvvədir. Və bunu yadda saxlamalıyıq. Hiylə, hər şeyi öz başına çevirmək və paylaşılan məlumatlara birinci dərəcəli obyektlər kimi baxmağa başlamaqdır. Stateful Stream Processing bunun üçün unikal kompromis təmin edir. O, tərəqqiyə mane olan mərkəzləşdirilmiş “Tanrı Komponentlərindən” çəkinir. Bundan əlavə, o, məlumat axını boru kəmərlərinin çevikliyini, genişlənməsini və dayanıqlığını təmin edir və onları hər bir xidmətə əlavə edir. Buna görə də, hər hansı bir xidmətin öz məlumatları ilə əlaqə saxlaya və işləyə biləcəyi ümumi şüur axınına diqqət yetirə bilərik. Bu, xidmətləri daha genişlənən, dəyişdirilə bilən və avtonom edir. Beləliklə, onlar yalnız lövhələrdə və fərziyyə testlərində yaxşı görünməyəcək, həm də onilliklər ərzində işləyəcək və inkişaf edəcəklər.
Mənbə: www.habr.com