Немесе монолитті әрбір бақытсыз компания өзінше бақытсыз.
Dodo IS жүйесінің дамуы Dodo Pizza бизнесі сияқты бірден басталды - 2011 жылы. Ол бизнес-процестерді толық және толық цифрландыру идеясына негізделген және , бұл 2011 жылдың өзінде көптеген сұрақтар мен күмән тудырды. Бірақ міне, 9 жыл бойы біз осы жолмен – монолиттен басталған өз дамуымызбен келе жатырмыз.
Бұл мақала «Неге архитектураны қайта жазып, осындай ауқымды және ұзақ мерзімді өзгерістерді жасау керек?» деген сұрақтарға «жауап» болып табылады. алдыңғы мақалаға . Мен Dodo IS-тің дамуы қалай басталғанын, бастапқы архитектурасы қандай болғанын, жаңа модульдердің қалай пайда болғанын және қандай мәселелерге байланысты ауқымды өзгерістерді енгізу керек болғанынан бастаймын.
«Dodo IS дегеніміз не?» Мақалалар топтамасы. туралы айтып береді:
-
Dodo IS-тегі ерте монолит (2011-2015). (Сен мындасың)
-
.
-
Клиент бөлігінің жолы: базаның үстіндегі қасбет (2016-2017). (Орындалуда...)
-
Шынайы микросервистердің тарихы. (2018-2019). (Орындалуда...)
-
Монолитті аралау және сәулетті тұрақтандыру аяқталды. (Орындалуда...)
Алғашқы сәулет
2011 жылы Dodo IS архитектурасы келесідей болды:
Архитектурадағы бірінші модуль тапсырысты қабылдау болып табылады. Бизнес процесі келесідей болды:
-
клиент пиццерияға қоңырау шалады;
-
Менеджер телефонды алады;
-
телефон арқылы тапсырыс қабылдайды;
-
Бұл ретте ол тапсырысты қабылдау интерфейсінде толтырады: клиент туралы ақпарат, тапсырыс мәліметтері туралы деректер және жеткізу мекенжайы ескеріледі.
Ақпараттық жүйе интерфейсі келесідей болды...
2011 жылғы қазандағы бірінші нұсқасы:
Бірінші тапсырысты қабылдау модулін әзірлеуге арналған ресурстар шектеулі болды. Көп нәрсені, тез және шағын ұжыммен істеу керек болды. Шағын команда болашақ жүйенің негізін қалаған 2 әзірлеушіден тұрады.
Олардың бірінші шешімі технологиялық стектің болашақ тағдырын анықтады:
-
ASP.NET MVC, C# тілінде сервер. Әзірлеушілер нүктелер болды; бұл стек оларға таныс және жағымды болды.
-
Bootstrap және JQuery-дегі фронтен: теңшелетін стильдер мен сценарийлерге негізделген пайдаланушы интерфейстері.
-
MySQL дерекқоры: лицензиялық шығындар жоқ, пайдалану оңай.
-
Windows серверіндегі серверлер, өйткені .NET ол кезде тек Windows жүйесінде болуы мүмкін (біз Mono туралы талқыламаймыз).
Физикалық тұрғыдан алғанда, мұның бәрі «үй иесінің үстелінде» көрсетілген.
Тапсырысты қабылдау өтінімінің архитектурасы
Ол кезде барлығы микросервистер туралы айтып жүрді, ал SOA ірі жобаларда шамамен 5 жыл бойы қолданылды, мысалы, WCF 2006 жылы шығарылды. Бірақ содан кейін олар сенімді және дәлелденген шешімді таңдады.
Міне ол.
Asp.Net MVC — пішіннен немесе клиенттен сұрау бойынша серверде көрсетуі бар HTML бетін жасайтын Razor. Клиентте CSS және JS сценарийлері қазірдің өзінде ақпаратты көрсетеді және қажет болса, JQuery арқылы AJAX сұрауларын орындайды.
Сервердегі сұраулар *Controller сыныптарына жатады, мұнда әдіс соңғы HTML бетін өңдейді және жасайды. Контроллерлер *Қызметтер деп аталатын логикалық деңгейге сұраныстар жасайды. Қызметтердің әрқайсысы бизнестің кейбір аспектілеріне сәйкес келді:
-
Мысалы, DepartmentStructureService пиццериялар мен бөлімдер туралы ақпарат берді. Бөлім – бір франчайзи басқаратын пиццериялар тобы.
-
ReceivingOrdersService тапсырыс мазмұнын қабылдады және есептеді.
-
Ал SmsService SMS жіберу үшін API қызметтеріне қоңырау шалу арқылы SMS жіберді.
Қызметтер дерекқордағы деректерді өңдеп, бизнес логикасын сақтайды. Әрбір қызметте сәйкес атауы бар бір немесе бірнеше *Репозиторийлер болды. Олар дерекқордағы сақталатын процедураларға сұрауларды және салыстырушылардың қабатын қамтыған. Репозиторийлерде бизнес логикасы болды, әсіресе олардың көпшілігі есеп деректерін шығаратын. ORM пайдаланылмады, барлығы қолмен жазылған sql-ге сүйенді.
Сондай-ақ, домен үлгісінің қабаты және жалпы көмекші сыныптар болды, мысалы, тапсырысты сақтайтын Order класы. Онда, қабатта таңдалған валютаға сәйкес дисплей мәтінін түрлендіруге арналған көмекші болды.
Мұның барлығын мына үлгімен көрсетуге болады:
Тапсырыс жолы
Мұндай тапсырысты құрудың жеңілдетілген бастапқы әдісін қарастырайық.
Бастапқыда сайт статикалық болды. Онда бағалар жазылған, ал жоғарғы жағында телефон нөмірі мен «Егер пицца алғыңыз келсе, нөмірге қоңырау шалыңыз және тапсырыс беріңіз» деген жазу бар. Тапсырыс беру үшін бізге қарапайым ағынды енгізу керек:
-
Клиент бағалары бар статикалық веб-сайтқа өтіп, өнімдерді таңдайды және веб-сайтта көрсетілген нөмірге қоңырау шалады.
-
Тұтынушы тапсырысқа қосқысы келетін өнімдерді атайды.
-
Мекен-жайы мен атын айтады.
-
Оператор тапсырысты қабылдайды.
-
Тапсырыс қабылданған тапсырыстар интерфейсінде көрсетіледі.
Барлығы мәзірді көрсетуден басталады. Жүйеге кірген оператор пайдаланушысы бір уақытта тек бір тапсырысты қабылдайды. Сондықтан арба жобасы өз сеансында сақталуы мүмкін (пайдаланушы сеансы жадта сақталады). Өнімдер мен тұтынушы туралы ақпаратты қамтитын Cart нысаны бар.
Клиент өнімді атайды, оператор шертеді + өнімнің жанында болады және серверге сұрау жіберіледі. Өнім туралы ақпарат дерекқордан шығарылады және өнім туралы ақпарат себетке қосылады.
ескерту. Иә, бұл жерде өнімді дерекқордан шығарудың қажеті жоқ, оны алдыңғы жақтан тасымалдаңыз. Бірақ түсінікті болу үшін мен базадан дәл жолды көрсеттім.
Содан кейін клиенттің мекенжайы мен атын енгізіңіз.
«Тапсырысты жасау» түймесін басқан кезде:
-
Біз сұранысты OrderController.SaveOrder() қызметіне жібереміз.
-
Сеанстан Арба аламыз, қажетті мөлшерде өнімдер бар.
-
Біз Арбаны клиент туралы ақпаратпен толықтырамыз және оны ReceivingOrderService класының AddOrder әдісіне береміз, онда ол дерекқорға сақталады.
-
Мәліметтер базасында тапсырыс, тапсырыс мазмұны, клиент бар кестелер бар және олардың барлығы қосылған.
-
Тапсырысты көрсету интерфейсі өтіп, соңғы тапсырыстарды шығарып, оларды көрсетеді.
Жаңа модульдер
Тапсырысты қабылдау маңызды және қажет болды. Сатуға тапсырысыңыз болмаса, пицца бизнесін жүргізе алмайсыз. Сондықтан жүйе функционалдылыққа ие бола бастады - шамамен 2012 жылдан 2015 жылға дейін. Осы уақыт ішінде жүйенің көптеген әртүрлі блоктары пайда болды, мен оларды шақырамын модульдер, қызмет немесе өнім тұжырымдамасына қарсы.
Модуль – бұл қандай да бір ортақ бизнес мақсатымен біріктірілген функциялар жиынтығы. Сонымен қатар, олар физикалық түрде бір қолданбада орналасқан.
Модульдерді жүйелік блоктар деп атауға болады. Мысалы, бұл есеп беру модулі, әкімші интерфейстері, , авторизация. Бұлардың барлығы әртүрлі пайдаланушы интерфейстері, кейбіреулерінде тіпті әртүрлі көрнекі стильдер бар. Оның үстіне бәрі бір қолданбада, бір орындалатын процесте.
Техникалық тұрғыдан, модульдер аймақ ретінде жобаланған (бұл идея тіпті сақталды ). Фронт, үлгілер, сондай-ақ өздерінің контроллер сыныптары үшін бөлек файлдар болды. Нәтижесінде жүйе мұндай...
...оған:
Кейбір модульдер жеке сайттармен (орындалатын жоба) толығымен бөлек функционалдылыққа байланысты және ішінара біршама бөлек, көбірек бағытталған әзірлеуге байланысты жүзеге асырылады. Бұл:
-
Сайт - dodopizza.ru сайты.
-
экспорт: 1С үшін Dodo IS есептерін жүктеп алу.
-
Жеке — қызметкердің жеке кабинеті. Ол бөлек әзірленген және өзінің кіру нүктесі мен бөлек дизайны бар.
-
fs — статикалық хостингке арналған жоба. Кейінірек біз одан алыстап, барлық статикалық мазмұнды Akamai CDN-ге көшірдік.
Қалған блоктар BackOffice қолданбасында орналасқан.
Атауларды түсіндіру:
-
Кассир - Мейрамхананың кассасы.
-
ShiftManager - «Shift Manager» рөліне арналған интерфейстер: пиццерияларды сату бойынша операциялық статистика, өнімдерді тоқтату тізіміне қою, тапсырысты өзгерту мүмкіндігі.
-
OfficeManager – «Пиццерия менеджері» және «Франчайзи» рөлдеріне арналған интерфейстер. Мұнда сіз пиццерияны құру, оның бонустық акциялары, қызметкерлерді қабылдау және олармен жұмыс істеу, есеп беру функцияларын таба аласыз.
-
PublicScreens - пиццерияларда ілулі тұрған теледидарлар мен планшеттерге арналған интерфейстер. Теледидар жеткізілім кезінде мәзірді, жарнама туралы ақпаратты және тапсырыс күйін көрсетеді.
Олар жалпы қызмет көрсету деңгейін, Dodo.Core домен класстарының ортақ блогын және ортақ базаны пайдаланды. Кейде олар әлі де бір-біріне өту арқылы жете алады. Сонымен қатар, dodopizza.ru немесе personal.dodopizza.ru сияқты жеке сайттар да жалпы қызметтерге қол жеткізді.
Жаңа модульдер пайда болған кезде біз дерекқордағы қызметтер үшін бұрыннан жасалған кодты, сақталған процедуралар мен кестелерді мүмкіндігінше қайта пайдалануға тырыстық.
Жүйеде жасалған модульдердің масштабын жақсырақ түсіну үшін даму жоспарлары бар 2012 жылғы диаграмма:
2015 жылға қарай барлығы өз орнында болды, одан да көп өндірісте болды.
-
Тапсырысты қабылдау байланыс орталығының жеке блогына айналды, мұнда тапсырысты оператор қабылдайды.
-
Пиццерияларда мәзірлері мен ақпараттары бар жалпыға қолжетімді экрандар пайда болды.
-
Ас үйде жаңа тапсырыс келгенде автоматты түрде «Жаңа пицца» дауыстық хабарламасын беретін модуль бар, сонымен қатар курьер үшін шот-фактураны басып шығарады. Бұл асүйдегі процестерді айтарлықтай жеңілдетеді және қызметкерлерді қарапайым операциялардың үлкен санына алаңдатпауға мүмкіндік береді.
-
Жеткізу блогы жеке Жеткізу кассиріне айналды, мұнда тапсырыс бұрын ауысымын қабылдаған курьерге берілді. Жалақысын есептеу үшін оның жұмыс уақыты ескерілді.
Сонымен қатар, 2012 жылдан 2015 жылға дейін 10-нан астам әзірлеушілер пайда болды, 35 пиццерия ашылды, жүйе Румынияға орналастырылды және АҚШ-та нүктелерді ашуға дайындалды. Әзірлеушілер енді барлық тапсырмаларға қатыспады, бірақ командаларға бөлінді. әрқайсысы жүйенің өз бөлігіне маманданған.
проблемалар
Соның ішінде архитектураға байланысты (тек қана емес).
Базадағы хаос
Бір база ыңғайлы. Реляциялық мәліметтер базасына енгізілген құралдар есебінен жүйелілікке қол жеткізуге болады. Онымен жұмыс істеу таныс және ыңғайлы, әсіресе кестелер аз және деректер аз болса.
Бірақ дамудың 4 жылында деректер базасында 600-ге жуық кестелер, 1500 сақталған процедуралар болды, олардың көпшілігінде логика да болды. Өкінішке орай, сақталған процедуралар MySQL-мен жұмыс істегенде көп пайда бермейді. Олар дерекқормен кэштелмейді және оларда логиканы сақтау әзірлеуді және жөндеуді қиындатады. Кодты қайта пайдалану да қиын.
Көптеген кестелерде сәйкес индекстер болмады, бір жерде, керісінше, кірістіруді қиындатқан индекстер көп болды. 20-ға жуық кестені өзгерту керек болды — тапсырыс жасау үшін транзакция шамамен 3-5 секундқа созылуы мүмкін.
Кестелердегі деректер әрқашан ең қолайлы пішінде бола бермейді. Бір жерде денормальизация жасау керек болды. Тұрақты алынған деректердің кейбірі XML құрылымы түріндегі бағанда болды, бұл орындалу уақытын ұлғайтты, сұрауларды ұзартты және өңдеуді қиындатты.
Дәл осындай кестелер өте әсер етті гетерогенді сұраныстар. Жоғарыда аталған кесте сияқты танымал кестелер әсіресе әсер етті тапсырыстар немесе кестелер Пиццерия. Олар асүйдегі операциялық интерфейстерді және аналитиканы көрсету үшін пайдаланылды. Сайт оларға да хабарласты (), мұнда көптеген сұраулар кез келген уақытта кенеттен келуі мүмкін.
Деректер жинақталмаған және көптеген есептеулер базаны пайдалана отырып, ұшып жүрді. Бұл қажетсіз есептеулер мен қосымша жүктемені тудырды.
Көбінесе код дерекқорға оны жасай алмаған кезде кіреді. Бір жерде жаппай операциялар жетіспеді, бір жерде жылдамдату және сенімділікті арттыру үшін код арқылы бір сұрауды бірнешеге бөлу қажет болады.
Когезия және кодтағы шатасу
Бизнестің өз бөлігіне жауапты болуы керек модульдер мұны адал істемеді. Олардың кейбіреулерінде рөлдер үшін функциялардың қайталануы болды. Мысалы, өз қаласындағы желінің маркетингтік қызметіне жауапты жергілікті маркетолог «Әкімші» интерфейсін (жарнамаларды орнату үшін) және «Офис менеджері» интерфейсін (жарнамалардың компанияға әсерін көру үшін) пайдалануы керек болды. бизнес). Әрине, екі модульдің ішінде бонустық акциялармен жұмыс істейтін бір қызмет пайдаланылды.
Қызметтер (бір монолитті үлкен жобадағы сыныптар) деректерін байыту үшін бір-біріне қоңырау шала алады.
Деректерді сақтайтын үлгі сыныптарымен, кодекстегі жұмыс басқаша жүргізілді. Бір жерде конструкторлар болды, олар арқылы қажетті өрістерді көрсетуге болады. Бір жерде бұл қоғамдық мүлік арқылы жасалды. Әрине, мәліметтер базасынан деректерді алу және түрлендіру әртүрлі болды.
Логика контроллерлерде немесе қызмет көрсету сыныптарында болды.
Бұл кішігірім мәселелер сияқты көрінеді, бірақ олар дамуды айтарлықтай баяулатады және сапаны төмендетті, бұл тұрақсыздық пен қателерге әкелді.
Үлкен дамудың күрделілігі
Дамудың өзінде қиындықтар туындады. Жүйенің әртүрлі блоктарын және параллельді құру қажет болды. Әрбір құрамдастың қажеттіліктерін бір кодқа сәйкестендіру қиындай түсті. Барлық құрамдастарды бір уақытта келісіп, қуанту оңай болған жоқ. Бұған технологиядағы шектеулер қосылды, әсіресе негізге және алдыңғы жағына қатысты. Жоғары деңгейлі фреймворктардың пайдасына, әсіресе клиенттік қызмет көрсету (веб-сайт) тұрғысынан JQuery-ден бас тарту қажет болды.
Жүйенің кейбір бөліктері бұл үшін қолайлы деректер қорын пайдалана алады. Мысалы, кейінірек бізде тапсырыс арбасын сақтау үшін Redis-тен CosmosDB-ге ауысу прецеденті болды.
Өз аймағында жұмыс істейтін командалар мен әзірлеушілер өз қызметтеріне даму тұрғысынан да, шығару тұрғысынан да көбірек тәуелсіздікті қалайтыны анық. Біріктіру кезіндегі қайшылықтар, шығарылымдар кезіндегі проблемалар. Егер 5 әзірлеуші үшін бұл мәселе елеусіз болса, онда 10 және одан да көп жоспарланған өсумен бәрі маңыздырақ болады. Ал мобильді қосымшаны әзірлеу күтіп тұрды (ол 2017 жылы басталды, ал 2018 жылы болды. ).
Жүйенің әртүрлі бөліктері әртүрлі тұрақтылық көрсеткіштерін талап етті, бірақ жүйенің күшті қосылуына байланысты біз мұны қамтамасыз ете алмадық. Әкімші панеліндегі жаңа функцияны әзірлеу кезіндегі қате сайтта тапсырысты қабылдауға әкелуі мүмкін, себебі код жалпы және қайта пайдалануға жарамды, дерекқор мен деректер де бірдей.
Осындай монолитті-модульдік архитектура аясында бұл қателер мен проблемаларды болдырмауға болатын шығар: жауапкершіліктердің бөлінуін жасаңыз, кодты да, дерекқорды да рефакторлаңыз, қабаттарды бір-бірінен анық бөліңіз және күн сайын сапаны бақылаңыз. Бірақ таңдалған архитектуралық шешімдер мен жүйенің функционалдығын тез кеңейтуге назар аудару тұрақтылық мәселелерінде проблемаларға әкелді.
Power of Mind блогы кассаларды мейрамханаларға қалай қояды
Егер пиццерия желісінің өсуі (және жүктеме) сол қарқынмен жалғасатын болса, онда біраз уақыттан кейін құлдырау жүйе қалпына келмейтіндей болады. Келесі оқиға 2015 жылға қарай бетпе-бет келе бастаған мәселелерді жақсы көрсетеді.
блогында»«барлық желі бойынша бір жылдағы кіріс деректерін көрсететін виджет болды. Виджет осы деректерді беретін жалпы Dodo API интерфейсіне қол жеткізді. Бұл статистика қазір қол жетімді . Виджет әр бетте көрсетіліп, әрбір 20 секунд сайын таймерде сұраулар жасалды. Өтініш api.dodopizza.ru сайтына кіріп, сұрады:
-
желідегі пиццериялардың саны;
-
жыл басынан бері желінің жалпы кірісі;
-
бүгінгі табыс.
Кіріс статистикасына сұраныс тікелей дерекқорға түсіп, тапсырыстар туралы деректерді сұрай бастады, деректерді тікелей жылдам біріктіріп, соманы шығара бастады.
Мейрамханалардағы кассалар сол тапсырыстар кестесіне кіріп, бүгінгі күнге қабылданған тапсырыстар тізімін жүктеп, оған жаңа тапсырыстар қосылды. Кассалар әрбір 5 секунд сайын немесе бетті жаңартқанда өз сұраныстарын жасады.
Диаграмма келесідей болды:
Күздің бір күні Федор Овчинников өзінің блогында ұзақ әрі танымал мақала жазды. Көптеген адамдар блогқа келіп, бәрін мұқият оқи бастады. Келген адамдардың әрқайсысы мақаланы оқып жатқанда, кіріс виджеті дұрыс жұмыс істеп, API интерфейсін әрбір 20 секунд сайын сұрады.
API желідегі барлық пиццериялар үшін жыл басынан бері барлық тапсырыстар сомасын есептеу үшін сақталған процедураны шақырды. Агрегация өте танымал тапсырыстар кестесіне негізделген. Сол кездегі барлық ашылған мейрамханалардың барлық кассалары соған барады. Кассалар жауап беруді тоқтатып, тапсырыстар қабылданбады. Олар сондай-ақ сайттан қабылданбады, трекерде пайда болмады және ауысым менеджері оларды интерфейсінде көре алмады.
Бұл жалғыз әңгіме емес. 2015 жылдың күзіне қарай әр жұма сайын жүйеге жүктеме өте ауыр болды. Бірнеше рет біз жалпыға ортақ API-ны өшірдік, бірде ештеңе көмектеспегендіктен сайтты өшіруге тура келді. Тіпті ауыр жүктеме кезінде өшіру тәртібімен қызметтердің тізімі де болды.
Осы уақыттан бастап біздің жүктемелермен және жүйені тұрақтандыру үшін күрес басталады (2015 жылдың күзінен 2018 жылдың күзіне дейін). Сол кезде болды»" Әрі қарай, кейде сәтсіздіктер де болды, олардың кейбіреулері өте сезімтал болды, бірақ жалпы тұрақсыздық кезеңі енді аяқталды деп санауға болады.
Бизнестің жылдам өсуі
Неліктен мұны «бірден жақсы» жасауға болмайды? Тек келесі графиктерді қараңыз.
Сондай-ақ 2014-2015 жылдары Румынияда ашылу болды және АҚШ-та ашылу дайындалуда.
Тізбек өте тез өсті, жаңа елдер ашылды, пиццерияның жаңа форматтары пайда болды, мысалы, фуд-кортта пиццерия ашылды. Мұның бәрі Dodo IS функцияларын кеңейтуге ерекше назар аударуды талап етті. Осы функциялардың барлығынсыз, ас үйде қадағаламай, жүйедегі өнімдер мен ысыраптарды есепке алмай, фуд-корт залында тапсырыстарды жеткізуді көрсетпестен, біз қазір «дұрыс» архитектура және «дұрыс» туралы айту екіталай. » даму тәсілі.
Архитектураны уақтылы қайта қарауға және техникалық мәселелерге жалпы көңіл бөлуге тағы бір кедергі 2014 жылғы дағдарыс болды. Мұндай нәрселер командалардың өсу мүмкіндіктеріне, әсіресе Dodo Pizza сияқты жас бизнеске зиян тигізеді.
Көмектесетін жылдам шешімдер
Мәселелерді шешу қажет. Шартты түрде шешімдерді 2 топқа бөлуге болады:
-
Өртті сөндіретін және бізге кішкене қауіпсіздік шегін беретін және өзгертуге уақыт алатын жылдам адамдар.
-
Жүйелі және, демек, ұзақ. Бірқатар модульдерді реинжинирингтеу, монолитті архитектураны бөлек қызметтерге бөлу (олардың көпшілігі микро емес, макро қызметтер және бұл туралы тағы басқалар бар. ).
Жылдам өзгерістердің құрғақ тізімі:
Негізгі шебердің масштабын ұлғайту
Әрине, жүктемемен күресу үшін жасалатын бірінші нәрсе - сервер қуатын арттыру. Бұл негізгі дерекқор мен веб-серверлер үшін жасалды. Өкінішке орай, бұл белгілі бір шекке дейін ғана мүмкін, ал одан әрі ол тым қымбатқа түседі.
2014 жылдан бастап біз Azure-ге көштік; біз бұл тақырыпты сол кездегі мақалада жазғанбыз." Бірақ сервердің бірқатар ұлғаюынан кейін базаның құны шекке жетті.
Оқуға арналған деректер базасының көшірмелері
Біз база үшін екі көшірме жасадық:
Репликаны оқу каталог сұраулары үшін. Ол қала, көше, пиццерия, өнімдер (баяу өзгертілген домен) сияқты анықтамалықтарды оқу үшін және кішкене кідіріс қолайлы болатын интерфейстерде қолданылады. Бұл көшірмелердің 2-і болды, біз олардың қол жетімділігін шебері сияқты қамтамасыз еттік.
Есеп сұрауларына арналған репликаны оқыңыз. Бұл дерекқордың қолжетімділігі төмен болды, бірақ барлық есептер оған жіберілді. Оларда үлкен деректерді қайта есептеуге үлкен сұраныстар болуы мүмкін, бірақ олар негізгі дерекқорға және операциялық интерфейстерге әсер етпейді.
Кодтағы кэштер
Кодтың еш жерінде кэштер болған жоқ (мүлдем). Бұл жүктелген дерекқорға әрқашан қажет емес қосымша сұрауларға әкелді. Бастапқыда кэштер жадта да, сыртқы кэш қызметінде де болды, бұл Redis болды. Барлығы уақыт бойынша жарамсыз болды, параметрлер кодта көрсетілді.
Серверге арналған бірнеше серверлер
Қолданбаның артқы жағы да жоғары жүктемелерге төтеп беру үшін масштабталуы керек болды. Бір IIS серверінен кластер жасау қажет болды. Біз көштік RedisCache жадынан, бұл қарапайым жүктеме теңгерімінің артында бірнеше серверлерді айналмалы жүйемен құруға мүмкіндік берді. Бастапқыда кэштер үшін бірдей Redis пайдаланылды, содан кейін олар бірнешеге бөлінді.
Нәтижесінде сәулет күрделене түсті...
...бірақ біраз шиеленіс басылды.
Содан кейін жүктелген компоненттерді қайта жасау керек болды, бұл біз қабылдаған нәрсе. Бұл туралы келесі бөлімде айтатын боламыз.
Ақпарат көзі: www.habr.com