Mikroservislər böyük bir tətbiqi sadə bir API vasitəsilə bir-biri ilə əlaqə saxlayan boş birləşdirilmiş modullara bölmək üsuludur.
Son vaxtlar mikroservislərdən ancaq lal adamlar danışmır. Bu getdikcə populyarlaşır. Modul memarlıq üslubu bulud əsaslı mühitlər üçün xüsusilə uyğun görünür və populyarlığı artır. Təfərrüatlara keçməzdən əvvəl gəlin hər şeyə bir quşbakışı baxaq . Buna görə də: Mikroservislər böyük bir layihəni kiçik, müstəqil və sərbəst birləşdirilən modullara bölmək üsuludur. Müstəqil modullar aydın şəkildə müəyyən edilmiş və diskret tapşırıqlara cavabdehdir və sadə və əlçatan API vasitəsilə bir-biri ilə əlaqə qurur. Başqa sözlə, mikroservislər mürəkkəb, əsasən veb proqramların layihələndirilməsi üçün sadəcə fərqli bir memarlıq üslubudur. Bəs SOA (Xidmət yönümlü memarlıq) kimi mövcud memarlıq həllərinin nəyi pisdir? SOA istifadə edərək yazılmış əksər müasir müəssisə həlləri olduqca yaxşı işləyir. Bu, sənayenin bu günlərdə üzləşdiyi bəzi çətinliklər haqqında danışmaq üçün əla vaxt ola bilər... Gəlin sadə bir nümunə ilə başlayaq. Tutaq ki, mən Java-da yazılmış klassik proqram işlətməliyəm. Əvvəlcə İstifadəçi İnterfeysini, sonra UI ilə qarşılıqlı əlaqədə olacaq bir neçə komponentlə biznes məntiqi təbəqəsini və nəhayət, davamlı verilənlər bazası üçün əlçatan olacaq verilənlər bazası qatını inkişaf etdirəcəyəm. İndi tətbiqi işə salmaq istədiyimə görə, WAR/EAR/JAR yaradacağam və onu serverə (JBoss, Tomcat və ya WebLogic kimi) quraşdıracağam. Bütün bunlar bir yerdə edildiyi üçün mən monolit tətbiq alıram, yəni bütün komponentlər bir yerdədir... Şəkildəki nümunə:
Çox güman ki, siz artıq bu yanaşma ilə tanışsınız və ondan istifadə etmisiniz, lakin ideya bu memarlıq həllindən istifadə edərək tərtibatçıların hansı çətinliklərlə üzləşəcəyini göstərmək üçün bu nümunədən istifadə etməkdir. Monolit tətbiqi: çətinliklərlə üzləşir
Tətbiq böyüdükcə yazılan kodun miqdarı da artır, bu da hər dəfə onu açmağınız lazım olduqda inkişaf mühitini çox yükləyə bilər. Bu, mütləq tərtibatçının səmərəliliyini azaldır.
Hər şey bir yerə quraşdırılmalı olduğundan, bu, başqa proqramlaşdırma dilinə keçidin və ya başqa texnologiyalara keçidin böyük problem olmasına gətirib çıxarır. Məsələn, Java-da bir proqram yazdınız və bir müddət sonra Kotlin çıxdı və onu yenidən yazmağa can atdınız, çünki o, daha sərin, daha yaxşı, daha sürətli kimi təbliğ edildi . Monolitik bir tətbiq ilə, hətta refaktorinq haqqında düşünmək, prosesin özünü qeyd etməmək üçün əsl ağrıya səbəb olacaq. Hal-hazırda bu şəkildə hazırlanmış bir çox proqram var və kod sətirlərinin sayı sadəcə inanılmazdır.
Komponentlərdən hər hansı biri hər hansı bir səbəbdən işləməyi dayandırarsa , bütün proqram da çökəcək. Təsəvvür edin ki, avtorizasiya, ödəniş, tarix və s. kimi modulları olan bir veb tətbiqi var. Və nədənsə onlardan biri qırılır. Bu, sadəcə olaraq biznes və nəticədə tərtibatçılar üçün şokdur.
Monolit tətbiqin miqyasının artırılmasına yalnız eyni tipli başqa bir tətbiqin artırılması ilə nail olmaq olar. Bəs bütün tətbiqi deyil, yalnız bir komponenti miqyaslaşdırmaq lazımdırsa? Nə qədər resurs boşa gedəcək?...
Bu, proqramın inkişaf prosesinə və quraşdırılması prosesinə böyük təsir göstərə bilər. Tətbiq nə qədər böyükdürsə, tərtibatçıların tətbiqi daha kiçik işçi hissələrə bölməsi bir o qədər vacibdir. Monolit proqramdakı bütün modullar bir-birinə bağlı olduğundan, tərtibatçılar bu modulları bir-birindən asılı olmayaraq işləyə və quraşdıra bilməzlər. Tərtibatçılar bir-birindən asılı olduğundan, inkişaf müddəti artır.
Eyni zamanda, biz mikroxidmətlərin mənasını, yəni SOA üslubu ilə itirilən çevikliyi bərpa etmək üçün onlardan necə istifadə oluna biləcəyini nəzərdən keçirməyə və anlamağa hazırıq. Xilasetmə üçün Tanrı Mikroxidmətləri Hər hansı bir memarlıq həllində ən vacib xüsusiyyətlərdən biri miqyaslılıqdır. Mikroservisləri ilk dəfə öyrənərkən gördüm ki, hər şey “The Art of Scalability” kitabından sitatlara çox bənzəyir. Bu, əla başlanğıc və müzakirə yeridir. Bu kitab üçölçülü miqyaslılıq sistemini təsvir edən sözdə "Ölçeklenebilirlik Kubi" modelini müəyyənləşdirir:
Gördüyünüz kimi, X oxu "üfüqi miqyaslılığı" təsvir edir (gördük ki, monolit arxitekturalar üçün də mövcuddur), Y oxu müxtəlif xidmət komponentlərini ayırmaq mənasında miqyaslaşdırmanı təmsil edir . Z oxunun ideyası məlumat bölündükdə başa düşülür və proqram məlumatların yerləşdiyi yerə sorğu göndərir. Yəni onların hamısı bir yerdə deyil. Y oxunun ideyası daha ətraflı üzərində dayanacağımız ideyadır. Bu ox funksional parçalanmanı təmsil edir . Bu strategiyada müxtəlif funksiyalar müstəqil xidmətlər kimi qəbul edilə bilər. Buna görə də, bütün tətbiqi yalnız hər şey edildikdən sonra quraşdırmaqla, tərtibatçılar fərdi xidmətləri bir-birindən asılı olmayaraq quraşdıra bilərlər və başqalarının modulları üzərində işləməsini gözləmədən. Bu, nəinki inkişaf müddətini yaxşılaşdıracaq, həm də tətbiqin qalan komponentləri ilə bağlı narahatçılıq keçirmədən dəyişdirmək və yenidən quraşdırmaq üçün çeviklik təklif edəcək. Bu diaqramı əvvəlki monolit ilə müqayisə edək:
Mikroservislər: Faydalar Mikroservislərin faydaları Amazon, Netflix, Ebay kimi müəssisə tərtibatçılarını bu yanaşmadan istifadə etməyə inandırmaq üçün kifayət qədər görünür. Monolit memarlıq tətbiqlərindən fərqli olaraq, mikroservislər:
Komponent çatışmazlığının izolyasiyasını yaxşılaşdırır: Böyük proqramlar tək modul uğursuz olsa belə səmərəli işləməyə davam edə bilər.
Tətbiqin bir texnologiya yığınına bağlılığını aradan qaldırır: bəzi xidmətlərdə yeni texnologiya yığınını sınamaq istəyirsinizsə, davam edin. Asılılıqlar monolitdən daha yüngül olacaq və hər şeyi geri qaytarmaq daha asan olacaq. Bir proqramda kod nə qədər az olsa, işləmək bir o qədər asan olar.
Yeni işçilərin xidmətin funksionallığını başa düşməsini xeyli asanlaşdırır.
Mikroservislər: quraşdırma və virtuallaşdırma xüsusiyyətləri İndi biz mikroservislərin nə olduğunu başa düşürük. Ən böyük üstünlüyü isə onun birdən çox WAR/EAR/JAR arxivi ilə quraşdırılmasıdır. Bəs necə quraşdırılıb? Mikroservisləri konteynerlərə quraşdırmağın ən yaxşı yolu. Konteyner konfiqurasiya edilmiş lazımi mühitə malik tam konfiqurasiya edilmiş virtual əməliyyat sistemidir və konteynerin quraşdırıldığı aparat sisteminin resurslarına çıxışı təcrid etməyə kömək edir. Bazarda ən məşhur həll əlbəttə Docker-dir . AWS kimi IaaS (xidmət kimi infrastruktur) virtual maşınları da mikroxidmətlərin quraşdırılması üçün yaxşı işləyə bilər, lakin nisbətən yüngül mikroservislər virtual maşında olan bütün resurslardan istifadə etməyə bilər ki, bu da istifadənin gəlirliliyini azalda bilər. Siz həmçinin OSGI (Open Service Gateway Initiative) paketindən istifadə edərək mikroxidmətlərinizi quraşdıra bilərsiniz . Bu halda, bütün mikroservislər tək JVM-də işləyəcək, lakin bu, nəzarət və təcrid arasında mübadilə məsələlərini əhatə edir. Mikroservislər: Dezavantajlar Sadəcə “bunlar gözəldir” və “biz bunu əvvəllər görməmişik” demək deyil ki, heç bir çatışmazlıq yoxdur. Aşağıda mikroservis arxitekturasının özü ilə gətirdiyi mümkün ağrı sahələrinin siyahısı verilmişdir:
Paylanmış sistemləri inkişaf etdirmək çətin ola bilər. Bununla demək istəyirəm ki, bütün komponentlər indi müstəqil xidmətlərdir - modullar arasında keçən sorğuları çox diqqətlə idarə etməlisiniz. Bir modulun cavab vermədiyi, sistemin qəzaya uğramaması üçün sizi əlavə kod yazmağa məcbur edən bir ssenari ola bilər. Uzaqdan gələn zənglər gecikməyə həssasdırsa, bu daha çətin ola bilər .
Çoxlu verilənlər bazası və əməliyyatların idarə edilməsi əsl ağrı ola bilər.
mikroservis proqramlarının sınaqdan keçirilməsi çətin ola bilər. Monolit proqramdan istifadə etməklə biz yalnız serverdə WAR/EAR/JAR arxivini işə salmalı və onun verilənlər bazasına qoşulduğuna əmin olmalıyıq. Mikroservislərdə isə sınaq başlamazdan əvvəl hər bir fərdi xidmət işə salınmalıdır.
Tətbiqlərin quraşdırılması çətin ola bilər. Onlar MÜHARİBƏ konteyneri kimi quraşdırmaq asan olmayan çoxsaylı xidmətlər ətrafında koordinasiya tələb edə bilər.
.... Təbii ki, düzgün alətlər və yanaşmalarla bu çatışmazlıqların qarşısını almaq olar. Ancaq onlar özləri dəstək tələb edir və bütün problemləri tamamilə həll etmirlər. Məqalə CloudAcademy saytından tərcümə edilib . Pulsuz tərcümə. Hər kəs öz fikirlərini şərhlərdə ifadə etməkdə sərbəstdir. Onlar mütləq oxunacaq. Orijinal məqalə Mənim Github hesabım
GO TO FULL VERSION