Yoki monolitga ega bo'lgan har bir baxtsiz kompaniya o'ziga xos tarzda baxtsizdir.
Dodo IS tizimining rivojlanishi Dodo Pizza biznesi kabi darhol boshlandi - 2011 yilda. U biznes jarayonlarini to'liq va to'liq raqamlashtirish g'oyasiga asoslangan edi , bu 2011 yilda ham ko'plab savollar va shubhalarni keltirib chiqardi. Ammo mana 9 yildan beri biz bu yoβldan β oβz taraqqiyotimiz bilan, yaxlitlikdan boshlangan yoβldan bormoqdamiz.
Ushbu maqola "Nega arxitekturani qayta yozish va bunday keng ko'lamli va uzoq muddatli o'zgarishlarni amalga oshirish kerak?" Degan savollarga "javob" dir. oldingi maqolaga . Men Dodo IS ning rivojlanishi qanday boshlanganligi, boshlang'ich arxitekturasi qanday ko'rinishi, yangi modullar qanday paydo bo'lganligi va qanday muammolar tufayli keng ko'lamli o'zgarishlar qilish kerakligidan boshlayman.
Maqolalar turkumi "Dodo IS nima?" haqida hikoya qiladi:
-
Dodo ISda dastlabki monolit (2011-2015). (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...)
Dastlabki arxitektura
2011 yilda Dodo IS arxitekturasi quyidagicha ko'rinishga ega edi:
Arxitekturadagi birinchi modul buyurtmani qabul qilishdir. Biznes jarayoni quyidagicha edi:
-
mijoz pitseriyaga qo'ng'iroq qiladi;
-
Menejer telefonni ko'taradi;
-
telefon orqali buyurtmalarni qabul qiladi;
-
Shu bilan birga, u buyurtmani qabul qilish interfeysida to'ldiradi: mijoz haqidagi ma'lumotlar, buyurtma tafsilotlari va etkazib berish manzili hisobga olinadi.
Axborot tizimining interfeysi shunday ko'rinardi...
2011 yil oktyabr oyidan birinchi versiya:
Birinchi buyurtma qabul qilish modulini ishlab chiqish uchun resurslar cheklangan edi. Tez va kichik jamoa bilan ko'p ish qilish kerak edi. Kichik jamoa butun kelajakdagi tizim uchun poydevor qo'ygan 2 ta ishlab chiquvchidan iborat.
Ularning birinchi qarori texnologik stekning kelajakdagi taqdirini belgilab berdi:
-
ASP.NET MVC, C# tilida backend. Ishlab chiquvchilar dotnetters edi; bu stek ularga tanish va yoqimli edi.
-
Bootstrap va JQuery-dagi frontend: shaxsiy uslublar va skriptlarga asoslangan foydalanuvchi interfeyslari.
-
MySQL ma'lumotlar bazasi: litsenziya xarajatlari yo'q, foydalanish oson.
-
Windows Serverdagi serverlar, chunki .NET o'shanda faqat Windowsda bo'lishi mumkin edi (biz Mono haqida gaplashmaymiz).
Jismoniy jihatdan, bularning barchasi "mezbon stolida" ifodalangan.
Buyurtmani qabul qilish arizasining arxitekturasi
O'sha paytda hamma allaqachon mikroservislar haqida gapirgan va SOA taxminan 5 yil davomida yirik loyihalarda ishlatilgan, masalan, WCF 2006 yilda chiqarilgan. Ammo keyin ular ishonchli va tasdiqlangan echimni tanladilar.
Mana.
Asp.Net MVC bu Razor bo'lib, u forma yoki mijozning so'roviga ko'ra serverda ko'rsatish bilan HTML sahifani ishlab chiqaradi. Mijozda CSS va JS skriptlari allaqachon ma'lumotni ko'rsatadi va agar kerak bo'lsa, JQuery orqali AJAX so'rovlarini amalga oshiradi.
Serverdagi so'rovlar *Controller sinflariga to'g'ri keladi, bu erda usul yakuniy HTML sahifani qayta ishlaydi va yaratadi. Kontrollerlar *Xizmatlar deb nomlangan mantiqiy qatlamga so'rovlar yuboradilar. Xizmatlarning har biri biznesning ba'zi jihatlariga mos keladi:
-
Misol uchun, DepartmentStructureService pitseriya va bo'limlar haqida ma'lumot berdi. Bo'lim - bu bitta franchayzi tomonidan boshqariladigan pitseriyalar guruhi.
-
ReceivingOrdersService buyurtma mazmunini oldi va hisoblab chiqdi.
-
Va SmsService SMS yuborish uchun API xizmatlariga qo'ng'iroq qilish orqali SMS yubordi.
Xizmatlar ma'lumotlar bazasidan ma'lumotlarni qayta ishladi va biznes mantiqini saqladi. Har bir xizmatda tegishli nomga ega bir yoki bir nechta *Repozitoriylar mavjud edi. Ularda allaqachon ma'lumotlar bazasida saqlangan protseduralar va xaritachilar qatlamiga so'rovlar mavjud edi. Repozitariylar biznes mantig'iga ega edi, ayniqsa ularning aksariyati hisobot ma'lumotlarini ishlab chiqaradigan. ORM ishlatilmadi, hamma qo'lda yozilgan sql-ga tayanardi.
Shuningdek, domen modeli qatlami va umumiy yordamchi sinflar, masalan, buyurtmani saqlaydigan Order sinfi mavjud edi. U erda qatlamda tanlangan valyutaga ko'ra displey matnini konvertatsiya qilish uchun yordamchi mavjud edi.
Bularning barchasi ushbu model bilan ifodalanishi mumkin:
Buyurtma usuli
Keling, bunday tartibni yaratishning soddalashtirilgan dastlabki usulini ko'rib chiqaylik.
Dastlab sayt statik edi. Unda narxlar bor edi, tepasida esa telefon raqami va "Agar siz pizza xohlasangiz, raqamga qo'ng'iroq qiling va buyurtma bering" degan yozuv bor edi. Buyurtma berish uchun biz oddiy oqimni amalga oshirishimiz kerak:
-
Mijoz narxlari ko'rsatilgan statik veb-saytga o'tadi, mahsulotlarni tanlaydi va veb-saytda ko'rsatilgan raqamga qo'ng'iroq qiladi.
-
Xaridor buyurtmaga qo'shmoqchi bo'lgan mahsulotlarni nomlaydi.
-
Uning manzili va ismini aytadi.
-
Operator buyurtmani qabul qiladi.
-
Buyurtma qabul qilingan buyurtmalar interfeysida ko'rsatiladi.
Hammasi menyuni ko'rsatishdan boshlanadi. Tizimga kirgan operator foydalanuvchisi bir vaqtning o'zida faqat bitta buyurtmani qabul qiladi. Shuning uchun qoralama arava o'z sessiyasida saqlanishi mumkin (foydalanuvchining sessiyasi xotirada saqlanadi). Mahsulotlar va mijozlar ma'lumotlarini o'z ichiga olgan Cart ob'ekti mavjud.
Mijoz mahsulotga nom beradi, operator uni bosadi + mahsulot yonida va serverga so'rov yuboriladi. Ma'lumotlar bazasidan mahsulot haqidagi ma'lumotlar chiqariladi va mahsulot haqidagi ma'lumotlar savatga qo'shiladi.
nota. Ha, bu erda siz mahsulotni ma'lumotlar bazasidan tortib olishingiz shart emas, lekin uni oldingi qismdan o'tkazing. Ammo aniqlik uchun men bazadan aniq yo'lni ko'rsatdim.
Keyin mijozning manzili va ismini kiriting.
βBuyurtma yaratishβ tugmasini bosganingizda:
-
Biz so'rovni OrderController.SaveOrder() ga yuboramiz.
-
Seansdan Cart olamiz, kerakli miqdorda mahsulotlar bor.
-
Biz Cart-ni mijoz haqidagi ma'lumotlar bilan to'ldiramiz va uni ReceivingOrderService sinfining AddOrder usuliga o'tkazamiz, u erda u ma'lumotlar bazasiga saqlanadi.
-
Ma'lumotlar bazasida buyurtma, buyurtma mazmuni, mijoz ko'rsatilgan jadvallar mavjud va ularning barchasi bog'langan.
-
Buyurtmani ko'rsatish interfeysi borib, eng so'nggi buyurtmalarni chiqaradi va ularni ko'rsatadi.
Yangi modullar
Buyurtmani qabul qilish muhim va zarur edi. Agar sizda sotish uchun buyurtma bo'lmasa, siz pizza biznesini yurita olmaysiz. Shu sababli, tizim funksionallikka ega bo'la boshladi - taxminan 2012 yildan 2015 yilgacha. Shu vaqt ichida tizimning ko'plab turli bloklari paydo bo'ldi, men ularni chaqiraman modullar, xizmat yoki mahsulot tushunchasidan farqli o'laroq.
Modul - bu qandaydir umumiy biznes maqsadi bilan birlashtirilgan funktsiyalar to'plami. Bundan tashqari, ular jismonan bir xil dasturda joylashgan.
Modullarni tizim bloklari deb atash mumkin. Masalan, bu hisobot moduli, administrator interfeyslari, , ruxsat. Bularning barchasi turli xil foydalanuvchi interfeyslari, ba'zilarida hatto turli xil vizual uslublar mavjud. Bundan tashqari, hamma narsa bitta dastur, bitta ishlaydigan jarayon ichida.
Texnik jihatdan modullar hudud sifatida ishlab chiqilgan (bu g'oya hatto saqlanib qolgan ). Frontend, modellar, shuningdek, o'zlarining kontroller sinflari uchun alohida fayllar mavjud edi. Natijada, tizim shunday o'zgartirildi ...
...buning uchun:
Ba'zi modullar butunlay alohida funksionallik va qisman alohida, ko'proq yo'naltirilgan ishlab chiqish tufayli alohida saytlar (bajariladigan loyiha) tomonidan amalga oshiriladi. Bu:
-
sayt - dodopizza.ru veb-sayti.
-
Eksport: 1C uchun Dodo IS dan hisobotlarni yuklab olish.
-
shaxsiy - xodimning shaxsiy hisobi. U alohida ishlab chiqilgan va o'zining kirish nuqtasi va alohida dizayniga ega.
-
fs β statik xosting uchun loyiha. Keyinchalik biz undan uzoqlashdik va barcha statik tarkibni Akamai CDN-ga o'tkazdik.
Qolgan bloklar BackOffice ilovasida joylashgan edi.
Ismlarni tushuntirish:
-
Kassir - Restoran kassasi.
-
ShiftManager - "Shift menejeri" roli uchun interfeyslar: pitseriya sotuvi bo'yicha operatsion statistika, mahsulotlarni to'xtash ro'yxatiga qo'yish, buyurtmani o'zgartirish imkoniyati.
-
OfficeManager - "Pitseriya menejeri" va "Franchayzi" rollari uchun interfeyslar. Bu yerda siz pitseriya tashkil etish, uning bonusli aktsiyalari, xodimlarni qabul qilish va ular bilan ishlash, hisobotlar bilan tanishishingiz mumkin.
-
PublicScreens - pitseriyalarda osilgan televizor va planshetlar uchun interfeyslar. Televizorlar yetkazib berish paytida menyu, reklama ma'lumotlari va buyurtma holatini ko'rsatadi.
Ular umumiy xizmat qatlami, Dodo.Core domen sinflarining umumiy bloki va umumiy bazadan foydalanganlar. Ba'zan ular hali ham o'tish joylari orqali bir-biriga olib borishlari mumkin edi. Bundan tashqari, dodopizza.ru yoki personal.dodopizza.ru kabi alohida saytlar ham umumiy xizmatlarga kirgan.
Yangi modullar paydo bo'lganda, biz ma'lumotlar bazasidagi xizmatlar, saqlangan protseduralar va jadvallar uchun allaqachon yaratilgan kodni iloji boricha qayta ishlatishga harakat qildik.
Tizimda yaratilgan modullar ko'lamini yaxshiroq tushunish uchun bu erda rivojlanish rejalari bilan 2012 yildagi diagramma:
2015 yilga kelib, hamma narsa o'z yo'lida va undan ham ko'proq ishlab chiqarishda edi.
-
Buyurtmani qabul qilish aloqa markazining alohida blokiga aylandi, bu erda buyurtma operator tomonidan qabul qilinadi.
-
Pitseriyalarda menyu va ma'lumotlarga ega ommaviy ekranlar paydo bo'ldi.
-
Oshxonada yangi buyurtma kelganda avtomatik ravishda βYangi pizzaβ ovozli xabarini eshittiruvchi modul mavjud, shuningdek, kurer uchun hisob-fakturani chop etadi. Bu oshxonadagi jarayonlarni sezilarli darajada soddalashtiradi va xodimlarni ko'p sonli oddiy operatsiyalar bilan chalg'itmaslikka imkon beradi.
-
Yetkazib berish bloki alohida Yetkazib berish kassiriga aylandi, u erda buyurtma avval o'z smenasini olgan kurerga berildi. Ish haqini hisoblashda uning ish vaqti hisobga olingan.
Bunga parallel ravishda, 2012 yildan 2015 yilgacha 10 dan ortiq dasturchilar paydo bo'ldi, 35 ta pitseriya ochildi, tizim Ruminiyaga joylashtirildi va AQShda punktlarni ochishga tayyorlandi. Ishlab chiquvchilar endi barcha vazifalarda ishtirok etmadilar, balki jamoalarga bo'lindilar. har biri tizimning o'z qismiga ixtisoslashgan.
Muammolar
Shu jumladan arxitektura tufayli (lekin nafaqat).
Bazadagi tartibsizlik
Bir baza qulay. Relyatsion ma'lumotlar bazalariga o'rnatilgan vositalar hisobiga izchillikka erishish mumkin. U bilan ishlash tanish va qulay, ayniqsa jadvallar va ma'lumotlar kam bo'lsa.
Ammo 4 yillik rivojlanish davomida ma'lumotlar bazasida 600 ga yaqin jadvallar, 1500 ta saqlangan protseduralar mavjud bo'lib, ularning ko'pchiligi mantiqqa ega edi. Afsuski, MySQL bilan ishlashda saqlangan protseduralar katta foyda keltirmaydi. Ular ma'lumotlar bazasi tomonidan keshlanmagan va ulardagi mantiqni saqlash ishlab chiqish va disk raskadrovkani murakkablashtiradi. Kodni qayta ishlatish ham qiyin.
Ko'pgina jadvallarda mos indekslar yo'q edi, bir joyda, aksincha, ko'plab indekslar mavjud edi, bu esa kiritishni qiyinlashtirdi. Taxminan 20 ta jadvalni o'zgartirish kerak edi - buyurtma yaratish uchun tranzaktsiya taxminan 3-5 soniya davom etishi mumkin edi.
Jadvallardagi ma'lumotlar har doim ham eng mos shaklda emas edi. Bir joyda denormalizatsiya qilish kerak edi. Doimiy qabul qilinadigan ma'lumotlarning ba'zilari XML tuzilmasi ko'rinishidagi ustunda edi, bu bajarilish vaqtini oshirdi, so'rovlarni uzaytirdi va rivojlanishni murakkablashtirdi.
Xuddi shu jadvallar juda bo'ysungan heterojen so'rovlar. Yuqorida aytib o'tilgan jadval kabi mashhur jadvallar ayniqsa ta'sir ko'rsatdi Buyurtmalar yoki jadvallar pizzeria. Ular oshxonada operatsion interfeyslarni va tahlillarni ko'rsatish uchun ishlatilgan. Sayt ular bilan ham bog'landi (), bu erda ko'plab so'rovlar to'satdan istalgan vaqtda kelishi mumkin.
Ma'lumotlar yig'ilmagan va ko'plab hisob-kitoblar tayanch yordamida parvozda amalga oshirildi. Bu keraksiz hisob-kitoblarni va qo'shimcha yukni yaratdi.
Ko'pincha kod ma'lumotlar bazasiga kirishi mumkin emas edi. Qaerdadir ommaviy operatsiyalarning etishmasligi bor edi, qaerdadir tezlashtirish va ishonchlilikni oshirish uchun bitta so'rovni kod orqali bir nechtaga bo'lish kerak edi.
Koddagi uyg'unlik va chalkashlik
Biznesning o'z qismi uchun javobgar bo'lishi kerak bo'lgan modullar buni halol qilmadilar. Ulardan ba'zilari rollar uchun funktsiyalarning takrorlanishiga ega edi. Masalan, o'z shahridagi tarmoqning marketing faoliyati uchun mas'ul bo'lgan mahalliy marketolog "Admin" interfeysidan (aksiyalarni o'rnatish uchun) va "Ofis menejeri" interfeysidan (aktsiyalarning kompaniyaga ta'sirini ko'rish uchun) foydalanishi kerak edi. biznes). Albatta, ikkala modulda ham bonusli aktsiyalar bilan ishlaydigan bir xil xizmat ishlatilgan.
Xizmatlar (bir monolit yirik loyiha doirasidagi sinflar) o'z ma'lumotlarini boyitish uchun bir-biriga qo'ng'iroq qilishlari mumkin.
Ma'lumotlarni saqlaydigan model sinflari bilan, kodeksdagi ishlar boshqacha amalga oshirildi. Qaerdadir konstruktorlar bor edi, ular orqali kerakli maydonlarni belgilashingiz mumkin edi. Qaerdadir bu davlat mulki orqali amalga oshirilgan. Albatta, ma'lumotlar bazasidan ma'lumotlarni olish va o'zgartirish har xil edi.
Mantiq nazoratchilarda yoki xizmat sinflarida edi.
Bu kichik muammolar kabi ko'rinadi, lekin ular rivojlanishni sezilarli darajada sekinlashtirdi va sifatni pasaytirdi, bu esa beqarorlik va xatolarga olib keldi.
Katta rivojlanishning murakkabligi
Rivojlanishning o'zida qiyinchiliklar paydo bo'ldi. Tizimning turli bloklarini va parallel ravishda yaratish kerak edi. Har bir komponentning ehtiyojlarini bitta kodga moslashtirish tobora qiyinlashdi. Bir vaqtning o'zida barcha komponentlarni rozi qilish va mamnun qilish oson emas edi. Bunga texnologiyadagi cheklovlar qo'shildi, ayniqsa baza va old qismga nisbatan. JQuery'dan yuqori darajadagi ramkalar foydasiga voz kechish kerak edi, ayniqsa mijozlarga xizmat ko'rsatish (veb-sayt).
Tizimning ba'zi qismlari bunga ko'proq mos keladigan ma'lumotlar bazalaridan foydalanishi mumkin. Misol uchun, keyinchalik buyurtma savatini saqlash uchun Redis-dan CosmosDB-ga o'tish uchun bizda pretsedent bor edi.
O'z hududlarida ishlaydigan jamoalar va ishlab chiquvchilar o'z xizmatlari uchun rivojlanish nuqtai nazaridan ham, ishlab chiqarish nuqtai nazaridan ham ko'proq mustaqillikni xohlashlari aniq. Birlashma paytida nizolar, relizlar paytida muammolar. Agar 5 ta ishlab chiquvchi uchun bu muammo ahamiyatsiz bo'lsa, unda 10 va undan ham ko'proq rejalashtirilgan o'sish bilan hamma narsa jiddiyroq bo'ladi. Va oldinda mobil ilovani ishlab chiqish kerak edi (u 2017 yilda boshlangan va 2018 yilda mavjud edi. ).
Tizimning turli qismlari turli barqarorlik ko'rsatkichlarini talab qildi, lekin tizimning kuchli ulanishi tufayli biz buni ta'minlay olmadik. Administrator panelida yangi funktsiyani ishlab chiqishda xatolik saytda buyurtma qabul qilinishiga olib kelishi mumkin edi, chunki kod keng tarqalgan va qayta foydalanish mumkin, ma'lumotlar bazasi va ma'lumotlar ham bir xil.
Bunday monolit-modulli arxitektura doirasida bu xato va muammolardan qochish mumkin bo'lishi mumkin: mas'uliyatni ajratish, kodni ham, ma'lumotlar bazasini ham qayta tiklash, qatlamlarni bir-biridan aniq ajratish va har kuni sifatni nazorat qilish. Ammo tanlangan me'moriy echimlar va tizimning funksionalligini tezda kengaytirishga e'tibor barqarorlik masalalarida muammolarga olib keldi.
Qanday qilib Power of Mind blogi kassa apparatlarini restoranlarga joylashtirdi
Agar pitseriya tarmog'ining o'sishi (va yuk) bir xil sur'atda davom etsa, unda bir muncha vaqt o'tgach, pasayishlar shunday bo'ladiki, tizim tiklanmaydi. Quyidagi hikoya 2015 yilga kelib biz duch kelgan muammolarni yaxshi ko'rsatib beradi.
Blogda ""butun tarmoq bo'yicha yil davomida daromad ma'lumotlarini ko'rsatadigan vidjet mavjud edi. Vidjet ushbu ma'lumotlarni taqdim etadigan umumiy Dodo API-ga kirdi. Ushbu statistika hozirda mavjud . Vidjet har bir sahifada ko'rsatildi va har 20 soniyada taymerda so'rovlar yuborildi. So'rov api.dodopizza.ru saytiga borib, so'radi:
-
tarmoqdagi pitseriyalar soni;
-
yil boshidan beri tarmoqning umumiy daromadi;
-
bugungi daromad.
Daromad statistikasi so'rovi to'g'ridan-to'g'ri ma'lumotlar bazasiga tushdi va buyurtmalar bo'yicha ma'lumotlarni so'rashni, ma'lumotlarni to'g'ridan-to'g'ri yig'ishni va miqdorni berishni boshladi.
Restoranlardagi kassa apparatlari bir xil buyurtmalar jadvaliga o'tdi, bugungi kun uchun qabul qilingan buyurtmalar ro'yxatini yukladi va unga yangi buyurtmalar qo'shildi. Kassa apparatlari har 5 soniyada yoki sahifa yangilanganda o'z so'rovlarini amalga oshirdi.
Diagramma quyidagicha ko'rinardi:
Kuzning bir kuni Fyodor Ovchinnikov o'z blogida uzoq va mashhur maqola yozdi. Ko'p odamlar blogga kelishdi va hamma narsani diqqat bilan o'qishni boshladilar. Kelganlarning har biri maqolani o'qiyotganda, daromad vidjeti to'g'ri ishladi va har 20 soniyada API so'radi.
API tarmoqdagi barcha pitseriyalar uchun yil boshidan beri barcha buyurtmalar miqdorini hisoblash uchun saqlangan protsedurani chaqirdi. Birlashtirish buyurtmalar jadvaliga asoslangan edi, bu juda mashhur. O'sha paytdagi barcha ochiq restoranlarning barcha kassalari unga boradi. Kassa apparatlari javob berishni to'xtatdi va buyurtmalar qabul qilinmadi. Ular shuningdek saytdan qabul qilinmadi, trekerda ko'rinmadi va smena menejeri ularni o'z interfeysida ko'ra olmadi.
Bu yagona hikoya emas. 2015 yilning kuziga kelib, har juma kuni tizimdagi yuk juda muhim edi. Bir necha marta biz umumiy APIni o'chirib qo'ydik va bir marta hech narsa yordam bermagani uchun saytni o'chirishga majbur bo'ldik. Hatto og'ir yuk ostida o'chirish tartibi bilan xizmatlar ro'yxati ham bor edi.
Shu vaqtdan boshlab, bizning yuklar va tizimni barqarorlashtirish uchun kurashimiz boshlanadi (2015 yil kuzidan 2018 yil kuzigacha). O'shanda sodir bo'ldi"" Bundan tashqari, ba'zida muvaffaqiyatsizliklar ham bo'lgan, ularning ba'zilari juda sezgir edi, ammo endi umumiy beqarorlik davri tugagan deb hisoblash mumkin.
Biznesning tez o'sishi
Nega buni "darhol yaxshi qilish" mumkin emas edi? Faqat quyidagi grafiklarga qarang.
Shuningdek, 2014-2015 yillarda Ruminiyada ochilish bo'lib o'tgan va AQShda ochilishga tayyorgarlik ko'rilayotgan edi.
Zanjir juda tez o'sdi, yangi mamlakatlar ochildi, pitseriyalarning yangi formatlari paydo bo'ldi, masalan, oziq-ovqat kortida pitseriya ochildi. Bularning barchasi Dodo IS funksiyalarini kengaytirishga alohida e'tibor qaratishni talab qildi. Bu barcha funktsiyalarsiz, oshxonada kuzatilmasdan, tizimdagi mahsulotlar va yo'qotishlarni hisobga olmasdan, oziq-ovqat korti zalida buyurtmalarni etkazib berishni ko'rsatmasdan, biz hozir "to'g'ri" arxitektura va "to'g'ri" arxitektura haqida gapirishimiz dargumon. β rivojlanishga yondashuv.
Arxitekturani o'z vaqtida qayta ko'rib chiqish va texnik muammolarga umumiy e'tibor qaratish uchun yana bir to'siq 2014 yilgi inqiroz edi. Bunday narsalar jamoalarning o'sish imkoniyatlariga putur etkazadi, ayniqsa Dodo Pizza kabi yosh biznes uchun.
Tez yechimlar yordam berdi
Muammolar yechimga muhtoj. An'anaviy ravishda echimlarni 2 guruhga bo'lish mumkin:
-
Yong'inni o'chiradigan va bizga kichik xavfsizlik chegarasini beradigan va o'zgartirish uchun vaqt sotib oladigan tezkorlar.
-
Tizimli va shuning uchun uzoq. Bir qator modullarni qayta qurish, monolit arxitekturani alohida xizmatlarga bo'lish (ularning aksariyati mikro emas, balki makro xizmatlardir va bu haqda ko'proq narsa bor. ).
Tez o'zgarishlarning quruq ro'yxati:
Asosiy ustani kattalashtirish
Albatta, yuk bilan kurashish uchun qilinadigan birinchi narsa server quvvatini oshirishdir. Bu asosiy ma'lumotlar bazasi va veb-serverlar uchun amalga oshirildi. Afsuski, bu faqat ma'lum bir chegaragacha mumkin, bundan tashqari u juda qimmatga tushadi.
2014 yildan beri biz Azure-ga ko'chib o'tdik; biz bu mavzu haqida o'sha paytdagi maqolada ham yozgan edik "" Ammo serverning bir qator o'sishidan so'ng, bazaning narxi chegaraga yetdi.
O'qish uchun ma'lumotlar bazasi nusxalari
Biz baza uchun ikkita nusxa yaratdik:
Replikani o'qing katalog so'rovlari uchun. U shahar, ko'cha, pitseriya, mahsulotlar (asta-sekin o'zgartirilgan domen) kabi ma'lumotnomalarni o'qish uchun va kichik kechikish maqbul bo'lgan interfeyslarda qo'llaniladi. Ushbu replikatsiyalardan ikkitasi bor edi, biz ularning mavjudligini usta bilan bir xil tarzda ta'minladik.
Hisobot so'rovlari uchun o'qing. Ushbu ma'lumotlar bazasi kamroq mavjud edi, ammo barcha hisobotlar unga o'tdi. Ular katta ma'lumotlarni qayta hisoblash uchun og'ir so'rovlarga ega bo'lishi mumkin, ammo ular asosiy ma'lumotlar bazasi va operatsion interfeyslarga ta'sir qilmaydi.
Koddagi keshlar
Kodning biron bir joyida keshlar yo'q edi (umuman). Bu yuklangan ma'lumotlar bazasiga har doim ham zarur bo'lmagan qo'shimcha so'rovlarga olib keldi. Avvaliga keshlar ham xotirada, ham tashqi kesh xizmatida edi, bu Redis edi. Hamma narsa vaqt bilan bekor qilindi, sozlamalar kodda ko'rsatilgan.
Backend uchun bir nechta serverlar
Ilovaning orqa tomoni ham ortib borayotgan yuklarga bardosh berish uchun masshtablanishi kerak edi. Bitta IIS serveridan klaster yaratish kerak edi. Biz ko'chdik RedisCache-da xotiradan, bu oddiy yuk balansi orqasida bir nechta serverlarni yumaloq robin bilan yaratishga imkon berdi. Avvaliga bir xil Redis keshlar uchun ishlatilgan, keyin ular bir nechta bo'lingan.
Natijada arxitektura yanada murakkablashdi...
...lekin taranglikning bir qismi yengildi.
Va keyin yuklangan komponentlarni qayta tiklash kerak edi, biz buni qabul qildik. Bu haqda keyingi qismda gaplashamiz.
Manba: www.habr.com