Սա երկար պատմության շարունակությունն է մեր փշոտ ուղու մասին՝ ստեղծելու հզոր, բարձր բեռնվածության համակարգ, որն ապահովում է Բորսայի աշխատանքը: Առաջին մասը՝ այստեղ.
Առեղծվածային սխալ
Բազմաթիվ փորձարկումներից հետո գործարկվեց նորացված առևտրի և քլիրինգային համակարգը, և մենք հանդիպեցինք մի վրիպակի, որի մասին կարող էինք գրել դետեկտիվ-միստիկական պատմություն։
Հիմնական սերվերի վրա գործարկվելուց կարճ ժամանակ անց գործարքներից մեկը մշակվել է սխալմամբ: Այնուամենայնիվ, պահուստային սերվերում ամեն ինչ լավ էր: Պարզվեց, որ հիմնական սերվերի վրա ցուցիչի հաշվարկման պարզ մաթեմատիկական գործողությունը բացասական արդյունք տվեց իրական փաստարկից: Մենք շարունակեցինք մեր հետազոտությունը, և SSE2 ռեգիստրում մենք գտանք տարբերություն մեկ բիթում, որը պատասխանատու է լողացող կետով թվերի հետ աշխատելիս կլորացման համար։
Մենք գրեցինք պարզ փորձնական ծրագիր՝ ցուցիչը հաշվարկելու համար կլորացման բիթերի հավաքածուով: Պարզվեց, որ RedHat Linux-ի տարբերակում, որը մենք օգտագործում էինք, մաթեմատիկական ֆունկցիայի հետ աշխատելու սխալ կար, երբ չարաբաստիկ բիթը տեղադրվեց: Մենք այս մասին հայտնեցինք RedHat-ին, որոշ ժամանակ անց նրանցից ստացանք կարկատել և այն դուրս հանեցինք: Սխալն այլևս տեղի չունեցավ, բայց անհասկանալի էր, թե որտեղի՞ց էր այս բիթը: Գործառույթը պատասխանատու էր դրա համար fesetround C լեզվից: Մենք ուշադիր վերլուծեցինք մեր ծածկագիրը ենթադրյալ սխալի որոնման համար. մենք ստուգեցինք բոլոր հնարավոր իրավիճակները. նայեց բոլոր գործառույթները, որոնք օգտագործում էին կլորացում; փորձել է վերարտադրել ձախողված նիստը; օգտագործել տարբեր կոմպիլյատորներ տարբեր տարբերակներով; Օգտագործվել են ստատիկ և դինամիկ վերլուծություններ:
Սխալի պատճառը չհաջողվեց գտնել:
Հետո սկսեցին ստուգել սարքավորումները. ստուգեց RAM-ը; Մենք նույնիսկ փորձարկումներ կատարեցինք մեկ բջիջում բազմաբիթ սխալի շատ անհավանական սցենարի համար: Անօգուտ։
Ի վերջո, մենք հիմնավորվեցինք բարձր էներգիայի ֆիզիկայի աշխարհից մի տեսության վրա. ինչ-որ բարձր էներգիայի մասնիկ թռավ մեր տվյալների կենտրոն, ծակեց գործի պատը, հարվածեց պրոցեսորին և ստիպեց ձգանային սողնակը հենց այդ մասում մնալ: Այս անհեթեթ տեսությունը կոչվում էր «նեյտրինո»։ Եթե հեռու եք մասնիկների ֆիզիկայից, նեյտրինոները գրեթե չեն փոխազդում արտաքին աշխարհի հետ և, իհարկե, չեն կարող ազդել պրոցեսորի աշխատանքի վրա:
Քանի որ հնարավոր չի եղել գտնել խափանման պատճառը, «վիրավորող» սերվերը հանվել է շահագործումից ամեն դեպքում:
Որոշ ժամանակ անց մենք սկսեցինք բարելավել տաք պահուստավորման համակարգը. մենք ներմուծեցինք այսպես կոչված «տաք պահուստներ» (տաք)՝ ասինխրոն կրկնօրինակներ: Նրանք ստացան գործարքների հոսք, որը կարող էր տեղակայվել տվյալների տարբեր կենտրոններում, սակայն ջերմները ակտիվորեն չեն փոխազդում այլ սերվերների հետ:
Ինչու՞ դա արվեց: Եթե պահուստային սերվերը ձախողվի, ապա հիմնական սերվերի հետ կապված ջերմությունը դառնում է նոր կրկնօրինակում: Այսինքն՝ ձախողումից հետո համակարգը չի մնում մեկ հիմնական սերվերով մինչև առևտրային նստաշրջանի ավարտը։
Եվ երբ համակարգի նոր տարբերակը փորձարկվեց և գործարկվեց, նորից տեղի ունեցավ կլորացման բիթային սխալ: Ավելին, ջերմ սերվերների քանակի ավելացմամբ սխալը սկսեց ավելի հաճախ ի հայտ գալ։ Միևնույն ժամանակ, վաճառողը ոչինչ չուներ ցույց տալու, քանի որ չկար կոնկրետ ապացույցներ։
Իրավիճակի հերթական վերլուծության ժամանակ տեսություն առաջացավ, որ խնդիրը կարող է կապված լինել ՕՀ-ի հետ։ Մենք գրել ենք մի պարզ ծրագիր, որը ֆունկցիա է կանչում անվերջ օղակում fesetround, հիշում է ներկա վիճակը և ստուգում այն քնի միջոցով, և դա արվում է շատ մրցակցող թեմաներում։ Ընտրելով քնի պարամետրերը և թելերի քանակը՝ մենք սկսեցինք հետևողականորեն վերարտադրել բիթի ձախողումը կոմունալ ծառայությունը գործարկելուց մոտ 5 րոպե հետո: Այնուամենայնիվ, Red Hat-ի աջակցությունը չկարողացավ վերարտադրել այն: Մեր մյուս սերվերների փորձարկումը ցույց է տվել, որ միայն որոշակի պրոցեսորներ ունեցողներն են ենթակա սխալի: Միաժամանակ, նոր միջուկին անցնելը լուծեց խնդիրը։ Ի վերջո, մենք պարզապես փոխարինեցինք ՕՀ-ն, և սխալի իրական պատճառը մնաց անհասկանալի:
Եվ հանկարծ անցյալ տարի հոդված հրապարակվեց Habré-ում.« Դրանում նկարագրված իրավիճակը շատ նման էր մեր իրավիճակին, բայց հեղինակը հետաքննությունն ավելի առաջ տարավ և տեսություն առաջ քաշեց, որ սխալը միկրոկոդի մեջ է։ Եվ երբ Linux միջուկները թարմացվում են, արտադրողները նաև թարմացնում են միկրոկոդը:
Համակարգի հետագա զարգացում
Չնայած մենք ազատվեցինք սխալից, այս պատմությունը ստիպեց մեզ վերանայել համակարգի ճարտարապետությունը: Ի վերջո, մենք պաշտպանված չէինք նման սխալների կրկնությունից։
Հետևյալ սկզբունքները հիմք են հանդիսացել ամրագրումների համակարգի հաջորդ բարելավման համար.
- Չես կարող վստահել ոչ մեկին: Սերվերները կարող են ճիշտ չաշխատել:
- Մեծամասնության վերապահում.
- Կոնսենսուսի ապահովում. Որպես մեծամասնության վերապահման տրամաբանական լրացում:
- Հնարավոր են կրկնակի ձախողումներ.
- Կենսունակություն. Նոր տաք սպասման սխեման պետք է լինի ոչ ավելի վատ, քան նախորդը: Առևտուրը պետք է շարունակվի անխափան մինչև վերջին սերվերը:
- Լատենտության մի փոքր աճ: Ցանկացած պարապուրդի հետ կապված հսկայական ֆինանսական կորուստներ է առաջանում:
- Ցանցի նվազագույն փոխազդեցությունը հնարավորինս ցածր պահելու ուշացումը:
- Նոր գլխավոր սերվերի ընտրություն վայրկյանների ընթացքում:
Շուկայում առկա լուծումներից ոչ մեկը մեզ չէր համապատասխանում, և Raft արձանագրությունը դեռ սկզբնական փուլում էր, ուստի մենք ստեղծեցինք մեր լուծումը:
Ցանցային կապ
Բացի ամրագրման համակարգից, մենք սկսեցինք արդիականացնել ցանցային փոխգործակցությունը: I/O ենթահամակարգը բաղկացած էր բազմաթիվ գործընթացներից, որոնք ամենավատ ազդեցությունն էին թողնում ջիթերի և հետաձգման վրա: Հարյուրավոր պրոցեսներով, որոնք կառավարում են TCP կապերը, մենք ստիպված էինք անընդհատ անցնել դրանց միջև, և միկրովայրկյան սանդղակով սա բավականին ժամանակատար գործողություն է: Բայց ամենավատն այն է, որ երբ պրոցեսը մշակման համար փաթեթ էր ստանում, այն ուղարկում էր SystemV-ի մեկ հերթ, այնուհետև սպասում էր իրադարձության մեկ այլ SystemV հերթից: Այնուամենայնիվ, երբ կան մեծ թվով հանգույցներ, նոր TCP փաթեթի ժամանումը մի գործընթացում և տվյալների ստացումը հերթում մեկ այլ գործընթացում ներկայացնում են երկու մրցակցող իրադարձություններ ՕՀ-ի համար: Այս դեպքում, եթե երկու առաջադրանքների համար հասանելի ֆիզիկական պրոցեսորներ չկան, մեկը կմշակվի, իսկ երկրորդը կտեղադրվի սպասման հերթում։ Անհնար է կանխատեսել հետեւանքները։
Նման իրավիճակներում կարող է կիրառվել գործընթացի առաջնահերթության դինամիկ հսկողություն, սակայն դա կպահանջի ռեսուրսների ինտենսիվ համակարգային զանգերի օգտագործում: Արդյունքում, մենք անցանք մեկ թեմայի՝ օգտագործելով դասական epoll-ը, ինչը մեծապես մեծացրեց արագությունը և նվազեցրեց գործարքների մշակման ժամանակը: Մենք նաև ազատվեցինք առանձին ցանցային հաղորդակցման գործընթացներից և SystemV-ի միջոցով հաղորդակցությունից, զգալիորեն կրճատեցինք համակարգային զանգերի քանակը և սկսեցինք վերահսկել գործառնությունների առաջնահերթությունները։ Միայն I/O ենթահամակարգի վրա հնարավոր էր խնայել մոտ 8-17 միկրովայրկյան՝ կախված սցենարից։ Այս մեկ թելային սխեման այն ժամանակվանից ի վեր օգտագործվել է անփոփոխ, մեկ էպոլի շարանը՝ լուսանցքով, բավական է բոլոր կապերը սպասարկելու համար:
Գործարքների մշակում
Մեր համակարգի աճող ծանրաբեռնվածությունը պահանջում էր արդիականացնել դրա գրեթե բոլոր բաղադրիչները: Սակայն, ցավոք, վերջին տարիներին պրոցեսորային ժամացույցի արագության աճի լճացումը այլևս հնարավորություն չի տվել գործընթացները մասշտաբավորել: Հետևաբար, մենք որոշեցինք Շարժիչի գործընթացը բաժանել երեք մակարդակի, որոնցից ամենածանրաբեռնվածը ռիսկերի ստուգման համակարգն է, որը գնահատում է միջոցների առկայությունը հաշիվներում և ինքն է ստեղծում գործարքները: Բայց փողը կարող է լինել տարբեր արժույթներով, և պետք էր պարզել, թե ինչի հիման վրա պետք է բաժանվի հարցումների մշակումը։
Տրամաբանական լուծումը այն բաժանելն է ըստ արժույթի՝ մի սերվերը առևտուր է անում դոլարով, մյուսը՝ ֆունտով, երրորդը՝ եվրոյով: Բայց եթե նման սխեմայով երկու գործարք ուղարկվի տարբեր արժույթներ ձեռք բերելու համար, ապա դրամապանակի ապասինխրոնիզացիայի խնդիր կառաջանա։ Բայց համաժամացումը դժվար է և թանկ: Հետևաբար, ճիշտ կլինի բեկորները առանձին ըստ դրամապանակների և առանձին գործիքների: Ի դեպ, արևմտյան բորսաների մեծ մասը խնդիր չունի ռիսկերը ստուգելու այնքան սուր, որքան մենք, ուստի ամենից հաճախ դա արվում է օֆլայն: Մեզ անհրաժեշտ էր առցանց ստուգում իրականացնել:
Բացատրենք օրինակով. Առևտրականը ցանկանում է գնել $30, և հարցումը գնում է գործարքի վավերացման. մենք ստուգում ենք, թե արդյոք այս վաճառողին թույլատրված է այս առևտրային ռեժիմում և արդյոք նա ունի անհրաժեշտ իրավունքներ: Եթե ամեն ինչ կարգին է, հարցումը գնում է ռիսկերի ստուգման համակարգ, այսինքն. գործարք կնքելու համար միջոցների բավարարությունը ստուգելու համար. Նշում կա, որ պահանջվող գումարը ներկայումս արգելափակված է։ Հարցումն այնուհետև ուղարկվում է առևտրային համակարգ, որը հաստատում կամ մերժում է գործարքը: Ենթադրենք, գործարքը հաստատված է, այնուհետև ռիսկերի ստուգման համակարգը նշում է, որ փողն ապաբլոկավորված է, և ռուբլին վերածվում է դոլարի:
Ընդհանուր առմամբ, ռիսկերի ստուգման համակարգը պարունակում է բարդ ալգորիթմներ և կատարում է մեծ քանակությամբ շատ ռեսուրսային հաշվարկներ և պարզապես չի ստուգում «հաշվի մնացորդը», ինչպես դա կարող է թվալ առաջին հայացքից:
Երբ մենք սկսեցինք Շարժիչի գործընթացը բաժանել մակարդակների, մենք հանդիպեցինք մի խնդրի. այն կոդը, որը հասանելի էր այն ժամանակ, ակտիվորեն օգտագործում էր տվյալների նույն զանգվածը վավերացման և ստուգման փուլերում, ինչը պահանջում էր վերաշարադրել կոդերի ամբողջ բազան: Արդյունքում, մենք ժամանակակից պրոցեսորներից փոխառեցինք հրահանգների մշակման տեխնիկա. նրանցից յուրաքանչյուրը բաժանված է փոքր փուլերի և մի քանի գործողություններ կատարվում են զուգահեռ մեկ ցիկլով:
Կոդի փոքր հարմարեցումից հետո մենք ստեղծեցինք գործարքների զուգահեռ մշակման խողովակաշար, որում գործարքը բաժանվեց խողովակաշարի 4 փուլերի՝ ցանցային փոխազդեցություն, վավերացում, կատարում և արդյունքի հրապարակում։
Դիտարկենք մի օրինակ։ Մենք ունենք երկու մշակման համակարգ՝ սերիական և զուգահեռ։ Առաջին գործարքը գալիս է և ուղարկվում է վավերացման երկու համակարգերում: Երկրորդ գործարքը անմիջապես գալիս է. զուգահեռ համակարգում այն անմիջապես գործի է դրվում, իսկ հաջորդական համակարգում՝ հերթում, սպասելով, որ առաջին գործարքն անցնի ընթացիկ մշակման փուլը: Այսինքն, խողովակաշարի մշակման հիմնական առավելությունն այն է, որ մենք ավելի արագ ենք մշակում գործարքների հերթը։
Ահա թե ինչպես ստեղծեցինք ASTS+ համակարգը:
Ճիշտ է, փոխակրիչներով էլ ամեն ինչ այդքան հարթ չէ։ Ենթադրենք, մենք ունենք գործարք, որն ազդում է հարևան գործարքի տվյալների զանգվածների վրա, սա տիպիկ իրավիճակ է փոխանակման համար: Նման գործարքը չի կարող իրականացվել խողովակաշարով, քանի որ այն կարող է ազդել ուրիշների վրա: Այս իրավիճակը կոչվում է տվյալների վտանգ, և նման գործարքները պարզապես մշակվում են առանձին. երբ հերթում «արագ» գործարքներն ավարտվում են, խողովակաշարը դադարում է, համակարգը մշակում է «դանդաղ» գործարքը և նորից սկսում խողովակաշարը: Բարեբախտաբար, նման գործարքների մասնաբաժինը ընդհանուր հոսքում շատ փոքր է, ուստի խողովակաշարն այնքան հազվադեպ է կանգնում, որ չի ազդում ընդհանուր աշխատանքի վրա:
Այնուհետև մենք սկսեցինք լուծել կատարման երեք թելերի համաժամացման խնդիրը: Արդյունքը եղավ մի համակարգ, որը հիմնված էր ֆիքսված չափի բջիջներով օղակային բուֆերի վրա: Այս համակարգում ամեն ինչ ենթակա է մշակման արագության, տվյալները չեն պատճենվում։
- Բոլոր մուտքային ցանցային փաթեթները մտնում են տեղաբաշխման փուլ:
- Մենք դրանք տեղադրում ենք զանգվածի մեջ և նշում որպես հասանելի թիվ 1 փուլի համար:
- Երկրորդ գործարքը հասել է, այն կրկին հասանելի է թիվ 1 փուլի համար։
- Առաջին պրոցեսինգային շարանը տեսնում է առկա գործարքները, մշակում է դրանք և տեղափոխում երկրորդ մշակման թելի հաջորդ փուլ:
- Այնուհետև այն մշակում է առաջին գործարքը և նշում համապատասխան բջիջը
deleted— այն այժմ հասանելի է նոր օգտագործման համար:
Ամբողջ հերթը մշակվում է այս կերպ.
Յուրաքանչյուր փուլի մշակումը տեւում է միավորներ կամ տասնյակ միկրովայրկյաններ: Եվ եթե մենք օգտագործենք ՕՀ-ի համաժամացման ստանդարտ սխեմաներ, ապա մենք ավելի շատ ժամանակ կկորցնենք ինքնին համաժամացման վրա: Ահա թե ինչու մենք սկսեցինք օգտագործել spinlock: Այնուամենայնիվ, սա շատ վատ ձև է իրական ժամանակի համակարգում, և RedHat-ը կտրականապես խորհուրդ չի տալիս դա անել, այնպես որ մենք կիրառում ենք spinlock 100 ms-ով, այնուհետև անցնում ենք սեմաֆորի ռեժիմին, որպեսզի վերացնենք փակուղու հնարավորությունը:
Արդյունքում մենք հասել ենք վայրկյանում մոտ 8 միլիոն գործարքի կատարողականի: Եվ բառացիորեն երկու ամիս անց LMAX Disruptor-ի մասին մենք տեսանք նույն ֆունկցիոնալությամբ շղթայի նկարագրությունը:
Այժմ մեկ փուլում կարող են լինել կատարման մի քանի թելեր: Բոլոր գործարքները մշակվել են մեկ առ մեկ՝ ըստ ստացման հերթականության։ Արդյունքում առավելագույն կատարողականը 18 հազարից հասել է 50 հազարի մեկ վայրկյանում:
Փոխանակման ռիսկերի կառավարման համակարգ
Կատարելության սահման չկա, և շուտով մենք նորից սկսեցինք արդիականացումը. ASTS+-ի շրջանակներում մենք սկսեցինք ռիսկերի կառավարման և հաշվարկային գործառնությունների համակարգերը տեղափոխել ինքնավար բաղադրիչներ: Մենք մշակեցինք ճկուն ժամանակակից ճարտարապետություն և հիերարխիկ ռիսկի նոր մոդել և փորձեցինք օգտագործել դասը, որտեղ հնարավոր էր fixed_point փոխարենը double.
Բայց անմիջապես առաջացավ խնդիր՝ ինչպե՞ս սինխրոնիզացնել երկար տարիներ գործող ողջ բիզնես տրամաբանությունը և տեղափոխել նոր համակարգ։ Արդյունքում, նոր համակարգի նախատիպի առաջին տարբերակը ստիպված եղավ հրաժարվել։ Երկրորդ տարբերակը, որն այժմ աշխատում է արտադրության մեջ, հիմնված է նույն ծածկագրի վրա, որն աշխատում է և՛ առևտրային, և՛ ռիսկային մասերում։ Մշակման ընթացքում ամենադժվարը երկու տարբերակների միջև git merge-ն էր: Մեր գործընկեր Եվգենի Մազուրենոկը ամեն շաբաթ անում էր այս վիրահատությունը և ամեն անգամ շատ երկար հայհոյում էր։
Նոր համակարգ ընտրելիս մենք անմիջապես պետք է լուծեինք փոխգործակցության խնդիրը։ Տվյալների ավտոբուս ընտրելիս անհրաժեշտ էր ապահովել կայուն ցնցում և նվազագույն ուշացում: InfiniBand RDMA ցանցը լավագույնս համապատասխանում էր դրա համար. մշակման միջին ժամանակը 4 անգամ պակաս է, քան 10 G Ethernet ցանցերում: Բայց այն, ինչ մեզ իսկապես գրավեց, տոկոսների տարբերությունն էր՝ 99 և 99,9:
Իհարկե, InfiniBand-ն ունի իր մարտահրավերները: Նախ, այլ API - իբբայներ վարդակների փոխարեն: Երկրորդ, գրեթե չկան լայնորեն հասանելի բաց կոդով հաղորդագրությունների լուծումներ: Մենք փորձեցինք պատրաստել մեր նախատիպը, բայց պարզվեց, որ դա շատ դժվար էր, ուստի ընտրեցինք կոմերցիոն լուծում՝ Confinity Low Latency Messaging (նախկինում՝ IBM MQ LLM):
Հետո առաջացավ ռիսկային համակարգը ճիշտ բաժանելու խնդիրը։ Եթե դուք պարզապես հեռացնեք Risk Engine-ը և չստեղծեք միջանկյալ հանգույց, ապա երկու աղբյուրներից գործարքները կարող են խառնվել:
Այսպես կոչված Ultra Low Latency լուծումներն ունեն վերադասավորման ռեժիմ. ստացման պահից կարելի է գործարքներ կազմակերպել երկու աղբյուրներից, որն իրականացվում է պատվերի մասին տեղեկատվության փոխանակման առանձին ալիքի միջոցով: Բայց մենք դեռ չենք օգտագործում այս ռեժիմը. այն բարդացնում է ողջ գործընթացը, իսկ մի շարք լուծումներում այն ընդհանրապես չի ապահովվում: Բացի այդ, յուրաքանչյուր գործարքի համար պետք է նշանակվեն համապատասխան ժամանակային դրոշմներ, և մեր սխեմայում այդ մեխանիզմը շատ դժվար է ճիշտ իրականացնել: Հետևաբար, մենք օգտագործեցինք դասական սխեման հաղորդագրության բրոքերի հետ, այսինքն՝ դիսպետչերի հետ, որը հաղորդագրություններ է բաշխում ռիսկային շարժիչի միջև:
Երկրորդ խնդիրը կապված էր հաճախորդի մուտքի հետ. եթե կան մի քանի ռիսկային դարպասներ, ապա հաճախորդը պետք է միանա դրանցից յուրաքանչյուրին, և դա կպահանջի փոփոխություններ հաճախորդի շերտում: Այս փուլում մենք ցանկանում էինք խուսափել դրանից, այնպես որ ռիսկի դարպասի ներկայիս դիզայնը մշակում է տվյալների ամբողջ հոսքը: Սա մեծապես սահմանափակում է առավելագույն թողունակությունը, բայց զգալիորեն հեշտացնում է համակարգի ինտեգրումը:
Կրկնօրինակում
Մեր համակարգը չպետք է ունենա խափանման մեկ կետ, այսինքն, բոլոր բաղադրիչները պետք է կրկնօրինակվեն, ներառյալ հաղորդագրությունների բրոքերը: Մենք լուծեցինք այս խնդիրը CLLM համակարգի միջոցով. այն պարունակում է RCMS կլաստեր, որում երկու դիսպետչեր կարող են աշխատել master-slave ռեժիմում, և երբ մեկը ձախողվում է, համակարգը ավտոմատ կերպով անցնում է մյուսին:
Պահուստային տվյալների կենտրոնի հետ աշխատելը
InfiniBand-ը օպտիմիզացված է որպես լոկալ ցանց աշխատելու համար, այսինքն՝ դարակաշարային սարքավորումները միացնելու համար, և InfiniBand ցանցը չի կարող տեղադրվել աշխարհագրորեն բաշխված տվյալների երկու կենտրոնների միջև: Հետևաբար, մենք ներդրեցինք կամուրջ/դիսպետչեր, որը միանում է հաղորդագրությունների պահպանմանը սովորական Ethernet ցանցերի միջոցով և փոխանցում բոլոր գործարքները երկրորդ IB ցանցին: Երբ մենք պետք է տեղափոխվենք տվյալների կենտրոնից, մենք կարող ենք ընտրել, թե որ տվյալների կենտրոնի հետ աշխատենք հիմա:
Արդյունքները
Վերը նշված բոլորը միանգամից չեն արվել, նոր ճարտարապետություն մշակելու համար պահանջվել են մի քանի կրկնություններ: Նախատիպը ստեղծեցինք մեկ ամսում, սակայն երկու տարուց ավելի պահանջվեց այն աշխատանքային վիճակի բերելու համար։ Մենք փորձեցինք հասնել լավագույն փոխզիջման գործարքների մշակման ժամանակի ավելացման և համակարգի հուսալիության բարձրացման միջև:
Քանի որ համակարգը մեծապես թարմացվել է, մենք իրականացրել ենք տվյալների վերականգնում երկու անկախ աղբյուրներից: Եթե հաղորդագրությունների խանութը ինչ-ինչ պատճառներով ճիշտ չի գործում, կարող եք գործարքների մատյան վերցնել երկրորդ աղբյուրից՝ Risk Engine-ից: Այս սկզբունքը պահպանվում է ամբողջ համակարգում։
Ի թիվս այլ բաների, մենք կարողացանք պահպանել հաճախորդի API-ն, որպեսզի ոչ բրոքերները, ոչ էլ որևէ մեկը զգալի վերամշակում չպահանջի նոր ճարտարապետության համար: Մենք ստիպված եղանք փոխել որոշ ինտերֆեյսներ, բայց գործառնական մոդելում էական փոփոխություններ կատարելու կարիք չկար։
Մենք անվանեցինք մեր պլատֆորմի ներկայիս տարբերակը Rebus՝ որպես ճարտարապետության երկու առավել նկատելի նորարարությունների հապավում՝ Risk Engine և BUS:
Ի սկզբանե ուզում էինք հատկացնել միայն քլիրինգային մասը, բայց արդյունքը հսկայական բաշխված համակարգ էր։ Հաճախորդներն այժմ կարող են փոխազդել կամ Առևտրի դարպասի, Մաքրման դարպասի կամ երկուսի հետ:
Այն, ինչ մենք ի վերջո հասանք.
Նվազեցրեց հետաձգման մակարդակը: Գործարքների փոքր ծավալի դեպքում համակարգը աշխատում է նույնը, ինչ նախորդ տարբերակը, բայց միևնույն ժամանակ կարող է դիմակայել շատ ավելի մեծ բեռի:
Պիկ կատարողականը վայրկյանում 50 հազարից հասել է 180 հազարի: Հետագա աճին խոչընդոտում է պատվերի համապատասխանության միակ հոսքը:
Հետագա բարելավման երկու եղանակ կա՝ համընկնումի զուգահեռացում և Gateway-ի հետ աշխատելու ձևի փոփոխություն: Այժմ բոլոր Gateway-ները գործում են կրկնօրինակման սխեմայի համաձայն, որը նման ծանրաբեռնվածության դեպքում դադարում է նորմալ գործել:
Վերջապես, ես կարող եմ մի քանի խորհուրդ տալ նրանց, ովքեր վերջնական տեսքի են բերում ձեռնարկությունների համակարգերը.
- Միշտ պատրաստ եղեք ամենավատին: Խնդիրները միշտ անսպասելի են առաջանում։
- Սովորաբար անհնար է արագ վերափոխել ճարտարապետությունը: Հատկապես, եթե ձեզ անհրաժեշտ է հասնել առավելագույն հուսալիության բազմաթիվ ցուցիչների վրա: Որքան շատ հանգույցներ, այնքան ավելի շատ ռեսուրսներ են անհրաժեշտ աջակցության համար:
- Բոլոր մաքսային և սեփականության լուծումները կպահանջեն լրացուցիչ ռեսուրսներ հետազոտության, աջակցության և պահպանման համար:
- Մի հետաձգեք համակարգի հուսալիության և վերականգնման խնդիրների լուծումը խափանումներից հետո, հաշվի առեք դրանք նախնական նախագծման փուլում:
Source: www.habr.com