Dodo IS ճարտարապետության պատմություն. Back Office Path

Հաբրը փոխում է աշխարհը։ Մենք բլոգում ենք արդեն մեկ տարուց ավելի: Մոտ վեց ամիս առաջ խաբրովիտներից ստացանք միանգամայն տրամաբանական արձագանք. «Դոդո, դու ամեն տեղ ասում ես, որ ունես քո սեփական համակարգը։ Իսկ ի՞նչ է այս համակարգը։ Իսկ ինչի՞ն է դա պետք պիցցայի ցանցին:

Նստեցինք, մտածեցինք ու հասկացանք, որ դու ճիշտ ես։ Մենք փորձում ենք ամեն ինչ բացատրել մեր մատների վրա, բայց այն դուրս է գալիս պատառոտված կտորներով, և ոչ մի տեղ չկա համակարգի ամբողջական նկարագրությունը։ Այսպիսով սկսվեց տեղեկատվության հավաքագրման, հեղինակների որոնման և Dodo IS-ի մասին հոդվածների շարք գրելու երկար ճանապարհորդություն: Գնացինք!

Երախտագիտություն. Շնորհակալություն մեզ հետ ձեր կարծիքը կիսելու համար: Նրա շնորհիվ մենք վերջապես նկարագրեցինք համակարգը, կազմեցինք տեխնիկական ռադար և շուտով կներկայացնենք մեր գործընթացների մեծ նկարագրությունը: Առանց քեզ մենք դեռ 5 տարի էլ այնտեղ նստած կլինեինք։

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

1. Վաղ մոնոլիտ Dodo IS-ում (2011-2015): (Ընթացքի մեջ է...)
2. Հետևի գրասենյակի ուղին՝ առանձին բազաներ և ավտոբուս: (դու այստեղ ես)
3. Հաճախորդի կողմի ուղին. ճակատը բազայի վրա (2016-2017 թթ.): (Ընթացքի մեջ է...)
4. Իրական միկրոծառայությունների պատմություն. (2018-2019 թթ.). (Ընթացքի մեջ է...)
5. Ավարտվեց մոնոլիտի սղոցումը և ճարտարապետության կայունացումը: (Ընթացքի մեջ է...)

Եթե ​​ձեզ հետաքրքրում է այլ բան իմանալ, գրեք մեկնաբանություններում։

Ժամանակագրական նկարագրության վերաբերյալ կարծիք հեղինակից
Ես պարբերաբար հանդիպում եմ նոր աշխատակիցների համար «Համակարգային ճարտարապետություն» թեմայով։ Մենք այն անվանում ենք «Intro to Dodo IS Architecture» և այն նոր մշակողների համար ներբեռնման գործընթացի մի մասն է: Այս կամ այն ​​ձևով պատմելով մեր ճարտարապետության, նրա առանձնահատկությունների մասին՝ ես նկարագրության որոշակի պատմական մոտեցում եմ ծնել։

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

• Իրականությունը տարբերվում է թղթի վրա եղածից։ Ամեն ինչ չէ, որ ստացվում է այնպես, ինչպես նախատեսված է: Իսկ մեզ հետաքրքրում է, թե իրականում ինչպես է ստացվել ու աշխատում։
• Տեղեկատվության հետևողական ներկայացում: Փաստորեն, դուք կարող եք ժամանակագրական կարգով սկզբից գնալ ներկայիս վիճակին:
• Պարզից մինչև բարդ: Ոչ համընդհանուր, բայց մեր դեպքում այդպես է։ Ճարտարապետությունը ավելի պարզ մոտեցումներից տեղափոխվեց ավելի բարդ մոտեցումների: Հաճախ իրականացման արագության և կայունության խնդիրները լուծվում էին բարդության միջոցով, ինչպես նաև տասնյակ այլ հատկություններ ոչ ֆունկցիոնալ պահանջների ցանկից (այստեղ լավ ասված է այլ պահանջների հետ բարդության հակադրման մասին):

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

2020 թվականին այն մի փոքր ավելի բարդ է դարձել և դարձել է այսպես.

Ինչպե՞ս տեղի ունեցավ այս էվոլյուցիան: Ինչու են անհրաժեշտ համակարգի տարբեր մասեր: Ինչ ճարտարապետական ​​որոշումներ են կայացվել և ինչու: Եկեք պարզենք այս հոդվածաշարում:

2016 թվականի առաջին խնդիրները. ինչու՞ պետք է ծառայությունները հեռանան մոնոլիտից

Ցիկլի առաջին հոդվածները կլինեն այն ծառայությունների մասին, որոնք առաջինն են առանձնացել մոնոլիտից։ Կոնտեքստի մեջ դնելու համար ասեմ, թե 2016-ի սկզբին ինչ խնդիրներ ունեինք համակարգում, որ պետք է զբաղվեինք ծառայությունների տարանջատմամբ։

Միասնական MySql տվյալների բազա, որում բոլոր հավելվածները, որոնք այն ժամանակ գոյություն ունեին Dodo IS-ում, գրել են իրենց գրառումները։ Հետևանքները եղել են.

• Ծանր բեռ (ընթերցանության հարցումների 85%-ը):
• Հիմքը մեծացել է. Դրա պատճառով դրա արժեքը և աջակցությունը խնդիր դարձան:
• Անհաջողության մեկ կետ. Եթե ​​տվյալների շտեմարան գրվող հավելվածներից մեկը հանկարծ սկսեց դա անել ավելի ակտիվ, ապա մյուս հավելվածներն իրենց վրա զգացին դա:
• Պահպանման և հարցումների անարդյունավետություն: Հաճախ տվյալները պահվում էին ինչ-որ կառույցում, որը հարմար էր որոշ սցենարների համար, բայց հարմար չէր մյուսների համար: Ինդեքսները արագացնում են որոշ գործողություններ, բայց կարող են դանդաղեցնել մյուսները:
• Խնդիրներից մի քանիսը վերացվել են հապճեպ պատրաստված քեշերի և հիմքերի ընթերցման կրկնօրինակների միջոցով (սա առանձին հոդված է լինելու), բայց դրանք միայն ժամանակ են շահել և հիմնովին չեն լուծել խնդիրը:

Խնդիրը հենց մոնոլիտի առկայությունն էր. Հետևանքները եղել են.

• Միայնակ և հազվագյուտ թողարկումներ:
• Մեծ թվով մարդկանց համատեղ զարգացման դժվարություն.
• Նոր տեխնոլոգիաներ, նոր շրջանակներ և գրադարաններ ներմուծելու անկարողություն:

Բազայի և մոնոլիտի հետ կապված խնդիրները բազմիցս նկարագրվել են, օրինակ, 2018 թվականի սկզբին վթարների համատեքստում (Եղեք Մունկի պես, կամ մի քանի խոսք տեխնիկական պարտքի մասին, Այն օրը, երբ Դոդոն կանգ առավ: Ասինխրոն սցենար и Ֆենիքսների ընտանիքից Դոդո թռչնի պատմությունը. Դոդոյի մեծ անկումը IS), այնպես որ ես շատ չեմ անդրադառնա։ Ասեմ միայն, որ մենք ցանկանում էինք ավելի շատ ճկունություն տալ ծառայություններ մշակելիս։ Առաջին հերթին դա վերաբերում էր նրանց, ովքեր ամենածանրաբեռնվածն ու արմատն էին ամբողջ համակարգում՝ Auth-ը և Tracker-ը:

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

Գլուխ նավարկություն

1. Մոնոլիտ սխեման 2016 թ
2. Սկսում է բեռնաթափել մոնոլիտը. Auth և Tracker Separation
   
3. Ի՞նչ է անում Auth-ը:
4. Որտեղի՞ց են բեռները:
5. Բեռնաթափվում է Auth
6. Ի՞նչ է անում Tracker-ը:
7. Որտեղի՞ց են բեռները:
8. Բեռնաթափում Tracker

Մոնոլիտ սխեման 2016 թ

Ահա Dodo IS 2016 մոնոլիտի հիմնական բլոկները, իսկ հենց ներքևում ներկայացված է դրանց հիմնական առաջադրանքների սղագրությունը:

Գանձապահի առաքում. Սուրհանդակների հաշվառում, առաքիչներին պատվերների տրամադրում.
Կոնտակտային կենտրոն. Պատվերների ընդունում օպերատորի միջոցով։
կայքի. Մեր կայքերը (dodopizza.ru, dodopizza.co.uk, dodopizza.by և այլն):
Հեղինակ. Թույլտվության և նույնականացման ծառայություն հետին գրասենյակի համար:
Հետախույզ. Պատվիրեք թրեքեր խոհանոցում։ Պատվերի պատրաստման ժամանակ պատրաստականության կարգավիճակները նշելու ծառայություն։
Ռեստորանի դրամարկղ. Պատվերների ընդունում ռեստորանում, գանձապահի միջերես:
Արտահանում. Հաշվետվությունների բեռնում 1C-ում հաշվապահական հաշվառման համար:
Ծանուցումներ և հաշիվ-ապրանքագրեր. Ձայնային հրամաններ խոհանոցում (օրինակ՝ «Նոր պիցցա եկավ») + ապրանքագրի տպագրություն սուրհանդակների համար։
Հերթափոխի մենեջեր. Հերթափոխի ղեկավարի աշխատանքի ինտերֆեյսներ՝ պատվերների ցանկ, կատարողականի գրաֆիկներ, աշխատողների տեղափոխում հերթափոխ:
Գրասենյակի մենեջեր. Ինտերֆեյսեր ֆրանչայզերի և մենեջերի աշխատանքի համար՝ աշխատակիցների ընդունելություն, հաշվետվություններ պիցցերիայի աշխատանքի մասին։
Ռեստորանի ցուցատախտակ. Պիցցերիաների հեռուստացույցների մենյուի ցուցադրում:
ադմին. Կարգավորումներ որոշակի պիցցերիայում՝ մենյու, գներ, հաշվապահական հաշվառում, պրոմո կոդեր, առաջխաղացումներ, վեբ կայքերի պաստառներ և այլն:
Աշխատողի անձնական հաշիվ. Աշխատակիցների աշխատանքային գրաֆիկները, տեղեկություններ աշխատողների մասին։
Խոհանոցի մոտիվացիոն խորհուրդը. Առանձին էկրան, որը կախված է խոհանոցում և ցուցադրում է պիցցա արտադրողների արագությունը։
հաղորդակցություն. Ուղարկելով sms և էլ.
Ֆայլերի պահեստավորում. Ստատիկ ֆայլերի ստացման և թողարկման սեփական ծառայություն:

Խնդիրները լուծելու առաջին փորձերը մեզ օգնեցին, բայց դրանք ընդամենը ժամանակավոր հանգստություն էին։ Դրանք չդարձան համակարգային լուծումներ, ուստի պարզ էր, որ պետք է ինչ-որ բան անել բազաների հետ։ Օրինակ՝ ընդհանուր տվյալների բազան մի քանի ավելի մասնագիտացվածների բաժանելու համար։

Սկսում է բեռնաթափել մոնոլիտը. Auth և Tracker Separation

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

1. Հաստատություն Թույլտվության և նույնականացման ծառայություն հետին գրասենյակի համար:
2. Հետագծող. Պատվիրեք թրեքեր խոհանոցում։ Պատվերի պատրաստման ժամանակ պատրաստականության կարգավիճակները նշելու ծառայություն։

Ի՞նչ է անում Auth-ը:

Auth-ը ծառայություն է, որի միջոցով օգտվողները մուտք են գործում հետին գրասենյակ (հաճախորդի կողմից կա առանձին անկախ մուտք): Հարցման մեջ նաև կոչ է արվում համոզվել, որ մուտքի պահանջվող իրավունքները առկա են, և որ այդ իրավունքները չեն փոխվել վերջին մուտքից հետո: Դրա միջոցով սարքերը մտնում են պիցցերիա։

Օրինակ, մենք ցանկանում ենք դահլիճում կախված հեռուստացույցի վրա բացել պատրաստի պատվերների կարգավիճակներով ցուցադրություն։ Հետո բացում ենք auth.dodopizza.ru-ն, ընտրում ենք «Մուտք գործել որպես սարք», հայտնվում է կոդ, որը կարելի է մուտքագրել հերթափոխի մենեջերի համակարգչի հատուկ էջում՝ նշելով սարքի (սարքի) տեսակը։ Հեռուստացույցն ինքը կանցնի իր պիցցերիայի ցանկալի ինտերֆեյսին և կսկսի ցուցադրել այն հաճախորդների անունները, որոնց պատվերներն այնտեղ պատրաստ են:

Որտեղի՞ց են բեռները:

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

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

Բեռնաթափվում է Auth

Auth-ն ունի մեկուսացված տիրույթ, այսինքն՝ օգտատերերի, մուտքերի կամ սարքերի մասին տվյալները մտնում են ծառայություն (առայժմ) և մնում այնտեղ։ Եթե ​​դրանք ինչ-որ մեկին պետք են, ապա նա կգնա այս ծառայության տվյալների համար:

ԵՂԵԼ. Աշխատանքի սկզբնական սխեման հետևյալն էր.

Ես կցանկանայի մի փոքր բացատրել, թե ինչպես է դա աշխատել.

1. Արտաքին հարցումը գալիս է հետնամասում (կա Asp.Net MVC), իր հետ բերում է նիստի քուքի, որն օգտագործվում է Redis(1) սեսիայի տվյալները ստանալու համար։ Այն կամ պարունակում է տեղեկատվություն մուտքերի մասին, և այնուհետև մուտքը դեպի վերահսկիչ բաց է (3,4), կամ ոչ:
2. Եթե ​​մուտք չկա, դուք պետք է անցնեք թույլտվության ընթացակարգը: Այստեղ, պարզության համար, այն ցուցադրվում է որպես նույն հատկանիշի ուղու մաս, թեև դա անցում է դեպի մուտքի էջ։ Դրական սցենարի դեպքում մենք կստանանք ճիշտ ավարտված նիստ և կանցնենք Backoffice Controller:
3. Եթե ​​կան տվյալներ, ապա դուք պետք է ստուգեք դրանք օգտատերերի բազայում համապատասխանության համար: Նրա դերը փոխվե՞լ է, նրան հիմա չթողնե՞ն էջում։ Այս դեպքում, նիստը (1) ստանալուց հետո անհրաժեշտ է ուղղակիորեն գնալ տվյալների բազա և ստուգել օգտատիրոջ հասանելիությունը՝ օգտագործելով վավերացման տրամաբանական շերտը (2): Հաջորդը, կամ մուտքի էջ, կամ գնացեք վերահսկիչ: Նման պարզ համակարգ, բայց ոչ այնքան ստանդարտ:
4. Եթե ​​բոլոր ընթացակարգերն ընդունված են, ապա մենք բաց ենք թողնում հետագա տրամաբանությունը կարգավորիչների և մեթոդների մեջ:

Օգտատիրոջ տվյալները առանձնացված են բոլոր մյուս տվյալներից, այն պահվում է առանձին անդամակցության աղյուսակում, AuthService տրամաբանական շերտի գործառույթները կարող են դառնալ api մեթոդներ: Դոմենի սահմանները բավականին հստակ են սահմանվում՝ օգտվողներ, նրանց դերերը, մուտքի տվյալներ, մուտքի թույլտվություն և չեղարկում: Ամեն ինչ այնպես է նայվում, որ կարելի է առանձին ծառայության մեջ հանել։

ԴԱՌՆԱԼ. Այսպիսով նրանք արեցին.

Այս մոտեցումը մի շարք խնդիրներ ունի. Օրինակ, պրոցեսի ներսում մեթոդ կանչելը նույնը չէ, ինչ արտաքին ծառայություն կանչելը http-ի միջոցով: Լատենտությունը, հուսալիությունը, սպասունակությունը, գործողության թափանցիկությունը բոլորովին տարբեր են։ Նման խնդիրների մասին իր զեկույցում առավել մանրամասն է խոսել Անդրեյ Մորևսկին։ «Միկրոծառայությունների 50 երանգները».

Նույնականացման ծառայությունը և դրա հետ մեկտեղ սարքի ծառայությունն օգտագործվում են հետին գրասենյակի համար, այսինքն՝ արտադրության մեջ օգտագործվող ծառայությունների և միջերեսների համար։ Հաճախորդների ծառայությունների նույնականացումը (օրինակ՝ կայք կամ բջջային հավելված) կատարվում է առանձին՝ առանց Auth-ի օգտագործման: Անջատումը տևեց մոտ մեկ տարի, և այժմ մենք կրկին զբաղվում ենք այս թեմայով, համակարգը տեղափոխում ենք նույնականացման նոր ծառայություններ (ստանդարտ արձանագրություններով):

Ինչու՞ այդքան երկար տևեց բաժանումը:
Ճանապարհին շատ խնդիրներ կային, որոնք դանդաղեցնում էին մեզ.

1. Մենք ցանկանում էինք օգտատերերի, սարքի և նույնականացման տվյալները երկրի հատուկ տվյալների բազաներից մեկում տեղափոխել: Դա անելու համար մենք պետք է թարգմանեինք բոլոր աղյուսակները և օգտագործումը int նույնացուցիչից գլոբալ UUId նույնացուցիչի (վերջերս վերամշակված այս կոդը Ռոման Բուկին «Ուուիդ - փոքր կառույցի մեծ պատմություն» և բաց կոդով նախագիծ Պրիմիտիվներ). Օգտատիրոջ տվյալների պահպանումը (քանի որ դրանք անձնական տվյալներ են) ունի իր սահմանափակումները, և որոշ երկրների համար անհրաժեշտ է դրանք առանձին պահել: Բայց օգտագործողի գլոբալ ID-ն պետք է լինի:
2. Տվյալների բազայի շատ աղյուսակներ ունեն աուդիտորական տեղեկատվություն այն օգտագործողի մասին, ով կատարել է գործողությունը: Սա պահանջում էր հետևողականության լրացուցիչ մեխանիզմ:
3. Api-service-ների ստեղծումից հետո եղավ մեկ այլ համակարգի անցման երկար ու աստիճանական շրջան։ Անցումը պետք է կատարվեր անխափան օգտագործողների համար և պահանջեր ձեռքով աշխատանք:

Սարքի գրանցման սխեման պիցցերիայում.

Ընդհանուր ճարտարապետություն Auth և Devices ծառայության արդյունահանումից հետո.

Նշում. 2020 թվականի համար մենք աշխատում ենք Auth-ի նոր տարբերակի վրա, որը հիմնված է OAuth 2.0 թույլտվության ստանդարտի վրա: Այս ստանդարտը բավականին բարդ է, բայց այն օգտակար է փոխանցման վավերացման ծառայության մշակման համար: Հոդվածում «Թույլտվության նրբությունները. OAuth 2.0 տեխնոլոգիայի ակնարկ» մենք Ալեքսեյ Չերնյաևը փորձեցինք չափանիշի մասին պատմել հնարավորինս պարզ և հստակ, որպեսզի դուք ժամանակ խնայեք այն ուսումնասիրելու վրա:

Ի՞նչ է անում Tracker-ը:

Հիմա բեռնված ծառայությունների երկրորդի մասին։ Թրեքերը կատարում է երկակի դեր.

• Մի կողմից, նրա խնդիրն է խոհանոցում աշխատողներին ցույց տալ, թե ինչ պատվերներ են ներկայումս գործում, ինչ ապրանքներ պետք է եփել հիմա:
• Մյուս կողմից՝ թվայնացնել խոհանոցում տեղի ունեցող բոլոր գործընթացները։

Երբ պատվերի մեջ հայտնվում է նոր ապրանք (օրինակ՝ պիցցա), այն գնում է Rolling out tracker կայան: Այս կայարանում կա մի պիցցա պատրաստող, ով վերցնում է անհրաժեշտ չափի բուլկի և գլորում այն, որից հետո նա նշում է թրեկերի պլանշետի վրա, որ կատարել է իր առաջադրանքը և գլորված խմորի հիմքը տեղափոխում է հաջորդ կայան՝ «Նախաձեռնում»: .

Այնտեղ հաջորդ պիցցա պատրաստողը լցնում է պիցցան, ապա պլանշետի վրա նշում է, որ կատարել է իր առաջադրանքը և պիցցան դնում է ջեռոցում (սա նույնպես առանձին կայան է, որը պետք է նշվի պլանշետի վրա): Նման համակարգ եղել է ի սկզբանե Դոդոյում և Dodo IS-ի գոյության հենց սկզբից: Այն թույլ է տալիս ամբողջությամբ հետևել և թվայնացնել բոլոր գործարքները: Բացի այդ, հետախույզն առաջարկում է, թե ինչպես պատրաստել որոշակի ապրանք, ուղղորդում է յուրաքանչյուր տեսակի արտադրանքի արտադրության սխեմաների համաձայն, պահպանում է արտադրանքի պատրաստման օպտիմալ ժամանակը և հետևում արտադրանքի բոլոր գործողություններին:

Ահա թե ինչպիսին է պլանշետի էկրանը «Ռասկատկա» թրեկերի կայանում.

Որտեղի՞ց են բեռները:

Պիցցերիաներից յուրաքանչյուրն ունի մոտ հինգ պլանշետ՝ հետքերով: 2016 թվականին մենք ունեինք 100-ից ավելի պիցցերիա (իսկ այժմ՝ ավելի քան 600): Պլանշետներից յուրաքանչյուրը յուրաքանչյուր 10 վայրկյանը մեկ հարցում է կատարում backend-ին և հավաքում տվյալներ պատվերի աղյուսակից (կապ հաճախորդի հետ և հասցե), պատվերի կազմը (ապրանքի հետ կապը և քանակի նշումը), մոտիվացիոն հաշվառման աղյուսակը ( սեղմման ժամանակը հետևվում է դրանում): Երբ պիցցա արտադրողը կտտացնում է թրեյքերում գտնվող ապրանքի վրա, այս բոլոր աղյուսակների գրառումները թարմացվում են: Պատվերների աղյուսակը ընդհանուր է, այն նաև պարունակում է ներդիրներ պատվեր ընդունելիս, թարմացումներ համակարգի այլ մասերից և բազմաթիվ ընթերցումներ, օրինակ՝ հեռուստացույցով, որը կախված է պիցցերիայում և ցուցադրում է պատրաստի պատվերները հաճախորդներին:

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

Բացի այդ, դրանց վրա սեփական աղյուսակների և ինդեքսների բացակայությունը թույլ չի տվել գրել դրանց օգտագործման համար հարմարեցված ավելի կոնկրետ հարցումներ: Օրինակ, կարող է արդյունավետ լինել, որ հետախույզը պատվերի աղյուսակում ունենա պիցցերիայի ցուցիչ: Մենք միշտ հեռացնում ենք պիցցերիայի պատվերները հետագծերի տվյալների բազայից: Ընդ որում, պատվեր ստանալու համար այնքան էլ կարևոր չէ, թե որ պիցցերիան է այն ընկնում, ավելի կարևոր է, թե որ հաճախորդն է կատարել այս պատվերը։ Եվ նշանակում է, որ այնտեղ հաճախորդի ինդեքսն անհրաժեշտ է: Պարտադիր չէ նաև, որ հետագծողը պատվերի աղյուսակում պահի տպագիր անդորրագրի կամ բոնուսային ակցիաների ID-ն: Այս տեղեկատվությունը չի հետաքրքրում մեր հետագծային ծառայությանը: Ընդհանուր մոնոլիտ տվյալների բազայում աղյուսակները կարող են լինել միայն փոխզիջում բոլոր օգտագործողների միջև: Սա սկզբնական խնդիրներից մեկն էր։

ԵՂԵԼ. Նախնական ճարտարապետությունը հետևյալն էր.

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

Բեռնաթափում Tracker

Թրեքերի հիմնական խնդիրն այն է, որ տվյալները պետք է համաժամանակացվեն տարբեր տվյալների բազաների միջև: Սա նաև նրա հիմնական տարբերությունն է Auth ծառայության առանձնացումից, կարգը և դրա կարգավիճակը կարող են փոխվել և պետք է ցուցադրվեն տարբեր ծառայություններում:

Մենք ընդունում ենք պատվեր Ռեստորանի Checkout-ում (սա ծառայություն է), այն պահվում է տվյալների բազայում «Ընդունված» կարգավիճակով: Դրանից հետո նա պետք է հասնի թրեքերին, որտեղ ևս մի քանի անգամ կփոխի իր կարգավիճակը՝ «Խոհանոցից» ​​«Փաթեթավորված»: Միևնույն ժամանակ, որոշ արտաքին ազդեցություններ Գանձապահի կամ Shift Manager-ի ինտերֆեյսի կողմից կարող են առաջանալ պատվերի հետ: Պատվերների կարգավիճակները կտամ դրանց նկարագրությամբ աղյուսակում.

Պատվերի կարգավիճակները փոխելու սխեման հետևյալն է.

Տարբեր համակարգերի միջև կարգավիճակները փոխվում են: Եվ այստեղ tracker-ը վերջնական համակարգ չէ, որում տվյալները փակ են։ Նման դեպքում մենք տեսել ենք բաժանման մի քանի հնարավոր մոտեցում.

1. Մենք կենտրոնացնում ենք պատվերի բոլոր գործողությունները մեկ ծառայության մեջ: Մեր դեպքում, այս տարբերակը պահանջում է չափազանց մեծ ծառայություն պատվերի հետ աշխատելու համար: Եթե ​​կանգ առնեինք դրա վրա, կստանայինք երկրորդ մոնոլիտը։ Մենք խնդիրը չէինք լուծի.
2. Մի համակարգ զանգ է անում մյուսին: Երկրորդ տարբերակն արդեն ավելի հետաքրքիր է. Բայց դրա հետ հնարավոր են զանգերի շղթաներ (կասկադային ձախողումներ), բաղադրիչների միացումն ավելի բարձր է, ավելի դժվար է կառավարել։
3. Մենք կազմակերպում ենք միջոցառումներ, և յուրաքանչյուր ծառայություն այս միջոցառումների միջոցով շփվում է մյուսի հետ: Արդյունքում ընտրվեց երրորդ տարբերակն, ըստ որի բոլոր ծառայությունները սկսում են իրադարձությունների փոխանակում միմյանց հետ։

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

Այդ ժամանակ մենք արդեն ունեինք RabbitMQ փաթեթում, հետևաբար վերջնական որոշում կայացվեց օգտագործել այն որպես հաղորդագրության բրոքեր: Դիագրամը ցույց է տալիս Ռեստորանի գանձապահից պատվերի անցումը Tracker-ի միջոցով, որտեղ այն փոխում է իր կարգավիճակը և ցուցադրումը Կառավարչի պատվերների միջերեսում: ԴԱՌՆԱԼ:

Պատվիրեք քայլ առ քայլ ճանապարհը
Պատվերի ուղին սկսվում է պատվերի աղբյուրի ծառայություններից մեկից: Ահա ռեստորանի գանձապահը.

1. Վճարման ժամանակ պատվերն ամբողջությամբ պատրաստ է, և ժամանակն է այն ուղարկելու թրեկերին: Իրադարձությունը, որին բաժանորդագրված է հետախույզը, նետվում է:
2. Թրեքերը, ընդունելով պատվերն իր համար, պահպանում է այն իր տվյալների բազայում՝ դարձնելով իրադարձությունը «Պատվերն ընդունված է Թրեքերի կողմից» և ուղարկելով RMQ:
3. Կան մի քանի մշակողներ, որոնք արդեն բաժանորդագրված են միջոցառման ավտոբուսին մեկ պատվերի համար: Մեզ համար կարևոր է նա, ով սինխրոնիզացիա է կատարում մոնոլիտ հիմքի հետ։
4. Կառավարիչը ստանում է իրադարձություն, դրանից ընտրում է իր համար կարևոր տվյալներ. մեր դեպքում սա պատվերի կարգավիճակն է «Ընդունված է Հետագողի կողմից» և թարմացնում է իր պատվերի կազմը հիմնական տվյալների բազայում:

Եթե ​​ինչ-որ մեկին պետք է պատվեր մոնոլիտ սեղանի պատվերներից, ապա այն կարող եք կարդալ նաև այնտեղից։ Օրինակ, Shift Manager-ում Orders ինտերֆեյսին անհրաժեշտ է սա.

Բոլոր մյուս ծառայությունները կարող են նաև բաժանորդագրվել՝ պատվիրելու իրադարձություններ tracker-ից՝ դրանք իրենց համար օգտագործելու համար:

Եթե ​​որոշ ժամանակ անց պատվերն ընդունվում է աշխատանքի, ապա դրա կարգավիճակը սկզբում փոխվում է տվյալների բազայում (Tracker database), ապա անմիջապես գեներացվում է «OrderIn Progress» իրադարձությունը։ Այն նաև մտնում է RMQ-ի մեջ, որտեղից այն համաժամացվում է մոնոլիտ տվյալների բազայում և առաքվում այլ ծառայությունների: Ճանապարհին կարող են լինել տարբեր խնդիրներ, որոնց մասին ավելի մանրամասն կարելի է ծանոթանալ Ժենյա Պեշկովի զեկույցում Հետագծում Eventual Consistency-ի իրականացման մանրամասների մասին.

Վերջնական ճարտարապետություն Auth-ի և Tracker-ի փոփոխություններից հետո

Ամփոփելով միջանկյալ արդյունքը. Սկզբում ես միտք ունեի Dodo IS համակարգի իննամյա պատմությունը մեկ հոդվածում փաթեթավորել: Ես ուզում էի արագ և պարզ կերպով խոսել էվոլյուցիայի փուլերի մասին։ Սակայն, նստելով նյութին, հասկացա, որ ամեն ինչ շատ ավելի բարդ ու հետաքրքիր է, քան թվում է։

Անդրադառնալով նման նյութի օգուտներին (կամ դրանց բացակայությունին՝ ես հանգեցի այն եզրակացության, որ շարունակական զարգացումն անհնար է առանց իրադարձությունների լիարժեք տարեգրության, մանրամասն հետահայացության և իմ անցյալ որոշումների վերլուծության:

Հուսով եմ, որ ձեզ համար օգտակար և հետաքրքիր էր իմանալ մեր ուղու մասին: Այժմ ես կանգնած եմ ընտրության առաջ, թե Dodo IS համակարգի որ հատվածը նկարագրեմ հաջորդ հոդվածում՝ գրել մեկնաբանություններում կամ քվեարկել:

Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ Մուտք գործել, խնդրում եմ:

Dodo IS-ի ո՞ր մասի մասին կցանկանայիք իմանալ հաջորդ հոդվածում:

• 24,1%Վաղ մոնոլիտ Dodo IS-ում (2011-2015)14

• 24,1%Առաջին խնդիրները և դրանց լուծումները (2015-2016)14

• 20,7%Հաճախորդի կողմի ուղին. ճակատը բազայի վրա (2016-2017)12

• 36,2%Իրական միկրոծառայությունների պատմություն (2018-2019)21

• 44,8%Մոնոլիտի ամբողջական սղոցում և ճարտարապետության կայունացում26

• 29,3%Համակարգի զարգացման հետագա ծրագրերի մասին17

• 19,0%Ես չեմ ուզում որևէ բան իմանալ Dodo IS11-ի մասին

Քվեարկել է 58 օգտատեր։ 6 օգտատեր ձեռնպահ է մնացել։

Source: www.habr.com