Habr dunyoni o'zgartirmoqda. Biz bir yildan ortiq vaqtdan beri blog yuritamiz. Taxminan olti oy oldin biz Xabrovitlardan mutlaqo mantiqiy fikr-mulohaza oldik: “Dodo, siz hamma joyda o'z tizimingiz borligini aytasiz. Va bu tizim nima? Va nima uchun pizza tarmog'iga kerak?
Biz o'tirdik, o'yladik va sizning haqligingizni angladik. Biz barmoqlarimizdagi hamma narsani tushuntirishga harakat qilamiz, lekin u yirtilgan bo'laklarga bo'linadi va hech qanday joyda tizimning to'liq tavsifi yo'q. Shunday qilib, ma'lumot to'plash, mualliflarni qidirish va Dodo IS haqida bir qator maqolalar yozish bo'yicha uzoq sayohat boshlandi. Qani ketdik!
Minnatdorchilik: fikr-mulohazalaringizni biz bilan baham ko'rganingiz uchun tashakkur. Unga rahmat, biz nihoyat tizimni tasvirlab berdik, texnik radar tuzdik va tez orada jarayonlarimizning keng tavsifini e'lon qilamiz. Siz bo'lmaganingizda yana 5 yil o'tirgan bo'lardik.
Maqolalar turkumi "Dodo IS nima?" haqida hikoya qiladi:
- Dodo ISda dastlabki monolit (2011-2015). (Jarayonda...)
- Orqa ofis yo'li: alohida bazalar va avtobus. (Siz bu yerdasiz)
- Mijoz tomoni yo'li: poydevor ustidagi fasad (2016-2017). (Jarayonda...)
- Haqiqiy mikroservislar tarixi. (2018-2019). (Jarayonda...)
- Monolitni arralash va arxitekturani barqarorlashtirish tugallandi. (Jarayonda...)
Agar siz boshqa narsani bilmoqchi bo'lsangiz - izohlarda yozing.
Muallifning xronologik tavsifi bo'yicha fikr
Men muntazam ravishda yangi xodimlar uchun "Tizim arxitekturasi" mavzusida uchrashuv o'tkazaman. Biz uni “Dodo IS Arxitekturasiga kirish” deb ataymiz va bu yangi ishlab chiquvchilar uchun ishga tushirish jarayonining bir qismidir. Arxitekturamiz, uning o‘ziga xos xususiyatlari haqida u yoki bu shaklda gapirar ekanman, tavsifga o‘ziga xos tarixiy yondashuv tug‘ildi.
An'anaga ko'ra, biz tizimga biron bir maqsadga erishish uchun bir-biri bilan o'zaro ta'sir qiluvchi komponentlar (texnik yoki yuqori darajadagi), biznes modullar to'plami sifatida qaraymiz. Va agar bunday ko'rinish dizayn uchun oqlangan bo'lsa, unda tavsif va tushunish uchun unchalik mos kelmaydi. Bu erda bir nechta sabablar bor:
- Haqiqat qog'ozdagidan farq qiladi. Hamma narsa mo'ljallangandek ishlamaydi. Va biz bu aslida qanday paydo bo'lganligi va ishlashi bilan qiziqamiz.
- Axborotni izchil taqdim etish. Aslida, siz boshidan hozirgi holatga qadar xronologik bo'lishingiz mumkin.
- Oddiydan murakkabgacha. Umumjahon emas, lekin bizning holatlarimizda shunday. Arxitektura oddiyroq yondashuvlardan murakkabroq yondashuvlarga o'tdi. Ko'pincha murakkablik tufayli amalga oshirish tezligi va barqarorligi muammolari, shuningdek, funktsional bo'lmagan talablar ro'yxatidan o'nlab boshqa xususiyatlar hal qilindi ( murakkablikni boshqa talablarga qarama-qarshi qo'yish haqida yaxshi aytilgan).
2011 yilda Dodo IS arxitekturasi quyidagicha ko'rinishga ega edi:
2020 yilga kelib, u biroz murakkablashdi va shunday bo'ldi:
Bu evolyutsiya qanday sodir bo'ldi? Nima uchun tizimning turli qismlari kerak? Qanday me'moriy qarorlar qabul qilindi va nima uchun? Keling, ushbu maqolalar turkumida bilib olaylik.
2016 yilning birinchi muammolari: nima uchun xizmatlar monolitni tark etishi kerak
Tsiklning birinchi maqolalari monolitdan birinchi bo'lib ajralib chiqqan xizmatlar haqida bo'ladi. Sizni kontekstga solish uchun men sizga 2016 yil boshida tizimda qanday muammolarga duch kelganimizni, xizmatlarni ajratish bilan shug'ullanishimiz kerakligini aytaman.
Yagona MySql ma'lumotlar bazasi, unda Dodo ISda o'sha paytda mavjud bo'lgan barcha ilovalar o'z yozuvlarini yozgan. Buning oqibatlari:
- Og'ir yuk (so'rovlarning 85% o'qishga to'g'ri keladi).
- Baza o'sdi. Shu sababli uning narxi va qo'llab-quvvatlashi muammoga aylandi.
- Bitta muvaffaqiyatsizlik nuqtasi. Agar ma'lumotlar bazasiga yozayotgan bitta dastur to'satdan buni faolroq qila boshlagan bo'lsa, boshqa ilovalar buni o'zlari his qildilar.
- Saqlash va so'rovlarning samarasizligi. Ko'pincha ma'lumotlar ba'zi stsenariylar uchun qulay bo'lgan, ammo boshqalar uchun mos bo'lmagan ba'zi tuzilmalarda saqlanadi. Indekslar ba'zi operatsiyalarni tezlashtiradi, lekin boshqalarni sekinlashtirishi mumkin.
- Ba'zi muammolar shoshilinch ravishda yaratilgan keshlar va bazalarga o'qish-replikatsiyalar orqali olib tashlandi (bu alohida maqola bo'ladi), lekin ular faqat vaqtni orttirishga imkon berdi va muammoni tubdan hal qilmadi.
Muammo monolitning o'zi mavjudligi edi. Buning oqibatlari:
- Yagona va noyob nashrlar.
- Ko'p sonli odamlarning birgalikdagi rivojlanishidagi qiyinchilik.
- Yangi texnologiyalar, yangi ramkalar va kutubxonalarni olib kela olmaslik.
Baza va monolit bilan bog'liq muammolar ko'p marta tasvirlangan, masalan, 2018 yil boshida avariyalar kontekstida (, и ), shuning uchun men ko'p to'xtalmayman. Aytmoqchimanki, biz xizmatlarni ishlab chiqishda ko'proq moslashuvchanlikni berishni xohladik. Avvalo, bu butun tizimda eng yuklangan va ildiz otganlarga tegishli - Auth va Tracker.
Orqa ofis yo'li: alohida bazalar va avtobus
Navigatsiya bo'limi
Monolit sxemasi 2016
Bu erda Dodo IS 2016 monolitining asosiy bloklari va quyida ularning asosiy vazifalari transkripti keltirilgan.
Kassir yetkazib berish. Kuryerlarni hisobga olish, kurerlarga buyurtmalar berish.
Aloqa markazi. Operator orqali buyurtmalarni qabul qilish.
sayt. Bizning veb-saytlarimiz (dodopizza.ru, dodopizza.co.uk, dodopizza.by va boshqalar).
Haqiqat. Bek ofis uchun avtorizatsiya va autentifikatsiya xizmati.
Treker. Oshxonada trekerga buyurtma bering. Buyurtmani tayyorlashda tayyorlik holatini belgilash xizmati.
Restoranning kassasi. Restoranda buyurtmalarni qabul qilish, kassir interfeyslari.
Eksport. Buxgalteriya hisobi uchun 1C da hisobotlarni yuklash.
Bildirishnomalar va hisob-fakturalar. Oshxonadagi ovozli buyruqlar (masalan, "Yangi pizza keldi") + kurerlar uchun fakturani chop etish.
Shift menejeri. Smenali boshqaruvchining ishi uchun interfeyslar: buyruqlar ro'yxati, ishlash grafiklari, xodimlarni smenaga o'tkazish.
Offis menedjeri. Franchayzi va menejerning ishi uchun interfeyslar: xodimlarni qabul qilish, pitseriya ishi bo'yicha hisobotlar.
Restoran reytingi. Pitseriyalardagi televizorlarda menyu ko'rinishi.
admin. Muayyan pitseriyadagi sozlamalar: menyu, narxlar, buxgalteriya hisobi, promo-kodlar, aktsiyalar, veb-sayt bannerlari va boshqalar.
Xodimning shaxsiy hisobi. Xodimlarning ish jadvallari, xodimlar haqida ma'lumot.
Oshxona motivatsiya kengashi. Oshxonada osilgan va pizza ishlab chiqaruvchilarning tezligini ko'rsatadigan alohida ekran.
aloqa. SMS va elektron pochta xabarlarini yuborish.
FileStorage. Statik fayllarni qabul qilish va chiqarish uchun shaxsiy xizmat.
Muammolarni hal qilishning birinchi urinishlari bizga yordam berdi, ammo ular faqat vaqtinchalik muhlat edi. Ular tizimli echimlarga aylanmadi, shuning uchun bazalar bilan nimadir qilish kerakligi aniq edi. Masalan, umumiy ma'lumotlar bazasini yana bir nechta ixtisoslashganlarga bo'lish.
Monolitni tushirishni boshlash: autentifikatsiya va kuzatuvchini ajratish
Keyinchalik ma'lumotlar bazasidan boshqalarga qaraganda ko'proq yozib olgan va o'qigan asosiy xizmatlar:
- Avtor. Bek ofis uchun avtorizatsiya va autentifikatsiya xizmati.
- Kuzatuvchi. Oshxonada trekerga buyurtma bering. Buyurtmani tayyorlashda tayyorlik holatini belgilash xizmati.
Auth nima qiladi?
Auth - bu foydalanuvchilar orqa ofisga kiradigan xizmat (mijoz tomonida alohida mustaqil kirish joyi mavjud). Shuningdek, so'rovda kerakli kirish huquqlari mavjudligiga va oxirgi logindan keyin bu huquqlar o'zgarmaganligiga ishonch hosil qilish uchun chaqiriladi. U orqali qurilmalar pitseriyaga kiradi.
Misol uchun, biz zalda osilgan televizorda tayyor buyurtmalar holati ko'rsatilgan displeyni ochmoqchimiz. Keyin biz auth.dodopizza.ru ni ochamiz, "Qurilma sifatida kirish" ni tanlaymiz, shift menejerining kompyuteridagi maxsus sahifaga kiritilishi mumkin bo'lgan kod paydo bo'lib, qurilma (qurilma) turini ko'rsatadi. Televizorning o'zi o'zining pitseriyasining kerakli interfeysiga o'tadi va u erda buyurtmalari tayyor bo'lgan mijozlarning ismlarini ko'rsatishni boshlaydi.
Yuklar qayerdan?
Bek ofisga kirgan har bir foydalanuvchi ma'lumotlar bazasiga, har bir so'rov bo'yicha foydalanuvchilar jadvaliga o'tadi, foydalanuvchini sql so'rovi orqali chiqaradi va uning ushbu sahifaga kerakli kirish huquqi va huquqlari borligini tekshiradi.
Qurilmalarning har biri faqat qurilma jadvali bilan bir xil ishlaydi, uning rolini va unga kirishni tekshiradi. Asosiy ma'lumotlar bazasiga ko'plab so'rovlar uning yuklanishiga va ushbu operatsiyalar uchun umumiy ma'lumotlar bazasi resurslarining isrof qilinishiga olib keladi.
Avtorni tushirish
Auth alohida domenga ega, ya'ni foydalanuvchilar, loginlar yoki qurilmalar haqidagi ma'lumotlar xizmatga kiradi (hozircha) va u erda qoladi. Agar kimdir ularga kerak bo'lsa, u ma'lumotlar uchun ushbu xizmatga boradi.
EDI. Dastlabki ish sxemasi quyidagicha edi:
Bu qanday ishlashini bir oz tushuntirmoqchiman:
- Tashqaridan so'rov backendga keladi (Asp.Net MVC mavjud), o'zi bilan Redis(1) dan sessiya ma'lumotlarini olish uchun foydalaniladigan sessiya cookie faylini olib keladi. U kirishlar haqida ma'lumotni o'z ichiga oladi va keyin boshqaruvchiga kirish ochiq (3,4) yoki yo'q.
- Agar kirish imkoni bo'lmasa, siz avtorizatsiya jarayonidan o'tishingiz kerak. Bu erda, soddaligi uchun, u bir xil atributdagi yo'lning bir qismi sifatida ko'rsatilgan, garchi u kirish sahifasiga o'tishdir. Ijobiy stsenariy bo'lsa, biz to'g'ri yakunlangan seansni olamiz va Backoffice Controller-ga o'tamiz.
- Agar ma'lumotlar mavjud bo'lsa, uni foydalanuvchi ma'lumotlar bazasida tegishliligini tekshirishingiz kerak. Uning roli o'zgarganmi, endi uni sahifaga kiritmaslik kerakmi? Bunday holda, sessiyani (1) olgandan so'ng, siz to'g'ridan-to'g'ri ma'lumotlar bazasiga o'tishingiz va autentifikatsiya mantiqiy qatlami (2) yordamida foydalanuvchining kirishini tekshirishingiz kerak. Keyin, kirish sahifasiga yoki kontrollerga o'ting. Bunday oddiy tizim, lekin unchalik standart emas.
- Agar barcha protseduralar o'tgan bo'lsa, biz kontrollerlar va usullarda mantiqqa o'tamiz.
Foydalanuvchi ma'lumotlari boshqa barcha ma'lumotlardan ajratilgan, ular alohida a'zolik jadvalida saqlanadi, AuthService mantiqiy qatlamining funktsiyalari api usullariga aylanishi mumkin. Domen chegaralari juda aniq belgilangan: foydalanuvchilar, ularning rollari, kirish ma'lumotlari, ruxsat berish va bekor qilish. Hammasi shunday ko'rinadiki, uni alohida xizmatda chiqarish mumkin.
BO'LING. Shunday qilib, ular shunday qilishdi:
Ushbu yondashuv bir qator muammolarga ega. Masalan, jarayon ichidagi usulni chaqirish http orqali tashqi xizmatni chaqirish bilan bir xil emas. Operatsiyaning kechikishi, ishonchliligi, barqarorligi, shaffofligi butunlay boshqacha. Andrey Morevskiy o‘z ma’ruzasida ana shunday muammolar haqida batafsil to‘xtalib o‘tdi. .
Autentifikatsiya xizmati va u bilan birga qurilma xizmati orqa ofis uchun, ya'ni ishlab chiqarishda ishlatiladigan xizmatlar va interfeyslar uchun ishlatiladi. Mijoz xizmatlari uchun autentifikatsiya (masalan, veb-sayt yoki mobil ilova) Auth-dan foydalanmasdan alohida amalga oshiriladi. Ajratish taxminan bir yil davom etdi va endi biz yana ushbu mavzu bilan shug'ullanmoqdamiz, tizimni yangi autentifikatsiya xizmatlariga (standart protokollar bilan) o'tkazamiz.
Nega ajralish shunchalik uzoq davom etdi?
Yo'lda bizni sekinlashtirgan ko'plab muammolar bor edi:
- Biz foydalanuvchi, qurilma va autentifikatsiya maʼlumotlarini mamlakatga oid maʼlumotlar bazalaridan bittasiga koʻchirmoqchi edik. Buning uchun biz barcha jadvallar va foydalanishni int identifikatoridan global UUId identifikatoriga tarjima qilishimiz kerak edi (yaqinda ushbu kod qayta ishlangan va ochiq kodli loyiha ). Foydalanuvchi ma'lumotlarini saqlash (bu shaxsiy ma'lumotlar bo'lgani uchun) o'z cheklovlariga ega va ba'zi mamlakatlar uchun ularni alohida saqlash kerak. Lekin foydalanuvchining global identifikatori bo'lishi kerak.
- Ma'lumotlar bazasidagi ko'plab jadvallar operatsiyani bajargan foydalanuvchi haqida audit ma'lumotlariga ega. Bu izchillik uchun qo'shimcha mexanizmni talab qildi.
- Api-servislar yaratilgandan keyin uzoq va bosqichma-bosqich boshqa tizimga o'tish davri bo'ldi. Kommutatsiya foydalanuvchilar uchun muammosiz bo'lishi va qo'lda ishlashni talab qilishi kerak edi.
Pitseriyada qurilmani ro'yxatdan o'tkazish sxemasi:
Auth va Devices xizmatidan olingandan so'ng umumiy arxitektura:
nota. 2020-yilda biz OAuth 2.0 avtorizatsiya standartiga asoslangan Authning yangi versiyasi ustida ishlamoqdamiz. Ushbu standart juda murakkab, ammo u o'tish orqali autentifikatsiya xizmatini ishlab chiqish uchun foydalidir. Maqolada "» Biz Aleksey Chernyaev standartni o'rganishga vaqtingizni tejashingiz uchun imkon qadar sodda va aniq aytib berishga harakat qildik.
Tracker nima qiladi?
Endi yuklangan xizmatlarning ikkinchisi haqida. Kuzatuvchi ikki tomonlama rolni bajaradi:
- Bir tomondan, uning vazifasi oshxonadagi xodimlarga hozirda qanday buyurtmalar ishlayotganligini, qanday mahsulotlarni hozir pishirish kerakligini ko'rsatishdir.
- Boshqa tomondan, oshxonadagi barcha jarayonlarni raqamlashtirish uchun.
Buyurtmada yangi mahsulot paydo bo'lganda (masalan, pizza), u Rolling out kuzatuvchi stantsiyasiga o'tadi. Ushbu stantsiyada pitsa ishlab chiqaruvchisi bor, u kerakli o'lchamdagi bulochkani olib, uni yoyadi, shundan so'ng u o'z vazifasini bajarganligi haqida treker planshetida qayd etadi va o'ralgan xamir bazasini keyingi stantsiyaga - "Boshlash" ga o'tkazadi. .
U erda navbatdagi pitsa ishlab chiqaruvchisi pitsani to'ldiradi, so'ngra planshetda o'z vazifasini bajarganini va pitsani pechga qo'yganligini qayd qiladi (bu ham planshetda qayd etilishi kerak bo'lgan alohida stantsiya). Bunday tizim Dododa eng boshidan va Dodo IS mavjudligining boshidanoq edi. Bu sizga barcha tranzaktsiyalarni to'liq kuzatish va raqamlashtirish imkonini beradi. Bundan tashqari, treker ma'lum bir mahsulotni qanday pishirishni taklif qiladi, har bir mahsulot turini ishlab chiqarish sxemalari bo'yicha yo'naltiradi, mahsulot uchun optimal pishirish vaqtini saqlaydi va mahsulotdagi barcha operatsiyalarni kuzatib boradi.
"Raskatka" treker stantsiyasida planshetning ekrani shunday ko'rinadi.
Yuklar qayerdan?
Pitseriyalarning har birida trekerga ega taxminan beshta planshet mavjud. 2016 yilda bizda 100 dan ortiq (hozir esa 600 dan ortiq) pitseriya bor edi. Planshetlarning har biri har 10 soniyada bir marta backendga so'rov yuboradi va buyurtmalar jadvalidan (mijoz va manzil bilan bog'lanish), buyurtma tarkibi (mahsulot bilan bog'lanish va miqdorni ko'rsatish), motivatsiya hisobi jadvalidan (mijoz bilan bog'lanish) ma'lumotlarni o'chiradi. unda bosish vaqti kuzatiladi). Pitsa ishlab chiqaruvchisi trekerdagi mahsulotni bosganda, ushbu jadvallarning barchasidagi yozuvlar yangilanadi. Buyurtmalar jadvali umumiy bo'lib, unda buyurtmani qabul qilishda qo'shimchalar, tizimning boshqa qismlaridan yangilanishlar va ko'plab o'qishlar mavjud, masalan, pitseriyada osilgan va mijozlarga tayyor buyurtmalarni ko'rsatadigan televizorda.
Yuklarga qarshi kurash davrida, hamma narsa va hamma narsa keshlangan va bazaning asinxron nusxasiga o'tkazilganda, treker bilan bu operatsiyalar asosiy bazaga o'tishda davom etdi. Hech qanday kechikish bo'lmasligi kerak, ma'lumotlar yangilangan bo'lishi kerak, sinxronlashtirilmagan bo'lishi mumkin emas.
Shuningdek, o'z jadvallari va ulardagi indekslarning yo'qligi ulardan foydalanish uchun moslashtirilgan aniqroq so'rovlarni yozishga imkon bermadi. Misol uchun, kuzatuvchi uchun buyurtmalar stolida pitseriya uchun indeks bo'lishi samarali bo'lishi mumkin. Biz har doim pitseriya buyurtmalarini trekerlar bazasidan olib tashlaymiz. Shu bilan birga, buyurtma olish uchun uning qaysi pitseriyaga tushishi muhim emas, bu buyurtmani qaysi mijoz qilgani muhimroq. Va u erda mijozda indeks kerak degan ma'noni anglatadi. Shuningdek, trekerga bosilgan chekning identifikatorini yoki buyurtma bilan bog'liq bonusli aktsiyalarni buyurtmalar jadvalida saqlash shart emas. Bu maʼlumot bizning kuzatuvchi xizmatimiz uchun qiziq emas. Umumiy monolit ma'lumotlar bazasida jadvallar faqat barcha foydalanuvchilar o'rtasida kelishuv bo'lishi mumkin edi. Bu asl muammolardan biri edi.
EDI. Asl arxitektura quyidagicha edi:
Alohida jarayonlarga bo'lingandan keyin ham, kod bazasining aksariyati turli xizmatlar uchun umumiy bo'lib qoldi. Nazoratchilar ostidagi hamma narsa yolg'iz edi va bir xil omborda yashagan. Biz xizmatlarning umumiy usullaridan, omborxonalardan, umumiy jadvallar joylashgan umumiy bazadan foydalandik.
Yukni tushirish kuzatuvchisi
Kuzatuvchining asosiy muammosi shundaki, ma'lumotlar turli ma'lumotlar bazalari o'rtasida sinxronlashtirilishi kerak. Bu, shuningdek, uning Auth xizmatini ajratishdan asosiy farqidir, tartib va uning holati o'zgarishi mumkin va turli xizmatlarda ko'rsatilishi kerak.
Biz buyurtmani restoran kassasida qabul qilamiz (bu xizmat), u ma'lumotlar bazasida "Qabul qilingan" holatida saqlanadi. Shundan so'ng, u trekerga borishi kerak, u erda u o'z holatini yana bir necha bor o'zgartiradi: "Oshxona" dan "Qadoqlangan" ga. Shu bilan birga, buyurtma bilan Kassir yoki Shift menejeri interfeysidan ba'zi tashqi ta'sirlar paydo bo'lishi mumkin. Buyurtma holatlarini ularning tavsifi bilan jadvalda beraman:
Buyurtma holatini o'zgartirish sxemasi quyidagicha ko'rinadi:
Statuslar turli tizimlar o'rtasida o'zgaradi. Va bu erda kuzatuvchi ma'lumotlar yopiq bo'lgan yakuniy tizim emas. Bunday holatda bo'linishning bir nechta mumkin bo'lgan yondashuvlarini ko'rdik:
- Biz barcha buyurtma harakatlarini bitta xizmatda jamlaymiz. Bizning holatda, bu variant buyurtma bilan ishlash uchun juda ko'p xizmat talab qiladi. Agar biz to'xtab qolsak, ikkinchi monolitni olamiz. Muammoni hal qilmas edik.
- Bir tizim boshqasiga qo'ng'iroq qiladi. Ikkinchi variant allaqachon qiziqroq. Ammo u bilan qo'ng'iroqlar zanjiri mumkin (), komponentlarning ulanishi yuqoriroq, uni boshqarish qiyinroq.
- Biz tadbirlarni tashkil qilamiz va har bir xizmat ushbu tadbirlar orqali boshqasi bilan muloqot qiladi. Natijada, uchinchi variant tanlandi, unga ko'ra barcha xizmatlar bir-biri bilan voqealar almashishni boshlaydilar.
Uchinchi variantni tanlaganimiz shuni anglatadiki, treker o'z ma'lumotlar bazasiga ega bo'ladi va har bir tartib o'zgarishi uchun u boshqa xizmatlar obuna bo'lgan va asosiy ma'lumotlar bazasiga kiradigan voqeani yuboradi. Buning uchun bizga xizmatlar o'rtasida xabarlarni yetkazib berishni ta'minlaydigan ba'zi xizmat kerak edi.
O'sha vaqtga kelib, bizda RabbitMQ allaqachon stekda bor edi, shuning uchun uni xabar brokeri sifatida ishlatishga yakuniy qaror. Diagrammada buyurtmaning restoran kassiridan Tracker orqali o'tishi ko'rsatilgan, bu erda u o'z holatini o'zgartiradi va Menejerning Buyurtmalari interfeysida ko'rsatiladi. BO'LING:
Bosqichma-bosqich yo'lni buyurtma qiling
Buyurtma yo'li buyurtma manbasi xizmatlaridan birida boshlanadi. Mana restoran kassiri:
- Kassada buyurtma to'liq tayyor va uni trekerga yuborish vaqti keldi. Kuzatuvchi obuna bo'lgan voqea tashlanadi.
- Kuzatuvchi o'zi uchun buyurtmani qabul qilib, uni o'z ma'lumotlar bazasiga saqlaydi, "Buyurtma kuzatuvchi tomonidan qabul qilindi" hodisasini yaratadi va uni RMQga yuboradi.
- Har bir buyurtma uchun voqea avtobusiga allaqachon obuna bo'lgan bir nechta ishlov beruvchilar mavjud. Biz uchun monolit asos bilan sinxronizatsiya qiladigan narsa muhim.
- Ishlovchi voqeani qabul qiladi, undan o'zi uchun muhim bo'lgan ma'lumotlarni tanlaydi: bizning holatlarimizda bu "Tracker tomonidan qabul qilingan" buyurtmaning holati va asosiy ma'lumotlar bazasida uning buyurtma ob'ektini yangilaydi.
Agar kimdir monolit stol buyurtmalaridan buyurtma kerak bo'lsa, unda siz uni o'sha erdan ham o'qishingiz mumkin. Masalan, Shift menejeridagi Buyurtmalar interfeysi quyidagilarni talab qiladi:
Boshqa barcha xizmatlar, shuningdek, kuzatuvchidan voqealarni o'zlari uchun ishlatish uchun buyurtma berish uchun obuna bo'lishlari mumkin.
Agar bir muncha vaqt o'tgach, buyurtma ishga tushirilsa, uning holati birinchi navbatda ma'lumotlar bazasida (Tracker ma'lumotlar bazasi) o'zgaradi va keyin darhol "OrderIn Progress" hodisasi hosil bo'ladi. Shuningdek, u RMQ-ga kiradi, u erdan monolit ma'lumotlar bazasida sinxronlashtiriladi va boshqa xizmatlarga yetkaziladi. Yo'lda turli muammolar bo'lishi mumkin, ular haqida batafsil ma'lumotni Zhenya Peshkovning hisobotida topish mumkin .
Auth va Tracker-dagi o'zgarishlardan so'ng yakuniy arxitektura
Oraliq natijani umumlashtirish: Dastlab menda Dodo IS tizimining to‘qqiz yillik tarixini bitta maqolaga jamlash g‘oyasi bor edi. Men evolyutsiya bosqichlari haqida tez va sodda gapirmoqchi edim. Biroq, materialga o'tirib, men hamma narsa tuyulgandan ko'ra ancha murakkab va qiziqarli ekanligini angladim.
Bunday materialning afzalliklari (yoki yo'qligi) haqida o'ylab, men voqealarning to'liq yilnomasi, batafsil retrospektivlar va o'tgan qarorlarimni tahlil qilmasdan turib, uzluksiz rivojlanish mumkin emas degan xulosaga keldim.
Umid qilamanki, bizning yo'limizni o'rganish siz uchun foydali va qiziqarli bo'ldi. Endi men Dodo IS tizimining qaysi qismini keyingi maqolada tasvirlashni tanlashga duch keldim: sharhlarda yozing yoki ovoz bering.
So'rovda faqat ro'yxatdan o'tgan foydalanuvchilar ishtirok etishlari mumkin. iltimos.
Keyingi maqolada Dodo ISning qaysi qismi haqida bilishni xohlaysiz?
-
24,1%Dodo ISda dastlabki monolit (2011-2015)14
-
24,1%Birinchi muammolar va ularning yechimlari (2015-2016)14
-
20,7%Mijoz tomoni yo'li: poydevor ustidagi fasad (2016-2017)12
-
36,2%Haqiqiy mikroservislar tarixi (2018-2019)21
-
44,8%Monolitni to'liq arralash va arxitekturani barqarorlashtirish26
-
29,3%Tizimni rivojlantirishning keyingi rejalari haqida17
-
19,0%Men Dodo IS11 haqida hech narsa bilishni xohlamayman
58 foydalanuvchi ovoz berdi. 6 nafar foydalanuvchi betaraf qolgan.
Manba: www.habr.com