«Կոշիկներովս քայլում եմ» - սպասեք, դրանք նշված են:

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

X5-ում համակարգը, որը կհետևի պիտակավորված ապրանքներին և տվյալներ կփոխանակի պետության և մատակարարների հետ, կոչվում է «Marcus»: Եկեք ձեզ հերթականությամբ պատմենք, թե ինչպես և ով է այն մշակել, ինչպիսին է դրա տեխնոլոգիական փաթեթը և ինչու մենք հպարտանալու բան ունենք:

Իրական բարձր բեռնվածություն

«Marcus»-ը լուծում է բազմաթիվ խնդիրներ, որոնցից գլխավորը X5 տեղեկատվական համակարգերի և պիտակավորված ապրանքների պետական ​​տեղեկատվական համակարգի (GIS MP) միջև ինտեգրացիոն փոխազդեցությունն է՝ պիտակավորված ապրանքների շարժը հետևելու համար: Պլատֆորմը նաև պահպանում է մեր կողմից ստացված բոլոր պիտակավորման կոդերը և այս կոդերի շարժման ողջ պատմությունը օբյեկտների վրա և օգնում է վերացնել պիտակավորված ապրանքների վերագնահատումը: Օգտվելով ծխախոտի արտադրանքի օրինակից, որոնք ներառված էին մակնշված ապրանքների առաջին խմբերում, ծխախոտի միայն մեկ բեռնատարը պարունակում է մոտ 600 տուփ, որոնցից յուրաքանչյուրն ունի իր յուրահատուկ ծածկագիրը։ Եվ մեր համակարգի խնդիրն է հետևել և ստուգել յուրաքանչյուր նման փաթեթի տեղաշարժերի օրինականությունը պահեստների և խանութների միջև և, ի վերջո, ստուգել դրանց վաճառքի թույլատրելիությունը վերջնական գնորդին: Եվ մենք ժամում գրանցում ենք մոտ 000 կանխիկ գործարք, ինչպես նաև պետք է արձանագրենք, թե ինչպես է յուրաքանչյուր նման փաթեթ հայտնվել խանութ։ Այսպիսով, հաշվի առնելով օբյեկտների միջև տեղի ունեցող բոլոր շարժումները, մենք տարեկան ակնկալում ենք տասնյակ միլիարդավոր գրառումներ։

Թիմ Մ

Չնայած այն հանգամանքին, որ Marcus-ը համարվում է նախագիծ X5-ի շրջանակներում, այն իրականացվում է արտադրանքի մոտեցմամբ: Թիմն աշխատում է ըստ Scrum-ի։ Նախագիծը մեկնարկել է անցյալ ամառ, բայց առաջին արդյունքները եղան միայն հոկտեմբերին. մեր սեփական թիմն ամբողջությամբ հավաքվեց, մշակվեց համակարգի ճարտարապետությունը և գնվեցին սարքավորումներ: Այժմ թիմն ունի 16 մարդ, որոնցից վեցը ներգրավված են backend-ի և frontend-ի մշակման մեջ, որոնցից երեքը ներգրավված են համակարգի վերլուծության մեջ: Եվս վեց մարդ ներգրավված է ձեռնարկի, բեռնվածքի, ավտոմատացված փորձարկման և արտադրանքի սպասարկման մեջ: Բացի այդ, մենք ունենք SRE մասնագետ:

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

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

Թիմի հեռավար հանդիպում

Հանդիպումներ հեռավար աշխատանքի ժամանակ

Լուծման տեխնոլոգիական փաթեթ

X5-ի ստանդարտ պահեստը և CI/CD գործիքը GitLab-ն է: Մենք այն օգտագործում ենք կոդի պահպանման, շարունակական փորձարկման և սերվերների փորձարկման և արտադրության համար: Մենք նաև օգտագործում ենք կոդի վերանայման պրակտիկան, երբ առնվազն 2 գործընկեր պետք է հաստատի մշակողի կողմից կոդում կատարված փոփոխությունները։ SonarQube և JaCoCo ստատիկ կոդերի անալիզատորներն օգնում են մեզ մաքուր պահել մեր կոդը և ապահովել միավորի թեստի ծածկույթի պահանջվող մակարդակը: Կոդի բոլոր փոփոխությունները պետք է անցնեն այս ստուգումները: Բոլոր թեստային սցենարները, որոնք գործարկվում են ձեռքով, հետագայում ավտոմատացված են:

«Marcus»-ի կողմից բիզնես գործընթացների հաջող իրականացման համար մենք պետք է լուծեինք մի շարք տեխնոլոգիական խնդիրներ՝ յուրաքանչյուրի մոտ՝ ըստ հերթականության։

Առաջադրանք 1. Համակարգի հորիզոնական մասշտաբայնության անհրաժեշտությունը

Այս խնդիրը լուծելու համար մենք ընտրել ենք ճարտարապետության միկրոսերվիսային մոտեցումը: Միևնույն ժամանակ, շատ կարևոր էր հասկանալ ծառայությունների պատասխանատվության ոլորտները։ Մենք փորձեցինք դրանք բաժանել բիզնես գործառնությունների՝ հաշվի առնելով գործընթացների առանձնահատկությունները։ Օրինակ, պահեստում ընդունումը շատ հաճախակի, բայց շատ լայնածավալ գործողություն չէ, որի ընթացքում անհրաժեշտ է պետական ​​կարգավորող մարմնից արագ ստանալ տեղեկատվություն ընդունվող ապրանքների միավորների մասին, որոնց թիվը մեկ առաքման դեպքում հասնում է 600000-ի: , ստուգեք այս ապրանքը պահեստ ընդունելու թույլատրելիությունը և վերադարձրեք պահեստի ավտոմատացման համակարգի համար անհրաժեշտ բոլոր տեղեկությունները: Բայց պահեստներից առաքումն ունի շատ ավելի մեծ ինտենսիվություն, բայց միևնույն ժամանակ գործում է տվյալների փոքր ծավալներով։

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

Մենք որոշեցինք առանձնացնել արտաքին համակարգերի հետ փոխգործակցության մոդուլները առանձին ծառայությունների: Սա հնարավորություն տվեց լուծել արտաքին համակարգերի հաճախակի փոփոխվող API-ների խնդիրը՝ գործնականում չազդելով բիզնես ֆունկցիոնալությամբ ծառայությունների վրա:

Բոլոր միկրոծառայությունները տեղակայված են OpenShift կլաստերում, որը լուծում է և՛ յուրաքանչյուր միկրոծառայության մասշտաբավորման խնդիրը, և՛ թույլ է տալիս մեզ չօգտագործել երրորդ կողմի Service Discovery գործիքները:

Առաջադրանք 2. Պլատֆորմի ծառայությունների միջև բարձր բեռ և շատ ինտենսիվ տվյալների փոխանակման անհրաժեշտություն. Միայն ծրագրի մեկնարկի փուլում վայրկյանում կատարվում է մոտ 600 գործողություն: Մենք ակնկալում ենք, որ այս արժեքը կաճի մինչև 5000 օպեր/վրկ, քանի որ մանրածախ առևտրի կետերը միանում են մեր հարթակին:

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

Մեծ ուշադրություն է դարձվել տեղեկամատյանների հետագծմանը, որպեսզի դրանց TraceId-ը չկորչի, երբ բացառություններ են լինում ծառայությունների շահագործման ընթացքում կամ Կաֆկա խմբաքանակի հետ աշխատելիս: Եվ եթե առաջինի հետ կապված հատուկ խնդիրներ չեն եղել, ապա երկրորդ դեպքում մենք ստիպված ենք գրանցել բոլոր TraceIds-ները, որոնց հետ եկել է խմբաքանակը և ընտրել մեկը՝ հետագծումը շարունակելու համար: Այնուհետև, երբ որոնում է բնօրինակ TraceId-ով, օգտատերը հեշտությամբ կպարզի, թե որով է շարունակվել հետագծումը։

Առաջադրանք 3. Մեծ քանակությամբ տվյալների պահպանման անհրաժեշտությունը. Միայն ծխախոտի համար տարեկան ավելի քան 1 միլիարդ պիտակներ գալիս են X5-ին: Նրանք պահանջում են մշտական ​​և արագ մուտք: Ընդհանուր առմամբ, համակարգը պետք է մշակի այս պիտակավորված ապրանքների շարժման պատմության շուրջ 10 միլիարդ գրառում:

Երրորդ խնդիրը լուծելու համար ընտրվել է NoSQL MongoDB տվյալների բազան։ Մենք կառուցել ենք 5 հանգույցների բեկոր, և յուրաքանչյուր հանգույց ունի 3 սերվերից բաղկացած Replica Set: Սա թույլ է տալիս սանդղակավորել համակարգը հորիզոնական՝ ավելացնելով նոր սերվերներ կլաստերին և ապահովել դրա սխալների հանդուրժողականությունը: Այստեղ մենք հանդիպեցինք մեկ այլ խնդրի՝ մոնգո կլաստերում գործարքների ապահովումը՝ հաշվի առնելով հորիզոնական մասշտաբավոր միկրոծառայությունների օգտագործումը։ Օրինակ, մեր համակարգի խնդիրներից է նույն պիտակավորման ծածկագրերով ապրանքների վերավաճառքի փորձերը բացահայտելը: Այստեղ ծածկույթները հայտնվում են սխալ սկանավորումներով կամ գանձապահների սխալ գործողություններով: Մենք պարզեցինք, որ նման կրկնօրինակները կարող են առաջանալ ինչպես մշակվող Kafka-ի մեկ խմբաքանակի, այնպես էլ զուգահեռ մշակվող երկու խմբաքանակի ընթացքում: Այսպիսով, տվյալների բազայի հարցումով կրկնօրինակների ստուգումը ոչինչ չտվեց։ Յուրաքանչյուր միկրոծառայության համար մենք խնդիրը լուծել ենք առանձին՝ ելնելով այս ծառայության բիզնես տրամաբանությունից։ Օրինակ, չեկերի համար մենք ավելացրել ենք ստուգում խմբաքանակի ներսում և առանձին մշակում` տեղադրման ժամանակ կրկնօրինակների տեսքի համար:

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

Առաջադրանք 4. Հերթի վերամշակում և մոնիտորինգ.

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

Նման սխեմա իրականացնելու համար մեզ անհրաժեշտ էր հետևյալը՝ ինտեգրել այս լուծումը Spring-ի հետ և խուսափել կոդի կրկնօրինակումից։ Համացանցում ճամփորդելիս հանդիպեցինք Spring BeanPostProccessor-ի վրա հիմնված նմանատիպ լուծման, բայց այն մեզ անհարկի ծանր էր թվում: Մեր թիմը ստեղծել է ավելի պարզ լուծում, որը թույլ է տալիս մեզ ինտեգրվել Գարնանային ցիկլին՝ սպառողներ ստեղծելու համար և հավելյալ ավելացնել Կրկնել սպառողներին: Գարուն թիմին առաջարկեցինք մեր լուծման նախատիպը, կարող եք տեսնել այստեղ. Կրկնվող սպառողների թիվը և յուրաքանչյուր սպառողի համար փորձերի քանակը կազմաձևվում են պարամետրերի միջոցով՝ կախված բիզնես գործընթացի կարիքներից, և որպեսզի ամեն ինչ աշխատի, մնում է ավելացնել org.springframework.kafka.annotation.KafkaListener ծանոթագրությունը: , որը ծանոթ է բոլոր Գարուն ծրագրավորողներին։

Եթե ​​հաղորդագրությունը չհաջողվեց մշակել բոլոր կրկնվող փորձերից հետո, այն անցնում է DLT (մեռած նամակի թեմա)՝ օգտագործելով Spring DeadLetterPublishingRecoverer: Աջակցության խնդրանքով մենք ընդլայնեցինք այս գործառույթը և ստեղծեցինք առանձին ծառայություն, որը թույլ է տալիս դիտել DLT, stackTrace, traceId-ում ներառված հաղորդագրությունները և դրանց մասին այլ օգտակար տեղեկություններ: Բացի այդ, DLT բոլոր թեմաներին ավելացվել են մոնիտորինգ և ահազանգեր, և այժմ, փաստորեն, DLT թեմայում հաղորդագրության հայտնվելը պատճառ է վերլուծելու և շտկելու թերությունը։ Սա շատ հարմար է. թեմայի անունով մենք անմիջապես հասկանում ենք, թե գործընթացի որ փուլում է առաջացել խնդիրը, ինչը զգալիորեն արագացնում է դրա հիմնական պատճառի որոնումը:

Բոլորովին վերջերս մենք ներդրել ենք ինտերֆեյս, որը թույլ է տալիս մեզ նորից ուղարկել հաղորդագրություններ՝ օգտագործելով մեր աջակցությունը՝ դրանց պատճառները վերացնելուց հետո (օրինակ՝ արտաքին համակարգի ֆունկցիոնալությունը վերականգնելուց) և, իհարկե, վերլուծության համար համապատասխան թերություն հաստատելուց հետո: Ահա այստեղ է, որ մեր ինքնակառավարման թեմաները օգտակար են. երկար մշակման շղթան չվերագործարկելու համար կարող եք այն վերագործարկել ցանկալի քայլից:

Պլատֆորմի շահագործում

Հարթակն արդեն արդյունավետ շահագործման մեջ է, ամեն օր իրականացնում ենք առաքում և առաքում, միացնում ենք նոր բաշխիչ կենտրոններ և խանութներ։ Որպես փորձնական մաս՝ համակարգը աշխատում է «Ծխախոտ» և «Կոշիկ» ապրանքախմբերի հետ։

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

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

Այժմ մենք շարունակում ենք զարգացնել և կատարելագործել մեր հարթակը և մշտապես դիմակայել նոր մարտահրավերներին: Եթե ​​հետաքրքրված եք, մեր լուծումների մասին կխոսենք հաջորդ հոդվածներում։

Source: www.habr.com