Mikroservis arxitekturası haqqında bir müddətdir yazmaq istəyirdim, amma iki şey mənim fikrimi yayındırırdı — mövzuya daldıqca düşündüm ki, bildiyim şeylər açıqdır, bilmədiyim şeylər isə hələ öyrənməyə ehtiyac var. Digər tərəfdən, artıq müzakirə edə biləcəyim mövzuların olduğunu düşünürəm. Beləliklə, alternativ fikirlər qəbul edilir.
Conway qanunu və biznes, təşkilat və informasiya sistemi arasındakı əlaqə
Bir daha özümü sitat gətirməyə icazə verərəm:
«Hər hansı bir təşkilat, hansısa bir sistemi (geniş mənada) dizayn edən zaman, onun dizaynı həmin təşkilatdakı komandaların strukturunu təkrarlayacaq»
— Melvyn Conway, 1967
Mənim fikrimcə, bu qanun daha çox biznesin təşkilatlanma məqsədinə aiddir, birbaşa informasiya sisteminə deyil. Məsələn, belə izah edim. Təsəvvür edin ki, kifayət qədər sabit bir iş imkanı var, onun dövrü o qədər uzundur ki, müəssisəni təşkil etmək məntiqli olar (bu, səhv yazma deyil, amma bu termini öz üzərimə götürdüm). Əlbəttə ki, bu biznes üçün dəstək verən sistem bu biznesə uyğun şəkildə təşkilati və proses baxımından uyğun olmalıdır.
İnformasiya sistemlərinin biznes yönümlülüyü
Bir daha belə izah edim. Təsəvvür edin ki, pizanın satışı üçün bir iş imkanımız var. V1 versiyasında (biz onu informasiyadan əvvəlki versiya adlandıraq) şirkət pizzariya, kassir və çatdırılma xidmətindən ibarət idi. Bu versiya, ətraf mühitin aşağı dəyişkənliyi şəraitində uzun ömürlü idi. Sonra isə versiya 2 gəldi - daha irəlidə və monolit arxitekturası əsasında iş üçün informasiya sistemini istifadə etməyə qadir olan. Və burada, mənim fikrimcə, monolitlərə qarşı sadəcə dəhşətli bir ədalətsizlik ortaya çıxır — göydəki monolit arxitekturasının biznesin domen modelinə uyğun gəlmədiyi. Əgər belə olsaydı, sistem ümumiyyətlə işləməzdi - eyni Conway qanununa və sağlam düşüncəyə zidd. Xeyr, monolit arxitekturası tam şəkildə biznes inkişafın bu mərhələsində biznes modelinə uyğundur — əlbəttə ki, sistem artıq yaradılıb və istifadəyə verilib. Möhkəm bir fakt odur ki, arxitektura yanaşmasından asılı olmayaraq, xidmətə yönəldilmiş arxitektura versiya 3 və mikroservis arxitekturası versiya N eyni dərəcədə yaxşı işləyəcək. Harada maneə var?
Hər şey axır, hər şey dəyişir, yoxsa mikroservislər – mürəkkəbliyin öhdəsindən gəlmək üçün bir vasitədir?
Davam etmədən əvvəl, mikroservis arxitekturası ilə bağlı bəzi yanlış anlayışları nəzərdən keçirək.
Mikroservis yanaşmasının tərəfdarları tez-tez deyirlər ki, monolitin mikroservislərə bölünməsi inkişaf prosesini asanlaşdırır, çünki ayrı-ayrı servislərin kod bazası azalır. Mənim fikrimcə, bu iddia tamamilə absurdur. Ciddi deyirəm, monolit və homojen kod arasındakı görünən qarşılıqlı təsir çətindir? Əgər bu doğrudan belə olsaydı, bütün layihələr əvvəldən mikroservislər kimi qurulardı, lakin təcrübə göstərir ki, monolitdən mikroservislərə keçid daha yaygındır. Çətinlik yoxdur, o, sadəcə ayrı modullardan interfeyslərə (data şinləri, RPC, API və digər protokollar olsun) və orkestrasiya sistemlərinə keçir. Və bu — çətindir!
Heterogen stək istifadə etmənin üstünlüyü də şübhəlidir. Bunun mümkün olduğunu inkar etmirəm, lakin reallıqda nadir hallarda qarşılaşılır (Qısa qeyd - bu baş verməlidir - lakin daha çox nəticə kimi, üstünlükdən daha az).
Məhsulun həyat dövrü və xidmətin həyat dövrü
Yuxarıdakı diaqramı bir daha nəzərdən keçirin. Ayrı versiya biznesinin azalan həyat dövrünü təsadüfən qeyd etmədim - müasir şəraitdə biznesin versiyalar arasında sürətli keçidi onun müvəffəqiyyətini müəyyən edən amildir. Məhsulun müvəffəqiyyəti onun içindəki biznes hipotezlərinin yoxlanma sürəti ilə müəyyən edilir. Və burada mənim fikrimcə mikroservis memarlığının əsas üstünlüyü gizlənir. Amma ardıcıllıqla davam edək.
İnformasiya sistemlərinin növbəti inkişaf mərhələsinə — xidmət yönümlü memarlıq SOA-ya keçək. Beləliklə, müəyyən bir anda biz məhsulumuzda uzunömürlü xidmətləri müəyyən etdik — uzunömürlü, çünki məhsulun versiyaları arasında keçid edərkən xidmətin həyat dövrünün, məhsulun növbəti versiyasının həyat dövründən daha uzun olma ehtimalı var. Onları heç dəyişməmək məntiqlidir — biz növbəti versiyaya keçid sürətinə xüsusi diqqət yetiririk. Ancaq təəssüf ki, biz xidmətlərdə davamlı dəyişikliklər etməyə məcburuq — burada bizə DevOps təcrübələri, konteynerləşdirmə və başqaları lazımdır — ağlımıza gələn hər şey. Amma bu hələ də mikroservislər deyil!
Mikroservislər mürəkkəbliyi idarə etmənin bir vasitəsi kimi... konfiqurasiyanı idarə etmək
Və burada mikroservislərin müəyyənedici roluna keçmək imkanımız yaranır — bu, məhsulun konfiqurasiyasının idarə edilməsini sadələşdirən bir yanaşmadır. Daha ətraflı desək, hər bir mikroservisin funksiyası məhsul daxilindəki iş funksiyasını domen modelinə uyğun olaraq təsvir edir — bu da artıq qısa müddətli versiyalarda yaşamayan, əksinə uzun müddətli biznes imkanı olan şeylərdir. Və növbəti məhsul versiyasına keçid tam olaraq həssas şəkildə baş verir — siz bir mikroservisi dəyişdirirsiniz/əlavə edirsiniz, ya da bəlkə onların qarşılıqlı təsir sxemini sadəcə dəyişirsiniz və qəfildən gələcəyinizdə olursunuz, arxada ağlayan rəqiblərinizi buraxaraq, monolitlərinin versiyaları arasında sıçrayış etməyə davam edirlər. İndi təsəvvür edin ki, əvvəlcədən təyin edilmiş interfeysləri və iş imkanlarını olan kifayət qədər böyük mikroservis topluluğu var. Və siz gəlib məhsulunuzun strukturunu hazır mikroservislərdən qurursunuz — sadəcə, məsələn, diaqram çəkməklə. Təbriq edirəm — artıq sizin platformanız var — və indi siz öz biznesinizi yarada bilərsiniz. Xəyallar, xəyallar.
Sonuçlar
- Sistem arxitekturası onun tərkib hissələrinin həyat dövrü ilə müəyyən edilməlidir. Əgər komponent məhsulun versiyası çərçivəsində yaşasa — mikroservis yanaşmasını tətbiq edərək sistemin mürəkkəbliyini artırmaq mənasızdır.
- Mikroservis arxitekturası domen modelinə əsaslanmalıdır — çünki iş imkanı ən uzunömürlü sahədir.
- Çatdırılma praktikaları (DevOps praktikaları) və orkestrasiya mikroservis arxitekturası üçün ən mühüm əhəmiyyətə malikdir — çünki komponentlərin dəyişmə sürətinin artması, çatdırılma sürəti və keyfiyyətinə olan tələbləri artırır.
Mənbə: habr.com
