Habr dünyanı dəyişir. Artıq bir ildən çoxdur ki, blog yazırıq. Təxminən altı ay əvvəl biz Xabrovitlərdən tam məntiqli rəy aldıq: “Dodo, sən hər yerdə deyirsən ki, sənin öz sistemin var. Və bu sistem nədir? Bir pizza zəncirinə niyə ehtiyac var?
Oturduq, düşündük və anladıq ki, siz haqlısınız. Biz hər şeyi barmaqlarımızla izah etməyə çalışırıq, lakin o, cırıq-cırıq halda çıxır və heç bir yerdə sistemin tam təsviri yoxdur. Beləliklə, məlumat toplamaq, müəllifləri axtarmaq və Dodo IS haqqında bir sıra məqalələr yazmaq kimi uzun bir səyahət başladı. Gedək!
Minnətdarlıq: Rəyinizi bizimlə bölüşdüyünüz üçün təşəkkür edirik. Onun sayəsində biz nəhayət sistemi təsvir etdik, texniki radar tərtib etdik və tezliklə proseslərimizin geniş təsvirini təqdim edəcəyik. Sən olmasaydın, daha 5 il orda oturardıq.
Məqalələr silsiləsi "Dodo IS nədir?" haqqında danışır:
- Dodo IS-də erkən monolit (2011-2015). (Davam edir...)
- Arxa ofis yolu: ayrı bazalar və avtobus. (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...)
Başqa bir şey bilmək istəyirsinizsə - şərhlərdə yazın.
Müəllifdən xronoloji təsvirə dair rəy
Mən mütəmadi olaraq yeni işçilər üçün “Sistem arxitekturası” mövzusunda görüş keçirirəm. Biz bunu “Dodo IS Architecture-a giriş” adlandırırıq və bu, yeni tərtibatçılar üçün işə qəbul prosesinin bir hissəsidir. Memarlığımızdan, onun xüsusiyyətlərindən bu və ya digər formada danışarkən mən təsvirə müəyyən tarixi yanaşma doğurmuşam.
Ənənəvi olaraq biz sistemə hansısa məqsədə çatmaq üçün bir-biri ilə qarşılıqlı əlaqədə olan komponentlər (texniki və ya daha yüksək səviyyəli), biznes modulları toplusu kimi baxırıq. Və belə bir görünüş dizayn üçün əsaslandırılıbsa, o zaman təsvir və başa düşmək üçün olduqca uyğun deyil. Burada bir neçə səbəb var:
- Reallıq kağız üzərində olandan fərqlidir. Hər şey nəzərdə tutulduğu kimi alınmır. Və biz bunun əslində necə ortaya çıxması və işləməsi ilə maraqlanırıq.
- Məlumatın ardıcıl təqdimatı. Əslində, əvvəldən indiki vəziyyətə xronoloji olaraq gedə bilərsiniz.
- Sadədən mürəkkəbə. Ümumdünya deyil, amma bizim vəziyyətimizdə belədir. Memarlıq daha sadə yanaşmalardan daha mürəkkəb olanlara keçdi. Çox vaxt mürəkkəbləşmə yolu ilə icra sürəti və sabitlik problemləri, eləcə də qeyri-funksional tələblər siyahısından onlarla digər xüsusiyyətlər həll olunurdu ( Mürəkkəbliyin digər tələblərlə ziddiyyət təşkil etməsi haqqında yaxşı izah edilmişdir).
2011-ci ildə Dodo IS memarlığı belə görünürdü:
2020-ci ilə qədər bu, bir az daha mürəkkəbləşdi və belə oldu:
Bu təkamül necə baş verdi? Sistemin müxtəlif hissələri nə üçün lazımdır? Hansı memarlıq qərarları verildi və niyə? Gəlin bu məqalələr silsiləsində öyrənək.
2016-cı ilin ilk problemləri: niyə xidmətlər monolitdən çıxmalıdır?
Tsikldən ilk məqalələr monolitdən ilk ayrılan xidmətlər haqqında olacaq. Sizi kontekstdə qoymaq üçün sizə deyim ki, 2016-cı ilin əvvəlinə qədər sistemdə hansı problemlərimiz var idi ki, biz xidmətlərin ayrılması ilə məşğul olduq.
Dodo IS-də o dövrdə mövcud olan bütün proqramların öz qeydlərini yazdığı vahid MySql verilənlər bazası. Nəticələr belə idi:
- Ağır yük (sorğuların 85% -i oxumaq üçün nəzərdə tutulmuşdur).
- Baza böyüdü. Bu səbəbdən onun dəyəri və dəstəyi problemə çevrildi.
- Tək uğursuzluq nöqtəsi. Əgər verilənlər bazasına yazan bir proqram birdən-birə bunu daha aktiv şəkildə etməyə başladısa, digər proqramlar bunu öz üzərində hiss etdi.
- Saxlama və sorğularda səmərəsizlik. Çox vaxt məlumatlar bəzi ssenarilər üçün əlverişli olan, digərləri üçün uyğun olmayan bəzi strukturda saxlanılırdı. İndekslər bəzi əməliyyatları sürətləndirir, lakin digərlərini yavaşlata bilər.
- Problemlərin bəziləri tələsik hazırlanmış keşlər və bazalara oxunan replikalarla aradan qaldırıldı (bu ayrıca məqalə olacaq), lakin onlar yalnız vaxt qazanmağa imkan verdi və problemi əsaslı şəkildə həll etmədi.
Problem monolitin özünün olması idi. Nəticələr belə idi:
- Tək və nadir buraxılışlar.
- Çox sayda insanın birgə inkişafında çətinlik.
- Yeni texnologiyalar, yeni çərçivələr və kitabxanalar gətirə bilməmək.
Baza və monolitlə bağlı problemlər dəfələrlə təsvir edilmişdir, məsələn, 2018-ci ilin əvvəlində baş verən qəzalar kontekstində (, и ), buna görə də çox dayanmayacağam. Sadəcə onu deyim ki, biz xidmətləri inkişaf etdirərkən daha çox çeviklik vermək istəyirdik. Əvvəla, bu, bütün sistemdə ən çox yüklənmiş və kök olanlara aiddir - Auth və Tracker.
Arxa Ofis Yolu: Ayrı-ayrı bazalar və avtobus
Fəsil naviqasiyası
Monolit sxemi 2016
Budur Dodo IS 2016 monolitinin əsas blokları və bir az aşağıda onların əsas vəzifələrinin stenoqramı var.
Kassir Çatdırılma. Kuryerlərin uçotunun aparılması, kuryerlərə sifarişlərin verilməsi.
Əlaqə mərkəzi. Operator vasitəsilə sifarişlərin qəbulu.
Sayt. Veb saytlarımız (dodopizza.ru, dodopizza.co.uk, dodopizza.by və s.).
Həqiqi. Arxa ofis üçün avtorizasiya və autentifikasiya xidməti.
Tracker. Mətbəxdə izləyici sifariş edin. Sifariş hazırlayarkən hazırlıq vəziyyətlərinin qeyd edilməsi xidməti.
Restoranın kassası. Restoranda sifarişlərin qəbulu, kassir interfeysləri.
Ixrac. Mühasibat uçotu üçün 1C-də hesabatların yüklənməsi.
Bildirişlər və fakturalar. Mətbəxdə səsli əmrlər (məsələn, “Yeni pizza gəldi”) + kuryerlər üçün faktura çapı.
Növbə meneceri. Növbə menecerinin işi üçün interfeyslər: sifarişlərin siyahısı, performans qrafikləri, işçilərin növbəyə köçürülməsi.
Ofis meneceri. Françayzi və menecerin işi üçün interfeyslər: işçilərin qəbulu, pitseriyanın işi haqqında hesabatlar.
Restoran Hesab Tablosu. Pitseriyalarda televizorlarda menyu nümayişi.
admin. Müəyyən bir pizzacıdakı parametrlər: menyu, qiymətlər, mühasibat uçotu, promo kodlar, promosyonlar, veb sayt bannerləri və s.
İşçinin şəxsi hesabı. İşçilərin iş qrafikləri, işçilər haqqında məlumatlar.
Mətbəx Motivasiya Şurası. Mətbəxdə asılan və pizza istehsalçılarının sürətini göstərən ayrıca ekran.
Rabitə. SMS və e-poçt göndərilməsi.
Fayl Storage. Statik faylların qəbulu və verilməsi üçün öz xidməti.
Problemləri həll etmək üçün ilk cəhdlər bizə kömək etdi, lakin onlar yalnız müvəqqəti möhlət idi. Onlar sistem həllərinə çevrilmədilər, buna görə də əsaslarla bir şey etmək lazım olduğu aydın idi. Məsələn, ümumi məlumat bazasını daha bir neçə ixtisaslaşmışa bölmək.
Monoliti boşaltmağa başlayın: Auth və Tracker Ayrılması
Daha sonra verilənlər bazasından digərlərinə nisbətən daha çox qeyd edən və oxuyan əsas xidmətlər:
- Auth. Arxa ofis üçün avtorizasiya və autentifikasiya xidməti.
- İzləyici. Mətbəxdə izləyici sifariş edin. Sifariş hazırlayarkən hazırlıq vəziyyətlərinin qeyd edilməsi xidməti.
Auth nə edir?
Auth, istifadəçilərin arxa ofisə daxil olduğu xidmətdir (müştəri tərəfində ayrıca müstəqil giriş var). Tələb olunan giriş hüquqlarının mövcudluğuna və bu hüquqların sonuncu girişdən sonra dəyişmədiyinə əmin olmaq üçün sorğuda da tələb olunur. Onun vasitəsilə cihazlar pizzacıya daxil olur.
Məsələn, zalda asılmış televizorda bitmiş sifarişlərin statuslarının əks olunduğu ekran açmaq istəyirik. Sonra auth.dodopizza.ru-nu açırıq, "Cihaz kimi daxil ol" seçin, növbə menecerinin kompüterində cihazın (cihazın) növünü göstərən xüsusi bir səhifəyə daxil edilə bilən bir kod görünür. Televiziya özü pizzacısının istədiyiniz interfeysinə keçəcək və orada sifarişləri hazır olan müştərilərin adlarını göstərməyə başlayacaq.
Yüklər haradandır?
Bek ofisə daxil olan hər bir istifadəçi verilənlər bazasına, hər sorğu üçün istifadəçi cədvəlinə keçir, sql sorğusu vasitəsilə istifadəçini çıxarır və onun bu səhifəyə lazımi giriş və hüquqların olub olmadığını yoxlayır.
Cihazların hər biri yalnız cihaz cədvəli ilə eyni şeyi edir, onun rolunu və girişini yoxlayır. Əsas verilənlər bazasına çoxlu müraciətlər onun yüklənməsinə və bu əməliyyatlar üçün ümumi verilənlər bazası resurslarının israfına səbəb olur.
Auth boşaldılır
Auth-un təcrid olunmuş domeni var, yəni istifadəçilər, girişlər və ya cihazlar haqqında məlumatlar xidmətə daxil olur (hələlik) və orada qalır. Əgər kiməsə ehtiyac varsa, o zaman məlumat üçün bu xidmətə gedəcək.
OLDU. Orijinal iş sxemi belə idi:
Bunun necə işlədiyini bir az izah etmək istərdim:
- Kənardan sorğu arxa tərəfə gəlir (Asp.Net MVC var), özü ilə Redis(1)-dən sessiya məlumatlarını almaq üçün istifadə olunan sessiya kukisini gətirir. O, ya girişlər haqqında məlumat ehtiva edir, sonra nəzarətçiyə giriş açıqdır (3,4), ya da yox.
- Giriş yoxdursa, avtorizasiya prosedurundan keçməlisiniz. Burada, sadəlik üçün, giriş səhifəsinə keçid olsa da, eyni atributda yolun bir hissəsi kimi göstərilir. Müsbət bir ssenari halında, düzgün tamamlanan bir seans alacağıq və Backoffice Controller-ə keçəcəyik.
- Məlumat varsa, o zaman istifadəçi məlumat bazasında uyğunluğunu yoxlamaq lazımdır. Onun rolu dəyişib, indi onu səhifəyə buraxmaq olmazmı? Bu halda, sessiyanı (1) qəbul etdikdən sonra birbaşa verilənlər bazasına daxil olmaq və autentifikasiya məntiqi qatından (2) istifadə edərək istifadəçinin girişini yoxlamaq lazımdır. Sonra, ya giriş səhifəsinə keçin, ya da nəzarətçiyə keçin. Belə sadə bir sistem, lakin olduqca standart deyil.
- Əgər bütün prosedurlar keçibsə, onda biz kontrollerlər və üsullardakı məntiqə daha da keçirik.
İstifadəçi məlumatları bütün digər məlumatlardan ayrılır, ayrıca üzvlük cədvəlində saxlanılır, AuthService məntiq səviyyəsindən funksiyalar api metodlarına çevrilə bilər. Domen sərhədləri olduqca aydın şəkildə müəyyən edilmişdir: istifadəçilər, onların rolları, giriş məlumatları, girişin verilməsi və ləğv edilməsi. Hər şey elə görünür ki, onu ayrı bir xidmətdə çıxarmaq olar.
OLMAQ. Beləliklə etdilər:
Bu yanaşmanın bir sıra problemləri var. Məsələn, proses daxilində metodu çağırmaq http vasitəsilə xarici xidmətə zəng etməklə eyni deyil. Latency, etibarlılıq, davamlılıq, əməliyyatın şəffaflığı tamamilə fərqlidir. Andrey Morevski öz məruzəsində belə problemlərdən daha ətraflı danışıb. .
Autentifikasiya xidməti və onunla birlikdə cihaz xidməti arxa ofis üçün, yəni istehsalda istifadə olunan xidmətlər və interfeyslər üçün istifadə olunur. Müştəri xidmətləri üçün autentifikasiya (sayt və ya mobil proqram kimi) Auth istifadə etmədən ayrıca baş verir. Ayrılma təxminən bir il çəkdi və indi biz yenidən bu mövzu ilə məşğul oluruq, sistemi yeni autentifikasiya xidmətlərinə (standart protokollarla) köçürürük.
Ayrılıq niyə bu qədər uzandı?
Bu yolda bizi ləngidən bir çox problemlər var idi:
- Biz ölkəyə aid verilənlər bazalarından istifadəçi, cihaz və autentifikasiya məlumatlarını bir yerə köçürmək istədik. Bunun üçün biz bütün cədvəlləri və istifadəni int identifikatorundan qlobal UUId identifikatoruna çevirməli olduq (bu kodu bu yaxınlarda yenidən işlədik) və açıq mənbə layihəsi ). İstifadəçi məlumatlarının saxlanması (bu, şəxsi məlumat olduğundan) öz məhdudiyyətlərinə malikdir və bəzi ölkələr üçün onları ayrıca saxlamaq lazımdır. Lakin istifadəçinin qlobal identifikatoru olmalıdır.
- Verilənlər bazasındakı bir çox cədvəldə əməliyyatı yerinə yetirən istifadəçi haqqında audit məlumatı var. Bu, ardıcıllıq üçün əlavə mexanizm tələb etdi.
- Api-xidmətlərin yaradılmasından sonra uzun və tədricən başqa sistemə keçid dövrü olmuşdur. Kommutasiya istifadəçilər üçün qüsursuz olmalı və əl işi tələb olunmalı idi.
Bir pizzacıda cihazın qeydiyyatı sxemi:
Auth and Devices xidmətinin çıxarılmasından sonra ümumi arxitektura:
Qeyd. 2020-ci il üçün biz OAuth 2.0 avtorizasiya standartına əsaslanan Auth proqramının yeni versiyası üzərində işləyirik. Bu standart olduqca mürəkkəbdir, lakin keçid autentifikasiyası xidmətinin inkişafı üçün faydalıdır. Məqalədə "» biz Aleksey Çernyaev standart haqqında mümkün qədər sadə və aydın danışmağa çalışdıq ki, onu öyrənməyə vaxtınıza qənaət edəsiniz.
Tracker nə edir?
İndi yüklənmiş xidmətlərin ikincisi haqqında. İzləyici ikili rol oynayır:
- Bir tərəfdən, onun vəzifəsi mətbəxdəki işçilərə hazırda hansı sifarişlərin işlədiyini, hansı məhsulların indi bişirilməli olduğunu göstərməkdir.
- Digər tərəfdən, mətbəxdəki bütün prosesləri rəqəmsallaşdırmaq.
Sifarişdə yeni məhsul görünəndə (məsələn, pizza), o, Rolling out izləyici stansiyasına gedir. Bu stansiyada lazımi ölçüdə bir çörək götürüb yuvarlayan bir pizza istehsalçısı var, bundan sonra izləyici planşetdə tapşırığını yerinə yetirdiyini qeyd edir və yuvarlanan xəmir əsasını növbəti stansiyaya - “İnsiasiya”ya köçürür. .
Orada növbəti pizza istehsalçısı pizzanı doldurur, sonra planşetdə tapşırığı yerinə yetirdiyini qeyd edir və pizzanı sobaya qoyur (bu da planşetdə qeyd edilməli olan ayrıca stansiyadır). Belə bir sistem Dododa ən əvvəldən və Dodo İD-nin mövcud olduğu ilk vaxtdan mövcud idi. Bu, bütün əməliyyatları tam izləməyə və rəqəmsallaşdırmağa imkan verir. Bundan əlavə, izləyici müəyyən bir məhsulun necə bişirilməsini təklif edir, hər bir məhsul növünü onun istehsal sxemlərinə uyğun olaraq istiqamətləndirir, məhsul üçün optimal bişirmə vaxtını saxlayır və məhsul üzərində bütün əməliyyatları izləyir.
Planşetin ekranı "Raskatka" izləyicisinin stansiyasında belə görünür
Yüklər haradandır?
Pizzaxanaların hər birində izləyicisi olan təxminən beş tablet var. 2016-cı ildə 100-dən çox pizzaçımız var idi (hazırda isə 600-dən çox). Planşetlərin hər biri 10 saniyədə bir dəfə arxa plana sorğu göndərir və sifariş cədvəlindən (müştəri və ünvanla əlaqə), sifariş tərkibi (məhsulla əlaqə və miqdarın göstərilməsi), motivasiya uçotu cədvəlindən məlumatları silir. basma vaxtı orada izlənilir). Pizza istehsalçısı izləyicidə məhsula kliklədikdə, bütün bu cədvəllərdəki qeydlər yenilənir. Sifariş cədvəli ümumidir, sifariş qəbul edərkən əlavələr, sistemin digər hissələrindən yeniləmələr və çoxsaylı oxunuşlar, məsələn, pizzacıda asılan və hazır sifarişləri müştərilərə göstərən televizorda.
Yüklərlə mübarizə dövründə, hər şey və hər şey önbelleğe alındıqda və bazanın asinxron replikasına köçürüldükdə, izləyici ilə bu əməliyyatlar master bazaya getməyə davam etdi. Heç bir gecikmə olmamalıdır, məlumatlar aktual olmalıdır, sinxronizasiya yolverilməzdir.
Həmçinin, öz cədvəllərinin və onların üzərində indekslərin olmaması onların istifadəsi üçün uyğunlaşdırılmış daha konkret sorğular yazmağa imkan vermirdi. Məsələn, sifariş masasında pizzacı üçün indeksin olması izləyici üçün səmərəli ola bilər. Biz həmişə pizzacı sifarişlərini izləyici verilənlər bazasından silirik. Eyni zamanda, sifariş almaq üçün onun hansı pizzacıya düşməsi o qədər də önəmli deyil, bu sifarişi hansı müştərinin etdiyi daha önəmlidir. Və o deməkdir ki, orada müştərinin indeksi lazımdır. Həm də izləyicinin çap edilmiş qəbzin və ya sifarişlə əlaqəli bonus promosyonlarının id-sini sifariş cədvəlində saxlamağa ehtiyac yoxdur. Bu məlumat izləyici xidmətimiz üçün maraqlı deyil. Ümumi monolit verilənlər bazasında cədvəllər yalnız bütün istifadəçilər arasında kompromis ola bilər. Bu, ilkin problemlərdən biri idi.
OLDU. Orijinal memarlıq belə idi:
Ayrı-ayrı proseslərə ayrıldıqdan sonra belə, kod bazasının əksəriyyəti müxtəlif xidmətlər üçün ümumi olaraq qaldı. Nəzarətçilərin altındakı hər şey tək idi və eyni depoda yaşayırdı. Biz ümumi xidmət üsullarından, anbarlardan, ümumi masaların yerləşdiyi ümumi bazadan istifadə etdik.
Yükləmə İzləyicisi
İzləyicinin əsas problemi ondan ibarətdir ki, verilənlər müxtəlif verilənlər bazaları arasında sinxronlaşdırılmalıdır. Bu həm də onun Auth xidmətinin ayrılmasından əsas fərqidir, sıra və onun statusu dəyişə bilər və müxtəlif xidmətlərdə göstərilməlidir.
Restoranın kassasında sifariş qəbul edirik (bu xidmətdir), o, verilənlər bazasında "Qəbul edildi" statusunda saxlanılır. Bundan sonra o, statusunu daha bir neçə dəfə dəyişəcəyi izləyiciyə getməlidir: "Mətbəx" dən "Paketlənmiş" a. Eyni zamanda, sifarişlə Kassir və ya Shift Manager interfeysindən bəzi xarici təsirlər baş verə bilər. Sifariş statuslarını cədvəldə təsviri ilə verəcəyəm:
Sifariş statuslarının dəyişdirilməsi sxemi belə görünür:
Fərqli sistemlər arasında statuslar dəyişir. Və burada izləyici məlumatların bağlandığı son sistem deyil. Belə bir vəziyyətdə bölmə üçün bir neçə mümkün yanaşma gördük:
- Biz bütün sifariş hərəkətlərini bir xidmətdə cəmləşdiririk. Bizim vəziyyətimizdə, bu seçim sifarişlə işləmək üçün çox xidmət tələb edir. Onun üzərində dayansaydıq, ikinci monolit əldə edərdik. Problemi həll etməyəcəkdik.
- Bir sistem digərinə zəng edir. İkinci seçim artıq daha maraqlıdır. Bununla birlikdə zəng zəncirləri mümkündür (), komponentlərin əlaqəsi daha yüksəkdir, idarə etmək daha çətindir.
- Biz tədbirlər təşkil edirik və hər bir xidmət bu tədbirlər vasitəsilə digəri ilə əlaqə saxlayır. Nəticədə, bütün xidmətlər bir-biri ilə hadisələr mübadiləsi aparmağa başlayan üçüncü seçim seçildi.
Üçüncü variantı seçməyimiz o demək idi ki, izləyicinin öz verilənlər bazası olacaq və hər bir sifariş dəyişikliyi üçün o, bu barədə digər xidmətlərin abunə olduğu və master verilənlər bazasına daxil olan hadisə göndərəcək. Bunun üçün bizə xidmətlər arasında mesajların çatdırılmasını təmin edəcək bəzi xidmət lazım idi.
O vaxta qədər biz artıq yığında RabbitMQ-ya malik idik, buna görə də ondan mesaj brokeri kimi istifadə etmək üçün son qərar verildi. Diaqramda sifarişin Restoran Kassirindən Tracker vasitəsilə keçidi göstərilir, burada o, statusunu dəyişir və Menecer Sifarişləri interfeysində göstərilir. OLMAQ:
Addım-addım yolu sifariş edin
Sifariş yolu sifariş mənbəyi xidmətlərindən birində başlayır. Budur restoranın kassiri:
- Kassada sifariş tamamilə hazırdır və onu izləyiciyə göndərməyin vaxtıdır. İzləyicinin abunə olduğu hadisə atılır.
- Özü üçün sifariş qəbul edən izləyici onu öz verilənlər bazasında saxlayır, “Sifariş Tracker tərəfindən qəbul edilir” hadisəsini yaradır və RMQ-ya göndərir.
- Hər sifariş üzrə hadisə avtobusuna artıq abunə olan bir neçə işləyici var. Bizim üçün monolit baza ilə sinxronizasiya edən vacibdir.
- İşləyici hadisəni qəbul edir, ondan onun üçün əhəmiyyətli olan məlumatları seçir: bizim vəziyyətimizdə bu, "İzləyici tərəfindən qəbul edilib" əmrinin statusudur və əsas verilənlər bazasında onun sifariş obyektini yeniləyir.
Əgər kiməsə monolit masa sifarişlərindən sifariş lazımdırsa, onu oradan da oxuya bilərsiniz. Məsələn, Shift Manager-dəki Sifarişlər interfeysi buna ehtiyac duyur:
Bütün digər xidmətlər də izləyicidən hadisələrin özləri üçün istifadə edilməsinə abunə ola bilər.
Əgər bir müddətdən sonra sifariş işə salınarsa, onun statusu əvvəlcə verilənlər bazasında (Tracker verilənlər bazası) dəyişir, sonra isə dərhal "Sifarişdə Progress" hadisəsi yaradılır. O, həmçinin RMQ-yə daxil olur, buradan monolit verilənlər bazasında sinxronlaşdırılır və digər xidmətlərə çatdırılır. Yol boyu müxtəlif problemlər ola bilər, onlar haqqında daha ətraflı məlumatı Zhenya Peşkovun hesabatında tapmaq olar .
Auth və Tracker-də dəyişikliklərdən sonra son arxitektura
Aralıq nəticəni yekunlaşdıraraq: Əvvəlcə Dodo IS sisteminin doqquz illik tarixini bir məqalədə toplamaq fikrim var idi. Mən təkamül mərhələləri haqqında tez və sadə danışmaq istədim. Ancaq material üçün oturaraq hər şeyin göründüyündən daha mürəkkəb və maraqlı olduğunu başa düşdüm.
Bu cür materialın faydaları (və ya olmaması) haqqında düşünərək, hadisələrin tam salnaməsi, ətraflı retrospektivlər və keçmiş qərarlarımın təhlili olmadan davamlı inkişafın mümkün olmadığı qənaətinə gəldim.
Ümid edirəm ki, yolumuzu öyrənmək sizin üçün faydalı və maraqlı oldu. İndi növbəti məqalədə Dodo IS sisteminin hansı hissəsini təsvir edəcəyim seçim qarşısındayam: şərhlərdə yazın və ya səs verin.
Sorğuda yalnız qeydiyyatdan keçmiş istifadəçilər iştirak edə bilər. xahiş edirəm.
Növbəti məqalədə Dodo IS-in hansı hissəsi haqqında bilmək istərdiniz?
-
24,1%Dodo IS-də erkən monolit (2011-2015)14
-
24,1%İlk problemlər və onların həlli yolları (2015-2016)14
-
20,7%Müştəri tərəfi yol: baza üzərində fasad (2016-2017)12
-
36,2%Əsl mikroxidmətlərin tarixi (2018-2019)21
-
44,8%Monolitin tam kəsilməsi və arxitekturanın sabitləşdirilməsi26
-
29,3%Sistemin inkişafı üçün gələcək planlar haqqında17
-
19,0%Dodo IS11 haqqında heç nə bilmək istəmirəm
58 istifadəçi səs verib. 6 istifadəçi bitərəf qalıb.
Mənbə: www.habr.com