Hey Habr!

Koronavirusla bağlı mövcud hadisələr fonunda bir sıra internet xidmətləri artan yüklənməyə başlayıb. Misal üçün, Böyük Britaniyanın pərakəndə satış şəbəkələrindən biri sadəcə olaraq onlayn sifariş saytını dayandırdı., çünki kifayət qədər tutum yox idi. Sadəcə daha güclü avadanlıq əlavə etməklə serveri sürətləndirmək həmişə mümkün deyil, lakin müştəri sorğuları işlənməlidir (yaxud onlar rəqiblərə gedəcəklər).

Bu yazıda qısaca sizə sürətli və qüsurlara dözümlü xidmət yaratmağa imkan verəcək məşhur təcrübələrdən danışacağam. Bununla belə, mümkün inkişaf sxemlərindən yalnız hazırda mövcud olanları seçdim istifadəsi asan. Hər bir element üçün ya hazır kitabxanalarınız var, ya da problemi bulud platformasından istifadə edərək həll etmək imkanınız var.

Üfüqi miqyaslama

Ən sadə və ən məşhur məqam. Şərti olaraq, ən çox yayılmış iki yük paylama sxemi üfüqi və şaquli miqyasdır. Birinci halda siz xidmətlərin paralel işləməsinə icazə verirsiniz və bununla da yükü onlar arasında bölüşdürürsünüz. İkincisi daha güclü serverlər sifariş edirsiniz və ya kodu optimallaşdırırsınız.

Məsələn, mən mücərrəd bulud fayl yaddaşını götürəcəyəm, yəni OwnCloud, OneDrive və s.

Belə bir dövrənin standart şəkli aşağıdadır, lakin bu, yalnız sistemin mürəkkəbliyini nümayiş etdirir. Axı biz xidmətləri birtəhər sinxronlaşdırmalıyıq. İstifadəçi planşetdən faylı saxlasa və sonra onu telefondan görmək istəsə nə olar?

Yanaşmalar arasındakı fərq: şaquli miqyasda biz qovşaqların gücünü artırmağa, üfüqi miqyasda isə yükü bölüşdürmək üçün yeni qovşaqlar əlavə etməyə hazırıq.

CQRS

Komanda Sorğu Məsuliyyətinin Ayrılması Kifayət qədər vacib bir nümunə, çünki fərqli müştərilərə nəinki müxtəlif xidmətlərə qoşulmağa, həm də eyni hadisə axınlarını qəbul etməyə imkan verir. Onun faydaları sadə bir tətbiq üçün o qədər də açıq deyil, lakin məşğul xidmət üçün son dərəcə vacibdir (və sadədir). Onun mahiyyəti: daxil olan və gedən məlumat axınları kəsişməməlidir. Yəni siz sorğu göndərib cavab gözləyə bilməzsiniz, bunun əvəzinə A xidmətinə sorğu göndərirsiniz, lakin B xidmətindən cavab alırsınız.

Bu yanaşmanın ilk bonusu uzun bir sorğunu yerinə yetirərkən əlaqəni (sözün geniş mənasında) kəsmək qabiliyyətidir. Məsələn, az-çox standart ardıcıllığı götürək:

1. Müştəri serverə sorğu göndərdi.
2. Server uzun müddət işləməyə başladı.
3. Server müştəriyə nəticə ilə cavab verdi.

Təsəvvür edək ki, 2-ci bənddə əlaqə pozulub (yaxud şəbəkə yenidən qoşulub və ya istifadəçi əlaqəni pozaraq başqa səhifəyə keçib). Bu halda, serverin istifadəçiyə dəqiq nəyin işləndiyi barədə məlumatla cavab göndərməsi çətin olacaq. CQRS istifadə edərək, ardıcıllıq bir qədər fərqli olacaq:

1. Müştəri yeniləmələrə abunə olub.
2. Müştəri serverə sorğu göndərdi.
3. Server "sorğu qəbul edildi" cavabını verdi.
4. Server “1” nöqtəsindən kanal vasitəsilə nəticə ilə cavab verdi.

Gördüyünüz kimi, sxem bir az daha mürəkkəbdir. Üstəlik, burada intuitiv sorğu-cavab yanaşması yoxdur. Lakin, gördüyünüz kimi, sorğunun işlənməsi zamanı əlaqə kəsilməsi xətaya səbəb olmayacaq. Üstəlik, əgər həqiqətən istifadəçi xidmətə bir neçə cihazdan qoşulubsa (məsələn, mobil telefondan və planşetdən), cavabın hər iki cihaza gəldiyinə əmin ola bilərsiniz.

Maraqlıdır ki, daxil olan mesajların işlənməsi kodu həm müştərinin özündən təsirlənən hadisələr üçün, həm də digər müştərilərdən olanlar da daxil olmaqla digər hadisələr üçün eyni olur (100% deyil).

Bununla belə, əslində biz bir istiqamətli axını funksional üslubda (RX və buna bənzər) idarə oluna bildiyinə görə əlavə bonus alırıq. Və bu, artıq ciddi bir artıdır, çünki mahiyyət etibarilə proqram tamamilə reaktiv edilə bilər, həm də funksional bir yanaşma istifadə olunur. Yağlı proqramlar üçün bu, inkişafa və dəstək resurslarına əhəmiyyətli dərəcədə qənaət edə bilər.

Bu yanaşmanı üfüqi miqyasla birləşdirsək, bonus olaraq bir serverə sorğu göndərmək və digərindən cavab almaq imkanı əldə edirik. Beləliklə, müştəri özünə uyğun olan xidməti seçə bilər və daxilindəki sistem yenə də hadisələri düzgün emal edə biləcək.

Hadisə mənbəyi

Bildiyiniz kimi, paylanmış sistemin əsas xüsusiyyətlərindən biri ümumi zamanın, ümumi kritik bölmənin olmamasıdır. Bir proses üçün siz sinxronizasiya edə bilərsiniz (eyni mutexeslərdə), onun daxilində bu kodu başqa heç kimin icra etmədiyinə əminsiniz. Bununla belə, bu, paylanmış bir sistem üçün təhlükəlidir, çünki o, əlavə xərc tələb edəcək və miqyaslaşdırmanın bütün gözəlliyini öldürəcək - bütün komponentlər hələ də birini gözləyəcək.

Buradan biz vacib bir fakt əldə edirik - sürətli paylanmış sistem sinxronlaşdırıla bilməz, çünki o zaman biz performansı azaldacağıq. Digər tərəfdən, tez-tez komponentlər arasında müəyyən bir tutarlılığa ehtiyacımız var. Və bunun üçün ilə yanaşmadan istifadə edə bilərsiniz nəticəli ardıcıllıq, əgər son yeniləmədən sonra müəyyən müddət ərzində məlumat dəyişikliyi olmazsa (“nəhayət”), bütün sorğuların sonuncu yenilənmiş dəyəri qaytaracağına zəmanət verilir.

Klassik verilənlər bazaları üçün olduqca tez-tez istifadə olunduğunu başa düşmək vacibdir güclü tutarlılıq, burada hər bir node eyni məlumata malikdir (bu, çox vaxt əməliyyatın yalnız ikinci server cavab verdikdən sonra qurulduğu hesab edildiyi halda əldə edilir). Burada təcrid səviyyələrinə görə bəzi istirahətlər var, lakin ümumi fikir dəyişməz olaraq qalır - tamamilə uyğunlaşdırılmış bir dünyada yaşaya bilərsiniz.

Bununla belə, orijinal tapşırığa qayıdaq. Əgər sistemin bir hissəsi ilə inşa edilə bilər nəticəli ardıcıllıq, onda aşağıdakı diaqramı qura bilərik.

Bu yanaşmanın vacib xüsusiyyətləri:

• Hər bir daxil olan sorğu bir növbəyə yerləşdirilir.
• Sorğunu emal edərkən, xidmət digər növbələrdə də tapşırıqlar yerləşdirə bilər.
• Hər bir daxil olan hadisənin identifikatoru var (bu, təkmilləşdirmə üçün lazımdır).
• Növbə ideoloji olaraq “yalnız əlavə et” sxeminə uyğun işləyir. Ondan elementləri silə və ya onları yenidən təşkil edə bilməzsiniz.
• Növbə FİFO sxeminə uyğun işləyir (tavtologiyaya görə üzr istəyirəm). Paralel icra etmək lazımdırsa, bir mərhələdə obyektləri müxtəlif növbələrə köçürməlisiniz.

Nəzərinizə çatdırım ki, biz onlayn fayl saxlama məsələsini nəzərdən keçiririk. Bu vəziyyətdə sistem bu kimi görünəcək:

Diaqramdakı xidmətlərin mütləq ayrı bir server mənasını verməməsi vacibdir. Hətta proses eyni ola bilər. Başqa bir şey vacibdir: ideoloji olaraq, bu şeylər üfüqi miqyaslamanın asanlıqla tətbiq oluna biləcəyi şəkildə ayrılır.

Və iki istifadəçi üçün diaqram bu kimi görünəcək (müxtəlif istifadəçilər üçün nəzərdə tutulmuş xidmətlər müxtəlif rənglərlə göstərilmişdir):

Belə birləşmədən bonuslar:

• İnformasiya emalı xidmətləri ayrılır. Növbələr də ayrılıb. Əgər sistemin ötürmə qabiliyyətini artırmaq lazımdırsa, onda sadəcə daha çox serverdə daha çox xidmət işə salmalıyıq.
• Biz istifadəçidən məlumat aldıqda, məlumatların tamamilə saxlanmasını gözləmək məcburiyyətində deyilik. Əksinə, sadəcə “ok” cavabını vermək və sonra tədricən işə başlamaq lazımdır. Eyni zamanda, növbə zirvələri hamarlayır, çünki yeni bir obyekt əlavə etmək tez baş verir və istifadəçi bütün dövr ərzində tam keçid gözləməli deyil.
• Nümunə olaraq, eyni faylları birləşdirməyə çalışan təkmilləşdirmə xidməti əlavə etdim. 1% hallarda uzun müddət işləyirsə, müştəri çətin ki, bunu fərq etsin (yuxarıya baxın), bu böyük bir artıdır, çünki bizdən artıq XNUMX% sürət və etibarlı olmaq tələb olunmur.

Bununla belə, çatışmazlıqlar dərhal görünür:

• Sistemimiz ciddi ardıcıllığını itirdi. Bu o deməkdir ki, məsələn, müxtəlif xidmətlərə abunə olsanız, nəzəri olaraq fərqli bir vəziyyət əldə edə bilərsiniz (çünki xidmətlərdən birinin daxili növbədən bildiriş almağa vaxtı olmaya bilər). Başqa bir nəticə olaraq, sistemin indi ümumi vaxtı yoxdur. Yəni, məsələn, bütün hadisələri sadəcə gəliş vaxtına görə çeşidləmək mümkün deyil, çünki serverlər arasında saatlar sinxron olmaya bilər (üstəlik, iki serverdə eyni vaxt utopiyadır).
• İndi heç bir hadisə sadəcə olaraq geri qaytarıla bilməz (verilənlər bazası ilə edilə bilər). Bunun əvəzinə yeni bir hadisə əlavə etməlisiniz - kompensasiya hadisəsi, sonuncu vəziyyəti tələb olunan vəziyyətə dəyişəcək. Bənzər bir sahədən bir nümunə olaraq: tarixi yenidən yazmadan (bəzi hallarda pisdir), git-də öhdəliyi geri qaytara bilməzsiniz, ancaq xüsusi edə bilərsiniz. geri qaytarma öhdəliyi, bu əslində köhnə vəziyyəti qaytarır. Bununla belə, həm səhv öhdəlik, həm də geri çəkilmə tarixdə qalacaq.
• Məlumat sxemi buraxılışdan buraxılışa dəyişə bilər, lakin köhnə hadisələr daha yeni standarta yenilənə bilməyəcək (çünki hadisələr prinsipcə dəyişdirilə bilməz).

Gördüyünüz kimi, Event Sourcing CQRS ilə yaxşı işləyir. Üstəlik, səmərəli və rahat növbələri olan, lakin məlumat axınlarını ayırmadan sistemin tətbiqi artıq özlüyündə çətindir, çünki növbələrin bütün müsbət təsirini neytrallaşdıracaq sinxronizasiya nöqtələrini əlavə etməli olacaqsınız. Hər iki yanaşmanı bir anda tətbiq edərək, proqram kodunu bir az tənzimləmək lazımdır. Bizim vəziyyətimizdə, faylı serverə göndərərkən, cavab yalnız "ok" gəlir, bu yalnız "faylın əlavə edilməsi əməliyyatı saxlandığını" bildirir. Formal olaraq, bu, məlumatların artıq digər cihazlarda mövcud olması demək deyil (məsələn, təkmilləşdirmə xidməti indeksi yenidən qura bilər). Bununla belə, bir müddət sonra müştəri “X faylı saxlandı” üslubunda bildiriş alacaq.

Nəticə olaraq:

• Fayl göndərmə statuslarının sayı artır: klassik "göndərilmiş fayl" əvəzinə iki alırıq: "fayl serverdəki növbəyə əlavə edildi" və "fayl yaddaşda saxlandı." Sonuncu o deməkdir ki, digər qurğular artıq faylı qəbul etməyə başlaya bilər (növbələrin müxtəlif sürətlərdə işləməsi üçün düzəliş edilmişdir).
• Təqdimat məlumatlarının indi müxtəlif kanallar vasitəsilə gəldiyinə görə, faylın işlənməsi statusunu almaq üçün həllər tapmalıyıq. Bunun nəticəsi olaraq: klassik sorğu-cavabdan fərqli olaraq, faylı işləyərkən müştəri yenidən işə salına bilər, lakin bu emalın özü düzgün olacaq. Üstəlik, bu maddə qutudan kənarda işləyir. Nəticə olaraq: biz indi uğursuzluqlara daha dözümlüyük.

Sharding

Yuxarıda təsvir edildiyi kimi, hadisə qaynaq sistemlərində ciddi ardıcıllıq yoxdur. Bu o deməkdir ki, biz bir neçə yaddaşdan aralarında sinxronizasiya olmadan istifadə edə bilərik. Problemimizə yaxınlaşaraq, edə bilərik:

• Faylları növünə görə ayırın. Məsələn, şəkillər/videolar deşifrə edilə bilər və daha səmərəli format seçilə bilər.
• Hesabları ölkəyə görə ayırın. Bir çox qanunlara görə, bu tələb oluna bilər, lakin bu memarlıq sxemi avtomatik olaraq belə bir fürsət təmin edir

Məlumatları bir yaddaşdan digərinə köçürmək istəyirsinizsə, standart vasitələr artıq kifayət deyil. Təəssüf ki, bu vəziyyətdə növbəni dayandırmalı, köçürməni yerinə yetirməli və sonra işə başlamalısınız. Ümumi halda, məlumat "tez" ötürülə bilməz, lakin hadisə növbəsi tamamilə saxlanılırsa və əvvəlki yaddaş vəziyyətlərinin anlıq görüntüləri varsa, hadisələri aşağıdakı kimi təkrarlaya bilərik:

• Event Source-da hər bir hadisənin öz identifikatoru var (ideal olaraq azalmayan). Bu o deməkdir ki, biz yaddaşa sahə əlavə edə bilərik - sonuncu işlənmiş elementin id-si.
• Növbənin dublikatını edirik ki, bütün hadisələr bir neçə müstəqil saxlama üçün emal olunsun (birincisi, verilənlərin artıq saxlandığı, ikincisi isə yeni, lakin hələ də boşdur). İkinci növbə, təbii ki, hələ işlənmir.
• İkinci növbəni işə salırıq (yəni hadisələri təkrarlamağa başlayırıq).
• Yeni növbə nisbətən boş olduqda (yəni elementin əlavə edilməsi ilə onu əldə etmək arasında orta vaxt fərqi məqbuldur), siz oxucuları yeni yaddaşa keçirməyə başlaya bilərsiniz.

Gördüyünüz kimi, sistemimizdə ciddi ardıcıllıq yox idi və indi də yoxdur. Yalnız son ardıcıllıq var, yəni hadisələrin eyni ardıcıllıqla (lakin ola bilsin ki, müxtəlif gecikmələrlə) işlənməsinə zəmanət. Və bundan istifadə edərək, sistemi dünyanın digər tərəfinə dayandırmadan nisbətən asanlıqla məlumat ötürə bilərik.

Beləliklə, fayllar üçün onlayn saxlama nümunəmizə davam edərək, belə bir arxitektura artıq bizə bir sıra bonuslar verir:

• Biz obyektləri dinamik şəkildə istifadəçilərə yaxınlaşdıra bilərik. Bu yolla siz xidmətin keyfiyyətini yüksəldə bilərsiniz.
• Bəzi məlumatları şirkətlərdə saxlaya bilərik. Məsələn, Enterprise istifadəçiləri tez-tez məlumatlarının idarə olunan məlumat mərkəzlərində saxlanmasını tələb edirlər (məlumat sızmasının qarşısını almaq üçün). Sharding vasitəsilə biz bunu asanlıqla dəstəkləyə bilərik. Müştərinin uyğun buludları varsa, tapşırıq daha da asandır (məsələn, Azure özünə ev sahibliyi etdi).
• Və ən əsası odur ki, biz bunu etməməliyik. Bütün bunlardan sonra, bütün hesablar üçün bir yaddaşdan (tez işləməyə başlamaq üçün) olduqca məmnun olardıq. Və bu sistemin əsas xüsusiyyəti odur ki, genişləndirilə bilsə də, ilkin mərhələdə olduqca sadədir. Sadəcə bir milyon ayrı müstəqil növbə ilə işləyən kodu dərhal yazmağa ehtiyac yoxdur və s. Lazım gələrsə, bu, gələcəkdə də edilə bilər.

Statik Məzmun Hostinqi

Bu nöqtə olduqca açıq görünə bilər, lakin daha çox və ya daha az standart yüklənmiş proqram üçün hələ də lazımdır. Onun mahiyyəti sadədir: bütün statik məzmun tətbiqin yerləşdiyi eyni serverdən deyil, xüsusi olaraq bu vəzifəyə həsr olunmuş xüsusi serverlərdən paylanır. Nəticədə, bu əməliyyatlar daha sürətli yerinə yetirilir (şərti nginx Java serverindən daha tez və daha ucuz qiymətə fayllara xidmət göstərir). Üstəlik CDN arxitekturası (Məzmun çatdırılması şəbəkə) bizə fayllarımızı son istifadəçilərə daha yaxın yerləşdirməyə imkan verir ki, bu da xidmətlə işləməyin rahatlığına müsbət təsir göstərir.

Statik məzmunun ən sadə və ən standart nümunəsi vebsayt üçün skriptlər və şəkillər toplusudur. Onlarla hər şey sadədir - onlar əvvəlcədən məlumdur, sonra arxiv CDN serverlərinə yüklənir, oradan son istifadəçilərə paylanır.

Bununla belə, əslində, statik məzmun üçün lambda arxitekturasına bir qədər oxşar yanaşmadan istifadə edə bilərsiniz. Faylları istifadəçilərə paylamağımız lazım olan vəzifəmizə (onlayn fayl saxlama) qayıdaq. Ən sadə həll yolu, hər bir istifadəçi sorğusu üçün bütün lazımi yoxlamaları (avtorizasiya və s.) həyata keçirən və sonra faylı birbaşa yaddaşımızdan endirən bir xidmət yaratmaqdır. Bu yanaşmanın əsas çatışmazlığı ondan ibarətdir ki, statik məzmun (və müəyyən reviziyaya malik fayl, əslində, statik məzmundur) biznes məntiqini ehtiva edən eyni server tərəfindən paylanır. Bunun əvəzinə aşağıdakı diaqramı edə bilərsiniz:

• Server yükləmə URL-i təmin edir. O, file_id + açar şəklində ola bilər, burada açar növbəti XNUMX saat ərzində resursa daxil olmaq hüququ verən mini-rəqəmsal imzadır.
• Fayl sadə nginx tərəfindən aşağıdakı seçimlərlə paylanır:
  • Məzmunun keşləşdirilməsi. Bu xidmət ayrı bir serverdə yerləşə bildiyi üçün biz özümüzə gələcək üçün ən son yüklənmiş faylları diskdə saxlamaq imkanı ilə özümüzə ehtiyat buraxdıq.
  • Bağlantının yaradılması zamanı açarın yoxlanılması
• Könüllü: axın məzmununun işlənməsi. Məsələn, xidmətdəki bütün faylları sıxışdırırıqsa, onda biz birbaşa bu modulda zip çıxara bilərik. Nəticədə: IO əməliyyatları aid olduqları yerdə edilir. Java-da arxivator asanlıqla çoxlu əlavə yaddaş ayıracaq, lakin xidməti iş məntiqi ilə Rust/C++ şərtlərinə yenidən yazmaq da səmərəsiz ola bilər. Bizim vəziyyətimizdə müxtəlif proseslər (və ya hətta xidmətlər) istifadə olunur və buna görə də biz biznes məntiqini və IO əməliyyatlarını kifayət qədər effektiv şəkildə ayıra bilərik.

Bu sxem statik məzmunun yayılmasına çox bənzəmir (çünki biz bütün statik paketi hardasa yükləməyəcəyik), lakin əslində bu yanaşma dəyişməz məlumatların yayılması ilə bağlıdır. Üstəlik, bu sxem məzmunun sadəcə statik olmadığı, dəyişməz və silinməyən bloklar toplusu kimi təqdim oluna bilən digər hallar üçün ümumiləşdirilə bilər (baxmayaraq ki, onlar əlavə edilə bilər).

Başqa bir misal (möhkəmləndirmə üçün): əgər siz Jenkins/TeamCity ilə işləmisinizsə, onda siz bilirsiniz ki, hər iki həll Java-da yazılmışdır. Onların hər ikisi həm quruluş orkestrini, həm də məzmunun idarə edilməsini idarə edən Java prosesidir. Xüsusilə, hər ikisinin “serverdən fayl/qovluq köçürmək” kimi vəzifələri var. Nümunə olaraq: artefaktların verilməsi, mənbə kodunun ötürülməsi (agent kodu birbaşa depodan yükləmədikdə, lakin server bunu onun üçün edir), qeydlərə giriş. Bütün bu vəzifələr IO yükü ilə fərqlənir. Yəni belə çıxır ki, mürəkkəb biznes məntiqinə cavabdeh olan server eyni zamanda böyük məlumat axınını effektiv şəkildə özü vasitəsilə ötürə bilməlidir. Ən maraqlısı odur ki, belə bir əməliyyat eyni sxemə görə eyni nginx-ə həvalə edilə bilər (məlumat açarının sorğuya əlavə edilməsi istisna olmaqla).

Ancaq sistemimizə qayıtsaq, oxşar bir diaqram alırıq:

Göründüyü kimi, sistem kökündən daha mürəkkəbləşib. İndi bu, yalnız faylları lokal olaraq saxlayan mini-proses deyil. İndi tələb olunan ən sadə dəstək deyil, API versiyasına nəzarət və s. Buna görə də, bütün diaqramlar tərtib edildikdən sonra, genişlənmənin dəyərinə dəyər olub olmadığını ətraflı qiymətləndirmək yaxşıdır. Bununla belə, sistemi genişləndirə bilmək istəyirsinizsə (daha çox sayda istifadəçi ilə işləmək də daxil olmaqla), o zaman oxşar həllərə müraciət etməli olacaqsınız. Lakin, nəticədə, sistem memarlıq baxımından artan yükə hazırdır (demək olar ki, hər bir komponent üfüqi miqyasda klonlana bilər). Sistem dayandırılmadan yenilənə bilər (sadəcə bəzi əməliyyatlar bir qədər yavaşlayacaq).

Əvvəldə dediyim kimi, indi bir sıra internet xidmətləri artan yüklənməyə başlayıb. Və bəziləri sadəcə düzgün işləməyi dayandırmağa başladılar. Əslində, sistemlər işin pul qazanmalı olduğu anda uğursuz oldu. Yəni, təxirə salınmış çatdırılma əvəzinə, müştərilərə “gələn aylara çatdırılmanızı planlaşdırın” demək əvəzinə, sistem sadəcə olaraq “rəqiblərinizə gedin” dedi. Əslində, bu, aşağı məhsuldarlığın qiymətidir: itkilər məhz mənfəətin ən yüksək olacağı vaxt baş verəcəkdir.

Nəticə

Bütün bu yanaşmalar əvvəllər məlum idi. Eyni VK uzun müddətdir ki, şəkilləri göstərmək üçün Static Content Hosting ideyasından istifadə edir. Bir çox onlayn oyunlar oyunçuları bölgələrə bölmək və ya oyun yerlərini ayırmaq üçün (dünyanın özü birdirsə) Sharding sxemindən istifadə edir. E-poçtda Event Sourcing yanaşması fəal şəkildə istifadə olunur. Məlumatların daim qəbul edildiyi əksər ticarət proqramları, alınan məlumatları süzgəcdən keçirə bilmək üçün əslində CQRS yanaşması üzərində qurulur. Yaxşı, üfüqi miqyaslama bir çox xidmətlərdə kifayət qədər uzun müddətdir istifadə olunur.

Ancaq ən əsası, bütün bu nümunələri müasir tətbiqlərdə tətbiq etmək çox asan oldu (əlbəttə ki, uyğundursa). Buludlar dərhal Sharding və üfüqi miqyaslaşdırma təklif edir, bu, müxtəlif məlumat mərkəzlərində müxtəlif xüsusi serverləri özünüz sifariş etməkdən daha asandır. Yalnız RX kimi kitabxanaların inkişafı sayəsində CQRS çox asanlaşdı. Təxminən 10 il əvvəl nadir bir veb sayt bunu dəstəkləyə bilərdi. Apache Kafka ilə hazır konteynerlər sayəsində Event Sourcing-i qurmaq da olduqca asandır. 10 il əvvəl bu bir yenilik olardı, indi adi hala çevrilib. Statik Məzmun Hostinqi ilə də eynidir: daha rahat texnologiyalar (o cümlədən ətraflı sənədlərin və geniş cavablar bazası olması) sayəsində bu yanaşma daha da sadələşdi.

Nəticədə, bir sıra olduqca mürəkkəb memarlıq nümunələrinin həyata keçirilməsi indi çox sadələşdi, yəni əvvəlcədən ona daha yaxından baxmaq daha yaxşıdır. Əgər on illik tətbiqdə yuxarıda göstərilən həllərdən biri həyata keçirilməsi və istismarının yüksək qiymətinə görə tərk edilibsə, indi yeni tətbiqdə və ya refaktorinqdən sonra siz artıq memarlıq baxımından həm genişləndirilə bilən bir xidmət yarada bilərsiniz ( performans baxımından) və müştərilərin yeni sorğularına hazır (məsələn, şəxsi məlumatların lokallaşdırılması üçün).

Və ən əsası: sadə bir tətbiqiniz varsa, bu yanaşmalardan istifadə etməyin. Bəli, onlar gözəl və maraqlıdırlar, lakin 100 nəfərin pik ziyarəti olan bir sayt üçün tez-tez klassik monolitlə əldə edə bilərsiniz (ən azı kənarda, içəridə hər şey modullara bölünə bilər və s.).

Mənbə: www.habr.com