Բարև, ես Սերգեյ Էլանցևն եմ, ես զարգացնում եմ
Նախ, եկեք ներկայացնենք մի քանի տերմիններ.
- 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-ում, ինչպես մենք արդեն
Եկեք վերադառնանք հավասարակշռող վերահսկիչին: Դրա խնդիրն է պահպանել հավասարակշռողի մասին տեղեկատվությունը և վիրտուալ մեքենայի պատրաստվածությունը ստուգելու առաջադրանք ուղարկել առողջության ստուգման վերահսկիչին:
Առողջության ստուգման վերահսկիչ
Այն ստանում է ստուգման կանոնները փոխելու հարցումներ, դրանք պահպանում է YDB-ում, բաշխում է առաջադրանքները առողջական ստուգման հանգույցների միջև և միավորում արդյունքները, որոնք այնուհետև պահվում են տվյալների բազայում և ուղարկվում loadbalancer վերահսկիչին: Այն, իր հերթին, տվյալների հարթության մեջ կլաստերի կազմը փոխելու հարցում է ուղարկում loadbalancer-node, որը ես կքննարկեմ ստորև։
Եկեք ավելին խոսենք առողջության ստուգումների մասին: Դրանք կարելի է բաժանել մի քանի դասերի. Աուդիտներն ունեն հաջողության տարբեր չափանիշներ: TCP ստուգումները պետք է հաջողությամբ հաստատեն կապը ֆիքսված ժամանակի ընթացքում: HTTP ստուգումները պահանջում են և՛ հաջող միացում, և՛ 200 կարգավիճակի կոդով պատասխան:
Բացի այդ, ստուգումները տարբերվում են գործողությունների դասից՝ դրանք ակտիվ են և պասիվ: Պասիվ ստուգումները պարզապես վերահսկում են, թե ինչ է կատարվում երթևեկության հետ՝ առանց որևէ հատուկ գործողություն ձեռնարկելու: Սա այնքան էլ լավ չի աշխատում L4-ի վրա, քանի որ դա կախված է ավելի բարձր մակարդակի արձանագրությունների տրամաբանությունից. L4-ում տեղեկություններ չկան, թե որքան ժամանակ է տևել գործողությունը կամ կապի ավարտը լավ է եղել, թե վատ: Ակտիվ ստուգումները պահանջում են, որ հավասարակշռողը հարցումներ ուղարկի յուրաքանչյուր սերվերի օրինակին:
Բեռի հավասարակշռողներից շատերն իրենք են կատարում աշխուժության ստուգումներ: Cloud-ում մենք որոշեցինք առանձնացնել համակարգի այս հատվածները՝ մասշտաբայնությունը մեծացնելու համար: Այս մոտեցումը թույլ կտա մեզ ավելացնել հավասարակշռողների թիվը՝ միաժամանակ պահպանելով ծառայությանն ուղղված առողջության ստուգման հարցումների քանակը: Ստուգումները կատարվում են առողջության ստուգման առանձին հանգույցներով, որոնց միջով ստուգման թիրախները բաժանվում և կրկնօրինակվում են: Դուք չեք կարող ստուգումներ կատարել մեկ հոսթից, քանի որ այն կարող է ձախողվել: Այդ ժամանակ մենք չենք ստանա իր ստուգած ատյանների վիճակը։ Մենք ստուգումներ ենք իրականացնում առնվազն երեք առողջության ստուգման հանգույցներից որևէ մեկի վրա: Մենք կիսում ենք հանգույցների միջև ստուգումների նպատակները՝ օգտագործելով հետևողական հեշավորման ալգորիթմներ:
Հավասարակշռության և առողջության ստուգման տարանջատումը կարող է հանգեցնել խնդիրների: Եթե առողջության ստուգման հանգույցը հարցումներ է կատարում ատյան՝ շրջանցելով հավասարակշռողին (որը ներկայումս չի սպասարկում երթևեկությունը), ապա տարօրինակ իրավիճակ է առաջանում՝ ռեսուրսը կարծես կենդանի է, բայց տրաֆիկը դրան չի հասնի։ Մենք այս խնդիրը լուծում ենք այսպես. Այլ կերպ ասած, հաճախորդներից և առողջապահական ստուգումներից տրաֆիկով փաթեթների տեղափոխման սխեման մինիմալ տարբերվում է. երկու դեպքում էլ փաթեթները կհասնեն հավասարակշռողներին, որոնք դրանք կհասցնեն թիրախային ռեսուրսներին:
Տարբերությունն այն է, որ հաճախորդները հարցումներ են կատարում VIP-ին, մինչդեռ առողջապահական ստուգումները հարցումներ են կատարում յուրաքանչյուր առանձին RIP-ի համար: Այստեղ մի հետաքրքիր խնդիր է առաջանում՝ մենք մեր օգտատերերին հնարավորություն ենք տալիս ռեսուրսներ ստեղծել գորշ IP ցանցերում։ Եկեք պատկերացնենք, որ կան երկու տարբեր ամպի սեփականատերեր, ովքեր թաքցրել են իրենց ծառայությունները հավասարակշռողների հետևում: Նրանցից յուրաքանչյուրն ունի ռեսուրսներ 10.0.0.1/24 ենթացանցում՝ նույն հասցեներով։ Դուք պետք է կարողանաք ինչ-որ կերպ տարբերել դրանք, և այստեղ դուք պետք է սուզվեք Yandex.Cloud վիրտուալ ցանցի կառուցվածքի մեջ: Ավելի լավ է ավելին իմանալ այստեղ
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 կրկնակի հեշը օգնում է մեզ ավելի քիչ հաշվարկներ կատարել հետագա հետևողական հեշավորման հանգույցում, ինչպես նաև ավելի լավ կարգավորել ռեսուրսների ցանկի փոփոխությունները հավասարակշռողի հետևում: Երբ փաթեթը, որի համար նիստ չկա, հասնում է հավասարակշռողին, այն ուղարկվում է հետևողական հեշավորման հանգույց: Այստեղ է, որ հավասարակշռումը տեղի է ունենում հետևողական հեշինգի միջոցով. մենք ընտրում ենք ռեսուրս առկա «կենդանի» ռեսուրսների ցանկից: Այնուհետև փաթեթներն ուղարկվում են 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 Load Balancer-ի հրապարակային թողարկումը։ Հետազոտել
Source: www.habr.com