19 sentyabr Moskvada mikroservislərə həsr olunmuş ilk tematik görüş HUG (Highload++ İstifadəçi Qrupu). Flantın mikroservis arxitekturası ilə layihələrin idarə edilməsində geniş təcrübəsini paylaşdığımız “Mikroservislərin istismarı: Kubernetiniz olsa belə, ölçü vacibdir” adlı təqdimat oldu. Hər şeydən əvvəl, bu yanaşmanı cari və ya gələcək layihələrində istifadə etməyi düşünən bütün tərtibatçılar üçün faydalı olacaq.
Təqdim edir (50 dəqiqə, məqalədən daha çox məlumatlandırıcı), həmçinin mətn şəklində ondan əsas çıxarış.
Qeyd: Video və təqdimat da bu postun sonunda mövcuddur.
Giriş
Adətən yaxşı hekayənin başlanğıcı, əsas süjeti və həlli olur. Bu hesabat daha çox müqəddiməyə bənzəyir, həm də faciəvidir. Onu da qeyd etmək lazımdır ki, o, mikroservislərə kənar baxışı təmin edir. istismar.
Müəllifi (2015-ci ildə) bu qrafikdən başlayacağam Martin Fowler:
Müəyyən bir dəyərə çatan monolit tətbiqi vəziyyətində məhsuldarlığın necə aşağı düşməyə başladığını göstərir. Mikroservislər onunla ilkin məhsuldarlığın aşağı olması ilə fərqlənir, lakin mürəkkəblik artdıqca səmərəliliyin azalması onlar üçün o qədər də nəzərə çarpmır.
Kubernetes-dən istifadə etmək üçün bu qrafikə əlavə edəcəyəm:
Mikroservisləri olan bir proqram niyə daha yaxşıdır? Çünki belə bir memarlıq arxitekturaya ciddi tələblər qoyur ki, bu da öz növbəsində Kubernetes-in imkanları ilə mükəmməl şəkildə əhatə olunur. Digər tərəfdən, bu funksionallığın bəziləri monolit üçün faydalı olacaq, xüsusən də bu gün tipik monolit tam olaraq monolit olmadığı üçün (ətraflı məlumat daha sonra hesabatda veriləcəkdir).
Gördüyünüz kimi, son qrafik (həm monolit, həm də mikroservis proqramları Kubernetes ilə infrastrukturda olduqda) orijinaldan çox da fərqlənmir. Sonra Kubernetes istifadə edərək idarə olunan proqramlar haqqında danışacağıq.
Faydalı və zərərli mikroservislər
Və əsas fikir budur:
nədir normal mikroservis arxitekturası? Bu, işinizin səmərəliliyini artıraraq sizə real fayda gətirməlidir. Qrafikə qayıtsaq, budur:
Əgər ona zəng etsən faydalı, onda qrafikin digər tərəfində olacaq zərərli mikroservislər (işə müdaxilə edir):
“Əsas fikrə” qayıdaq: ümumiyyətlə öz təcrübəmə etibar etməliyəmmi? Bu ilin əvvəlindən baxmışam 85 layihə. Onların hamısı mikroservislər deyildi (onların təxminən üçdə biri belə bir arxitekturaya malik idi), lakin bu, hələ də böyük rəqəmdir. Biz (Flant şirkəti) autsorserlər olaraq həm kiçik şirkətlərdə (5 tərtibatçı ilə), həm də böyük şirkətlərdə (~500 tərtibatçı) hazırlanmış geniş çeşidli proqramları görməyə nail oluruq. Əlavə fayda ondan ibarətdir ki, biz bu tətbiqlərin illər ərzində canlı olduğunu və inkişaf etdiyini görürük.
Niyə mikroservislər?
Mikroservislərin faydaları ilə bağlı sual var artıq qeyd olunan Martin Fowlerdən:
- modulluğun aydın sərhədləri;
- müstəqil yerləşdirmə;
- texnologiyaları seçmək azadlığı.
Mən proqram memarları və tərtibatçıları ilə çox danışdım və mikroservislərə niyə ehtiyac duyduqlarını soruşdum. Və mən onların gözləntilərinin siyahısını hazırladım. Budur, baş verənlər:
Bəzi məqamları “hisslərdə” təsvir etsək, onda:
- modulların aydın sərhədləri: burada dəhşətli bir monolitimiz var və indi hər şey hər şeyin "rəflərdə" olduğu, isti və yumşaqın qarışdırılmadığı Git depolarında səliqəli şəkildə qurulacaq;
- yerləşdirmə müstəqilliyi: inkişafın daha sürətli getməsi üçün xidmətləri müstəqil şəkildə təqdim edə biləcəyik (paralel olaraq yeni funksiyaları dərc edin);
- inkişaf müstəqilliyi: biz bu mikroxidməti bir komandaya/developerə, digərini isə digərinə verə bilərik, bunun sayəsində daha sürətli inkişaf edə bilərik;
- боdaha yüksək etibarlılıq: qismən deqradasiya baş verərsə (20 mikroservisdən biri düşür), onda yalnız bir düymə işləməyi dayandıracaq və bütövlükdə sistem işləməyə davam edəcəkdir.
Tipik (zərərli) mikroservis arxitekturası
Reallığın niyə gözlədiyimiz kimi olmadığını izah etmək üçün təqdim edəcəyəm kollektiv bir çox müxtəlif layihələrin təcrübəsinə əsaslanan mikroservis arxitekturasının təsviri.
Məsələn, Amazon və ya ən azı OZON ilə rəqabət aparacaq mücərrəd onlayn mağaza ola bilər. Onun mikroservis arxitekturası belə görünür:
Müxtəlif səbəblərə görə bu mikroservislər müxtəlif platformalarda yazılır:
Hər bir mikroservis muxtariyyətə malik olmalı olduğundan, onların çoxunun öz verilənlər bazası və önbelleği lazımdır. Son arxitektura aşağıdakı kimidir:
Onun nəticələri nələrdir?
Fowlerdə də bu var — mikroxidmətlərdən istifadə üçün “ödəniş” haqqında:
Və gözləntilərimizin doğru olub-olmadığını görəcəyik.
Modulların sərhədlərini təmizləyin...
Lakin neçə mikroxidməti düzəltməyə ehtiyacımız var?dəyişikliyi yaymaq üçün? Hətta paylanmış izləyici olmadan hər şeyin necə işlədiyini anlaya bilərikmi (hər şeydən sonra, hər hansı bir sorğu mikroservislərin yarısı tərəfindən emal olunur)?
Bir nümunə var "", və burada paylanmış bir kir parçası olduğu ortaya çıxdı. Bunu təsdiqləmək üçün burada sorğuların necə getdiyinin təxmini təsviri verilmişdir:
Yerləşdirmə müstəqilliyi...
Texniki cəhətdən buna nail olunub: biz hər bir mikroservisi ayrıca istifadə edə bilərik. Amma praktikada nəzərə almaq lazımdır ki, o, həmişə yayılır çoxlu mikroservislər, və biz nəzərə almalıyıq onların yayılma qaydası. Yaxşı bir şəkildə, biz ümumiyyətlə buraxılışı düzgün qaydada yaydığımızı ayrı bir dövrədə test etməliyik.
Texnologiya seçmək azadlığı...
Odur. Sadəcə unutmayın ki, azadlıq çox vaxt qanunsuzluqla həmsərhəddir. Burada texnologiyaları sadəcə onlarla “oynamaq” üçün seçməmək çox vacibdir.
İnkişafın müstəqilliyi...
Bütün tətbiq üçün bir test dövrəsini necə etmək olar (bu qədər komponentlə)? Amma yenə də onu yeniləməlisən. Bütün bunlar ona gətirib çıxarır ki sınaq dövrələrinin faktiki sayıprinsipcə ehtiva edə biləcəyimiz, minimal olduğu ortaya çıxır.
Bütün bunları lokal olaraq yerləşdirməyə necə baxırsınız?.. Belə çıxır ki, tərtibatçı çox vaxt öz işini müstəqil, lakin “təsadüfi” yerinə yetirir, çünki o, dövrənin sınaqdan keçməsini gözləmək məcburiyyətində qalır.
Ayrı-ayrı miqyaslama...
Bəli, lakin istifadə olunan DBMS sahəsində məhduddur. Verilmiş memarlıq nümunəsində Cassandra problemi olmayacaq, lakin MySQL və PostgreSQL-də olacaq.
Боdaha yüksək etibarlılıq...
Əslində bir mikroservisin uğursuzluğu tez-tez bütün sistemin düzgün işləməsini pozmur, həm də yeni bir problem var: hər bir mikroservisin xətaya dözümlü olması çox çətindir. Mikroservislər müxtəlif texnologiyalardan (memcache, Redis və s.) istifadə etdiyi üçün hər biri üçün hər şeyi düşünüb həyata keçirməlisən, bu, əlbəttə ki, mümkündür, lakin böyük resurslar tələb edir.
Yük ölçülməsi...
Bu, həqiqətən yaxşıdır.
Mikroservislərin "yüngülliyi"...
Bizdə təkcə böyük deyil şəbəkə yükü (DNS sorğuları çoxalır və s.), həm də başladığımız çoxsaylı alt sorğulara görə məlumatların təkrarlanması (mağaza keşləri), bu da əhəmiyyətli miqdarda saxlama ilə nəticələndi.
Və gözləntilərimizi qarşılamağın nəticəsi budur:
Ancaq bu, hamısı deyil!
Çünki:
- Çox güman ki, bizə mesaj avtobusu lazım olacaq.
- Zamanında düzgün anda ardıcıl ehtiyat nüsxəsini necə etmək olar? yeganə həqiqi seçim bunun üçün trafiki söndürməkdir. Bəs bunu istehsalda necə etmək olar?
- Söhbət bir neçə regionun dəstəklənməsindən gedirsə, onda onların hər birində davamlılığın təşkili çox əmək tələb edən işdir.
- Mərkəzləşdirilmiş dəyişikliklərin edilməsi problemi yaranır. Məsələn, PHP versiyasını yeniləməli olsaq, hər bir repozitoriyaya öhdəlik götürməliyik (və onlardan onlarla var).
- Əməliyyat mürəkkəbliyində artım gözlənilməzdir.
Bütün bunlarla nə etmək lazımdır?
Monolitik bir tətbiq ilə başlayın. Fowlerin təcrübəsi demək olar ki, bütün uğurlu mikroservis tətbiqləri çox böyük olan və sonra qırılan bir monolit kimi başladı. Eyni zamanda, mikroservis kimi qurulan demək olar ki, bütün sistemlər əvvəldən gec-tez ciddi problemlər yaşayırdı.
Başqa bir dəyərli fikir odur ki, mikroservis arxitekturasına malik bir layihənin uğurlu olması üçün siz çox yaxşı bilməlisiniz və mövzu sahəsi və mikroservislərin necə edilməsi. Bir mövzu sahəsini öyrənməyin ən yaxşı yolu monolit etməkdir.
Bəs biz artıq bu vəziyyətdəyiksə necə?
İstənilən problemi həll etmək üçün ilk addım onunla razılaşmaq və bunun problem olduğunu, daha əziyyət çəkmək istəmədiyimizi başa düşməkdir.
Əgər həddindən artıq monolit halında (bunun üçün əlavə resurslar almaq imkanımız tükəndikdə) onu kəsiriksə, bu vəziyyətdə əks hekayə çıxır: həddindən artıq mikroservislər artıq kömək etmir, əksinə mane olur - artıqlığı kəsin və böyüdün!
Məsələn, yuxarıda müzakirə olunan kollektiv görüntü üçün...
Ən şübhəli mikroservislərdən xilas olun:
Frontend istehsalı üçün cavabdeh olan bütün mikroservisləri birləşdirin:
... bir mikroservisə, bir dildə/çərçivədə yazılmış (müasir və normal, sizin fikrinizə görə):
Onun bir ORM (bir DBMS) və əvvəlcə bir neçə tətbiqi olacaq:
... lakin ümumiyyətlə, aşağıdakı nəticəni əldə edərək orada daha çox köçürə bilərsiniz:
Üstəlik, Kubernetes-də biz bütün bunları ayrı-ayrı hallarda işlədirik, bu o deməkdir ki, biz hələ də yükü ölçə və ayrıca miqyaslaya bilərik.
Xülasə
Daha böyük şəklə baxın. Çox vaxt mikroservislərlə bağlı bütün bu problemlər kiminsə öz vəzifəsini yerinə yetirməsi, lakin “mikroservislərlə oynamaq” istəməsi səbəbindən yaranır.
"Mikroservislər" sözündə "mikro" hissəsi lazımsızdır.. Onlar yalnız nəhəng bir monolitdən daha kiçik olduqları üçün "mikro" olurlar. Ancaq onları kiçik bir şey kimi düşünməyin.
Və son fikir üçün orijinal qrafikə qayıdaq:
Üstündə qeyd yazılıb (yuxarı sağ) ki, qaynar layihənizi edən komandanın bacarıqları həmişə əsasdır — onlar mikroservislər və monolit arasında seçiminizdə əsas rol oynayacaqlar. Komanda kifayət qədər bacarıqlara malik deyilsə, lakin mikroservislər etməyə başlayırsa, hekayə mütləq ölümcül olacaq.
Videolar və slaydlar
Çıxışdan video (~50 dəqiqə; təəssüf ki, məruzənin əhval-ruhiyyəsini müəyyən edən ziyarətçilərin çoxsaylı emosiyalarını çatdırmır, amma belədir):
Hesabat təqdimatı:
PS
Bloqumuzdakı digər hesabatlar:
- «» (Dmitri Stolyarov; 28 may 2018-ci il, RootConf-da);
- «» (Dmitri Stolyarov; 7 noyabr 2017-ci il HighLoad++ ilə);
- «» (Dmitri Stolyarov; 6 iyun 2017-ci ildə RootConf-da);
- «» (Dmitri Stolyarov; 8 noyabr 2016-ci il HighLoad++ ilə);
- «» (Dmitri Stolyarov; 31 may 2016-ci il, RootConf-da).
Aşağıdakı nəşrlərlə də maraqlana bilərsiniz:
- «";
- «";
- «.
Mənbə: www.habr.com