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
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:
- 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.
- 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.
- 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.
GO TO FULL VERSION