Բարև, իմ անունը Եվգենի է: Ես աշխատում եմ Yandex.Market որոնման ենթակառուցվածքում: Ես ուզում եմ պատմել Հաբր համայնքին շուկայի ներքին խոհանոցի մասին, և ես շատ բան ունեմ պատմելու: Առաջին հերթին, թե ինչպես է աշխատում շուկայի որոնումը, գործընթացները և ճարտարապետությունը: Ինչպե՞ս ենք մենք վարվում արտակարգ իրավիճակների հետ. ի՞նչ է տեղի ունենում, եթե մեկ սերվերն անջատվի: Իսկ եթե կա 100 այդպիսի սերվեր:
Դուք նաև կսովորեք, թե ինչպես ենք մենք իրականացնում նոր գործառույթներ միանգամից մի շարք սերվերների վրա: Եվ ինչպես ենք մենք փորձարկում համալիր ծառայություններն անմիջապես արտադրության մեջ՝ առանց օգտվողներին անհարմարություն պատճառելու: Ընդհանուր առմամբ, ինչպես է աշխատում շուկայի որոնումը, որպեսզի բոլորը լավ ժամանակ անցկացնեն:
Մի փոքր մեր մասին՝ ինչ խնդիր ենք լուծում
Երբ մուտքագրում եք տեքստ, որոնում եք ապրանք ըստ պարամետրերի կամ համեմատում գները տարբեր խանութներում, բոլոր հարցումներն ուղարկվում են որոնման ծառայությանը: Որոնումը շուկայում ամենամեծ ծառայությունն է:
Մենք մշակում ենք որոնման բոլոր հարցումները՝ market.yandex.ru, beru.ru, Supercheck ծառայությունից, Yandex.Advisor, բջջային հավելվածներից: Մենք ներառում ենք նաև ապրանքների առաջարկներ yandex.ru-ի որոնման արդյունքներում:
Որոնման ծառայություն ասելով նկատի ունեմ ոչ միայն բուն որոնումը, այլ նաև շուկայի բոլոր առաջարկներով տվյալների բազան: Սանդղակն այսպիսին է՝ օրական մեկ միլիարդից ավելի որոնման հարցումներ են մշակվում: Եվ ամեն ինչ պետք է աշխատի արագ, առանց ընդհատումների և միշտ տա ցանկալի արդյունքը։
Ինչ է ինչ: Շուկայական ճարտարապետություն
Ես հակիրճ նկարագրելու եմ Շուկայի ներկայիս ճարտարապետությունը: Այն կարելի է մոտավորապես նկարագրել ստորև բերված գծապատկերով.
Ենթադրենք, գործընկեր խանութ է գալիս մեզ մոտ: Նա ասում է, որ ես ուզում եմ խաղալիք վաճառել. Եվ մեկ այլ զայրացած կատու՝ առանց ճռռացողի։ Եվ պարզապես կատու: Այնուհետև խանութը պետք է պատրաստի առաջարկներ, որոնց համար շուկան որոնում է: Խանութը ստեղծում է հատուկ xml առաջարկներով և փոխկապակցված ինտերֆեյսի միջոցով հաղորդում է դեպի այս xml-ի ուղին: Այնուհետև ինդեքսավորիչը պարբերաբար ներբեռնում է այս xml-ը, ստուգում է սխալների համար և պահպանում է ողջ տեղեկատվությունը հսկայական տվյալների բազայում:
Կան բազմաթիվ նման պահպանված xml-ներ: Այս տվյալների բազայից ստեղծվում է որոնման ինդեքս: Ցուցանիշը պահվում է ներքին ձևաչափով: Ինդեքսը ստեղծելուց հետո Layout ծառայությունը այն վերբեռնում է որոնման սերվերներ։
Արդյունքում տվյալների բազայում հայտնվում է բարկացած կատու՝ ճռռոցով, իսկ կատվի ինդեքսը՝ սերվերում:
Ես ձեզ կասեմ, թե ինչպես ենք մենք փնտրում կատու որոնման ճարտարապետության մասում:
Շուկայի որոնման ճարտարապետություն
Մենք ապրում ենք միկրոծառայությունների աշխարհում. յուրաքանչյուր մուտքային հարցում առաջացնում է բազմաթիվ ենթհարցումներ, որոնց մշակման մեջ ներգրավված են տասնյակ ծառայություններ։ Դիագրամը ցույց է տալիս միայն մի քանիսը.
Հարցումների մշակման պարզեցված սխեմա
Յուրաքանչյուր ծառայություն ունի մի հրաշալի բան՝ իր սեփական հավասարակշռողը՝ յուրահատուկ անունով.
Հավասարակշռիչը մեզ ավելի մեծ ճկունություն է տալիս ծառայության կառավարման հարցում. դուք կարող եք, օրինակ, անջատել սերվերները, ինչը հաճախ պահանջվում է թարմացումների համար: Հավասարակշռողը տեսնում է, որ սերվերն անհասանելի է և ինքնաբերաբար վերահղում է հարցումները այլ սերվերներ կամ տվյալների կենտրոններ: Սերվեր ավելացնելիս կամ հեռացնելիս բեռը ավտոմատ կերպով վերաբաշխվում է սերվերների միջև:
Հավասարակշռողի եզակի անունը կախված չէ տվյալների կենտրոնից: Երբ A ծառայությունը հարցում է կատարում B-ին, ապա լռելյայնորեն հավասարակշռող B-ն հարցումը վերահղում է ընթացիկ տվյալների կենտրոն: Եթե ծառայությունն անհասանելի է կամ գոյություն չունի ընթացիկ տվյալների կենտրոնում, ապա հարցումը վերահղվում է տվյալների այլ կենտրոններ:
Բոլոր տվյալների կենտրոնների համար մեկ FQDN-ն թույլ է տալիս A ծառայությանը լիովին վերացական լինել տեղանքներից: Բ ծառայությանն ուղղված նրա խնդրանքը միշտ ընթացք կստանա: Բացառություն է այն դեպքը, երբ ծառայությունը տեղակայված է տվյալների բոլոր կենտրոններում։
Բայց այս հավասարակշռողի հետ ամեն ինչ այնքան էլ վարդագույն չէ. մենք ունենք լրացուցիչ միջանկյալ բաղադրիչ: Հավասարակշռիչը կարող է անկայուն լինել, և այս խնդիրը լուծվում է ավելորդ սերվերների միջոցով: Կա նաև լրացուցիչ ուշացում A և B ծառայությունների միջև: Բայց գործնականում այն 1 ms-ից պակաս է, և ծառայությունների մեծ մասի համար դա կարևոր չէ:
Գործ ունենալ անսպասելիի հետ. Որոնման ծառայության հավասարակշռում և ճկունություն
Պատկերացրեք, որ փլուզում կա՝ պետք է ճռռացող կատու գտնել, բայց սերվերը խափանում է: Կամ 100 սերվեր: Ինչպե՞ս դուրս գալ: Իսկապե՞ս պատրաստվում ենք օգտատիրոջը թողնել առանց կատու:
Իրավիճակը սարսափելի է, բայց մենք պատրաստ ենք դրան։ Ես ձեզ հերթականությամբ կասեմ.
Որոնման ենթակառուցվածքը գտնվում է մի քանի տվյալների կենտրոններում.
Նախագծելիս մենք ներառում ենք տվյալների մեկ կենտրոնի անջատման հնարավորությունը: Կյանքը լի է անակնկալներով. օրինակ, էքսկավատորը կարող է կտրել ստորգետնյա մալուխը (այո, դա եղել է): Մնացած տվյալների կենտրոնների հզորությունը պետք է բավարար լինի առավելագույն ծանրաբեռնվածությանը դիմակայելու համար:
Դիտարկենք մեկ տվյալների կենտրոն: Յուրաքանչյուր տվյալների կենտրոն ունի հավասարակշռող գործառնական նույն սխեման.
Մեկ հավասարակշռողն առնվազն երեք ֆիզիկական սերվեր է: Այս ավելորդությունը ստեղծված է հուսալիության համար: Հավասարակշռիչները աշխատում են HAProx-ով:
Մենք ընտրեցինք HAProx-ը բարձր կատարողականության, ռեսուրսների ցածր պահանջների և լայն ֆունկցիոնալության շնորհիվ: Մեր որոնման ծրագրակազմն աշխատում է յուրաքանչյուր սերվերի ներսում:
Մեկ սերվերի ձախողման հավանականությունը ցածր է: Բայց եթե դուք ունեք շատ սերվերներ, ապա հավանականությունը, որ գոնե մեկը իջնի, մեծանում է:
Սա այն է, ինչ տեղի է ունենում իրականում. սերվերները խափանում են: Ուստի անհրաժեշտ է մշտապես վերահսկել բոլոր սերվերների կարգավիճակը։ Եթե սերվերը դադարում է արձագանքել, այն ավտոմատ կերպով անջատվում է տրաֆիկից: Այդ նպատակով HAProxy-ն ունի ներկառուցված առողջության ստուգում: Այն անցնում է բոլոր սերվերներին վայրկյանը մեկ HTTP հարցումով «/ping»:
HAProxy-ի մեկ այլ առանձնահատկություն՝ գործակալի ստուգումը թույլ է տալիս հավասարաչափ բեռնել բոլոր սերվերները: Դա անելու համար HAProxy-ը միանում է բոլոր սերվերներին, և նրանք վերադարձնում են իրենց քաշը՝ կախված ընթացիկ բեռնվածությունից 1-ից մինչև 100: Քաշը հաշվարկվում է մշակման համար հերթում առկա հարցումների քանակի և պրոցեսորի ծանրաբեռնվածության հիման վրա:
Հիմա կատվին գտնելու մասին։ Որոնման արդյունքում ստացվում են այնպիսի հարցումներ, ինչպիսիք են. /որոնում?text=զայրացած+կատու. Որպեսզի որոնումը արագ լինի, կատվի ամբողջ ինդեքսը պետք է տեղավորվի RAM-ում: Նույնիսկ SSD-ից կարդալը բավականաչափ արագ չէ:
Ժամանակին առաջարկների բազան փոքր էր, և մեկ սերվերի օպերատիվ հիշողությունը բավական էր դրա համար։ Քանի որ առաջարկների բազան մեծանում էր, ամեն ինչ այլևս չէր տեղավորվում այս RAM-ի մեջ, և տվյալները բաժանվեցին երկու մասի՝ բեկոր 1 և բեկոր 2:
Բայց դա միշտ էլ լինում է. ցանկացած լուծում, թեկուզ լավը, այլ խնդիրներ է ծնում։
Հավասարակշռողը դեռ գնաց ցանկացած սերվեր: Բայց մեքենայի վրա, որտեղ հայտը եկավ, ինդեքսի միայն կեսն էր: Մնացածը այլ սերվերների վրա էր: Հետևաբար, սերվերը պետք է գնա հարևան մեքենա: Երկու սերվերներից տվյալներ ստանալուց հետո արդյունքները համակցվել և վերադասավորվել են:
Քանի որ հավասարակշռողը հավասարաչափ բաշխում է հարցումները, բոլոր սերվերները զբաղված էին վերադասակարգմամբ, և ոչ միայն տվյալների ուղարկմամբ:
Խնդիրն առաջացավ, եթե հարևան սերվերն անհասանելի էր: Լուծումը կայանում էր նրանում, որ որպես «հարևան» սերվեր նշել տարբեր առաջնահերթություններ ունեցող մի քանի սերվեր: Նախ, հարցումն ուղարկվել է ընթացիկ դարակի սերվերներին: Եթե պատասխան չեղավ, հարցումն ուղարկվեց այս տվյալների կենտրոնի բոլոր սերվերներին: Եվ վերջապես, հարցումն ուղղվեց այլ տվյալների կենտրոններ:
Քանի որ առաջարկների թիվը մեծանում էր, տվյալները բաժանվեցին չորս մասի. Բայց սա սահմանը չէր։
Ներկայումս օգտագործվում է ութ բեկորների կոնֆիգուրացիա: Բացի այդ, ավելի շատ հիշողություն խնայելու համար ինդեքսը բաժանվեց որոնման մասի (որն օգտագործվում է որոնման համար) և հատվածի մասի (որը ներգրավված չէ որոնման մեջ):
Մեկ սերվերը պարունակում է տեղեկատվություն միայն մեկ բեկորի համար: Հետևաբար, ամբողջական ինդեքսը որոնելու համար անհրաժեշտ է որոնել տարբեր բեկորներ պարունակող ութ սերվերների վրա։
Սերվերները խմբավորված են կլաստերների մեջ: Յուրաքանչյուր կլաստեր պարունակում է ութ որոնման համակարգ և մեկ հատվածի սերվեր:
Հատված սերվերը գործարկում է ստատիկ տվյալների բազայի արժեքի բազա: Դրանք անհրաժեշտ են փաստաթղթեր տրամադրելու համար, օրինակ՝ ճռռոցով կատվի նկարագրություն։ Տվյալները հատուկ փոխանցվում են առանձին սերվեր՝ որոնման սերվերների հիշողությունը չբեռնելու համար։
Քանի որ փաստաթղթերի ID-ները եզակի են միայն մեկ ինդեքսում, կարող է առաջանալ իրավիճակ, երբ հատվածներում փաստաթղթեր չկան: Դե, կամ որ մեկ ID-ի համար տարբեր բովանդակություն կլինի։ Հետևաբար, որպեսզի որոնումն աշխատի և արդյունքները վերադարձվեն, ամբողջ կլաստերում հետևողականության կարիք կար: Ես ձեզ կպատմեմ ստորև, թե ինչպես ենք մենք հետևում հետևողականությանը:
Որոնումն ինքնին կառուցված է հետևյալ կերպ. որոնման հարցումը կարող է գալ ութ սերվերներից որևէ մեկին: Ենթադրենք, նա եկել է սերվեր 1: Այս սերվերը մշակում է բոլոր փաստարկները և հասկանում է, թե ինչ և ինչպես փնտրել: Կախված մուտքային հարցումից, սերվերը կարող է լրացուցիչ հարցումներ կատարել արտաքին ծառայություններին անհրաժեշտ տեղեկատվության համար: Մեկ հարցումին կարող են հաջորդել մինչև տասը հարցումներ արտաքին ծառայություններին:
Անհրաժեշտ տեղեկատվությունը հավաքելուց հետո որոնումը սկսվում է առաջարկների բազայում: Դա անելու համար ենթահարցումներ են արվում կլաստերի բոլոր ութ սերվերներին:
Պատասխանները ստանալուց հետո արդյունքները համակցվում են: Ի վերջո, արդյունքների ստեղծման համար կարող են անհրաժեշտ լինել ևս մի քանի ենթահերթումներ դեպի հատվածային սերվեր:
Կլաստերում որոնման հարցումները նման են. /shard1?text=զայրացած+կատու. Բացի այդ, ձևի ենթահարցումները անընդհատ կատարվում են կլաստերի բոլոր սերվերների միջև վայրկյանը մեկ. /կարգավիճակ.
Հարցում /կարգավիճակ հայտնաբերում է մի իրավիճակ, որտեղ սերվերը հասանելի չէ:
Այն նաև վերահսկում է, որ որոնման համակարգի տարբերակը և ինդեքսային տարբերակը նույնն են բոլոր սերվերների վրա, հակառակ դեպքում կլաստերի ներսում կլինեն անհամապատասխան տվյալներ:
Չնայած այն հանգամանքին, որ մեկ հատված սերվերը մշակում է ութ որոնողական համակարգերի հարցումները, նրա պրոցեսորը շատ թույլ է բեռնված: Հետևաբար, մենք այժմ փոխանցում ենք հատվածի տվյալները առանձին ծառայության:
Տվյալների փոխանցման համար մենք ներկայացրել ենք փաստաթղթերի ունիվերսալ բանալիներ: Այժմ անհնար է մի իրավիճակում, երբ մեկ այլ փաստաթղթի բովանդակությունը վերադարձվում է մեկ բանալիով:
Բայց անցումը այլ ճարտարապետության դեռ ավարտված չէ։ Այժմ մենք ցանկանում ենք ազատվել հատուկ հատվածի սերվերից: Եվ հետո ընդհանրապես հեռացեք կլաստերի կառուցվածքից: Սա թույլ կտա մեզ հեշտությամբ շարունակել մասշտաբը: Լրացուցիչ բոնուսը երկաթի զգալի խնայողությունն է:
Իսկ հիմա սարսափելի պատմություններ՝ երջանիկ ավարտով: Դիտարկենք սերվերի անհասանելիության մի քանի դեպք։
Ինչ-որ սարսափելի բան է տեղի ունեցել. մեկ սերվեր անհասանելի է
Ենթադրենք, մեկ սերվեր անհասանելի է: Այնուհետև կլաստերի մնացած սերվերները կարող են շարունակել պատասխանել, բայց որոնման արդյունքները թերի կլինեն:
Կարգավիճակի ստուգման միջոցով /կարգավիճակ հարևան սերվերները հասկանում են, որ մեկը անհասանելի է: Հետևաբար, ամբողջականությունը պահպանելու համար կլաստերի բոլոր սերվերները յուրաքանչյուր հարցումով /պինգ նրանք սկսում են պատասխանել հավասարակշռողին, որ իրենք նույնպես անհասանելի են: Պարզվում է, որ կլաստերի բոլոր սերվերները մահացել են (ինչը ճիշտ չէ): Սա մեր կլաստերային սխեմայի հիմնական թերությունն է, այդ իսկ պատճառով մենք ցանկանում ենք հեռանալ դրանից:
Սխալով ձախողվող հարցումները կրկին ուղարկվում են հավասարակշռողի կողմից այլ սերվերների վրա:
Հավասարակշռողը նաև դադարեցնում է օգտատերերի տրաֆիկ ուղարկել մահացած սերվերներին, բայց շարունակում է ստուգել նրանց կարգավիճակը:
Երբ սերվերը հասանելի է դառնում, այն սկսում է արձագանքել /պինգ. Հենց որ մահացած սերվերներից պինգերի նորմալ պատասխանները սկսում են գալ, հավասարակշռողները սկսում են այնտեղ ուղարկել օգտատերերի տրաֆիկը: Կլաստերի աշխատանքը վերականգնված է, շտապեք։
Նույնիսկ ավելի վատ. շատ սերվերներ անհասանելի են
Տվյալների կենտրոնի սերվերների զգալի մասը կտրված է։ Ի՞նչ անել, որտե՞ղ վազել: Հավասարակշռողը կրկին օգնության է հասնում։ Յուրաքանչյուր հավասարակշռող մշտապես պահում է հիշողության մեջ գործող սերվերների ընթացիկ թիվը: Այն անընդհատ հաշվարկում է տրաֆիկի առավելագույն քանակը, որը կարող է մշակել ընթացիկ տվյալների կենտրոնը:
Երբ տվյալների կենտրոնի շատ սերվերներ իջնում են, հավասարակշռողը հասկանում է, որ այս տվյալների կենտրոնը չի կարող մշակել ամբողջ տրաֆիկը:
Այնուհետև ավելորդ տրաֆիկը սկսում է պատահականորեն բաշխվել այլ տվյալների կենտրոններ: Ամեն ինչ աշխատում է, բոլորը երջանիկ են:
Ինչպես ենք մենք դա անում. թողարկումների հրատարակում
Հիմա եկեք խոսենք այն մասին, թե ինչպես ենք մենք հրապարակում ծառայության մեջ կատարված փոփոխությունները: Այստեղ մենք բռնել ենք գործընթացների պարզեցման ճանապարհը. նոր թողարկման թողարկումը գրեթե ամբողջությամբ ավտոմատացված է:
Երբ նախագծում որոշակի քանակությամբ փոփոխություններ են կուտակվում, ավտոմատ կերպով ստեղծվում է նոր թողարկում և սկսվում է դրա կառուցումը:
Այնուհետև ծառայությունը անցնում է փորձարկման, որտեղ ստուգվում է շահագործման կայունությունը:
Միաժամանակ գործարկվում է կատարողականի ավտոմատ թեստավորում։ Սա զբաղվում է հատուկ ծառայության կողմից: Ես հիմա դրա մասին չեմ խոսի, դրա նկարագրությունը արժանի է առանձին հոդվածի:
Եթե թեստավորման ժամանակ հրապարակումը հաջող է, թողարկման հրապարակումը prestable-ում ավտոմատ կերպով սկսվում է: Prestable-ը հատուկ կլաստեր է, որտեղ ուղղորդվում է սովորական օգտատերերի տրաֆիկը: Եթե այն վերադարձնում է սխալ, հավասարակշռողը նորից հարցում է կատարում արտադրությանը:
Prestable-ում արձագանքման ժամանակները չափվում և համեմատվում են արտադրության մեջ նախորդ թողարկման հետ: Եթե ամեն ինչ լավ է, ապա մարդը միանում է. ստուգում է գրաֆիկները և բեռնվածության փորձարկման արդյունքները, այնուհետև սկսում է դուրս գալ արտադրության:
Ամենալավը գնում է օգտագործողին՝ A/B թեստավորում
Միշտ չէ, որ ակնհայտ է, թե արդյոք ծառայության փոփոխությունները իրական օգուտներ կբերեն: Փոփոխությունների օգտակարությունը չափելու համար մարդիկ հանդես եկան A/B թեստով: Ես ձեզ մի փոքր կպատմեմ, թե ինչպես է այն աշխատում Yandex.Market որոնման մեջ:
Ամեն ինչ սկսվում է նոր CGI պարամետր ավելացնելով, որը հնարավորություն է տալիս նոր գործառույթներ: Թող մեր պարամետրը լինի. շուկա_նոր_ֆունկցիոնալություն=1. Այնուհետև կոդում մենք միացնում ենք այս գործառույթը, եթե դրոշը առկա է.
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}Նոր ֆունկցիոնալությունը ներդրվում է արտադրության մեջ:
A/B թեստավորումն ավտոմատացնելու համար կա հատուկ ծառայություն, որը մանրամասն տեղեկատվություն է տրամադրում . Ծառայության մեջ ստեղծվում է փորձ. Երթևեկության մասնաբաժինը սահմանվում է, օրինակ, 15%: Տոկոսները սահմանվում են ոչ թե հարցումների, այլ օգտատերերի համար։ Նշված է նաեւ փորձի տեւողությունը, օրինակ՝ մեկ շաբաթ։
Մի քանի փորձեր կարող են իրականացվել միաժամանակ: Կարգավորումներում կարող եք նշել, թե արդյոք հնարավոր է խաչմերուկ այլ փորձերի հետ:
Արդյունքում ծառայությունը ավտոմատ կերպով ավելացնում է փաստարկ շուկա_նոր_ֆունկցիոնալություն=1 օգտատերերի 15%-ին: Այն նաև ավտոմատ կերպով հաշվարկում է ընտրված ցուցանիշները: Փորձի ավարտից հետո վերլուծաբանները դիտարկում են արդյունքները և եզրակացություններ անում: Գտածոների հիման վրա որոշում է կայացվում անցնել արտադրության կամ կատարելագործման:
Շուկայի հմուտ ձեռքը. փորձարկում արտադրության մեջ
Հաճախ է պատահում, որ դուք պետք է փորձարկեք նոր ֆունկցիոնալության գործարկումը արտադրության մեջ, բայց վստահ չեք, թե այն ինչպես կվարվի «մարտական» պայմաններում ծանր բեռի տակ:
Կա լուծում. CGI պարամետրերում դրոշները կարող են օգտագործվել ոչ միայն A/B թեստավորման, այլև նոր ֆունկցիոնալությունը փորձարկելու համար:
Մենք ստեղծել ենք գործիք, որը թույլ է տալիս ակնթարթորեն փոխել կոնֆիգուրացիան հազարավոր սերվերների վրա՝ առանց ծառայությունը ռիսկերի ենթարկելու: Այն կոչվում է Stop Tap: Նախնական գաղափարն այն էր, որ կարողանանք արագ անջատել որոշ գործառույթներ առանց դասավորության: Հետո գործիքն ընդլայնվեց և դարձավ ավելի բարդ:
Ծառայությունների հոսքի դիագրամը ներկայացված է ստորև.
Դրոշի արժեքները սահմանվում են API-ի միջոցով: Կառավարման ծառայությունը պահում է այս արժեքները տվյալների բազայում: Բոլոր սերվերները յուրաքանչյուր տասը վայրկյանը մեկ գնում են տվյալների բազա, դուրս մղում դրոշի արժեքները և կիրառում այդ արժեքները յուրաքանչյուր հարցման համար:
Stop հպումով դուք կարող եք սահմանել երկու տեսակի արժեքներ.
1) պայմանական արտահայտություններ. Կիրառել, երբ արժեքներից մեկը ճշմարիտ է: Օրինակ:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}«3» արժեքը կկիրառվի, երբ հարցումը մշակվի DC1 վայրում: Իսկ արժեքը «4» է, երբ հարցումը մշակվում է beru.ru կայքի երկրորդ կլաստերում:
2) Անվերապահ արժեքներ. Կիրառեք լռելյայն, եթե պայմաններից ոչ մեկը չի բավարարվում: Օրինակ:
արժեք, արժեք!
Եթե արժեքը ավարտվում է բացականչական նշանով, ապա նրան տրվում է ավելի մեծ առաջնահերթություն:
CGI պարամետրի վերլուծիչը վերլուծում է URL-ը: Այնուհետև կիրառում է Stop Tap-ի արժեքները:
Կիրառվում են հետևյալ գերակայություններով արժեքները.
- Stop Tap-ից (բացականչական նշան) ավելացված առաջնահերթությամբ:
- Արժեքը խնդրանքից.
- Կանխադրված արժեքը Stop Tap-ից:
- Կոդում կանխադրված արժեքը:
Կան բազմաթիվ դրոշներ, որոնք նշված են պայմանական արժեքներով, դրանք բավարար են մեզ հայտնի բոլոր սցենարների համար.
- Տվյալների կենտրոն.
- Շրջակա միջավայր՝ արտադրություն, փորձարկում, ստվեր:
- Վայրը՝ շուկա, բերու:
- Կլաստերի համարը.
Այս գործիքի միջոցով դուք կարող եք միացնել նոր ֆունկցիոնալությունը սերվերների որոշակի խմբի վրա (օրինակ՝ միայն մեկ տվյալների կենտրոնում) և փորձարկել այս գործառույթի աշխատանքը՝ առանց որևէ հատուկ ռիսկի ամբողջ ծառայության համար: Նույնիսկ եթե ինչ-որ տեղ լուրջ սխալ եք թույլ տվել, ամեն ինչ սկսեց ընկնել, և ամբողջ տվյալների կենտրոնը իջավ, հավասարակշռողները կվերահղեն հարցումները այլ տվյալների կենտրոններ: Վերջնական օգտվողները ոչինչ չեն նկատի:
Եթե նկատում եք խնդիր, կարող եք անմիջապես վերադարձնել դրոշը իր նախկին արժեքին, և փոփոխությունները հետ կվերադարձվեն:
Այս ծառայությունն ունի նաև իր բացասական կողմերը. մշակողները շատ են սիրում այն և հաճախ փորձում են բոլոր փոփոխությունները մտցնել «Stop Tap»-ի մեջ: Մենք փորձում ենք պայքարել չարաշահումների դեմ.
Stop Tap-ի մոտեցումը լավ է աշխատում, երբ դուք արդեն ունեք կայուն կոդ, որը պատրաստ է արտադրության համար: Միևնույն ժամանակ, դուք դեռևս կասկածներ ունեք, և ցանկանում եք ստուգել կոդը «մարտական» պայմաններում։
Այնուամենայնիվ, Stop Tap-ը հարմար չէ մշակման ընթացքում փորձարկման համար: Մշակողների համար կա առանձին կլաստեր, որը կոչվում է «ստվերային կլաստեր»:
Գաղտնի փորձարկում՝ ստվերային կլաստեր
Կլաստերներից մեկի հարցումները կրկնօրինակվում են ստվերային կլաստերի վրա: Բայց հավասարակշռողն ամբողջությամբ անտեսում է այս կլաստերի պատասխանները: Նրա շահագործման դիագրամը ներկայացված է ստորև։
Մենք ստանում ենք փորձնական կլաստեր, որը գտնվում է իրական «մարտական» պայմաններում։ Օգտատիրոջ սովորական տրաֆիկը գնում է այնտեղ: Երկու կլաստերների սարքաշարը նույնն է, այնպես որ կարող են համեմատվել կատարողականը և սխալները:
Եվ քանի որ հավասարակշռողն ամբողջությամբ անտեսում է պատասխանները, վերջնական օգտվողները չեն տեսնի պատասխաններ ստվերային կլաստերից: Ուստի սխալվելը սարսափելի չէ։
Արդյունքները
Այսպիսով, ինչպե՞ս ենք մենք կառուցել շուկայի որոնումը:
Որպեսզի ամեն ինչ հարթ ընթանա, մենք ֆունկցիոնալությունը բաժանում ենք առանձին ծառայությունների: Այս կերպ մենք կարող ենք մասշտաբավորել միայն այն բաղադրիչները, որոնք մեզ անհրաժեշտ են, և բաղադրիչներն ավելի պարզեցնել: Հեշտ է առանձին բաղադրիչ հանձնարարել մեկ այլ թիմի և կիսել դրա վրա աշխատելու պարտականությունները: Եվ այս մոտեցմամբ երկաթի զգալի խնայողությունները ակնհայտ պլյուս են:
Մեզ օգնում է նաև ստվերային կլաստերը. մենք կարող ենք մշակել ծառայություններ, փորձարկել դրանք գործընթացում և չանհանգստացնել օգտատիրոջը:
Դե, արտադրության մեջ փորձարկում, իհարկե: Պետք է փոխել կազմաձևումը հազարավոր սերվերների վրա: Հեշտ, օգտագործեք Stop Tap-ը: Այս կերպ դուք կարող եք անմիջապես դուրս բերել պատրաստի համալիր լուծում և հետ գլորել կայուն տարբերակի, եթե խնդիրներ առաջանան:
Հուսով եմ, որ կարողացա ցույց տալ, թե ինչպես ենք մենք շուկան դարձնում արագ և կայուն՝ անընդհատ աճող առաջարկների բազայով: Ինչպես ենք մենք լուծում սերվերի խնդիրները, առնչվում ենք հսկայական թվով հարցումների հետ, բարելավում ենք ծառայության ճկունությունը և դա անում առանց աշխատանքային գործընթացների ընդհատման:
Source: www.habr.com