Salam, habr. Yeni kurs axını üçün qeydiyyat hazırda OTUS-da açıqdır . Kursun başlaması ərəfəsində orijinal məqaləmi sizinlə bölüşmək istəyirəm.
Giriş
Memarlıq üslubunun seçimi informasiya sisteminin qurulması zamanı əsas texniki qərarlardan biridir. Bu məqalələr silsiləsində mən tikinti tətbiqləri üçün ən populyar memarlıq üslublarını təhlil etməyi və hansı memarlıq üslubunun nə vaxt daha çox üstünlük verdiyi sualına cavab verməyi təklif edirəm. Təqdimat prosesində monolitlərdən mikroservislərə qədər memarlıq üslublarının inkişafını izah edən məntiqi zəncir çəkməyə çalışacağam.
Bir az tarixi
Tərtibatçılardan soruşmağa çalışsanız: “Bizə mikroservislər niyə lazımdır?”, müxtəlif cavablar alacaqsınız. Mikroservislərin genişlənmə qabiliyyətini yaxşılaşdırdığını, kodun başa düşülməsini asanlaşdırdığını, nasazlığa dözümlülüyünü yaxşılaşdırdığını və bəzən onların "kodunuzu təmizləməyə" icazə verdiyini eşidəcəksiniz. Mikroservislərin yaranmasının arxasında duran məqsədi anlamaq üçün tarixə nəzər salaq.
Bir sözlə, mövcud anlayışımızda mikroservislər belə yaranmışdır: 2011-ci ildə Ceyms Lyuis müxtəlif şirkətlərin işini təhlil edərək, SOA-nın tətbiqini sürətləndirmək baxımından optimallaşdıran yeni “mikro proqram” modelinin meydana çıxmasına diqqət çəkdi. xidmətlər. Bir qədər sonra, 2012-ci ildə bir memarlıq sammitində nümunə mikroservis adlandırıldı. Beləliklə, mikroservislərin tətbiqinin ilkin məqsədi bədnam xidmətin təkmilləşdirilməsi idi bazar vaxtı.
Mikroservislər 2015-ci ildə şırınga dalğasında idi. Bəzi araşdırmalara görə, heç bir konfrans mikroservislər mövzusunda hesabat olmadan tamamlanmadı. Üstəlik, bəzi konfranslar yalnız mikroservislərə həsr olunmuşdu. Hal-hazırda, bir çox layihələr bu memarlıq üslubundan istifadə etməyə başlayır və əgər layihədə tonlarla köhnə kodlar varsa, o zaman mikroservislərə miqrasiya çox güman ki, aktiv şəkildə həyata keçirilir.
Yuxarıda göstərilənlərin hamısına baxmayaraq, kifayət qədər az sayda tərtibatçı hələ də "mikroservis" anlayışını müəyyən edə bilər. Amma bu haqda bir az sonra danışacağıq...
Monolit
Mikroservislərə zidd olan memarlıq üslubu monolitdir (və ya hamısı bir yerdə). Yəqin ki, monolitin nə olduğunu söyləmək mənasızdır, buna görə də mən dərhal memarlıq üslublarının daha da inkişafına səbəb olan bu memarlıq üslubunun çatışmazlıqlarını sadalayacağam: ölçü, əlaqə, yerləşdirmə, miqyaslılıq, etibarlılıq və sərtlik. Aşağıda çatışmazlıqların hər birinə ayrıca nəzər salmağı təklif edirəm.
boy
Monolit çox böyükdür. Və adətən çox böyük verilənlər bazası ilə əlaqə saxlayır. Tətbiq bir tərtibatçının ümumiyyətlə başa düşməsi üçün çox böyük olur. Yalnız bu kod üzərində işləməyə çox vaxt sərf edənlər monolitlə yaxşı işləyə bilər, yeni başlayanlar isə monoliti anlamağa çox vaxt sərf edəcəklər və onların bunu başa düşəcəyinə zəmanət yoxdur. Adətən, monolitlə işləyərkən həmişə monoliti az-çox yaxşı bilən və bir il yarım ərzində digər yeni tərtibatçıların əlini döyən bəzi “şərti” böyüklər olur. Təbii ki, belə bir şərti yaşlı tək bir uğursuzluq nöqtəsidir və onun gedişi monolitin ölümünə səbəb ola bilər.
Bağlılıq
Monolit "böyük palçıq topu"dur, dəyişikliklər gözlənilməz nəticələrə səbəb ola bilər. Bir yerdə dəyişiklik etməklə, başqa bir yerdə monolitə zərər verə bilərsiniz (eyni "qulağınızı cızdınız, *@ düşdü"). Bu, monolitdəki komponentlərin çox mürəkkəb və ən əsası qeyri-aşkar əlaqələrə malik olması ilə bağlıdır.
Yerləşdirmə
Monolitin yerləşdirilməsi, onun komponentləri arasındakı mürəkkəb əlaqələrə görə, öz ritualı olan uzun bir prosesdir. Belə bir ritual adətən tamamilə standartlaşdırılmır və “şifahi olaraq” ötürülür.
Ölçeklenebilirlik
Monolit modulların bir-birinə zidd olan resurs ehtiyacları ola bilər, bu da aparat baxımından güzəştə getməyi tələb edir. Təsəvvür edin ki, sizdə A və B xidmətlərindən ibarət monolit var. Xidmət A sabit diskin ölçüsünü, B xidməti isə RAM tələb edir. Bu halda, ya monolitin quraşdırıldığı maşın hər iki xidmətin tələblərini dəstəkləməlidir, ya da xidmətlərdən birini əl ilə, süni şəkildə söndürməli olacaqsınız.
Başqa bir misal (daha klassik): A xidməti B xidmətindən daha populyardır, ona görə də siz 100 xidmət A və 10 xidmət B olmasını istəyirsiniz. Yenə də iki seçim: ya 100 tam hüquqlu monolit yerləşdiririk, ya da bəzilərində sonra B xidmətləri əl ilə söndürülməlidir.
Etibarlılıq
Bütün xidmətlər bir yerdə yerləşdiyindən, monolit düşürsə, bütün xidmətlər bir anda düşür. Əslində bu o qədər də pis olmaya bilər, ən azı paylanmış sistemdə qismən nasazlıqlar olmayacaq, lakin digər tərəfdən istifadəçilərin 0.001%-nin istifadə etdiyi funksionallıq səhvinə görə bütün istifadəçiləri itirə bilərsiniz. sisteminizin.
Ətalət
Monolitin ölçüsünə görə yeni texnologiyalara keçmək çətindir. Nəticə etibarı ilə, həmin yaşlı işçini saxlamaq ayrı bir vəzifədir. Layihənin başlanğıcında seçilmiş texnologiya yığını məhsulun inkişafına mane olan bloka çevrilə bilər.
Nəticə
Növbəti dəfə biz insanların komponentlərə və SOA-ya keçməklə bu problemləri necə həll etməyə çalışdıqları barədə danışacağıq.
Daha çox oxu:
Mənbə: www.habr.com