Siz monolitinizi mikroservislərdə yenidən dizayn etmək üçün aylar sərf etdiniz və nəhayət, keçidi çevirmək üçün hamı bir araya gəldi. Siz ilk internet səhifəsinə daxil olursunuz... və heç nə baş vermir. Siz onu yenidən yükləyin - və yenə də yaxşı bir şey yoxdur, sayt o qədər yavaşdır ki, bir neçə dəqiqə cavab vermir. Nə olub?
Çıxışında Cimmi Boqard real həyatda baş verən mikroservis fəlakəti ilə bağlı “post-mortem” aparacaq. O, kəşf etdiyi modelləşdirmə, inkişaf və istehsal problemlərini və komandasının yavaş-yavaş yeni paylanmış monoliti ağlın son mənzərəsinə necə çevirdiyini göstərəcək. Dizayn səhvlərinin qarşısını tamamilə almaq mümkün olmasa da, son məhsulun etibarlı paylanmış sistemə çevrilməsini təmin etmək üçün ən azı dizayn prosesinin əvvəlində problemləri müəyyən edə bilərsiniz.
Hər kəsə salam, mən Cimmi və bu gün siz mikroservislər qurarkən meqa fəlakətlərdən necə qaça biləcəyinizi eşidəcəksiniz. Bu, gəmisinin aysberqlə toqquşmasının qarşısını almaq üçün təxminən bir il yarım işlədiyim bir şirkətin hekayəsidir. Bu hekayəni düzgün izah etmək üçün keçmişə qayıtmalı və bu şirkətin harada başladığı və zamanla İT infrastrukturunun necə böyüdüyü barədə danışmalıyıq. Bu fəlakətdə günahsız olanların adlarını qorumaq üçün bu şirkətin adını Bell Computers olaraq dəyişdirdim. Növbəti slayd 90-cı illərin ortalarında belə şirkətlərin İT infrastrukturunun necə göründüyünü göstərir. Bu, kompüter avadanlıqları mağazasını idarə etmək üçün böyük universal nasazlığa davamlı HP Tandem Mainframe serverinin tipik arxitekturasıdır.
Onlara bütün sifarişləri, satışları, gəlirləri, məhsul kataloqlarını və müştəri bazasını idarə etmək üçün bir sistem qurmalı idilər, ona görə də o dövrdə ən çox yayılmış mainframe həllini seçdilər. Bu nəhəng sistem şirkət haqqında hər bir məlumatı, mümkün olan hər şeyi ehtiva edirdi və hər bir əməliyyat bu meynframe vasitəsilə həyata keçirilirdi. Bütün yumurtalarını bir səbətdə saxlayırdılar və bunun normal olduğunu düşünürdülər. Buraya daxil olmayan yeganə şey poçt sifarişi kataloqları və telefonla sifariş verməkdir.
Zaman keçdikcə sistem böyüdü və böyüdü və orada çoxlu miqdarda zibil yığıldı. Həmçinin, COBOL dünyanın ən ifadəli dili deyil, ona görə də sistem böyük, monolit bir zibil parçasına çevrildi. 2000-ci ilə qədər onlar gördülər ki, bir çox şirkətlər tamamilə bütün işlərini apardıqları veb-saytlara malikdirlər və ilk kommersiya dot-com veb-saytlarını yaratmağa qərar verdilər.
İlkin dizayn olduqca gözəl görünürdü və yüksək səviyyəli bell.com saytından və fərdi proqramlar üçün bir sıra alt domenlərdən ibarət idi: catalog.bell.com, accounts.bell.com, orders.bell.com, məhsul axtarışı.bell. com. Hər bir subdomen ASP.Net 1.0 çərçivəsindən və öz verilənlər bazasından istifadə edirdi və onların hamısı sistemin arxa hissəsi ilə danışırdılar. Bununla belə, bütün sifarişlər bütün zibilin qaldığı tək nəhəng əsas çərçivədə işlənməyə və icra olunmağa davam etdi, lakin ön tərəf fərdi proqramlar və ayrıca verilənlər bazası olan ayrı veb-saytlar idi.
Beləliklə, sistemin dizaynı nizamlı və məntiqli görünürdü, lakin faktiki sistem növbəti slaydda göstərildiyi kimi idi.
Bütün elementlər bir-birinə zənglər ünvanlayır, API-lərə daxil olur, daxil edilmiş üçüncü tərəf DLL-ləri və s. Çox vaxt belə olurdu ki, versiyaya nəzarət sistemləri başqasının kodunu tutur, onu layihənin içərisinə itələyir və sonra hər şey pozulurdu. MS SQL Server 2005 keçid serverləri konsepsiyasından istifadə etdi və slaydda oxları göstərməsəm də, verilənlər bazalarının hər biri də bir-biri ilə danışırdı, çünki bir neçə verilənlər bazasından əldə edilən məlumatlar əsasında cədvəllər qurmaqda heç bir problem yoxdur.
Onların indi sistemin müxtəlif məntiqi sahələri arasında müəyyən qədər ayrılması olduğundan, bu, paylanmış kir ləkələrinə çevrildi və ən böyük zibil parçası hələ də əsas çərçivənin arxa hissəsində qalır.
Gülməlisi o idi ki, bu meynfreym Bell Computers-in rəqibləri tərəfindən qurulmuşdu və hələ də onların texniki məsləhətçiləri tərəfindən saxlanılırdı. Tətbiqlərinin qeyri-qənaətbəxş işləməsinə əmin olan şirkət onlardan qurtulmaq və sistemi yenidən dizayn etmək qərarına gəlib.
Mövcud proqram 15 ildir istehsalda olub ki, bu da ASP.Net əsaslı proqramlar üçün rekorddur. Xidmət dünyanın hər yerindən sifarişləri qəbul etdi və bu tək tətbiqdən illik gəlir bir milyard dollara çatdı. Mənfəətin əhəmiyyətli bir hissəsi bell.com saytı tərəfindən yaradılıb. Qara Cümə günlərində sayt vasitəsilə verilən sifarişlərin sayı bir neçə milyona çatırdı. Bununla belə, mövcud arxitektura heç bir inkişafa imkan vermədi, çünki sistem elementlərinin sərt qarşılıqlı əlaqəsi praktiki olaraq xidmətdə heç bir dəyişiklik etməyə imkan vermədi.
Ən ciddi problem, qlobal şirkətlərdə belə ticarət sxeminin çox yaygın olmasına baxmayaraq, bir ölkədən sifariş vermək, onun haqqını başqa ölkədə ödəmək və üçüncü ölkəyə göndərmək mümkün deyildi. Mövcud internet saytı belə bir şeyə icazə vermədiyi üçün onlar bu sifarişləri telefonla qəbul edib yerləşdirməli idilər. Bu, şirkətin arxitekturasını dəyişdirmək, xüsusən də mikroservislərə keçmək barədə getdikcə daha çox düşünməsinə səbəb oldu.
Bənzər bir problemi necə həll etdiklərini görmək üçün digər şirkətlərə baxaraq ağıllı bir şey etdilər. Bu həllərdən biri API və xarici verilənlər bazası vasitəsilə birləşdirilən mikroservislərdən ibarət Netflix xidmət arxitekturası idi.
Bell Computers rəhbərliyi müəyyən əsas prinsiplərə riayət edərək məhz belə bir arxitektura qurmaq qərarına gəldi. Birincisi, ortaq verilənlər bazası yanaşmasından istifadə edərək məlumatların təkrarlanmasının qarşısını aldılar. Heç bir məlumat göndərilmədi, əksinə, ehtiyacı olan hər kəs mərkəzləşdirilmiş mənbəyə getməli idi. Bunun ardınca təcrid və muxtariyyət gəldi - hər bir xidmət digərlərindən müstəqil idi. Onlar tamamilə hər şey üçün Web API-dən istifadə etmək qərarına gəldilər - məlumat əldə etmək və ya başqa sistemə dəyişiklik etmək istəyirsinizsə, hamısı Web API vasitəsilə edildi. Sonuncu böyük şey, rəqiblərin aparatına əsaslanan "Bell" meynfreymindən fərqli olaraq "Bell on Bell" adlı yeni meynfreym idi.
Beləliklə, 18 ay ərzində onlar sistemi bu əsas prinsiplər ətrafında qurdular və onu istehsaldan əvvəlki vəziyyətə gətirdilər. Həftəsonundan sonra işə qayıdan tərtibatçılar bir araya gələrək yeni sistemin qoşulduğu bütün serverləri işə saldılar. 18 aylıq iş, yüzlərlə tərtibatçı, ən müasir Bell aparatı - və heç bir müsbət nəticə yoxdur! Bu, bir çox insanı məyus etdi, çünki onlar bu sistemi öz noutbuklarında dəfələrlə işlədiblər və hər şey qaydasında idi.
Bütün pullarını bu problemin həllinə sərf etməkdə ağıllı idilər. Onlar açarları olan ən müasir server rəflərini quraşdırdılar, gigabit optik lifdən, dəli miqdarda operativ yaddaşa malik ən güclü server avadanlığından istifadə etdilər, hamısını birləşdirdilər, konfiqurasiya etdilər - və yenə də heç nə! Sonra səbəbin fasilələr ola biləcəyindən şübhələnməyə başladılar, buna görə də bütün veb parametrlərinə, bütün API parametrlərinə daxil oldular və bütün vaxt aşımı konfiqurasiyasını maksimum dəyərlərə yenilədilər, beləliklə, onların edə biləcəyi yeganə şey oturub nəyinsə baş verməsini gözləmək idi. sayta. Veb sayt nəhayət yüklənənə qədər gözlədilər və gözlədilər və 9 dəqiqə yarım gözlədilər.
Bundan sonra onların ağlına gəldi ki, mövcud vəziyyət hərtərəfli təhlil edilməlidir və bizi dəvət etdilər. İlk aşkar etdiyimiz şey o oldu ki, bütün 18 aylıq inkişaf ərzində heç bir real "mikro" yaradılmadı - hər şey daha da böyüdü. Bundan sonra biz fəlakətin səbəbini anlamaq üçün “beyin fırtınası”na bənzər “günah fırtınası” kimi də tanınan “reqretrospektiv” və ya “kədərli retrospektiv” kimi tanınan postmortem yazmağa başladıq.
Bir neçə ipucumuz var idi, onlardan biri API çağırışı zamanı trafikin tam doyması idi. Monolit xidmət arxitekturasından istifadə etdiyiniz zaman, nəyin səhv getdiyini dərhal anlaya bilərsiniz, çünki sizdə uğursuzluğa səbəb ola biləcək hər şeyi bildirən tək yığın izi var. Bir dəstə xidmətin eyni vaxtda eyni API-yə daxil olduğu halda, WireShark kimi əlavə şəbəkə monitorinq alətlərindən istifadə etməkdən başqa izi izləmək üçün heç bir yol yoxdur, bunun sayəsində tək bir sorğunu yoxlaya və onun həyata keçirilməsi zamanı nə baş verdiyini öyrənə bilərsiniz. Beləliklə, biz bir veb səhifə götürdük və tapmacanın hissələrini bir araya gətirmək, ona müxtəlif zənglər etmək və onların hər birinin nəyə gətirib çıxardığını təhlil etmək üçün demək olar ki, 2 həftə sərf etdik.
Bu şəkilə baxın. Bu göstərir ki, bir xarici sorğu xidməti geri qayıdan bir çox daxili zənglər etməyə sövq edir. Məlum olub ki, hər bir daxili zəng bu sorğuya müstəqil şəkildə xidmət göstərmək üçün əlavə sıçrayışlar edir, çünki lazımi məlumatları əldə etmək üçün başqa yerə müraciət edə bilmir. Bu şəkil mənasız zənglər kaskadına bənzəyir, çünki xarici sorğu əlavə xidmətlər çağırır, onlar digər əlavə xidmətlər çağırır və s. demək olar ki, sonsuzdur.
Bu diaqramdakı yaşıl rəng xidmətlərin bir-birini çağırdığı yarımdairəni göstərir - A xidməti B xidmətinə, B xidməti C xidmətinə zəng edir və yenidən A xidmətinə zəng edir.Nəticədə "paylanmış dalana dirəniş" alırıq. Tək sorğu min şəbəkə API çağırışı yaratdı və sistemdə daxili nasazlığa dözümlülük və loop mühafizəsi olmadığı üçün bu API çağırışlarından biri də uğursuz olarsa, sorğu uğursuz olardı.
Bir az riyaziyyat etdik. Hər bir API çağırışında 150 ms-dən çox olmayan SLA və 99,9% iş vaxtı var idi. Bir sorğu 200 müxtəlif zəngə səbəb oldu və ən yaxşı halda səhifə 200 x 150 ms = 30 saniyə ərzində göstərilə bilərdi. Təbii ki, bu yaxşı deyildi. 99,9% iş vaxtını 200-ə vuraraq, 0% əlçatanlıq əldə etdik. Belə çıxır ki, bu memarlıq əvvəldən uğursuzluğa məhkum olub.
Tərtibatçılardan 18 aylıq işdən sonra bu problemi necə tanıya bilmədiklərini soruşduq? Məlum oldu ki, onlar yalnız işlətdikləri kod üçün SLA-nı hesablayıblar, lakin onların xidməti başqa xidmətə zəng edibsə, onlar SLA-da həmin vaxtı saymayıblar. Bir proses daxilində işə salınan hər şey 150 ms dəyərinə riayət etdi, lakin digər xidmət proseslərinə giriş ümumi gecikməni dəfələrlə artırdı. Öyrənilən ilk dərs bu idi: "SLA-ya siz nəzarət edirsiniz, yoxsa SLA sizə nəzarət edir?" Bizim vəziyyətimizdə bu, sonuncu idi.
Kəşf etdiyimiz növbəti şey o idi ki, onlar Peter Deitch və James Gosling tərəfindən tərtib edilmiş paylanmış hesablama səhv anlayışları haqqında bilirdilər, lakin onun birinci hissəsinə məhəl qoymadılar. Orada bildirilir ki, “şəbəkə etibarlıdır”, “sıfır gecikmə” və “sonsuz ötürmə qabiliyyəti” ifadələri yanlış fikirdir. Digər yanlış təsəvvürlərə “şəbəkə təhlükəsizdir”, “topologiya heç vaxt dəyişmir”, “həmişə yalnız bir idarəçi var”, “məlumatların ötürülməsinin dəyəri sıfırdır” və “şəbəkə bircinslidir” ifadələri daxildir.
Xidmətlərini yerli maşınlarda sınaqdan keçirdikləri və heç vaxt xarici xidmətlərə qoşulmadığı üçün səhv etdilər. Yerli olaraq inkişaf etdirərkən və yerli keşdən istifadə edərkən, heç vaxt şəbəkə atlamaları ilə qarşılaşmadılar. Bütün 18 aylıq inkişafda onlar heç vaxt xarici xidmətlərin təsirinə məruz qaldıqda nə baş verə biləcəyini düşünməyiblər.
Əvvəlki şəkildəki xidmət sərhədlərinə baxsanız, onların hamısının səhv olduğunu görə bilərsiniz. Xidmət sərhədlərini necə müəyyənləşdirmək barədə məsləhət verən çoxlu mənbələr var və əksəriyyəti növbəti slaydda Microsoft kimi səhv edir.
Bu şəkil “Mikroservisləri necə qurmaq olar” mövzusundakı MS bloqundandır. Bu, sadə veb tətbiqini, biznes məntiqi blokunu və verilənlər bazasını göstərir. Sorğu birbaşa gəlir, ehtimal ki, veb üçün bir server, biznes üçün bir server və verilənlər bazası üçün bir server var. Əgər trafiki artırsanız, şəkil bir az dəyişəcək.
Burada trafiki iki veb server arasında paylamaq üçün yük balanslaşdırıcısı, veb xidməti ilə biznes məntiqi arasında yerləşən keş və biznes məntiqi ilə verilənlər bazası arasında başqa bir keş gəlir. Bu, Bell-in 2000-ci illərin ortalarında yük balansı və mavi/yaşıl yerləşdirmə tətbiqi üçün istifadə etdiyi memarlıqdır. Bir müddətə qədər hər şey yaxşı işləyirdi, çünki bu sxem monolit bir quruluş üçün nəzərdə tutulmuşdu.
Aşağıdakı şəkil MS-nin monolitdən mikroservislərə necə keçməyi tövsiyə etdiyini göstərir - sadəcə olaraq əsas xidmətlərin hər birini ayrıca mikroservislərə bölmək. Məhz bu sxemin həyata keçirilməsi zamanı Bell səhvə yol verdi.
Bütün xidmətlərini müxtəlif səviyyələrə böldülər, hər biri bir çox fərdi xidmətlərdən ibarət idi. Məsələn, veb-xidmətə məzmunun göstərilməsi və autentifikasiyası üçün mikroservislər, biznes məntiqi xidməti sifarişlərin və hesab məlumatlarının emalı üçün mikroservislərdən ibarət idi, verilənlər bazası ixtisaslaşdırılmış verilənlərə malik mikroservislər dəstəsinə bölündü. Həm internet, həm biznes məntiqi, həm də verilənlər bazası vətəndaşlığı olmayan xidmətlər idi.
Bununla belə, bu şəkil tamamilə yanlış idi, çünki o, şirkətin İT klasterindən kənarda heç bir biznes bölməsini əks etdirmirdi. Bu sxem xarici dünya ilə heç bir əlaqəni nəzərə almadı, buna görə də, məsələn, üçüncü tərəfin biznes analitikasını necə əldə etmək aydın deyildi. Qeyd edim ki, onlar da sadəcə olaraq, bunun üçün daha çox pul qazanmaq üçün mümkün qədər çox insanı idarə etməyə çalışan fərdi işçilərin karyeralarını inkişaf etdirmək üçün bir neçə xidmət icad ediblər.
Onlar inanırdılar ki, mikroservislərə keçmək onların daxili N səviyyəli fiziki təbəqə infrastrukturunu götürmək və Docker-i ona yapışdırmaq qədər asandır. Ənənəvi N səviyyəli arxitekturanın necə göründüyünə nəzər salaq.
O, 4 səviyyədən ibarətdir: UI istifadəçi interfeysi səviyyəsi, biznes məntiqi səviyyəsi, məlumatlara giriş səviyyəsi və verilənlər bazası. Daha mütərəqqi DDD (Domain-Driven Design) və ya proqram yönümlü arxitekturadır, burada iki orta səviyyə domen obyektləri və depodur.
Bu arxitekturada müxtəlif dəyişikliyə, fərqli məsuliyyət sahələrinə baxmağa çalışdım. Tipik bir N səviyyəli tətbiqdə quruluşa yuxarıdan aşağıya doğru şaquli olaraq nüfuz edən müxtəlif dəyişiklik sahələri təsnif edilir. Bunlar Kataloq, fərdi kompüterlərdə yerinə yetirilən konfiqurasiya parametrləri və komandam tərəfindən idarə olunan Checkout yoxlamalarıdır.
Bu sxemin özəlliyi ondan ibarətdir ki, bu dəyişiklik sahələrinin sərhədləri təkcə biznes məntiqi səviyyəsinə təsir etmir, həm də verilənlər bazasına qədər uzanır.
Gəlin xidmətin nə demək olduğuna baxaq. Xidmət tərifinin 6 xarakterik xüsusiyyəti var - bu proqram təminatıdır ki:
- müəyyən bir təşkilat tərəfindən yaradılmış və istifadə edilmişdir;
- sistem daxilində müəyyən növ məlumatların məzmununa, emalına və/və ya təqdim edilməsinə görə məsuliyyət daşıyır;
- xüsusi əməliyyat ehtiyaclarını ödəmək üçün müstəqil şəkildə tikilə, yerləşdirilə və idarə oluna bilər;
- istehlakçılarla və digər xidmətlərlə əlaqə saxlayır, müqavilələr və ya müqavilə zəmanətləri əsasında məlumat verir;
- özünü icazəsiz daxil olmaqdan, məlumatını isə itirməkdən qoruyur;
- uğursuzluqları elə idarə edir ki, onlar informasiyanın zədələnməsinə səbəb olmasın.
Bütün bu xassələri bir sözlə “muxtariyyət” ifadə etmək olar. Xidmətlər bir-birindən asılı olmayaraq fəaliyyət göstərir, müəyyən məhdudiyyətləri təmin edir və insanların ehtiyac duyduqları məlumatı əldə edə biləcəyi müqavilələr müəyyən edir. İstifadəsi öz-özünə aydın olan konkret texnologiyalardan bəhs etməmişəm.
İndi mikroservislərin tərifinə baxaq:
- mikroservis kiçik ölçülüdür və müəyyən bir problemi həll etmək üçün nəzərdə tutulmuşdur;
- Mikroservis avtonomdur;
- Mikroservis arxitekturasının yaradılması zamanı şəhərsalma metaforasından istifadə olunur. Bu, Sem Nyumanın "Mikroservislərin qurulması" kitabından verilən tərifdir.
Məhdud Kontekst tərifi Erik Evansın Domain-Driven Design kitabından götürülmüşdür. Bu, həcmli memarlıq modelləri ilə işləyən, onları müxtəlif Sərhədli Kontekstlərə bölən və aralarındakı qarşılıqlı əlaqəni açıq şəkildə müəyyən edən memarlıq dizayn mərkəzi olan DDD-də əsas nümunədir.
Sadəcə olaraq, məhdud kontekst müəyyən modulun istifadə oluna biləcəyi əhatə dairəsini bildirir. Bu kontekstdə, məsələn, biznes domeninizdə görünə bilən məntiqi birləşdirilmiş modeldir. Sifarişlərdə iştirak edən personala “müştəri kimdir” sualını versəniz, bir tərif alacaqsınız, satışla məşğul olanlardan soruşsanız, başqa bir tərif alacaqsınız, ifaçılar sizə üçüncü tərif verəcəklər.
Beləliklə, Məhdud Kontekst deyir ki, xidmətlərimizin istehlakçısının nə olduğuna dair dəqiq bir tərif verə bilmiriksə, gəlin bu terminin mənası haqqında danışa biləcəyimiz sərhədləri müəyyən edək və sonra bu müxtəlif təriflər arasında keçid nöqtələrini müəyyən edək. Yəni, əgər sifariş vermək baxımından müştəridən danışırıqsa, bu, bu və ya digər, satış baxımından isə, bu, bu və digər deməkdir.
Mikroxidmətin növbəti tərifi iş prosesinin komponentlərinin ətraf mühitə “sızmasının” qarşısını alan istənilən növ daxili əməliyyatların inkapsulyasiyasıdır. Daha sonra SLA-lardan qayıdan müqavilələr ideyası ilə təmsil olunan "xarici qarşılıqlı əlaqə və ya xarici ünsiyyət üçün açıq müqavilələrin tərifi" gəlir. Son tərif hüceyrənin və ya hüceyrənin metaforasıdır ki, bu da mikroservis daxilində əməliyyatlar dəstinin tam inkapsulyasiyasını və orada xarici dünya ilə əlaqə üçün reseptorların olmasını bildirir.
Beləliklə, biz Bell Computers-dəki uşaqlara dedik: “Biz yaratdığınız hər hansı xaosu düzəldə bilmərik, çünki bunu etmək üçün pulunuz yoxdur, lakin biz hər şeyi etmək üçün yalnız bir xidməti düzəldəcəyik. mənada.” Bu nöqtədə sizə yeganə xidmətimizi necə düzəltdiyimizi izah etməklə başlayacağam ki, o, sorğulara 9 dəqiqə yarımdan tez cavab verdi.
22:30 dəq
Tezliklə davamı olacaq...
Bir az reklam
Bizimlə qaldığınız üçün təşəkkür edirik. Məqalələrimiz xoşunuza gəlirmi? Daha maraqlı məzmun görmək istəyirsiniz? Sifariş verməklə və ya dostlarınıza tövsiyə etməklə bizə dəstək olun, , Sizin üçün bizim tərəfimizdən icad edilmiş giriş səviyyəli serverlərin unikal analoqu: (RAID1 və RAID10, 24 nüvəyə qədər və 40 GB DDR4 ilə mövcuddur).
Dell R730xd Amsterdamdakı Equinix Tier IV məlumat mərkəzində 2 dəfə ucuzdur? Yalnız burada Hollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! haqqında oxuyun
Mənbə: www.habr.com