Yandex.Cloud-ում ցանցային բեռի հավասարակշռողի ճարտարապետություն

Բարև, ես Սերգեյ Էլանցևն եմ, ես զարգացնում եմ ցանցի բեռի հավասարակշռող Yandex.Cloud-ում։ Նախկինում ես ղեկավարում էի Yandex պորտալի համար L7 հավասարակշռողի մշակումը. գործընկերները կատակում են, որ ինչ էլ որ անեմ, պարզվում է, որ հավասարակշռող է: Ես կպատմեմ Habr-ի ընթերցողներին, թե ինչպես կառավարել բեռը ամպային հարթակում, ինչն ենք մենք տեսնում որպես այս նպատակին հասնելու իդեալական գործիք և ինչպես ենք մենք շարժվում դեպի այս գործիքը կառուցելու ուղղությամբ:

Նախ, եկեք ներկայացնենք մի քանի տերմիններ.

• VIP (Վիրտուալ IP) - հավասարակշռող IP հասցե
• Սերվեր, backend, օրինակ՝ վիրտուալ մեքենա, որն աշխատում է հավելված
• RIP (Իրական IP) - սերվերի IP հասցե
• Healthcheck - սերվերի պատրաստվածության ստուգում
• Հասանելիության գոտի, AZ - մեկուսացված ենթակառուցվածք տվյալների կենտրոնում
• Տարածաշրջան - տարբեր AZ-ների միություն

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

Բեռի հավասարակշռիչը հաճախ դասակարգվում է OSI մոդելի արձանագրության շերտով, որի վրա այն աշխատում է: Cloud Balancer-ը գործում է TCP մակարդակով, որը համապատասխանում է չորրորդ շերտին՝ L4-ին:

Եկեք անցնենք Cloud balancer-ի ճարտարապետության ակնարկին: Մենք աստիճանաբար կբարձրացնենք մանրամասնության մակարդակը։ Մենք հավասարակշռող բաղադրիչները բաժանում ենք երեք դասի. Կազմաձև հարթության դասը պատասխանատու է օգտատերերի փոխազդեցության համար և պահպանում է համակարգի թիրախային վիճակը: Վերահսկիչ հարթությունը պահպանում է համակարգի ընթացիկ վիճակը և կառավարում համակարգերը տվյալների հարթության դասից, որոնք ուղղակիորեն պատասխանատու են հաճախորդներից երթևեկությունը ձեր ատյաններ հասցնելու համար:

Տվյալների հարթություն

Երթևեկությունը ավարտվում է թանկարժեք սարքերով, որոնք կոչվում են սահմանային երթուղիչներ: Սխալների հանդուրժողականությունը բարձրացնելու համար մի քանի նման սարքեր միաժամանակ աշխատում են մեկ տվյալների կենտրոնում: Հաջորդը, տրաֆիկը գնում է հավասարակշռողներին, որոնք հաճախորդների համար BGP-ի միջոցով հայտարարում են ցանկացած IP հասցեներ բոլոր AZ-ներին: 

Երթևեկությունը փոխանցվում է ECMP-ով. սա երթուղային ռազմավարություն է, ըստ որի կարող են լինել մի քանի հավասարապես լավ երթուղիներ դեպի թիրախ (մեր դեպքում թիրախը կլինի նպատակակետ IP հասցեն) և փաթեթները կարող են ուղարկվել դրանցից որևէ մեկի երկայնքով: Մենք նաև աջակցում ենք աշխատանքի հասանելիության մի քանի գոտիներում հետևյալ սխեմայով. յուրաքանչյուր գոտում մենք գովազդում ենք հասցե, երթևեկությունը գնում է դեպի մոտակա մեկը և չի անցնում դրա սահմանները: Ավելի ուշ գրառման մեջ մենք ավելի մանրամասն կանդրադառնանք, թե ինչ է տեղի ունենում երթևեկի հետ:

Կազմաձևման հարթություն

 
Կազմաձևման հարթության առանցքային բաղադրիչը API-ն է, որի միջոցով կատարվում են բալանսավորողներով հիմնական գործողություններ՝ ստեղծում, ջնջում, ինտանգների կազմի փոփոխություն, առողջական ստուգումների արդյունքների ստացում և այլն: Մի կողմից՝ սա REST API է, իսկ մյուս կողմից՝ մյուսը, մենք Cloud-ում շատ հաճախ օգտագործում ենք gRPC շրջանակը, այնպես որ մենք «թարգմանում ենք» REST-ը gRPC-ի, այնուհետև օգտագործում ենք միայն gRPC: Ցանկացած հարցում հանգեցնում է մի շարք ասինխրոն իդեմպոտենտ առաջադրանքների ստեղծմանը, որոնք կատարվում են Yandex.Cloud աշխատողների ընդհանուր լողավազանում: Առաջադրանքները գրված են այնպես, որ դրանք կարող են ցանկացած պահի կասեցվել, այնուհետև վերագործարկել: Սա ապահովում է մասշտաբայնություն, կրկնելիություն և գործողությունների գրանցում:

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

Ծառայությունը պահում է իր վիճակը Yandex Database-ում՝ բաշխված կառավարվող տվյալների բազայում, որը շուտով դուք կկարողանաք օգտագործել: Yandex.Cloud-ում, ինչպես մենք արդեն պատմեց, կիրառվում է շների սննդի հայեցակարգը. եթե մենք ինքներս օգտվենք մեր ծառայություններից, ապա մեր հաճախորդները նույնպես հաճույքով կօգտվեն դրանցից։ Yandex Database-ը նման հայեցակարգի իրականացման օրինակ է։ Մենք մեր բոլոր տվյալները պահում ենք YDB-ում և չպետք է մտածենք տվյալների բազայի պահպանման և մասշտաբի մասին. այս խնդիրները մեզ համար լուծված են, մենք օգտագործում ենք տվյալների բազան որպես ծառայություն։

Եկեք վերադառնանք հավասարակշռող վերահսկիչին: Դրա խնդիրն է պահպանել հավասարակշռողի մասին տեղեկատվությունը և վիրտուալ մեքենայի պատրաստվածությունը ստուգելու առաջադրանք ուղարկել առողջության ստուգման վերահսկիչին:

Առողջության ստուգման վերահսկիչ

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

Եկեք ավելին խոսենք առողջության ստուգումների մասին: Դրանք կարելի է բաժանել մի քանի դասերի. Աուդիտներն ունեն հաջողության տարբեր չափանիշներ: TCP ստուգումները պետք է հաջողությամբ հաստատեն կապը ֆիքսված ժամանակի ընթացքում: HTTP ստուգումները պահանջում են և՛ հաջող միացում, և՛ 200 կարգավիճակի կոդով պատասխան:

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

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

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

Տարբերությունն այն է, որ հաճախորդները հարցումներ են կատարում VIP-ին, մինչդեռ առողջապահական ստուգումները հարցումներ են կատարում յուրաքանչյուր առանձին RIP-ի համար: Այստեղ մի հետաքրքիր խնդիր է առաջանում՝ մենք մեր օգտատերերին հնարավորություն ենք տալիս ռեսուրսներ ստեղծել գորշ IP ցանցերում։ Եկեք պատկերացնենք, որ կան երկու տարբեր ամպի սեփականատերեր, ովքեր թաքցրել են իրենց ծառայությունները հավասարակշռողների հետևում: Նրանցից յուրաքանչյուրն ունի ռեսուրսներ 10.0.0.1/24 ենթացանցում՝ նույն հասցեներով։ Դուք պետք է կարողանաք ինչ-որ կերպ տարբերել դրանք, և այստեղ դուք պետք է սուզվեք Yandex.Cloud վիրտուալ ցանցի կառուցվածքի մեջ: Ավելի լավ է ավելին իմանալ այստեղ տեսանյութ about:cloud event-ից, մեզ համար այժմ կարևոր է, որ ցանցը բազմաշերտ է և ունի թունելներ, որոնք կարող են տարբերվել ենթացանցային ID-ով։

Healthcheck հանգույցները կապվում են հավասարակշռողների հետ՝ օգտագործելով այսպես կոչված քվազի-IPv6 հասցեները: Քվազի-հասցեն IPv6 հասցե է, որի ներսում տեղադրված է IPv4 հասցե և օգտվողի ենթացանց id: Երթևեկությունը հասնում է հավասարակշռողին, որը դրանից հանում է IPv4 ռեսուրսի հասցեն, փոխարինում է IPv6-ին IPv4-ով և փաթեթն ուղարկում օգտագործողի ցանց:

Հակադարձ տրաֆիկը նույն կերպ է ընթանում. հավասարակշռողը տեսնում է, որ նպատակակետը առողջության ստուգիչներից մոխրագույն ցանց է, և IPv4-ը փոխակերպում է IPv6-ի:

VPP - տվյալների հարթության սիրտը

Հավասարակշռիչն իրականացվում է Vector Packet Processing (VPP) տեխնոլոգիայի միջոցով, որը Cisco-ի շրջանակն է՝ ցանցային տրաֆիկի խմբաքանակային մշակման համար: Մեր դեպքում շրջանակն աշխատում է օգտատերերի տարածության ցանցի սարքի կառավարման գրադարանի վերևում՝ Data Plane Development Kit (DPDK): Սա ապահովում է փաթեթների մշակման բարձր արդյունավետություն. միջուկում շատ ավելի քիչ ընդհատումներ են տեղի ունենում, և միջուկի տարածության և օգտագործողի տարածության միջև կոնտեքստային փոխարկիչներ չկան: 

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

Օրինակ, IP փաթեթների մշակումը VPP-ում տեղի է ունենում հետևյալ հաջորդականությամբ. սկզբում փաթեթների վերնագրերը վերլուծվում են վերլուծական հանգույցում, այնուհետև դրանք ուղարկվում են հանգույց, որը փաթեթները հետագայում փոխանցում է ըստ երթուղային աղյուսակների:

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

n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
    vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
    // ...
    while (n_left_from >= 4 && n_left_to_next >= 2)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            vlib_buffer_t *p2, *p3;

            p2 = vlib_get_buffer (vm, from[2]);
            p3 = vlib_get_buffer (vm, from[3]);

            vlib_prefetch_buffer_header (p2, LOAD);
            vlib_prefetch_buffer_header (p3, LOAD);

            CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
            CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                to_next, n_left_to_next,
                bi0, bi1, next0, next1);
    }

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

Այսպիսով, Healthchecks-ը խոսում է IPv6-ի միջոցով VPP-ի հետ, որը դրանք վերածում է IPv4-ի: Դա արվում է գրաֆիկի մի հանգույցի միջոցով, որը մենք անվանում ենք ալգորիթմական NAT: Հակադարձ տրաֆիկի համար (և IPv6-ից IPv4-ի փոխակերպում) կա նույն ալգորիթմական NAT հանգույցը:

Հավասարակշռող հաճախորդների ուղիղ երթևեկությունը անցնում է գրաֆիկական հանգույցների միջով, որոնք ինքնին կատարում են հավասարակշռումը: 

Առաջին հանգույցը կպչուն նիստերն են: Այն պահպանում է հաշը 5 - կրկնակի հաստատված նիստերի համար։ 5-tuple-ը ներառում է հաճախորդի հասցեն և նավահանգիստը, որտեղից տեղեկատվությունը փոխանցվում է, տրաֆիկ ստանալու համար հասանելի ռեսուրսների հասցեն և նավահանգիստները, ինչպես նաև ցանցի արձանագրությունը: 

5 կրկնակի հեշը օգնում է մեզ ավելի քիչ հաշվարկներ կատարել հետագա հետևողական հեշավորման հանգույցում, ինչպես նաև ավելի լավ կարգավորել ռեսուրսների ցանկի փոփոխությունները հավասարակշռողի հետևում: Երբ փաթեթը, որի համար նիստ չկա, հասնում է հավասարակշռողին, այն ուղարկվում է հետևողական հեշավորման հանգույց: Այստեղ է, որ հավասարակշռումը տեղի է ունենում հետևողական հեշինգի միջոցով. մենք ընտրում ենք ռեսուրս առկա «կենդանի» ռեսուրսների ցանկից: Այնուհետև փաթեթներն ուղարկվում են NAT հանգույց, որն իրականում փոխարինում է նպատակակետի հասցեն և վերահաշվարկում ստուգիչ գումարները: Ինչպես տեսնում եք, մենք հետևում ենք VPP-ի կանոններին՝ հավանել, խմբավորելով նմանատիպ հաշվարկներ՝ պրոցեսորի քեշերի արդյունավետությունը բարձրացնելու համար:

Հետևողական հեշինգ

Ինչու՞ մենք ընտրեցինք այն և ինչ է դա նույնիսկ: Նախ, եկեք դիտարկենք նախորդ առաջադրանքը` ցանկից ռեսուրս ընտրելը: 

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

Հետևողական հեշավորումը լուծում է նկարագրված խնդիրը: Այս հայեցակարգը բացատրելու ամենահեշտ ձևը հետևյալն է. պատկերացրեք, որ դուք ունեք մի օղակ, որին ռեսուրսները բաժանում եք հեշի միջոցով (օրինակ՝ IP:port-ով): Ռեսուրս ընտրելը անիվի պտտումն է անկյան տակ, որը որոշվում է փաթեթի հեշով:

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

Մենք նայեցինք, թե ինչ է տեղի ունենում հավասարակշռողի և ռեսուրսների միջև ուղիղ երթևեկության հետ: Հիմա եկեք նայենք վերադարձի երթեւեկությանը: Այն հետևում է նույն օրինաչափությանը, ինչ ստուգիչ երթևեկությունը՝ ալգորիթմական NAT-ի միջոցով, այսինքն՝ հակառակ NAT 44-ի միջոցով՝ հաճախորդի տրաֆիկի և NAT 46-ի միջոցով՝ առողջության ստուգումների տրաֆիկի համար: Մենք հավատարիմ ենք մեր սեփական սխեմային. մենք միավորում ենք առողջության ստուգումների տրաֆիկը և իրական օգտագործողների տրաֆիկը:

Loadbalancer-հանգույց և հավաքված բաղադրիչներ

VPP-ում հավասարակշռողների և ռեսուրսների կազմը հաղորդում է տեղական ծառայությունը` loadbalancer-node: Այն բաժանորդագրվում է իրադարձությունների հոսքին loadbalancer-controller-ից և ի վիճակի է պատկերել տարբերությունը ընթացիկ VPP վիճակի և վերահսկիչից ստացված թիրախային վիճակի միջև: Մենք ստանում ենք փակ համակարգ. API-ից իրադարձությունները գալիս են հավասարակշռող վերահսկիչին, որը հանձնարարում է խնդիրներ առողջապահական ստուգման վերահսկիչին՝ ստուգելու ռեսուրսների «կենդանությունը»: Դա, իր հերթին, հանձնարարում է առաջադրանքներ առողջության ստուգման հանգույցին և միավորում արդյունքները, որից հետո դրանք հետ է ուղարկում հավասարակշռող վերահսկիչին: Loadbalancer-node-ը բաժանորդագրվում է վերահսկիչի իրադարձություններին և փոխում է VPP-ի վիճակը: Նման համակարգում յուրաքանչյուր ծառայություն գիտի միայն այն, ինչ անհրաժեշտ է հարևան ծառայությունների մասին: Միացումների թիվը սահմանափակ է, և մենք ունենք տարբեր հատվածներ ինքնուրույն գործելու և մասշտաբավորելու հնարավորություն:

Ի՞նչ խնդիրներ են խուսափել։

Կառավարման հարթության մեր բոլոր ծառայությունները գրված են Go-ում և ունեն լավ չափման և հուսալիության բնութագրեր: Go-ն ունի բազմաթիվ բաց կոդով գրադարաններ՝ բաշխված համակարգեր կառուցելու համար: Մենք ակտիվորեն օգտագործում ենք GRPC-ն, բոլոր բաղադրիչները պարունակում են ծառայության հայտնաբերման բաց կոդով իրականացում. մեր ծառայությունները վերահսկում են միմյանց կատարողականը, կարող են դինամիկ կերպով փոխել իրենց կազմը, և մենք դա կապել ենք GRPC հավասարակշռման հետ: Չափումների համար մենք նաև օգտագործում ենք բաց կոդով լուծում: Տվյալների հարթությունում մենք ստացանք արժանապատիվ կատարում և մեծ ռեսուրսների պաշար. պարզվեց, որ շատ դժվար է հավաքել մի ստենդ, որի վրա մենք կարող ենք ապավինել VPP-ի աշխատանքին, այլ ոչ թե երկաթյա ցանցային քարտին:

Խնդիրներ և լուծումներ

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

Բացի այդ, Go-ն չի կարող լավագույն ընտրությունը լինել ֆունկցիոնալ թեստերի համար: Նրանք բավականին խոսուն են, և «ամեն ինչ CI-ում խմբաքանակով գործարկելու» ստանդարտ մոտեցումն այնքան էլ հարմար չէ նրանց համար: Փաստն այն է, որ ֆունկցիոնալ թեստերն ավելի շատ ռեսուրսներ են պահանջում և իրական ժամանակամիջոցներ են առաջացնում: Դրա պատճառով թեստերը կարող են ձախողվել, քանի որ պրոցեսորը զբաղված է միավորի թեստերով: Եզրակացություն. Եթե հնարավոր է, կատարեք «ծանր» թեստեր առանձին միավորի թեստերից: 

Միկրոսպասարկման միջոցառումների ճարտարապետությունն ավելի բարդ է, քան մոնոլիտը. տասնյակ տարբեր մեքենաների վրա տեղեկամատյաններ հավաքելը այնքան էլ հարմար չէ: Եզրակացություն. եթե դուք միկրոծառայություններ եք անում, անմիջապես մտածեք հետագծման մասին:

Մեր ծրագրերը

Մենք կգործարկենք ներքին հավասարակշռող՝ IPv6 հավասարակշռող, կավելացնենք աջակցություն Kubernetes-ի սկրիպտներին, կշարունակենք կիսել մեր ծառայությունները (ներկայումս միայն healthcheck-node-ն ու healthcheck-ctrl-ը մասնատված են), կավելացնենք առողջության նոր ստուգումներ, ինչպես նաև կիրականացնենք ստուգումների խելացի համախմբում: Մենք դիտարկում ենք մեր ծառայություններն էլ ավելի անկախ դարձնելու հնարավորությունը, որպեսզի նրանք շփվեն ոչ թե ուղղակիորեն միմյանց հետ, այլ օգտագործելով հաղորդագրությունների հերթ: Վերջերս Cloud-ում հայտնվել է SQS-ի հետ համատեղելի ծառայություն Yandex հաղորդագրությունների հերթ.

Վերջերս տեղի ունեցավ Yandex Load Balancer-ի հրապարակային թողարկումը։ Հետազոտել փաստաթղթեր ծառայությանը, կառավարեք հավասարակշռող սարքերը ձեզ համար հարմար ձևով և բարձրացրեք ձեր նախագծերի սխալների հանդուրժողականությունը:

Source: www.habr.com