Або кожная няшчасная кампанія з маналітам нешчаслівая па-свойму.
Распрацоўка сістэмы Dodo IS пачалася адразу ж, як і бізнэс Дадо Піцы – у 2011 годзе. У аснове ляжала ідэя поўнай і татальнай аблічбоўкі бізнес-працэсаў, прычым , што яшчэ тады ў 2011 годзе выклікала шмат пытанняў і скептыцызму. Але вось ужо 9 гадоў мы ідзем па такім шляху - з уласнай распрацоўкай, якая пачыналася з маналіта.
Гэты артыкул - "адказ" на пытанні "Навошта перапісваць архітэктуру і рабіць такія маштабныя і доўгія змены?" да папярэдняга артыкула . Пачну з таго як пачыналася распрацоўка Dodo IS, як выглядала першапачатковая архітэктура, як з'яўляліся новыя модулі, і з-за якіх праблем прыйшлося праводзіць маштабныя змены.
Серыя артыкулаў "Што такое Dodo IS?" раскажа пра:
-
Ранні маналіт у Dodo IS (2011-2015 гады). (You are here)
-
.
-
Шлях кліенцкай часткі: фасад над базай (2016-2017 гады). (In progress…)
-
Гісторыя сапраўдных мікрасэрвісаў. (2018-2019 гады). (In progress…)
-
Скончаны распілоўванне маналіта і стабілізацыя архітэктуры. (In progress…)
Першапачатковая архітэктура
У 2011 годзе архітэктура Dodo IS выглядала так:
Першы модуль у архітэктуры - прыём замовы. Бізнес-працэс быў такі:
-
кліент тэлефануе ў піцэрыю;
-
трубку бярэ менеджэр;
-
прымае па тэлефоне замову;
-
паралельна набівае яго ў інтэрфейсе прыёму замовы: улічваецца інфармацыя аб кліенце, дадзеныя па дэталях замовы, адрас дастаўкі.
Інтэрфейс інфармацыйнай сістэмы выглядаў прыкладна так…
Першая версія ад кастрычніка 2011:
Рэсурсы для распрацоўкі першага модуля прыёму замовы былі абмежаваныя. Трэба было рабіць шмат, хутка і малым саставам. Малы склад - гэта 2 распрацоўшчыка, якія і заклалі падмурак ўсёй будучай сістэмы.
Іх першае рашэнне вызначыла далейшы лёс тэхналагічнага стэка:
-
Backend на ASP.NET MVC, мова C#. Распрацоўнікі былі датнетчыкамі, гэты стэк быў ім знаёмы і прыемны.
-
Франтэнд на Bootstrap і JQuery: інтэрфейсы карыстальніка на самапісных стылях і скрыптах.
-
База дадзеных MySQL: без выдаткаў на ліцэнзіі, простая ў выкарыстанні.
-
Серверы на Windows Server, таму што. NET тады мог быць толькі пад Windows (Mono абмяркоўваць не будзем).
Фізічна гэта ўсё выяўлялася ў "дэдзіку ў хостэра".
Архітэктура прыкладання прыёму замовы
Тады ўжо ўсё казалі аб мікрасэрвісах, а SOA гадоў 5 выкарыстоўвалася ў буйных праектах, напрыклад, WCF выйшаў у 2006 году. Але тады выбралі надзейнае і праверанае рашэнне.
Вось яно.
Asp.Net MVC - гэта Razor, які выдае па запыце з формы або ад кліента HTML-старонку з рэндэрынгам на серверы. На кліенце ўжо CSS і JS-скрыпты адлюстроўваюць інфармацыю і, па неабходнасці, выконваюць AJAX-запыты праз JQuery.
Запыты на серверы пападаюць у класы *Controller, дзе ў метадзе адбываецца апрацоўка і генерацыя выніковай HTML-старонкі. Кантролеры робяць запыты на пласт логікі, званы Services. Кожны з сэрвісаў адказваў нейкаму аспекту бізнэсу:
-
Напрыклад, DepartmentStructureService выдаваў інфармацыю па піцэрыях, па дэпартаментах. Дэпартамент - гэта група піцэрый пад кіраваннем аднаго франчайзі.
-
ReceivingOrdersService прымаў і разлічваў склад замовы.
-
А SmsService адпраўляў смс, выклікаючы API-сэрвісы па адпраўцы смс.
Сэрвісы апрацоўвалі дадзеныя з базы, захоўвалі бізнэс-логіку. У кожным сэрвісе быў адзін ці некалькі *Repository з адпаведнай назвай. У іх ужо знаходзіліся запыты да захоўваемых працэдур у базе і пласт мапераў. У захоўвальнях была бізнэс-логіка, асабліва шмат у тых, якія выдавалі справаздачныя дадзеныя. ОРМ не выкарыстоўваўся, усё належылі на напісаны рукамі sql.
Яшчэ быў пласт даменнай мадэлі і агульных класаў-хелпераў, напрыклад, клас Order, які захоўваў замову. Тамсама, у пласце, знаходзіўся хелпер для пераўтварэння тэксту адлюстравання па абранай валюце.
Усё гэта можна ўявіць такой мадэллю:
Шлях замовы
Разгледзім спрошчаны першапачатковы шлях стварэння такой замовы.
Першапачаткова сайт быў статычны. На ім былі кошты, а зверху - нумар тэлефона і надпіс "Хочаш піцу - тэлефануй па нумары і закажы". Для замовы нам трэба рэалізаваць просты flow:
-
Кліент заходзіць на статычны сайт з коштамі, выбірае прадукты і тэлефануе па нумары, які пазначаны на сайце.
-
Кліент называе прадукты, якія хоча дадаць у замову.
-
Заве свой адрас і імя.
-
Аператар прымае замову.
-
Заказ адлюстроўваецца ў інтэрфейсе прынятых заказаў.
Усё пачынаецца з адлюстравання меню. Залагінены карыстач-аператар у адзін момант часу прымае толькі адна замова. Таму draft-кошык можа захоўвацца ў яго сесіі (сеанс карыстальніка захоўваецца ў памяці). Там аб'ект Cart, у якім прадукты і інфармацыя аб кліенце.
Кліент называе прадукт, аператар націскае на + побач з прадуктам, і на сервер адпраўляецца запыт. Па прадукце выцягваецца інфармацыя з базы і дадаецца інфармацыя аб прадукце ў кошык.
Заўвага. Так, тут можна не выцягваць прадукт з базы, а перадаваць з франтэнда. Але для навочнасці я паказаў менавіта шлях з базы.
Далей уводзім адрас і імя кліента.
Пры націску «Стварыць замову»:
-
Запыт адпраўляем у OrderController.SaveOrder().
-
Атрымліваем Cart з сесіі, там ляжаць прадукты ў патрэбнай нам колькасці.
-
Дапаўняем Cart інфармацыяй аб кліенце і перадаем у метад AddOrder класа ReceivingOrderService, дзе ён захоўваецца ў базу.
-
У базе ёсць табліцы з замовай, складам замовы, кліентам і яны ўсё злучаны.
-
Інтэрфейс адлюстравання замовы ідзе і выцягвае апошнія замовы і адлюстроўвае іх.
Новыя модулі
Прыём замовы быў важны і неабходны. Нельга зрабіць бізнэс па продажы піцы, калі няма прыёму замовы для продажу. Таму сістэма пачала абрастаць функцыяналам - прыкладна з 2012 па 2015 гады. За гэты час з'явілася шмат розных блокаў сістэмы, якія я буду зваць модулямі, у процівагу паняццю сэрвісу або прадукта.
Модуль - гэта набор функцый, якія аб'яднаны нейкі агульнай бізнес-мэтай. Пры гэтым фізічна яны знаходзяцца ў адным дадатку.
Модулі можна назваць блокамі сістэмы. Напрыклад, гэта модуль справаздач, інтэрфейсы адмінкі, , аўтарызацыя. Гэта ўсе розныя інтэрфейсы для карыстальніка, некаторыя маюць нават розныя візуальныя стылі. Пры гэтым усё ў рамках аднаго дадатку, аднаго працуючага працэсу.
Тэхнічна модулі афармляліся як Area (вось такая ідэя нават засталася ў ). Там былі асобныя файлы для франтэнда, мадэляў, а таксама свае класы кантролераў. У выніку сістэма пераўтварылася з такой…
…у такую:
Некаторыя модулі рэалізаваны асобнымі сайтамі (executable project), з прычыны зусім ужо асобнага функцыяналу і часткова з-за некалькі асобнай, больш сфакусаванай распрацоўкі. Гэта:
-
сайт - сайта dodopizza.ru.
-
Экспарт: выгрузка справаздач з Dodo IS для 1C.
-
Асабісты - асабісты кабінет супрацоўніка. Асобна распрацоўваўся і мае свой пункт уваходу і асобны дызайн.
-
fs - Праект для хостынгу статыкі. Пазней мы сышлі ад яго, перавядучы ўсю статыку на CDN Akamai.
Астатнія ж блокі знаходзіліся ў дадатку BackOffice.
Тлумачэнне па назвах:
-
Cashier - Каса рэстарана.
-
ShiftManager - інтэрфейсы для ролі "Менеджэр змены": аператыўная статыстыка па продажах піцэрыі, магчымасць паставіць у стоп-ліст прадукты, змяніць заказ.
-
OfficeManager – інтэрфейсы для ролі «Кіраўнік піцэрыі» і «франчайзі». Тут сабраны функцыі па наладзе піцэрыі, яе бонусных акцый, прыём і праца з супрацоўнікамі, справаздачы.
-
PublicScreens - інтэрфейсы для тэлевізараў і планшэтаў, якія вісяць у піцэрыях. На тэлевізарах адлюстроўваецца меню, рэкламная інфармацыя, статус замовы пры выдачы.
Яны выкарыстоўвалі агульны пласт сэрвісаў, агульны блок даменных класаў Dodo.Core, а таксама агульную базу. Часам яшчэ маглі весці па пераходах сябар да сябра. У тым ліку да агульных сэрвісаў хадзілі і асобныя сайты, накшталт dodopizza.ru ці personal.dodopizza.ru.
Пры з'яўленні новых модуляў імкнуліся па максімуме перавыкарыстоўваць ужо створаны код сэрвісаў, захоўваемых працэдур і табліц у базе.
Для лепшага разумення маштабу модуляў, зробленых у сістэме, вось схема з 2012 года з планамі развіцця:
Да 2015 года ўсё на схеме і нават больш было ў прадакшн.
-
Прыём замовы перарос у асобны блок Кантакт Цэнтра, дзе замова прымаецца аператарам.
-
З'явіліся агульнадаступныя экраны з меню і інфармацыяй, якія вісяць у піцэрыях.
-
На кухні ёсць модуль, які аўтаматычна прайгравае галасавое паведамленне "Новая піца" пры паступленні новай замовы, а таксама друкуе накладную для кур'ера. Гэта моцна спрашчае працэсы на кухні, дазваляе не адцягвацца на вялікую колькасць простых аперацый супрацоўнікам.
-
Блок дастаўкі стаў асобнай Касай Дастаўкі, дзе замова выдавалася кур'еру, які папярэдне стаў на змену. Улічваўся яго працоўны час для налічэння зарплаты.
Паралельна з 2012 па 2015 з'явілася больш за 10 распрацоўшчыкаў, адкрылася 35 піцэрый, разгарнулі сістэму на Румынію і падрыхтавалі да адкрыцця кропак у ЗША. Распрацоўнікі ўжо не займаліся ўсімі задачамі, а былі падзеленыя на каманды. кожная спецыялізавалася на сваёй частцы сістэмы.
Праблемы
У тым ліку з-за архітэктуры (але не толькі).
Хаос у базе
Адна база - гэта зручна. У ёй можна дабіцца кансістэнтнасці, прычым за кошт сродкаў, убудаваных у рэляцыйныя базы. Працаваць з ёй звыкла і зручна, асабліва, калі там мала табліц і крыху дадзеных.
Але за 4 гады распрацоўкі ў базе аказалася каля 600 табліц, 1500 захоўваемых працэдур, у многіх з якіх была яшчэ і логіка. Нажаль, захоўваемыя працэдуры не прыносяць адмысловай перавагі пры працы з MySQL. Яны не кэшуюцца базай, а захоўванне ў іх логікі ўскладняе распрацоўку і адладку. Перавыкарыстанне кода таксама абцяжарана.
На многіх табліцах не было прыдатных індэксаў, Недзе, наадварот, было вельмі шмат індэксаў, што абцяжарвала ўстаўку. Трэба было мадыфікаваць каля 20 табліц - транзакцыя на стварэнне замовы магла выконвацца каля 3-5 секунд.
Дадзеныя ў табліцах не заўсёды былі ў найбольш прыдатнай форме. Недзе трэба было зрабіць дэнармалізацыю. Частка рэгулярна атрымоўваных дадзеных была ў калонцы ў выглядзе XML-структуры, гэта павялічвала час выканання, даўжэла запыты і ўскладняла распрацоўку.
Да адных і тых жа табліц праводзіліся вельмі разнастайныя запыты. Асабліва пакутавалі папулярныя табліцы, накшталт згадванай табліцы заказы або табліцы піцэрыя. Яны выкарыстоўваліся для вываду аператыўных інтэрфейсаў на кухні, аналітыкі. Яшчэ да іх звяртаўся сайт(), куды ў любы момант часу магло прыйсці раптоўна шмат запытаў.
Дадзеныя не былі агрэгаваныя і шмат разлікаў адбывалася на ляту сродкамі базы. Гэта стварала лішнія вылічэнні і дадатковую нагрузку.
Часта код хадзіў у базу тады, калі мог гэтага не рабіць. Недзе не хапала bulk-аперацый, недзе трэба было б разнесці адзін запыт на некалькі праз код, каб паскорыць і павысіць надзейнасць.
Сувязь і заблытанасць у кодзе
Модулі, якія павінны былі адказваць за свой участак бізнэсу, не рабілі гэтага сапраўды. Некаторыя з іх мелі дубліраванне па функцый для роляў. Напрыклад, лакальнаму маркетолага, які адказвае за маркетынгавую актыўнасць сеткі ў сваім горадзе, даводзілася карыстацца як інтэрфейсам "Адміна" (для ўстановы акцый), так і інтэрфейсам "Менеджара Офіса" (для прагляду ўплыву акцый на бізнес). Вядома, усярэдзіне абодва модуля выкарыстоўвалі адзін сэрвіс, які працаваў з з бонуснымі акцыямі.
Сэрвісы (класы ў рамках аднаго маналітнага вялікага праекту) маглі выклікаць адзін аднаго для ўзбагачэння сваіх дадзеных.
З самімі класамі-мадэляў, якія захоўваюць дадзеныя, праца ў кодзе вялася розна. Недзе былі канструктары, праз якія можна было ўказаць абавязковыя палі. Недзе гэта рабілася праз публічныя ўласцівасці. Вядома, атрыманне і пераўтварэнне дадзеных з базы было разнастайным.
Логіка была альбо ў кантролерах, альбо ў класах сервісаў.
Гэта накшталт малаважныя праблемы, але яны моцна запавольвалі распрацоўку і змяншалі якасць, што прыводзіла да нестабільнасці і памылкам.
Складанасць вялікай распрацоўкі
Цяжкасці ўзніклі і ў самой распрацоўцы. Трэба было рабіць розныя блокі сістэмы, прычым раўналежна. Змясціць патрэбы кожнага кампанента ў адзіны код станавілася ўсё цяжэй. Было не проста дамовіцца і дагадзіць усім кампанентам адначасова. Да гэтага дадаваліся абмежаванні ў тэхналогіях, асабліва датычна базы і фронтэнда. Трэба было адмаўляцца ад JQuery у бок высокаўзроўневых фрэймворкаў, асабліва ў часткі кліенцкіх сэрвісаў (сайт).
У нейкіх частках сістэмы маглі б выкарыстоўвацца базы, больш прыдатныя для гэтага. Напрыклад, пазней у нас быў прэцэдэнт пераходу з Redis на CosmosDB для захоўвання кошыка замовы.
Каманды і распрацоўшчыкі, якія займаюцца сваёй вобласцю відавочна хацелі большай самастойнасці для сваіх сэрвісаў, як у частцы распрацоўкі, так і ў частцы выкаткі. Канфлікты пры мержы, праблемы пры рэлізах. Калі для 5 распрацоўшчыкаў гэтая праблема неістотная, то пры 10, а ўжо тым больш пры планаваным росце, усё стала б больш сур'ёзна. А а наперадзе павінна была быць распрацоўка мабільнага дадатку (яна стартанула ў 2017, а ў 2018 было ).
Розныя часткі сістэмы патрабавалі розных паказчыкаў стабільнасці, але ў сілу моцнай складнасці сістэмы, мы не маглі гэтага забяспечыць. Памылка пры распрацоўцы новай функцыі ў адмінцы, суцэль магла стрэліць у прыёме замовы на сайце, бо код агульны і які перавыкарыстоўваецца, база і дадзеныя таксама адзіныя.
Верагодна, можна было б і ў рамках такой маналітна-модульнай архітэктуры не дапушчаць гэтых памылак і праблем: зрабіць падзел адказнасці, праводзіць рэфактарынг як кода, так і базы дадзеных, выразна аддзяляць пласты сябар ад сябра, сачыць за якасцю кожны дзень. Але абраныя архітэктурныя рашэнні і фокус на хуткім пашырэнні функцыяналу сістэмы прывялі да праблем у пытаннях стабільнасці.
Як блог Сіла розуму паклаў касы ў рэстаранах
Калі рост сеткі піцэрый (і нагрузкі) працягваўся б у тым жа тэмпе, то праз некаторы час падзення былі б ужо такімі, што сістэма і не паднімецца. Добра ілюструе праблемы, з якімі мы пачалі сутыкацца да 2015 вось такая гісторыя.
У блогу «» быў віджэт, які паказваў дадзеныя па выручцы за год усёй сеткі. Віджэт звяртаўся да публічнага API Dodo, які падае гэтыя дадзеныя. Цяпер гэтая статыстыка даступная на . Віджэт паказваўся на кожнай старонцы і рабіў запыты па таймеры кожныя 20 секунд. Запыт сыходзіў у api.dodopizza.ru і запытваў:
-
колькасць піцэрый у сетцы;
-
агульную выручку сеткі з пачатку года;
-
выручку за сёння.
Запыт на статыстыку па выручцы ішоў адразу ў базу і пачынаў запытваць дадзеныя па замовах, агрэгаваць дадзеныя прама на лета і выдаваць суму.
У гэтую ж табліцу заказаў хадзілі Касы ў рэстаранах, выгружалі спіс прынятых за сёння заказаў, у яе ж дадаваліся новыя замовы. Касы рабілі свае запыты кожныя 5 секунд ці па абнаўленні старонкі.
Схема выглядала так:
Аднойчы ўвосень, Фёдар Аўчыннікаў напісаў у свой блог доўгі і папулярны артыкул. На блог прыйшло вельмі шмат людзей і сталі ўважліва чытаць. Пакуль кожны з прыйшэлых чалавек чытаў артыкул, віджэт з выручкай спраўна працаваў і запытваў API кожныя 20 секунд.
API выклікала захоўваемую працэдуру на разлік сумы ўсіх заказаў з пачатку года па ўсіх піцэрыях сеткі. Агрэгацыя ішла па табліцы orders, якая вельмі папулярная. У яе ж ходзяць усе касы ўсіх адкрытых рэстаранаў на той момант. Касы перасталі адказваць, замовы не прымаліся. Яшчэ яны не прымаліся з сайта, не з'яўляліся на трэкеры, менеджэр змены не мог убачыць іх у сваім інтэрфейсе.
Гэта не адзіная гісторыя. Да восені 2015 года кожную пятніцу нагрузка на сістэму была крытычная. Некалькі разоў мы выключалі публічнае API, а аднойчы нам давялося нават адключыць сайт, бо ўжо нічога не дапамагала. Быў нават спіс сервісаў з парадкам адключэння пры сур'ёзных нагрузках.
З гэтага часу пачынаецца нашая барацьба з нагрузкамі і за стабілізацыю сістэмы (з восені 2015 да восені 2018). Менавіта тады здарылася.». Далей таксама часам адбываліся збоі, некаторыя былі вельмі адчувальнымі, але агульны перыяд нестабільнасці зараз можна лічыць пройдзеным.
Бурны рост бізнэсу
Чаму нельга было "зрабіць адразу добра"? Дастаткова паглядзець на наступныя графікі.
Таксама ў 2014-2015 гг. было адкрыццё ў Румыніі і рыхтавалася адкрыццё ў ЗША.
Сетка расла вельмі хутка, адчыняліся новыя краіны, з'яўляліся новыя фарматы піцэрый, напрыклад, адкрылася піцэрыя на фудкорце. Усё гэта патрабавала значнай увагі менавіта да пашырэння функцый Dodo IS. Без усіх гэтых функцый, без трекінгу на кухні, уліку прадуктаў і страт у сістэме, адлюстравання выдачы замовы ў зале фудкорта, наўрад ці б мы цяпер разважалі аб «правільнай» архітэктуры і «верным» падыходзе да распрацоўкі.
Яшчэ перашкодамі для своечасовага перагляду архітэктуры і ўвогуле ўвагі да тэхнічных праблем, быў крызіс 2014 года. Такія рэчы балюча б'юць па магчымасцях для росту каманд, асабліва для маладога бізнэсу, якім была Дадо Піца.
Хуткія рашэнні, якія дапамаглі
Праблемы патрабавалі рашэнні. Умоўна, рашэнні можна падзяліць на 2 групы:
-
Хуткія, якія тушаць пажар і даюць невялікі запас трываласці і выйграюць нам час на змены.
-
Сістэмныя і таму доўгія. Рэінжынірынг шэрагу модуляў, падзел маналітнай архітэктуры на асобныя сэрвісы (большасць з іх цалкам не мікра, а хутчэй макрасервісы і пра гэта ёсць ).
Сухі спіс хуткіх змен такі:
Scale up майстар базы
Вядома, першае, што робіцца для барацьбы з нагрузкамі – павялічваецца магутнасць сервера. Гэта рабілі для майстар базы і для вэб-сервераў. Нажаль, гэта магчыма толькі да некаторай мяжы, далей становіцца занадта дорага.
З 2014 года мы перайшлі ў Azure, на гэтую тэму мы таксама пісалі яшчэ ў той час у артыкуле.». Але пасля чарады павелічэнняў сервера пад базу ўперліся па кошце.
Рэплікі базы на чытанне
Рэплік для базы зрабілі дзве:
ReadReplica для запытаў на даведнікі. Ужываецца для чытання даведнікаў, тыпу, гарады, вуліцы, піцэрыі, прадуктаў (slowly changed domain), і ў тых інтэрфейсах, дзе дапушчальная невялікая затрымка. Гэтых рэплік было 2, мы забяспечвалі іх даступнасць таксама, як і майстры.
ReadReplica для запытаў на справаздачы. У гэтай базы даступнасць была ніжэйшай, але ў яе хадзілі ўсе справаздачы. Няхай у іх цяжкія запыты на вялізныя пералікі дадзеных, але затое яны не ўплываюць на асноўную базу і аперацыйныя інтэрфейсы.
Кэшы ў кодзе
Кэшаў у кодзе нідзе не было (наогул). Гэта прыводзіла да дадатковых, не заўсёды патрэбных, запытаў у нагружаную базу. Кэшы былі спачатку як у памяці, так і на вонкавым кэш-сэрвісе, гэта быў Redis. Усё інвалідавалася па часе, налады паказваліся ў кодзе.
Некалькі сервераў для бэкэнда
Бэкэнд прыкладання таксама трэба было маштабаваць, каб вытрымліваць падвышаныя нагрузкі. Неабходна было зрабіць з аднаго iis-сервера кластар. Мы перанеслі з памяці на RedisCache, што дазволіла зрабіць некалькі сервераў, стаялых за простым балансавальнікам нагрузкі з round robin. Спачатку выкарыстоўваўся той жа Redis, што і для кэшаў, потым разнеслі на некалькі.
У выніку архітэктура ўскладнілася…
…але частку напружанасці ўдалося зняць.
А далей трэба было перарабляць нагружаныя кампаненты, завошта мы і ўзяліся. Пра гэта мы раскажам у наступнай частцы.
Крыніца: habr.com