Və ya monolitli hər bir bədbəxt şirkət öz yolu ilə bədbəxtdir.
Dodo IS sisteminin inkişafı, Dodo Pizza biznesi kimi, 2011-ci ildə dərhal başladı. Bu, biznes proseslərinin tam və tam rəqəmsallaşdırılması ideyasına əsaslanırdı və 2011-ci ildə də çoxlu suallara və şübhələrə səbəb olmuşdu. Amma artıq 9 ildir ki, biz bu yolla - monolitdən başlayan öz inkişafımızla gedirik.
Bu məqalə “Niyə arxitekturanı yenidən yazmaq və belə genişmiqyaslı və uzunmüddətli dəyişikliklər etmək lazımdır?” suallarına “cavab”dır. əvvəlki məqaləyə qayıt . Dodo IS-nin inkişafının necə başladığı, orijinal arxitekturanın necə göründüyü, yeni modulların necə göründüyü və hansı problemlərə görə genişmiqyaslı dəyişikliklərin edilməli olduğu ilə başlayacağam.
Məqalələr silsiləsi "Dodo IS nədir?" haqqında danışır:
-
Dodo IS-də erkən monolit (2011-2015). (burdasan)
-
.
-
Müştəri tərəfi yolu: baza üzərində fasad (2016-2017). (Davam edir...)
-
Real mikroxidmətlərin tarixi. (2018-2019). (Davam edir...)
-
Monolitin kəsilməsi və arxitekturanın sabitləşdirilməsi başa çatıb. (Davam edir...)
İlkin memarlıq
2011-ci ildə Dodo IS memarlığı belə görünürdü:
Memarlıqda ilk modul sifariş qəbuludur. İş prosesi belə idi:
-
müştəri pizzacıya zəng edir;
-
menecer telefonu götürür;
-
telefonla sifariş qəbul edir;
-
onu paralel olaraq sifarişin qəbulu interfeysində doldurur: müştəri haqqında məlumatları, sifarişin təfərrüatları haqqında məlumatları, çatdırılma ünvanını nəzərə alır.
İnformasiya sisteminin interfeysi belə bir şeyə bənzəyirdi ...
2011-ci ilin oktyabrından ilk versiya:
Birinci sifariş qəbulu modulunun inkişafı üçün resurslar məhdud idi. Tez və kiçik bir komanda ilə çox şey etməli idik. Kiçik bir komanda bütün gələcək sistemin əsasını qoyan 2 tərtibatçıdır.
Onların ilk qərarı texnologiya yığınının taleyini müəyyənləşdirdi:
-
ASP.NET MVC, C# dilində backend. Tərtibatçılar dotnetchiki idi, bu yığın onlara tanış və xoş idi.
-
Bootstrap və JQuery-də Frontend: öz-özünə yazılmış üslub və skriptlərdə istifadəçi interfeysləri.
-
MySQL verilənlər bazası: lisenziya xərcləri yoxdur, istifadəsi asandır.
-
Windows Serverdəki serverlər, çünki .NET o zaman yalnız Windows altında ola bilərdi (biz Mono-nu müzakirə etməyəcəyik).
Fiziki olaraq, bütün bunlar "ev sahibinə həsr olunmuş" ifadəsində ifadə edildi.
Sifariş Qəbul Tətbiqinin Arxitekturası
Onda hamı artıq mikroservislərdən danışırdı və SOA 5 il ərzində böyük layihələrdə istifadə olunurdu, məsələn, WCF 2006-cı ildə buraxıldı. Ancaq sonra etibarlı və sübut edilmiş bir həll seçdilər.
Bax budur.
Asp.Net MVC, formadan və ya müştəridən tələb əsasında server göstərilməsi ilə HTML səhifəsini təqdim edən Razor-dur. Müştəridə, CSS və JS skriptləri artıq məlumatları göstərir və lazım gələrsə, JQuery vasitəsilə AJAX sorğularını yerinə yetirir.
Serverdəki sorğular *Controller siniflərində başa çatır, burada son HTML səhifəsinin işlənməsi və yaradılması metodda baş verir. Nəzarətçilər *Xidmətlər adlı məntiq qatına sorğular göndərirlər. Xidmətlərin hər biri biznesin bəzi aspektlərinə uyğun gəlirdi:
-
Məsələn, DepartmentStructureService pizzacılar, şöbələr haqqında məlumat verdi. Departament tək bir françayzi tərəfindən idarə olunan bir qrup pizzacıdır.
-
ReceivingOrdersService qəbul etdi və sifarişin tərkibini hesabladı.
-
SmsService isə SMS göndərmək üçün API xidmətlərinə zəng edərək SMS göndərdi.
Xidmətlər verilənlər bazasından məlumatları emal edir, iş məntiqini saxlayır. Hər bir xidmətin müvafiq adı olan bir və ya daha çox *Repozitoriyaları var idi. Onlarda artıq verilənlər bazasında saxlanılan prosedurlara sorğular və xəritəçilərin təbəqəsi var idi. Anbarlarda iş məntiqi var idi, xüsusən də hesabat məlumatlarını verənlərdə. ORM istifadə olunmayıb, hamı əllə yazılmış sql-a güvənirdi.
Həmçinin domen modelinin təbəqəsi və ümumi köməkçi siniflər var idi, məsələn, sifarişi saxlayan Sifariş sinfi. Eyni yerdə, təbəqədə ekran mətnini seçilmiş valyutaya uyğun çevirmək üçün köməkçi var idi.
Bütün bunlar belə bir modellə təmsil oluna bilər:
Sifariş yolu
Belə bir sifariş yaratmaq üçün sadələşdirilmiş ilkin yolu nəzərdən keçirin.
Əvvəlcə sayt statik idi. Üzərində qiymətlər, üstündə isə telefon nömrəsi və “Pizza istəyirsənsə, nömrəyə zəng edib sifariş et” yazısı vardı. Sifariş vermək üçün sadə bir axını həyata keçirməliyik:
-
Müştəri qiymətləri olan statik sayta daxil olur, məhsulları seçir və saytda qeyd olunan nömrəyə zəng edir.
-
Müştəri sifarişə əlavə etmək istədiyi məhsulların adını çəkir.
-
Ünvanını və adını verir.
-
Operator sifarişi qəbul edir.
-
Sifariş qəbul edilmiş sifarişlər interfeysində göstərilir.
Hamısı menyunun göstərilməsi ilə başlayır. Daxil olan istifadəçi-operator eyni anda yalnız bir sifariş qəbul edir. Buna görə də, qaralama arabası onun sessiyasında saxlanıla bilər (istifadəçinin sessiyası yaddaşda saxlanılır). Məhsulları və müştəri məlumatlarını ehtiva edən Səbət obyekti var.
Müştəri məhsulun adını çəkir, operator klikləyir + məhsulun yanındadır və serverə sorğu göndərilir. Məhsul haqqında məlumat bazadan çıxarılır və məhsul haqqında məlumat səbətə əlavə olunur.
Qeyd. Bəli, burada məhsulu verilənlər bazasından çıxara bilməzsiniz, ancaq onu frontenddən köçürə bilərsiniz. Ancaq aydınlıq üçün verilənlər bazasından dəqiq yolu göstərdim.
Sonra, müştərinin ünvanını və adını daxil edin.
"Sifariş yarat" düyməsini kliklədiyiniz zaman:
-
Sorğu OrderController.SaveOrder() ünvanına göndərilir.
-
Seansdan Cart alırıq, bizə lazım olan miqdarda məhsullar var.
-
Biz Səbətə müştəri haqqında məlumat əlavə edirik və onu verilənlər bazasında saxlandığı ReceivingOrderService sinfinin AddOrder metoduna keçirik.
-
Verilənlər bazasında sifariş, sifarişin tərkibi, müştəri ilə cədvəllər var və hamısı bir-birinə bağlıdır.
-
Sifariş ekranı interfeysi gedir və ən son sifarişləri çıxarır və onları göstərir.
Yeni modullar
Sifariş almaq vacib və zəruri idi. Əgər satmaq üçün sifarişiniz yoxdursa, pizza biznesi ilə məşğul ola bilməzsiniz. Buna görə də sistem funksionallıq əldə etməyə başladı - təxminən 2012-ci ildən 2015-ci ilə qədər. Bu müddət ərzində sistemin bir çox müxtəlif blokları ortaya çıxdı, mən onları çağıracağam modullar, xidmət və ya məhsul anlayışından fərqli olaraq.
Modul bəzi ümumi iş məqsədi ilə birləşdirilən funksiyalar toplusudur. Eyni zamanda, fiziki olaraq eyni tətbiqdədirlər.
Modulları sistem blokları adlandırmaq olar. Məsələn, bu hesabat modulu, admin interfeysləri, , icazə. Bunların hamısı fərqli istifadəçi interfeysləridir, bəzilərinin hətta fərqli vizual üslubları var. Eyni zamanda, hər şey bir tətbiq, bir işləyən proses çərçivəsindədir.
Texniki cəhətdən modullar Sahə kimi dizayn edilmişdi (belə bir fikir hətta qaldı ). Frontend, modellər, eləcə də öz nəzarətçi sinifləri üçün ayrıca fayllar var idi. Nəticədə sistem bundan dəyişdirildi ...
...buna:
Bəzi modullar tamamilə ayrı bir funksionallıq və qismən bir az ayrıca, daha diqqətli inkişaf sayəsində ayrı saytlar (icra edilə bilən layihə) tərəfindən həyata keçirilir. Bu:
-
Sayt - dodopizza.ru saytı.
-
Ixrac: 1C üçün Dodo IS-dən hesabatların yüklənməsi.
-
Şəxsi - işçinin şəxsi hesabı. Ayrı-ayrılıqda hazırlanmışdır və öz giriş nöqtəsi və ayrıca dizaynı var.
-
fs — statiklərin yerləşdirilməsi üçün layihə. Daha sonra bütün statikləri Akamai CDN-ə köçürərək ondan uzaqlaşdıq.
Qalan bloklar BackOffice proqramında idi.
Ad izahatı:
-
Kassir - Restoran kassiri.
-
ShiftManager - "Shift Manager" rolu üçün interfeyslər: pizzacı satışları üzrə əməliyyat statistikası, məhsulları dayandırma siyahısına qoymaq, sifarişi dəyişdirmək imkanı.
-
OfficeManager - "Pizzeriya Meneceri" və "Françayzi" rolları üçün interfeyslər. Burada pizzacı qurmaq, onun bonus promosyonları, işçilərin qəbulu və onlarla işləmək funksiyaları, hesabatlar toplanmışdır.
-
PublicScreens - pizzacılarda asılan televizorlar və planşetlər üçün interfeyslər. Televizorlarda çatdırılma zamanı menyular, reklam məlumatları, sifariş statusu göstərilir.
Onlar ümumi xidmət qatından, ümumi Dodo.Core domen sinfi blokundan və ümumi bazadan istifadə ediblər. Bəzən onlar hələ də bir-birlərinə keçidlər apara bilərdilər. Dodopizza.ru və ya personal.dodopizza.ru kimi fərdi saytlar da daxil olmaqla ümumi xidmətlərə getdi.
Yeni modullar meydana çıxanda verilənlər bazasında artıq yaradılmış xidmətlər kodunu, saxlanan prosedurları və cədvəlləri maksimum dərəcədə təkrar istifadə etməyə çalışdıq.
Sistemdə hazırlanmış modulların miqyasını daha yaxşı başa düşmək üçün burada inkişaf planları ilə 2012-ci ilin diaqramı verilmişdir:
2015-ci ilə qədər hər şey xəritədə idi və daha çoxu istehsalda idi.
-
Sifarişin qəbulu, sifarişin operator tərəfindən qəbul edildiyi Əlaqə Mərkəzinin ayrıca blokuna çevrildi.
-
Pizzaxanalarda menyular və məlumatlar asılmış ictimai ekranlar var idi.
-
Mətbəxdə yeni sifariş gəldikdə avtomatik olaraq “Yeni Pizza” səsli mesajını səsləndirən, həmçinin kuryer üçün faktura çap edən modul var. Bu, mətbəxdəki prosesləri xeyli asanlaşdırır, işçilərin çoxlu sayda sadə əməliyyatlarla diqqətini yayındırmamağa imkan verir.
-
Çatdırılma bölməsi ayrıca Çatdırılma Kassasına çevrildi, burada sifariş əvvəllər növbəni götürmüş kuryerə verildi. Əmək haqqının hesablanmasında onun iş vaxtı nəzərə alınıb.
Paralel olaraq, 2012-ci ildən 2015-ci ilə qədər 10-dan çox tərtibatçı meydana çıxdı, 35 pizzacı açıldı, sistemi Rumıniyaya yerləşdirdi və ABŞ-da satış nöqtələrinin açılmasına hazırlaşdı. Tərtibatçılar artıq bütün tapşırıqları yerinə yetirmirdilər, lakin komandalara bölünürdülər. hər biri sistemin öz hissəsində ixtisaslaşmışdır.
Problemləri
O cümlədən arxitekturaya görə (yalnız deyil).
Bazada xaos
Bir baza rahatdır. Ardıcıllıq onda və əlaqəli verilənlər bazalarına quraşdırılmış alətlər hesabına əldə edilə bilər. Onunla işləmək tanış və rahatdır, xüsusən cədvəllər və məlumat azdırsa.
Lakin 4 illik inkişaf ərzində verilənlər bazasında təxminən 600 cədvəl, 1500 saxlanılan prosedur olduğu ortaya çıxdı ki, onların da çoxunda məntiq var. Təəssüf ki, saxlanılan prosedurlar MySQL ilə işləyərkən o qədər də üstünlük vermir. Onlar baza tərəfindən keşlənilmir və məntiqin onlarda saxlanması inkişafı və sazlanmağı çətinləşdirir. Kodun təkrar istifadəsi də çətindir.
Bir çox cədvəllərin uyğun indeksləri yox idi, haradasa, əksinə, çoxlu indekslər var idi, bu da daxil etməyi çətinləşdirirdi. Təxminən 20 cədvəli dəyişdirmək lazım idi - sifariş yaratmaq üçün əməliyyat təxminən 3-5 saniyə çəkə bilər.
Cədvəllərdəki məlumatlar həmişə ən uyğun formada deyildi. Hardasa denormalizasiya etmək lazım idi. Müntəzəm olaraq alınan məlumatların bir hissəsi XML strukturu şəklində bir sütunda idi, bu, icra müddətini artırdı, sorğuları uzatdı və inkişafı çətinləşdirdi.
Eyni masalar çox istehsal edilmişdir heterojen sorğular. Populyar masalar yuxarıda göstərilən cədvəl kimi xüsusilə əziyyət çəkirdi. sifariş və ya masalar pizzacı. Onlar mətbəxdə əməliyyat interfeyslərini, analitikləri göstərmək üçün istifadə edilmişdir. Başqa sayt onlarla əlaqə saxladı (), istənilən vaxt birdən çox sorğunun gələ biləcəyi yer.
Məlumatlar birləşdirilməyib və bazadan istifadə edərək tez bir zamanda bir çox hesablamalar aparıldı. Bu, lazımsız hesablamalar və əlavə yük yaratdı.
Çox vaxt kod bunu edə bilməyəndə verilənlər bazasına gedirdi. Bir yerdə kifayət qədər toplu əməliyyatlar yox idi, haradasa sürətləndirmək və etibarlılığı artırmaq üçün kod vasitəsilə bir sorğunu bir neçəyə yaymaq lazım idi.
Kodda birləşmə və qarışıqlıq
Biznesin öz hissəsinə cavabdeh olmalı olan modullar bunu vicdanla etmədilər. Onların bəzilərində rollar üçün funksiyaların təkrarlanması var idi. Məsələn, öz şəhərində şəbəkənin marketinq fəaliyyətinə cavabdeh olan yerli marketoloq həm “Admin” interfeysindən (təşviqat yaratmaq üçün), həm də “Ofis meneceri” interfeysindən (təşviqatların biznesə təsirini görmək üçün) istifadə etməli idi. Əlbəttə ki, hər iki modul daxilində bonus promosyonları ilə işləyən eyni xidmətdən istifadə edilmişdir.
Xidmətlər (bir monolit böyük layihə daxilindəki siniflər) məlumatlarını zənginləşdirmək üçün bir-birinə zəng edə bilər.
Məlumatları saxlayan model sinifləri ilə, məcəllədə iş başqa cür həyata keçirilirdi. Harada konstruktorlar var idi ki, onların vasitəsilə tələb olunan sahələri müəyyən etmək mümkün idi. Haradasa bu, ictimai mülklər vasitəsilə həyata keçirilirdi. Əlbəttə ki, verilənlər bazasından məlumatların alınması və dəyişdirilməsi müxtəlif idi.
Məntiq ya nəzarətçilərdə, ya da xidmət siniflərində idi.
Bunlar kiçik problemlər kimi görünür, lakin onlar inkişafı xeyli ləngitdi və keyfiyyəti aşağı saldı, qeyri-sabitliyə və səhvlərə səbəb oldu.
Böyük inkişafın mürəkkəbliyi
İnkişafın özündə çətinliklər yarandı. Sistemin müxtəlif bloklarını və paralel olaraq etmək lazım idi. Hər bir komponentin ehtiyaclarını bir koda uyğunlaşdırmaq getdikcə çətinləşdi. Razılaşmaq və eyni zamanda bütün komponentləri sevindirmək asan deyildi. Buna texnologiyada, xüsusən də baza və ön hissə ilə bağlı məhdudiyyətlər əlavə edildi. Xüsusilə müştəri xidmətləri (veb-sayt) baxımından yüksək səviyyəli çərçivələrə doğru jQuery-dən imtina etmək lazım idi.
Sistemin bəzi hissələrində bunun üçün daha uyğun verilənlər bazası istifadə edilə bilər.. Məsələn, daha sonra sifariş səbətini saxlamaq üçün Redis-dən CosmosDB-yə keçmək halımız oldu.
Öz sahələrində iştirak edən komandalar və tərtibatçılar açıq şəkildə həm inkişaf, həm də təqdimat baxımından xidmətləri üçün daha çox muxtariyyət istəyirdilər. Münaqişələri birləşdirin, problemləri buraxın. 5 tərtibatçı üçün bu problem əhəmiyyətsizdirsə, 10 ilə və daha da çox planlaşdırılan böyümə ilə hər şey daha ciddi olacaq. Qarşıda isə mobil tətbiqetmənin inkişafı olacaqdı (2017-ci ildə başlayıb, 2018-ci ildə isə ).
Sistemin müxtəlif hissələri müxtəlif səviyyələrdə sabitlik tələb edirdi, lakin sistemin güclü bağlantısı səbəbindən bunu təmin edə bilmədik. İdarə panelində yeni funksiyanın işlənib hazırlanmasında səhv saytdakı sifarişin qəbulu zamanı baş verə bilərdi, çünki kod ümumi və təkrar istifadə edilə bilər, verilənlər bazası və məlumatlar da eynidir.
Yəqin ki, belə monolit-modullu arxitektura çərçivəsində bu səhvlərdən və problemlərdən qaçmaq mümkün olardı: məsuliyyət bölgüsü aparın, həm kodu, həm də verilənlər bazasını refaktor edin, təbəqələri bir-birindən aydın şəkildə ayırın, keyfiyyətə hər gün nəzarət edin. Ancaq seçilmiş memarlıq həlləri və sistemin funksionallığının sürətlə genişlənməsinə diqqət yetirilməsi sabitlik baxımından problemlərə səbəb oldu.
Ağılın Gücü blogu kassa aparatlarını restoranlarda necə yerləşdirir
Əgər pizzacı şəbəkəsinin böyüməsi (və yüklənməsi) eyni sürətlə davam etsəydi, bir müddət sonra enişlər elə olacaq ki, sistem qalxmayacaq. 2015-ci ilə qədər qarşılaşmağa başladığımız problemləri yaxşı təsvir edir, burada belə bir hekayə var.
bloqda "” bütün şəbəkənin ili üçün gəlir haqqında məlumatları göstərən vidjet idi. Vidcet bu məlumatları təmin edən Dodo ictimai API-yə daxil oldu. Bu statistika hazırda burada mövcuddur . Vidcet hər səhifədə göstərildi və hər 20 saniyədən bir taymerdə sorğular edildi. Sorğu api.dodopizza.ru saytına getdi və xahiş etdi:
-
şəbəkədəki pizzacıların sayı;
-
ilin əvvəlindən şəbəkənin ümumi gəliri;
-
bu gün üçün gəlir.
Gəlirlə bağlı statistika sorğusu birbaşa verilənlər bazasına daxil oldu və sifarişlər haqqında məlumat tələb etməyə, məlumatları tez bir zamanda birləşdirməyə və məbləği verməyə başladı.
Restoranlardakı kassalar eyni sifarişlər cədvəlinə keçdi, bu gün üçün alınan sifarişlərin siyahısını boşaltdı və ona yeni sifarişlər əlavə edildi. Nəzarət-kassa aparatları hər 5 saniyədən bir və ya səhifənin yenilənməsi ilə sorğularını edirdi.
Diaqram belə görünürdü:
Bir payızda Fyodor Ovçinnikov öz bloqunda uzun və məşhur bir məqalə yazdı. Bloqa çoxlu adam gəldi və hər şeyi diqqətlə oxumağa başladı. Gələn insanların hər biri məqaləni oxuyarkən, gəlir vidceti düzgün işləyirdi və hər 20 saniyədən bir API tələb edirdi.
API şəbəkədəki bütün pizzacılar üçün ilin əvvəlindən bəri bütün sifarişlərin cəmini hesablamaq üçün saxlanılan prosedura çağırıb. Toplama çox populyar olan sifarişlər cədvəlinə əsaslanırdı. O vaxt bütün açıq restoranların bütün kassaları ona gedir. Kassalar cavab vermədi, sifarişlər qəbul olunmadı. Onlar da saytdan qəbul edilmədi, izləyicidə görünmədi, növbə meneceri onları interfeysində görə bilmədi.
Bu tək hekayə deyil. 2015-ci ilin payızına qədər hər cümə günü sistemdəki yük kritik idi. Bir neçə dəfə ictimai API-ni söndürdük və bir dəfə hətta saytı söndürməli olduq, çünki heç nə kömək etmədi. Hətta ağır yüklər altında bağlanma əmri olan xidmətlərin siyahısı da var idi.
Bundan sonra yüklərlə və sistemin sabitləşməsi üçün mübarizəmiz başlayır (2015-ci ilin payızından 2018-ci ilin payızına qədər). Elə o zaman oldu"". Bundan əlavə, uğursuzluqlar da bəzən baş verdi, bəziləri çox həssas idi, lakin ümumi qeyri-sabitlik dövrünü artıq keçmiş hesab etmək olar.
Sürətli biznes artımı
Niyə bunu dərhal etmək mümkün olmadı? Sadəcə aşağıdakı qrafiklərə baxın.
Həmçinin 2014-2015-ci illərdə Rumıniyada açılış var idi və ABŞ-da açılış hazırlanırdı.
Şəbəkə çox sürətlə böyüdü, yeni ölkələr açıldı, pizzacıların yeni formatları meydana çıxdı, məsələn, yeməkxanada pizzacı açıldı. Bütün bunlar Dodo IS funksiyalarının genişləndirilməsinə xüsusi diqqət yetirməyi tələb edirdi. Bütün bu funksiyalar olmadan, mətbəxdə izləmə olmadan, sistemdə məhsul və itkilərin uçotunu aparmadan, yemək məhkəməsi zalında sifarişin verilməsini nümayiş etdirmədən, çətin ki, "düzgün" arxitektura və "düzgün" yanaşma haqqında danışaq. inkişaf indi.
Arxitekturaya vaxtında yenidən baxılmasına və ümumiyyətlə texniki problemlərə diqqət yetirilməsinə daha bir maneə 2014-cü ilin böhranı oldu. Bu kimi şeylər komandaların, xüsusən də Dodo Pizza kimi gənc biznesin böyüməsi imkanlarına ağır zərbə vurdu.
Kömək edən sürətli həllər
Problemlərin həlli lazım idi. Şərti olaraq, həlləri 2 qrupa bölmək olar:
-
Yanğını söndürən və kiçik bir təhlükəsizlik marjası verən və dəyişmək üçün bizə vaxt qazandıran sürətli olanlar.
-
Sistemli və buna görə də uzun. Bir sıra modulların yenidən qurulması, monolit arxitekturanın ayrı-ayrı xidmətlərə bölünməsi (onların əksəriyyəti ümumiyyətlə mikro deyil, daha çox makro xidmətlərdir və bununla bağlı nəsə var. ).
Sürətli dəyişikliklərin quru siyahısı aşağıdakı kimidir:
Əsas ustanın ölçüsünü artırın
Əlbəttə ki, yüklərin öhdəsindən gəlmək üçün görülən ilk şey serverin tutumunu artırmaqdır. Bu, əsas verilənlər bazası və veb serverlər üçün edildi. Təəssüf ki, bu, yalnız müəyyən bir həddə qədər mümkündür, sonra çox bahalaşır.
2014-cü ildən Azure-a köçdük, biz də o vaxt məqalədə bu mövzu haqqında yazmışdıq “". Lakin baza üçün serverdə bir sıra artımlardan sonra onlar qiymətə qarşı çıxdılar.
Oxumaq üçün əsas replikalar
Baza üçün iki nüsxə hazırlanmışdır:
Replikanı oxuyun arayış sorğuları üçün. Kataloqları, növü, şəhəri, küçəni, pizzacıları, məhsulları (yavaş-yavaş dəyişdirilən domen) oxumaq üçün və kiçik bir gecikmənin məqbul olduğu interfeyslərdə istifadə olunur. Bu replikalardan 2-si var idi, biz də onların mövcudluğunu ustalar kimi təmin etdik.
Hesabat Sorğuları üçün Replikanı oxuyun. Bu verilənlər bazası daha az əlçatanlığa malik idi, lakin bütün hesabatlar ona getdi. Onların böyük məlumatların yenidən hesablanması üçün ağır sorğuları olsun, lakin onlar əsas verilənlər bazasına və əməliyyat interfeyslərinə təsir göstərmir.
Kodda keşlər
Kodun heç bir yerində heç bir önbellek yox idi (ümumiyyətlə). Bu, yüklənmiş verilənlər bazasına həmişə lazım olmayan əlavə sorğulara səbəb oldu. Keşlər əvvəlcə həm yaddaşda, həm də xarici keş xidmətində idi, yəni Redis. Hər şey zamanla etibarsız oldu, parametrlər kodda göstərildi.
Çoxsaylı arxa serverlər
Artan iş yüklərinin öhdəsindən gəlmək üçün tətbiqin arxa tərəfi də ölçülənməlidir. Bir iis-serverdən klaster yaratmaq lazım idi. Biz yenidən planlaşdırdıq yaddaşdan RedisCache-ə qədər, bu, sadə bir yük balanslaşdırıcısının arxasında bir neçə server yaratmağa imkan verdi. Əvvəlcə eyni Redis keşlər üçün istifadə edildi, sonra bir neçə hissəyə bölündü.
Nəticədə, memarlıq daha mürəkkəbləşdi ...
… lakin gərginliyin bir hissəsi aradan qaldırıldı.
Və sonra üzərimizə götürdüyümüz yüklənmiş komponentləri yenidən düzəltmək lazım idi. Bu barədə növbəti hissədə danışacağıq.
Mənbə: www.habr.com