Mikroservislər: onlar nədir, niyə və nə vaxt həyata keçirilməlidir

Mən uzun müddət mikroservis arxitekturası mövzusunda məqalə yazmaq istəyirdim, amma iki şey məni dayandırmağa davam etdi - mövzuya getdikcə daha çox mənə elə gəldi ki, bildiklərim göz qabağındadır. t öyrənmək və öyrənmək lazımdır. Digər tərəfdən, düşünürəm ki, artıq geniş auditoriya arasında müzakirə ediləcək bir şey var. Odur ki, alternativ fikirlər xoşdur.

Conway Qanunu və biznes, təşkilat və informasiya sistemi arasındakı əlaqə

Bir daha sitat gətirməyə icazə verirəm:

"Sistem dizayn edən hər hansı bir təşkilat (geniş mənada) strukturu həmin təşkilatdakı komandaların strukturunu təkrarlayan dizayn alacaq."
- Melvin Konvey, 1967

Fikrimcə, bu qanun birbaşa informasiya sisteminə deyil, biznesin təşkilinin məqsədəuyğunluğuna daha çox aiddir. Bir misalla izah edim. Tutaq ki, bizim kifayət qədər sabit iş imkanımız var ki, o qədər uzunömürlülük dövrü var ki, müəssisə təşkil etməyin mənası var (bu yazı səhvi deyil, amma oğurladığım bu termini çox bəyənirəm). Təbii ki, bu biznesin dəstəkləyici sistemi təşkilati və prosessual olaraq bu işə uyğun olacaq.

İnformasiya sistemlərinin biznes yönümlü olması

Mikroservislər: onlar nədir, niyə və nə vaxt həyata keçirilməlidir

Bir misalla izah edim. Tutaq ki, pizza satan bir iş təşkil etmək üçün bir iş imkanı var. V1 versiyasında (gəlin bunu əvvəlcədən məlumat adlandıraq) şirkət pizzacı, kassa aparatı və çatdırılma xidməti idi. Bu versiya ətraf mühitin aşağı dəyişkənliyi şəraitində uzun ömürlü idi. Sonra onu əvəz etmək üçün 2-ci versiya gəldi - daha təkmil və monolit arxitekturaya malik biznes üçün əsas məlumat sistemindən istifadə edə bilir. Və burada, mənim fikrimcə, monolitlərə münasibətdə sadəcə dəhşətli bir ədalətsizlik var - iddia edilən monolit arxitektura domen biznes modelinə uyğun gəlmir. Bəli, belə olsaydı, sistem heç işləyə bilməzdi - eyni Konvey qanunu və sağlam düşüncə ilə ziddiyyət təşkil edir. Xeyr, monolit arxitektura biznesin inkişafının bu mərhələsində biznes modelinə tam uyğundur - mən, əlbəttə ki, sistemin artıq yaradılıb istifadəyə verildiyi mərhələni nəzərdə tuturam. Tamamilə gözəl bir faktdır ki, memarlıq yanaşmasından asılı olmayaraq həm xidmət yönümlü memarlıq versiyası 3, həm də mikroservis memarlıq versiyası N eyni dərəcədə yaxşı işləyəcək. Tutmaq nədir?

Hər şey axır, hər şey dəyişir, yoxsa mikroservislər mürəkkəbliklə mübarizə vasitəsidir?

Davam etməzdən əvvəl mikroservis arxitekturası ilə bağlı bəzi yanlış təsəvvürlərə nəzər salaq.

Mikroservis yanaşmasından istifadənin tərəfdarları tez-tez iddia edirlər ki, monolitin mikroservislərə bölünməsi fərdi xidmətlərin kod bazasını azaltmaqla inkişaf yanaşmasını sadələşdirir. Məncə, bu bəyanat tamamilə cəfəngiyyatdır. Ciddi şəkildə, monolit və homojen kod daxilində aşkar qarşılıqlı əlaqə mürəkkəb görünür? Əgər bu, həqiqətən də belə olsaydı, bütün layihələr əvvəlcə mikroservislər kimi qurulardı, halbuki təcrübə göstərir ki, monolitdən mikroservislərə miqrasiya daha çox yayılmışdır. Mürəkkəblik aradan qalxmır; o, sadəcə olaraq fərdi modullardan interfeyslərə (məlumat avtobusları, RPC, API və ya digər protokollar) və orkestrləşdirmə sistemlərinə keçir. Və bu çətindir!

Heterojen bir yığından istifadənin üstünlüyü də şübhəlidir. Mübahisə etməyəcəyəm ki, bu da mümkündür, amma əslində bu nadir hallarda baş verir (İrəliyə baxanda - bu baş verməlidir - üstünlükdən daha çox nəticə kimi).

Məhsulun həyat dövrü və xidmət müddəti

Yuxarıdakı diaqrama bir daha nəzər salın. Təsadüfi deyil ki, mən biznesin ayrıca versiyasının həyat dövrünün azalmasını qeyd etdim - müasir şəraitdə onun uğuru üçün həlledici olan onun versiyalar arasında keçidinin sürətləndirilməsidir. Məhsulun uğuru onun içindəki biznes fərziyyələrinin sınanma sürəti ilə müəyyən edilir. Və burada, mənim fikrimcə, mikroservis arxitekturasının əsas üstünlüyü var. Amma gəlin qaydada gedək.

Gəlin informasiya sistemlərinin təkamülünün növbəti mərhələsinə - SOA-nın xidmət yönümlü arxitekturasına keçək. Beləliklə, müəyyən bir nöqtədə məhsulumuzda vurğuladıq uzunömürlü xidmətlər - uzunömürlülük o mənada ki, məhsulun versiyaları arasında keçid zamanı xidmətin həyat dövrünün məhsulun növbəti versiyasının həyat dövründən daha uzun olması şansı var. Onları heç dəyişməmək məntiqli olardı - biz Önəmli olan növbəti versiyaya keçid sürətidir. Ancaq təəssüf ki, biz xidmətlərdə daimi dəyişikliklər etmək məcburiyyətindəyik - və burada hər şey bizim üçün işləyir, DevOps təcrübələri, konteynerləşdirmə və s. - ağla gələn hər şey. Ancaq bunlar hələ də mikroservislər deyil!

Mikroservislər mürəkkəbliklə mübarizə vasitəsi kimi... konfiqurasiyanın idarə edilməsi

Və burada nəhayət, mikroservislərin müəyyənedici roluna keçə bilərik - bu, məhsulun konfiqurasiyasının idarə edilməsini asanlaşdıran yanaşmadır. Daha ətraflı desək, hər bir mikroservisin funksiyası domen modelinə uyğun olaraq məhsulun daxilindəki biznes funksiyasını dəqiq təsvir edir - və bunlar qısa müddətli versiyada deyil, uzunmüddətli biznes imkanında yaşayan şeylərdir. Və məhsulun növbəti versiyasına keçid sözün əsl mənasında gözədəyməz baş verir - siz bir mikroservisi və bəlkə də sadəcə onların qarşılıqlı əlaqə sxemini dəyişdirirsiniz/əlavə edirsiniz və birdən özünüzü gələcəkdə taparsınız və versiyalar arasında keçidi davam etdirən ağlayan rəqibləri geridə qoyursunuz. onların monolitləri. İndi təsəvvür edin ki, əvvəlcədən müəyyən edilmiş interfeyslər və biznes imkanları olan kifayət qədər böyük həcmdə mikroservislər mövcuddur. Siz isə gəlib hazır mikroservislərdən öz məhsulunuzun strukturunu qurursunuz - sadəcə olaraq, məsələn, diaqram çəkərək. Təbrik edirik - bir platformanız var - və indi özünüz üçün biznes cəlb edə bilərsiniz. Xəyallar Xəyallar.

Tapıntılar

  • Sistemin arxitekturası onun komponentlərinin həyat dövrü ilə müəyyən edilməlidir. Komponent məhsul versiyası daxilində yaşayırsa, mikroservis yanaşmasından istifadə edərək sistemin mürəkkəbliyini artırmağın mənası yoxdur.
  • Mikroservis arxitekturası domen modelinə əsaslanmalıdır - çünki biznes imkanı ən uzunömürlü domendir
  • Çatdırılma təcrübələri (DevOps təcrübələri) və orkestrləşdirmə mikroservis arxitekturası üçün ən vaciblərdən biridir - ona görə ki, komponentlərin dəyişmə sürətinin artması çatdırılmanın sürətinə və keyfiyyətinə artan tələblər qoyur.

Mənbə: www.habr.com

Добавить комментарий