Dodo IS ճարտարապետության պատմություն. վաղ մոնոլիտ

Կամ մոնոլիտ ունեցող յուրաքանչյուր դժբախտ ընկերություն յուրովի դժբախտ է։

Dodo IS համակարգի զարգացումը սկսվեց անմիջապես, ինչպես Dodo Pizza բիզնեսը, 2011 թվականին: Այն հիմնված էր բիզնես գործընթացների ամբողջական և ամբողջական թվայնացման գաղափարի վրա և ինքնուրույն, որը նույնիսկ այն ժամանակ 2011 թվականին առաջացրեց բազմաթիվ հարցեր ու թերահավատություն։ Բայց արդեն 9 տարի է, ինչ մենք գնում ենք այս ճանապարհով՝ մեր սեփական զարգացմամբ, որը սկսվել է մոնոլիտից։

Այս հոդվածը «պատասխան է» «Ինչու՞ վերաշարադրել ճարտարապետությունը և կատարել այդքան լայնածավալ և երկարաժամկետ փոփոխություններ» հարցերին: վերադառնալ նախորդ հոդվածին «Դոդո IS ճարտարապետության պատմություն. հետին գրասենյակի ճանապարհը». Ես կսկսեմ նրանից, թե ինչպես սկսվեց Dodo IS-ի զարգացումը, ինչպիսի տեսք ուներ սկզբնական ճարտարապետությունը, ինչպես հայտնվեցին նոր մոդուլներ և ինչ խնդիրների պատճառով պետք է լայնածավալ փոփոխություններ կատարվեին:

«Ի՞նչ է Dodo IS» հոդվածաշարը։ պատմում է.

1. Վաղ մոնոլիտ Dodo IS-ում (2011-2015): (դու այստեղ ես)

2. Հետևի գրասենյակի ուղին. առանձին բազաներ և ավտոբուսներ.

3. Հաճախորդի կողմի ուղին. ճակատը բազայի վրա (2016-2017 թթ.): (Ընթացքի մեջ է...)

4. Իրական միկրոծառայությունների պատմություն. (2018-2019 թթ.). (Ընթացքի մեջ է...)

5. Ավարտվեց մոնոլիտի սղոցումը և ճարտարապետության կայունացումը: (Ընթացքի մեջ է...)

Նախնական ճարտարապետություն

2011 թվականին Dodo IS ճարտարապետությունն այսպիսի տեսք ուներ.

Ճարտարապետության առաջին մոդուլը պատվերի ընդունումն է: Բիզնես գործընթացը հետևյալն էր.

• հաճախորդը զանգահարում է պիցցերիա;

• մենեջերը վերցնում է հեռախոսը;

• ընդունում է պատվեր հեռախոսով;

• այն զուգահեռ լրացնում է պատվերի ընդունման ինտերֆեյսում՝ հաշվի են առնվում հաճախորդի մասին տեղեկությունները, պատվերի մանրամասների տվյալները, առաքման հասցեն: 

Տեղեկատվական համակարգի ինտերֆեյսը այսպիսի տեսք ուներ…

Առաջին տարբերակը 2011 թվականի հոկտեմբերից.

Մի փոքր բարելավվել է 2012 թվականի հունվարին

Dodo Pizza Տեղեկատվական Համակարգ Առաքում Պիցցա Ռեստորան

Առաջին պատվերի ընդունման մոդուլի մշակման ռեսուրսները սահմանափակ էին: Մենք պետք է շատ բան անեինք՝ արագ և փոքր թիմով։ Փոքր թիմը 2 ծրագրավորողներ են, ովքեր հիմք են դրել ամբողջ ապագա համակարգի համար:

Նրանց առաջին որոշումը որոշեց տեխնոլոգիական փաթեթի ճակատագիրը.

• Backend ASP.NET MVC, C# լեզվով: Մշակողները dotnetchiki էին, այս բուրգը ծանոթ և հաճելի էր նրանց համար:

• Frontend-ը Bootstrap-ում և JQuery-ում. օգտատերերի միջերեսներ ինքնուրույն գրված ոճերի և սցենարների վրա: 

• MySQL տվյալների բազա՝ առանց լիցենզիայի ծախսերի, հեշտ օգտագործման համար:

• Սերվերներ Windows Server-ում, քանի որ .NET-ն այն ժամանակ կարող էր լինել միայն Windows-ի տակ (մենք չենք քննարկի Mono-ն):

Ֆիզիկապես այս ամենն արտահայտվում էր «հյուրընկալողի մոտ»։ 

Պատվերի ընդունման կիրառական ճարտարապետություն

Հետո արդեն բոլորը խոսում էին միկրոսերվիսների մասին, իսկ SOA-ն 5 տարի օգտագործվում էր խոշոր նախագծերում, օրինակ WCF-ն թողարկվեց 2006թ. Բայց հետո նրանք ընտրեցին հուսալի և ապացուցված լուծում:

Ահա այն.

Asp.Net MVC-ն Razor-ն է, որը ձևաթղթից կամ հաճախորդից խնդրանքով ներկայացնում է HTML էջ՝ սերվերի մատուցմամբ: Հաճախորդի վրա CSS և JS սկրիպտներն արդեն ցուցադրում են տեղեկատվություն և, անհրաժեշտության դեպքում, կատարում են AJAX հարցումներ JQuery-ի միջոցով:

Սերվերի հարցումները ավարտվում են *Controller դասերում, որտեղ մեթոդով տեղի է ունենում վերջնական HTML էջի մշակումն ու ստեղծումը։ Կարգավորիչները հարցումներ են կատարում տրամաբանության շերտին, որը կոչվում է *Ծառայություններ: Ծառայություններից յուրաքանչյուրը համապատասխանում էր բիզնեսի որոշ ասպեկտներին.

• Օրինակ, DepartmentStructureService-ը տեղեկատվություն է տրամադրել պիցցերիաների, բաժանմունքների մասին: Դեպարտամենտը պիցցերիաների խումբ է, որը ղեկավարվում է մեկ ֆրանչայզերի կողմից:

• Receiving OrdersService-ն ընդունել և հաշվարկել է պատվերի կազմը:

• Իսկ SmsService-ը SMS ուղարկեց՝ զանգահարելով API ծառայություններ՝ SMS ուղարկելու համար:

Ծառայությունները մշակել են տվյալների բազայից, պահպանել բիզնես տրամաբանությունը: Յուրաքանչյուր ծառայություն ուներ մեկ կամ մի քանի *պահեստներ՝ համապատասխան անունով: Դրանք արդեն պարունակում էին տվյալների բազայում պահված ընթացակարգերի հարցումներ և քարտեզագրողների շերտ: Պահեստներում բիզնեսի տրամաբանություն կար, հատկապես հաշվետու տվյալներ թողարկողներում: ORM-ը չէր օգտագործվում, բոլորն ապավինում էին ձեռքով գրված sql-ին: 

Կար նաև տիրույթի մոդելի շերտ և սովորական օգնական դասեր, օրինակ՝ Order դասը, որը պահում էր պատվերը։ Նույն տեղում՝ շերտում, ցուցադրման տեքստը ընտրված արժույթով փոխակերպելու օգնական կար։

Այս ամենը կարելի է ներկայացնել այսպիսի մոդելով.

Պատվերի ուղի

Դիտարկենք նման պատվեր ստեղծելու պարզեցված սկզբնական եղանակը:

Սկզբում կայքը ստատիկ էր: Դրա վրա գներ կային, իսկ վերևում՝ հեռախոսահամար և մակագրություն՝ «Եթե ուզում ես պիցցա, զանգիր համարով և պատվիրիր»։ Պատվիրելու համար մենք պետք է իրականացնենք պարզ հոսք. 

• Հաճախորդը այցելում է գներով ստատիկ կայք, ընտրում է ապրանքներ և զանգահարում է կայքում նշված համարով:

• Հաճախորդը անվանում է այն ապրանքները, որոնք ցանկանում են ավելացնել պատվերին:

• Տալիս է իր հասցեն և անունը։

• Օպերատորն ընդունում է պատվերը։

• Պատվերը ցուցադրվում է ընդունված պատվերների միջերեսում:

Ամեն ինչ սկսվում է մենյուի ցուցադրմամբ: Մուտք գործած օգտվող-օպերատորը միաժամանակ ընդունում է միայն մեկ պատվեր: Հետևաբար, սայլակը կարող է պահվել նրա նիստում (օգտագործողի նիստը պահվում է հիշողության մեջ): Կա զամբյուղի օբյեկտ, որը պարունակում է ապրանքներ և հաճախորդի տեղեկություններ:

Հաճախորդը անվանում է ապրանքը, օպերատորը կտտացնում է + ապրանքի կողքին, և հարցում է ուղարկվում սերվերին: Ապրանքի մասին տեղեկատվությունը հանվում է տվյալների բազայից և ապրանքի մասին տեղեկատվությունը ավելացվում է զամբյուղում:

Նշում. Այո, այստեղ դուք չեք կարող արտադրանքը հանել տվյալների բազայից, այլ փոխանցել այն ճակատային մասից: Բայց պարզության համար ես ցույց տվեցի ճշգրիտ ուղին տվյալների բազայից: 

Հաջորդը, մուտքագրեք հաճախորդի հասցեն և անունը: 

Երբ սեղմում եք «Ստեղծել պատվեր».

• Հարցումն ուղարկվում է OrderController.SaveOrder():

• Սեսիայից ստանում ենք զամբյուղ, կան ապրանքներ մեզ անհրաժեշտ քանակով։

• Մենք լրացնում ենք զամբյուղը հաճախորդի մասին տեղեկություններով և փոխանցում ReceivingOrderService դասի AddOrder մեթոդին, որտեղ այն պահվում է տվյալների բազայում: 

• Տվյալների բազան ունի աղյուսակներ՝ պատվերի, պատվերի կազմի, հաճախորդի, և դրանք բոլորը միացված են:

• Պատվերների ցուցադրման միջերեսը գնում է և դուրս է հանում վերջին պատվերները և ցուցադրում դրանք:

Նոր մոդուլներ

Պատվերն ընդունելը կարևոր էր և անհրաժեշտ։ Դուք չեք կարող պիցցայի բիզնեսով զբաղվել, եթե վաճառելու պատվեր չունեք: Հետևաբար, համակարգը սկսեց ձեռք բերել ֆունկցիոնալություն՝ մոտավորապես 2012 թվականից մինչև 2015 թվականը: Այս ընթացքում հայտնվեցին համակարգի բազմաթիվ տարբեր բլոկներ, որոնք ես կանվանեմ մոդուլներ, ի տարբերություն ծառայության կամ ապրանքի հասկացության։ 

Մոդուլը գործառույթների մի շարք է, որոնք միավորված են որոշ ընդհանուր բիզնես նպատակներով: Միաժամանակ նրանք ֆիզիկապես նույն հավելվածում են։

Մոդուլները կարելի է անվանել համակարգի բլոկներ: Օրինակ, սա հաշվետվության մոդուլ է, ադմինիստրատորի միջերեսներ, սննդի որոնիչ խոհանոցում, թույլտվություն։ Սրանք բոլորը տարբեր օգտատերերի միջերեսներ են, ոմանք նույնիսկ տարբեր տեսողական ոճեր ունեն: Ընդ որում, ամեն ինչ մեկ հավելվածի, մեկ ընթացիկ գործընթացի շրջանակներում է։ 

Տեխնիկապես մոդուլները նախագծված էին որպես Տարածք (նման գաղափարը նույնիսկ մնաց asp.net հիմնական). Առանձին ֆայլեր կային frontend-ի, մոդելների, ինչպես նաև իրենց սեփական վերահսկիչի դասերի համար։ Արդյունքում համակարգը վերափոխվեց այս ...

... սրա մեջ.

Որոշ մոդուլներ իրականացվում են առանձին կայքերով (գործարկվող նախագիծ)՝ լիովին առանձին ֆունկցիոնալության և մասամբ՝ մի փոքր առանձին, ավելի կենտրոնացված զարգացման շնորհիվ։ Սա.

• կայքի - առաջին տարբերակը կայքը dodopizza.ru.

• ԱրտահանումՎերբեռնում հաշվետվություններ Dodo IS-ից 1C-ի համար: 

• անձնական - աշխատողի անձնական հաշիվ. Այն մշակվել է առանձին և ունի իր մուտքի կետը և առանձին դիզայնը:

• fs — ստատիկ հոսթինգի նախագիծ: Ավելի ուշ մենք հեռացանք դրանից՝ բոլոր ստատիկները տեղափոխելով Akamai CDN: 

Մնացած բլոկները եղել են BackOffice հավելվածում։ 

Անվան բացատրությունը.

• Գանձապահ – Ռեստորանի գանձապահ։

• ShiftManager - ինտերֆեյսներ «Shift Manager» դերի համար. պիցցերիայի վաճառքի գործառնական վիճակագրություն, ապրանքները կանգառի ցուցակում տեղադրելու, կարգը փոխելու հնարավորություն:

• OfficeManager - ինտերֆեյսներ «Պիցցերիայի մենեջեր» և «Ֆրանչայզեր» դերերի համար: Այստեղ հավաքված են պիցցերիա հիմնելու գործառույթները, դրա բոնուսային առաջխաղացումները, աշխատակիցների ընդունման և աշխատելու, հաշվետվությունները։

• PublicScreens - ինտերֆեյսներ հեռուստացույցների և պլանշետների համար, որոնք կախված են պիցցերիաներում: Հեռուստացույցները ցուցադրում են մենյու, գովազդային տեղեկատվություն, պատվերի կարգավիճակը առաքման ժամանակ: 

Նրանք օգտագործում էին ընդհանուր սպասարկման շերտ, ընդհանուր Dodo.Core տիրույթի դասի բլոկ և ընդհանուր բազա: Երբեմն նրանք դեռ կարող էին առաջնորդել միմյանց անցումներով: Ներառյալ առանձին կայքերը, ինչպիսիք են dodopizza.ru-ն կամ personal.dodopizza.ru-ն, գնացին ընդհանուր ծառայություններ:

Երբ հայտնվեցին նոր մոդուլներ, մենք փորձեցինք առավելագույնս օգտագործել արդեն ստեղծված ծառայությունների ծածկագիրը, պահպանված ընթացակարգերը և աղյուսակները տվյալների բազայում: 

Համակարգում պատրաստված մոդուլների մասշտաբը ավելի լավ հասկանալու համար ներկայացնում ենք 2012 թվականի գծապատկեր՝ զարգացման պլաններով.

Մինչև 2015 թվականը ամեն ինչ կար քարտեզի վրա, և նույնիսկ ավելին էր արտադրության մեջ:

• Պատվերների ընդունումը վերածվել է Կոնտակտային կենտրոնի առանձին բլոկի, որտեղ պատվերն ընդունվում է օպերատորի կողմից:

• Պիցցերիաներում մենյուներով և տեղեկություններով հանրային էկրաններ էին կախված:

• Խոհանոցն ունի մոդուլ, որն ավտոմատ կերպով նվագարկում է «Նոր Պիցցա» ձայնային հաղորդագրությունը, երբ գալիս է նոր պատվեր, ինչպես նաև տպում է ապրանքագիր առաքիչի համար։ Սա մեծապես հեշտացնում է խոհանոցում տեղի ունեցող գործընթացները, թույլ է տալիս աշխատակիցներին չշեղվել մեծ թվով պարզ գործողություններից:

• Առաքման միավորը դարձավ առանձին Առաքման Checkout, որտեղ պատվերը տրվում էր նախկինում հերթափոխը վերցրած առաքիչին: Աշխատավարձը հաշվարկելիս հաշվի է առնվել նրա աշխատաժամանակը։ 

Զուգահեռաբար, 2012-ից 2015 թվականներին հայտնվեցին ավելի քան 10 ծրագրավորողներ, բացվեցին 35 պիցցերիաներ, տեղադրեցին համակարգը Ռումինիայում և պատրաստվեցին ԱՄՆ-ում վաճառակետերի բացմանը: Մշակողները այլեւս չէին զբաղվում բոլոր առաջադրանքներով, այլ բաժանվում էին թիմերի։ յուրաքանչյուրը մասնագիտացած է համակարգի իր մասում: 

Problems

Այդ թվում՝ ճարտարապետության պատճառով (բայց ոչ միայն):

Քաոս հիմքում

Մեկ բազան հարմար է։ Դրանում կարելի է հետևողականություն ձեռք բերել և հարաբերական տվյալների բազաներում ներկառուցված գործիքների հաշվին։ Դրա հետ աշխատելը ծանոթ և հարմար է, հատկապես, եթե կան քիչ աղյուսակներ և քիչ տվյալներ:

Սակայն 4 տարվա մշակման ընթացքում տվյալների բազան պարզվեց, որ ունի մոտ 600 աղյուսակ, 1500 պահված ընթացակարգեր, որոնցից շատերը նաև տրամաբանություն ունեին։ Ավաղ, պահպանված ընթացակարգերը մեծ առավելություն չեն տալիս MySQL-ի հետ աշխատելիս: Նրանք չեն պահվում բազայի կողմից, և դրանցում տրամաբանության պահպանումը բարդացնում է զարգացումն ու վրիպազերծումը: Կոդի կրկնակի օգտագործումը նույնպես դժվար է:

Շատ աղյուսակներ չունեին համապատասխան ինդեքսներ, ինչ-որ տեղ, ընդհակառակը, ինդեքսները շատ էին, ինչը դժվարացնում էր ներդրումը։ Անհրաժեշտ էր փոփոխել մոտ 20 աղյուսակ. պատվեր ստեղծելու գործարքը կարող էր տևել մոտ 3-5 վայրկյան: 

Աղյուսակների տվյալները միշտ չէ, որ եղել են ամենահարմար ձևով. Ինչ-որ տեղ անհրաժեշտ էր անել նորմալացում։ Պարբերաբար ստացված տվյալների մի մասը XML կառուցվածքի տեսքով սյունակում էր, ինչը մեծացրեց կատարման ժամանակը, երկարացրեց հարցումները և բարդացրեց զարգացումը:

Նույն սեղաններին արտադրվել են շատ տարասեռ պահանջներ. Հատկապես տուժել են հանրաճանաչ աղյուսակները, ինչպես վերը նշված աղյուսակը։ պատվեր կամ սեղաններ պիցցերիա. Դրանք օգտագործվել են խոհանոցում օպերատիվ ինտերֆեյսեր ցուցադրելու համար, վերլուծություններ: Նրանց հետ կապվեց մեկ այլ կայք (dodopizza.ru), որտեղ ցանկացած պահի կարող էին հանկարծակի շատ խնդրանքներ գալ: 

Տվյալները չեն համախմբվել և շատ հաշվարկներ են տեղի ունեցել թռիչքի ժամանակ՝ օգտագործելով բազան: Սա ավելորդ հաշվարկներ և լրացուցիչ բեռ է ստեղծել։ 

Հաճախ կոդը գնում էր տվյալների բազա, երբ չէր կարող դա անել: Ինչ-որ տեղ չկար բավարար զանգվածային գործողություններ, ինչ-որ տեղ անհրաժեշտ կլիներ մեկ հարցումը տարածել մի քանիսի կոդի միջոցով՝ արագացնելու և հուսալիությունը բարձրացնելու համար: 

Համախմբվածություն և խաբեություն կոդի մեջ

Մոդուլները, որոնք պետք է պատասխանատու լինեին բիզնեսի իրենց մասի համար, դա ազնվորեն չէին անում. Նրանցից ոմանք ունեցել են դերերի գործառույթների կրկնօրինակում: Օրինակ, տեղական շուկայավարը, ով պատասխանատու է ցանցի մարքեթինգային գործունեության համար իր քաղաքում, պետք է օգտագործեր և՛ «Ադմինիստրատոր» ինտերֆեյսը (առաջխաղացումներ ստեղծելու համար), և՛ «Գրասենյակային մենեջեր» ինտերֆեյսը (բիզնեսի վրա առաջխաղացումների ազդեցությունը դիտելու համար): Իհարկե, երկու մոդուլների ներսում էլ օգտագործվում էր նույն ծառայությունը, որն աշխատում էր բոնուսային առաջխաղացումների հետ:

Ծառայությունները (դասերը մեկ մոնոլիտ խոշոր նախագծի շրջանակներում) կարող են զանգահարել միմյանց՝ հարստացնելու իրենց տվյալները:

Մոդելի դասերի հետ, որոնք պահում են տվյալներ, օրենսգրքում աշխատանքն այլ կերպ է իրականացվել. Ինչ-որ տեղ կային կոնստրուկտորներ, որոնց միջոցով հնարավոր էր նշել պահանջվող դաշտերը։ Ինչ-որ տեղ դա արվել է հանրային սեփականության միջոցով: Իհարկե, տվյալների բազայից տվյալների ստացումն ու փոխակերպումը բազմազան էր: 

Տրամաբանությունը կա՛մ կարգավորիչներում էր, կա՛մ սպասարկման դասերում։ 

Թվում է, թե դրանք աննշան խնդիրներ են, բայց դրանք զգալիորեն դանդաղեցրել են զարգացումը և նվազեցրել որակը՝ հանգեցնելով անկայունության և սխալների: 

Մեծ զարգացման բարդությունը

Դժվարություններ առաջացան հենց զարգացման մեջ. Անհրաժեշտ էր կատարել համակարգի տարբեր բլոկներ, այն էլ՝ զուգահեռ. Յուրաքանչյուր բաղադրիչի կարիքները մեկ կոդի մեջ տեղավորելը գնալով ավելի դժվար էր դառնում: Հեշտ չէր բոլոր բաղադրիչներին միաժամանակ համաձայնել ու հաճոյանալ։ Սրան ավելացան տեխնոլոգիայի սահմանափակումները, հատկապես բազայի և ճակատային մասի հետ կապված: Անհրաժեշտ էր հրաժարվել jQuery-ից դեպի բարձր մակարդակի շրջանակներ, հատկապես հաճախորդների սպասարկման (կայքի) առումով:

Համակարգի որոշ մասերում դրա համար ավելի հարմար տվյալների բազաները կարող են օգտագործվել:. Օրինակ, ավելի ուշ մենք ունեցանք Redis-ից CosmosDB տեղափոխվելու օգտագործման դեպք՝ պատվերի զամբյուղ պահելու համար: 

Իրենց ոլորտում ներգրավված թիմերն ու ծրագրավորողները ակնհայտորեն ցանկանում էին ավելի շատ ինքնավարություն իրենց ծառայությունների համար, ինչպես զարգացման, այնպես էլ տարածման առումով: Միավորել կոնֆլիկտները, ազատել խնդիրները: Եթե ​​5 ծրագրավորողների համար այս խնդիրն աննշան է, ապա 10-ի դեպքում, իսկ պլանավորված աճի դեպքում՝ առավել եւս, ամեն ինչ ավելի լուրջ կդառնար։ Իսկ առջևում պետք է լիներ բջջային հավելվածի մշակումը (այն սկսվել է 2017թ., իսկ 2018թ. մեծ անկում). 

Համակարգի տարբեր մասերը պահանջում էին կայունության տարբեր մակարդակներ, սակայն համակարգի ամուր կապի պատճառով մենք չկարողացանք դա ապահովել։ Ադմինիստրատորի վահանակում նոր գործառույթի մշակման սխալ կարող էր տեղի ունենալ կայքում պատվերի ընդունման ժամանակ, քանի որ կոդը սովորական է և բազմակի օգտագործման, տվյալների բազան և տվյալները նույնպես նույնն են:

Այսպիսի միաձույլ-մոդուլային ճարտարապետության շրջանակներում, հավանաբար, հնարավոր կլիներ խուսափել այս սխալներից ու խնդիրներից. կատարել պատասխանատվության բաշխում, վերափոխել և՛ կոդը, և՛ տվյալների բազան, հստակ առանձնացնել շերտերն իրարից, ամեն օր վերահսկել որակը։ Բայց ընտրված ճարտարապետական ​​լուծումները և կենտրոնացումը համակարգի ֆունկցիոնալության արագ ընդլայնման վրա հանգեցրին խնդիրների կայունության առումով:

Ինչպես է «Մտքի ուժը» բլոգը դրել դրամարկղերը ռեստորաններում

Եթե ​​պիցցերիայի ցանցի (և բեռնվածության) աճը շարունակվեր նույն տեմպերով, ապա որոշ ժամանակ անց անկումները այնպիսին կլինեն, որ համակարգը չէր բարձրանա։ Լավ պատկերում է այն խնդիրները, որոնց հետ մենք սկսել ենք բախվել 2015 թվականին, ահա այսպիսի պատմություն. 

Բլոգում»Մտքի ուժ», վիդջեթ էր, որը ցույց էր տալիս ամբողջ ցանցի տարվա եկամուտների վերաբերյալ տվյալները: Վիջեթը մուտք է գործել Dodo հանրային API, որն ապահովում է այս տվյալները: Այս վիճակագրությունը ներկայումս հասանելի է http://dodopizzastory.com/. Վիջեթը ցուցադրվում էր յուրաքանչյուր էջում և յուրաքանչյուր 20 վայրկյանը մեկ ժամաչափով հարցումներ էր կատարում: Հարցումը գնաց api.dodopizza.ru և խնդրեց.

• ցանցում պիցցերիաների քանակը.

• ցանցի ընդհանուր եկամուտը տարվա սկզբից.

• եկամուտ այսօրվա համար.

Եկամուտների վերաբերյալ վիճակագրության հարցումն անմիջապես գնացել է տվյալների բազա և սկսել է պատվերների վերաբերյալ տվյալներ պահանջել՝ հավաքելով տվյալները և տրամադրել գումարը: 

Ռեստորանների դրամարկղերը գնացին նույն պատվերների աղյուսակին, բեռնաթափեցին այսօրվա համար ստացված պատվերների ցանկը և դրան ավելացան նոր պատվերներ։ ՀԴՄ-ներն իրենց հարցումներն անում էին 5 վայրկյանը մեկ կամ էջի թարմացումով:

Դիագրամն այսպիսի տեսք ուներ.

Մի աշնանը Ֆյոդոր Օվչիննիկովն իր բլոգում երկար ու հանրաճանաչ հոդված գրեց. Շատ մարդիկ եկան բլոգ և սկսեցին ուշադիր կարդալ ամեն ինչ: Մինչ եկած մարդկանցից յուրաքանչյուրը կարդում էր հոդվածը, եկամտի վիդջեթը ճիշտ էր աշխատում և API էր պահանջում յուրաքանչյուր 20 վայրկյանը մեկ:

API-ն անվանել է պահեստավորված ընթացակարգ՝ հաշվարկելու բոլոր պատվերների գումարը տարվա սկզբից շղթայի բոլոր պիցցերիաների համար: Համախմբումը հիմնված էր պատվերների աղյուսակի վրա, որը շատ տարածված է: Այն ժամանակ բոլոր բաց ռեստորանների բոլոր դրամարկղերը գնում են դրան։ Դրամարկղերը դադարել են արձագանքել, պատվերներ չեն ընդունվել։ Նրանք նույնպես չեն ընդունվել կայքից, չեն հայտնվել թրեքերի վրա, հերթափոխի ղեկավարը չի կարողացել դրանք տեսնել իր ինտերֆեյսում։ 

Սա միակ պատմությունը չէ. 2015 թվականի աշնանը ամեն ուրբաթ համակարգի ծանրաբեռնվածությունը կրիտիկական էր: Մի քանի անգամ մենք անջատեցինք հանրային API-ն, մեկ անգամ էլ ստիպված եղանք անջատել կայքը, քանի որ ոչինչ չօգնեց։ Անգամ կար ծանր բեռների տակ անջատման հրամանով ծառայությունների ցանկ։

Այսուհետ սկսվում է մեր պայքարը բեռների և համակարգի կայունացման համար (2015թ. աշնանից մինչև 2018թ. աշուն): Հենց դա եղավ»մեծ աշուն«. Ավելին, երբեմն պատահում էին նաև ձախողումներ, որոշները շատ զգայուն էին, բայց անկայունության ընդհանուր շրջանն այժմ կարելի է անցած համարել։

Բիզնեսի արագ աճ

Ինչու դա հնարավոր չէր անել անմիջապես: Պարզապես նայեք հետևյալ գծապատկերներին.

Նաև 2014-2015 թվականներին բացում էր Ռումինիայում և բացում էր պատրաստվում ԱՄՆ-ում։

Ցանցը շատ արագ աճեց, բացվեցին նոր երկրներ, ի հայտ եկան պիցցերիաների նոր ձևաչափեր, օրինակ՝ ֆուդ-քորթում պիցցերիա բացվեց։ Այս ամենը զգալի ուշադրություն էր պահանջում հատկապես Dodo IS գործառույթների ընդլայնմանը: Առանց այս բոլոր գործառույթների, առանց խոհանոցում հետևելու, համակարգում ապրանքների և կորուստների հաշվառման, ֆուդ դատարանի սրահում պատվերի թողարկման ցուցադրման, մենք դժվար թե խոսենք «ճիշտ» ճարտարապետության և «ճիշտ» մոտեցման մասին: զարգացում այժմ։

Ճարտարապետության ժամանակին վերանայման և ընդհանրապես տեխնիկական խնդիրների վրա ուշադրություն դարձնելու մյուս խոչընդոտը 2014թ. Նման բաները մեծ ազդեցություն են թողնում թիմերի զարգացման հնարավորությունների վրա, հատկապես այնպիսի երիտասարդ բիզնեսի համար, ինչպիսին Dodo Pizza-ն է:

Արագ լուծումներ, որոնք օգնեցին

Խնդիրները լուծումներ են պահանջում. Պայմանականորեն լուծումները կարելի է բաժանել 2 խմբի.

• Արագներ, որոնք հանգցնում են կրակը և ապահովության փոքր շեմ են տալիս և մեզ ժամանակ են գնում փոխվելու համար:

• Համակարգային և, հետևաբար, երկար. Մի շարք մոդուլների վերաճարտարագիտություն, մոնոլիտ ճարտարապետության բաժանում առանձին ծառայությունների (դրանց մեծ մասը ամենևին էլ միկրո չէ, այլ ավելի շուտ մակրո ծառայություններ, և դրա մեջ ինչ-որ բան կա. Անդրեյ Մորևսկու զեկույցը). 

Արագ փոփոխությունների չոր ցուցակը հետևյալն է.

Մեծացնել բազայի վարպետը

Իհարկե, առաջին բանը, որ արվում է բեռների հետ գործ ունենալու համար, սերվերի հզորությունը մեծացնելն է։ Սա արվել է հիմնական տվյալների բազայի և վեբ սերվերների համար: Ավաղ, դա հնարավոր է միայն մինչև որոշակի սահմանաչափ, հետո այն դառնում է չափազանց թանկ:

2014 թվականից մենք տեղափոխվել ենք Azure, մենք նաև գրել ենք այս թեմայի մասին այն ժամանակ հոդվածում «Ինչպես է Dodo Pizza-ն մատուցում պիցցա՝ օգտագործելով Microsoft Azure Cloud-ը«. Բայց բազայի համար սերվերի մի շարք ավելացումներից հետո նրանք դեմ եկան ծախսերին: 

Հիմնական կրկնօրինակներ ընթերցանության համար

Հիմքի համար պատրաստվել են երկու կրկնօրինակներ.

ReadReplica տեղեկանքների հարցումների համար. Այն օգտագործվում է գրացուցակները, տեսակը, քաղաքը, փողոցը, պիցցերիան, ապրանքները (դանդաղ փոխված տիրույթը) կարդալու և այն միջերեսներում, որտեղ փոքր ուշացումն ընդունելի է: Այդ կրկնօրինակներից 2-ն է եղել, մենք ապահովել ենք դրանց հասանելիությունը այնպես, ինչպես վարպետները։

ReadReplica զեկուցման հարցումների համար. Այս տվյալների բազան ավելի ցածր հասանելիություն ուներ, բայց բոլոր հաշվետվությունները գնացին դրան: Թող նրանք մեծ պահանջներ ունենան հսկայական տվյալների վերահաշվարկների համար, բայց դրանք չեն ազդում հիմնական տվյալների բազայի և գործառնական ինտերֆեյսերի վրա: 

Քեշերը կոդով

Կոդի մեջ ոչ մի տեղ (ընդհանրապես) ոչ մի քեշ չկար։ Սա հանգեցրեց լրացուցիչ, ոչ միշտ անհրաժեշտ, բեռնված տվյալների բազայի հարցումների: Քեշերը նախ և՛ հիշողության մեջ էին, և՛ արտաքին քեշի ծառայության վրա, դա Redis-ն էր: Ժամանակի ընթացքում ամեն ինչ անվավեր է ճանաչվել, կոդում նշված են կարգավորումները։

Բազմաթիվ backend սերվերներ

Հավելվածի հետնամասը նույնպես պետք է մասշտաբային լիներ, որպեսզի կարգավորվեր ավելացած աշխատանքային բեռները: Անհրաժեշտ էր մեկ iis-սերվերից կլաստեր պատրաստել։ Մենք փոխադրել ենք դիմումի նիստ հիշողությունից մինչև RedisCache, ինչը հնարավորություն տվեց մի քանի սերվերներ ստեղծել պարզ բեռի հավասարակշռիչի հետևում կլոր ռոբինով: Սկզբում օգտագործվում էր նույն Redis-ը, ինչ քեշերի համար, հետո այն բաժանվեց մի քանիսի։ 

Արդյունքում ճարտարապետությունն ավելի է բարդացել...

… բայց որոշ լարվածություն վերացավ:

Եվ հետո անհրաժեշտ եղավ վերափոխել բեռնված բաղադրիչները, որոնք մենք ձեռնարկեցինք։ Այս մասին կխոսենք հաջորդ մասում։

Source: www.habr.com