Բարեւ Ձեզ! Ես Վադիմ Մեդիսոնն եմ, ես ղեկավարում եմ Avito System Platform-ի զարգացումը: Մեկ անգամ չէ, որ ասվել է, թե ինչպես ենք մենք ընկերությունում մոնոլիտ ճարտարապետությունից տեղափոխվում միկրոսերվիսային: Ժամանակն է կիսվել, թե ինչպես ենք մենք փոխակերպել մեր ենթակառուցվածքը՝ միկրոծառայություններից առավելագույն օգուտ քաղելու և դրանցում չկորցնելու համար: Ինչպես է PaaS-ն օգնում մեզ այստեղ, ինչպես ենք մենք պարզեցրել տեղակայումը և կրճատել միկրոսերվիսի ստեղծումը մինչև մեկ սեղմում. շարունակեք կարդալ: Այն ամենը, ինչի մասին գրում եմ ստորև, ամբողջությամբ չի իրականացվում Avito-ում, դրա մի մասն այն է, թե ինչպես ենք մենք զարգացնում մեր հարթակը:

(Եվ այս հոդվածի վերջում ես կխոսեմ միկրոսերվիսների ճարտարապետության փորձագետ Քրիս Ռիչարդսոնի եռօրյա սեմինարին մասնակցելու հնարավորության մասին):

Ինչպես եկանք միկրոսերվիսներին

Avito-ն աշխարհի խոշորագույն գաղտնագրված կայքերից մեկն է, որի վրա օրական հրապարակվում է ավելի քան 15 միլիոն նոր գովազդ։ Մեր backend-ը վայրկյանում ընդունում է ավելի քան 20 հազար հարցում: Ներկայումս մենք ունենք մի քանի հարյուր միկրոսերվիսներ։

Արդեն մի քանի տարի է, ինչ մենք կառուցում ենք միկրոսերվիսային ճարտարապետություն։ Ինչպես կոնկրետ - մեր գործընկերները մանրամասն ասաց RIT++ 2017-ի մեր բաժնում: CodeFest 2017-ում (տես. video), Սերգեյ Օռլովը և Միխայիլ Պրոկոպչուկը մանրամասն բացատրեցին, թե ինչու էր մեզ անհրաժեշտ անցումը միկրոծառայությունների և ինչ դեր է խաղացել այստեղ Կուբերնետեսը։ Դե, հիմա մենք ամեն ինչ անում ենք, որպեսզի նվազագույնի հասցնենք մասշտաբային ծախսերը, որոնք բնորոշ են նման ճարտարապետությանը:

Ի սկզբանե մենք չստեղծեցինք էկոհամակարգ, որը համակողմանիորեն կօգնի մեզ զարգացնել և գործարկել միկրոծառայություններ: Նրանք պարզապես հավաքեցին բաց կոդով խելամիտ լուծումներ, գործարկեցին դրանք տանը և ծրագրավորողին հրավիրեցին զբաղվել դրանցով: Արդյունքում նա գնաց մի տասնյակ վայրեր (վահանակներ, ներքին ծառայություններ), որից հետո ավելի ուժեղացավ կոդերը հին ձևով՝ մոնոլիտ կտրելու ցանկությամբ։ Ստորև բերված դիագրամների կանաչ գույնը ցույց է տալիս, թե ինչ է մշակողը այս կամ այն ​​կերպ անում իր ձեռքերով, իսկ դեղին գույնը ցույց է տալիս ավտոմատացում:

Այժմ PaaS CLI կոմունալում նոր ծառայություն է ստեղծվում մեկ հրամանով, և նոր տվյալների բազա է ավելացվում ևս երկուսով և տեղակայվում Stage-ում:

Ինչպես հաղթահարել «միկրոծառայությունների մասնատման» դարաշրջանը.

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

Բացի այդ, միկրոծառայությունների ճարտարապետությունը արդյունավետ լինելու համար անհրաժեշտ է ստեղծել բազմաթիվ գործընթացներ, մասնավորապես.

• անտառահատումներ;
• հարցումների հետագծում (Jaeger);
• սխալների համախմբում (Sentry);
• կարգավիճակներ, հաղորդագրություններ, իրադարձություններ Kubernetes-ից (Իրադարձությունների հոսքի մշակում);
• մրցավազքի սահմանաչափ / անջատիչ (կարող եք օգտագործել Hystrix);
• ծառայության կապի վերահսկում (մենք օգտագործում ենք Netramesh);
• մոնիտորինգ (Գրաֆանա);
• հավաքում (TeamCity);
• հաղորդակցություն և ծանուցում (Slack, email);
• առաջադրանքների հետևում; (Ժիրա)
• փաստաթղթերի պատրաստում.

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

Ինչպես ենք մենք կառավարում միկրոծառայությունները

Հետևյալն օգնում է իրականացնել միասնական «կուսակցական քաղաքականություն» Avito-ի բազմաթիվ միկրոծառայությունների միջև.

• ենթակառուցվածքների բաժանում շերտերի;
• Պլատֆորմը որպես ծառայություն (PaaS) հայեցակարգ;
• վերահսկել այն ամենը, ինչ տեղի է ունենում միկրոսերվիսների հետ:

Ենթակառուցվածքի աբստրակցիոն շերտերը ներառում են երեք շերտ. Եկեք գնանք վերևից ներքև:

A. Վերև - սպասարկման ցանց: Սկզբում փորձեցինք Istio-ն, բայց պարզվեց, որ այն չափազանց շատ ռեսուրսներ է օգտագործում, ինչը չափազանց թանկ է մեր ծավալների համար։ Հետևաբար, ճարտարապետության թիմի ավագ ինժեներ Ալեքսանդր Լուկյանչենկոն մշակեց իր լուծումը. Նետրամեշ (հասանելի է Open Source-ում), որը մենք ներկայումս օգտագործում ենք արտադրության մեջ և որը մի քանի անգամ ավելի քիչ ռեսուրսներ է սպառում, քան Istio-ն (բայց չի անում այն ​​ամենը, ինչով կարող է պարծենալ Istio-ն):
B. Միջին - Kubernetes. Մենք դրա վրա տեղադրում և գործարկում ենք միկրոսերվիսներ:
C. Ստորին - մերկ մետաղ: Մենք չենք օգտագործում ամպեր կամ այնպիսի բաներ, ինչպիսիք են OpenStack-ը, այլ ամբողջովին ապավինում ենք մերկ մետաղին:

Բոլոր շերտերը համակցված են PaaS-ով: Իսկ այս հարթակը իր հերթին բաղկացած է երեք մասից.

I. Գեներատորներ, կառավարվում է CLI կոմունալ ծրագրի միջոցով: Նա է, ով օգնում է մշակողին ստեղծել միկրոսերվիս ճիշտ ձևով և նվազագույն ջանքերով:

II. Համախմբված կոլեկցիոներ բոլոր գործիքների կառավարմամբ ընդհանուր վահանակի միջոցով:

III. Պահպանում. Միանում է ժամանակացույցերի հետ, որոնք ավտոմատ կերպով սահմանում են նշանակալի գործողությունների գործարկիչներ: Նման համակարգի շնորհիվ ոչ մի խնդիր բաց չի թողնվել միայն այն պատճառով, որ ինչ-որ մեկը մոռացել է առաջադրանք տեղադրել Ժիրայում: Դրա համար մենք օգտագործում ենք Atlas կոչվող ներքին գործիք:

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

Ինչպե՞ս է աշխատում ստանդարտ միկրոծառայությունների զարգացման խողովակաշարը:

Ընդհանուր առմամբ, միկրոծառայությունների ստեղծման շղթան այսպիսի տեսք ունի.

CLI-push → Continuous Integration → Bake → Deploy → Artificial tests → Canary tests → Squeeze Testing → Production → Maintenance:

Անցնենք դրա միջով հենց այս հերթականությամբ։

CLI-հրում

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

Ի վերջո, մենք կառուցեցինք մի պարզ CLI օգտակար ծրագիր, որն ավտոմատացնում է հիմնական քայլերը միկրոսերվիս ստեղծելիս: Փաստորեն, այն փոխարինում է առաջին git push-ին: Ահա թե կոնկրետ ինչ է նա անում.

— Ստեղծում է ծառայություն ըստ ձևանմուշի — քայլ առ քայլ, «վիզարդ» ռեժիմով: Մենք Avito backend-ի հիմնական ծրագրավորման լեզուների ձևանմուշներ ունենք՝ PHP, Golang և Python:

- Մեկ հրամանը միաժամանակ տեղակայում է միջավայր տեղական զարգացման համար կոնկրետ մեքենայի վրա. Minikube-ն գործարկվում է, Helm գծապատկերները ավտոմատ կերպով ստեղծվում և գործարկվում են տեղական kubernetes-ում:

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

— Այն ինքնին կատարում է կենդանի հավաքում: Ենթադրենք, մշակողը իր IDE-ի միջոցով ինչ-որ բան ուղղել է միկրոսերվիսում։ Կոմունալը տեսնում է փոփոխություններ ֆայլային համակարգում և, դրանց հիման վրա, վերակառուցում է հավելվածը (Գոլանգի համար) և վերագործարկում: PHP-ի համար մենք պարզապես փոխանցում ենք գրացուցակը խորանարդի ներսում և այնտեղ «ավտոմատ կերպով» ստացվում է «live-reload»:

— Առաջացնում է ավտոմատ թեստեր: Բլանկների տեսքով, բայց օգտագործման համար բավականին հարմար։

• Միկրոծառայությունների տեղակայում.

Միկրոսերվիսի տեղակայումը նախկինում մեզ համար մի փոքր գործ էր: Պահանջվում էին հետևյալը.

I. Dockerfile.

II. Կազմաձև
III. Սաղավարտի աղյուսակը, որն ինքնին ծանրաբեռնված է և ներառում է.

- գծապատկերներն իրենք են;
- կաղապարներ;
— հատուկ արժեքներ՝ հաշվի առնելով տարբեր միջավայրեր։

Մենք վերացրել ենք Kubernetes-ի մանիֆեստների վերամշակման ցավը, ուստի դրանք այժմ ավտոմատ կերպով ստեղծվում են: Բայց ամենակարևորը, նրանք պարզեցրել են տեղակայումը մինչև սահմանը: Այսուհետ մենք ունենք Dockerfile, և մշակողը գրում է ամբողջ կազմաձևը մեկ կարճ app.toml ֆայլում:

Այո, և app.toml-ում մեկ րոպե անելու բան չկա: Մենք նշում ենք, թե ծառայության որտեղ և քանի օրինակ պետք է բարձրացվի (ծրագրավորող սերվերի վրա, բեմադրության վրա, արտադրության մեջ) և նշում ենք դրա կախվածությունը: Ուշադրություն դարձրեք [շարժիչի] բլոկում գծի չափը = «small»: Սա այն սահմանն է, որը կհատկացվի ծառայությանը Kubernetes-ի միջոցով:

Այնուհետև, կոնֆիգուրացիայի հիման վրա, բոլոր անհրաժեշտ Helm գծապատկերները ավտոմատ կերպով ստեղծվում են և ստեղծվում են կապեր տվյալների բազաների հետ:

• Հիմնական վավերացում. Նման ստուգումները նույնպես ավտոմատացված են։
Պետք է հետևել.
— կա՞ Dockerfile;
— կա app.toml;
- Կա՞ն փաստաթղթեր:
- կախվածությունը կարգի՞ն է:
- սահմանվել են արդյոք զգուշացման կանոններ:
Մինչև վերջին կետը. ծառայության սեփականատերն ինքն է որոշում, թե որ արտադրանքի չափումները պետք է վերահսկվեն:

• Փաստաթղթերի պատրաստում.
Դեռևս խնդրահարույց տարածք: Թվում է, թե դա ամենաակնհայտն է, բայց միևնույն ժամանակ նաև «հաճախ մոռացված» ռեկորդ է, հետևաբար՝ շղթայի խոցելի օղակ։
Անհրաժեշտ է, որ յուրաքանչյուր միկրոծառայության համար լինի փաստաթղթեր: Այն ներառում է հետևյալ բլոկները.

I. Ծառայության համառոտ նկարագրությունը. Բառացիորեն մի քանի նախադասություն այն մասին, թե ինչ է դա անում և ինչու է դա անհրաժեշտ:

II. Ճարտարապետության դիագրամի հղում. Կարևոր է, որ արագ հայացքով հեշտ լինի հասկանալ, օրինակ, արդյոք դուք օգտագործում եք Redis-ը քեշավորման համար, թե որպես տվյալների հիմնական պահեստ՝ մշտական ​​ռեժիմում: In Avito-ում այս պահին սա հղում է Confluence-ին:

III. Runbook. Ծառայությունը սկսելու և դրա հետ կապված բարդությունների մասին կարճ ուղեցույց:

IV. ՀՏՀ, որտեղ լավ կլինի կանխատեսել այն խնդիրները, որոնց կարող են հանդիպել ձեր գործընկերները ծառայության հետ աշխատելիս։

V. API-ի վերջնակետերի նկարագրությունը. Եթե ​​հանկարծ չնշեցիք ուղղությունները, գործընկերները, որոնց միկրոծառայությունները կապված են ձեր հետ, գրեթե անկասկած կվճարեն դրա համար: Այժմ մենք օգտագործում ենք Swagger-ը և մեր լուծումը, որը կոչվում է կարճ դրա համար:

VI. Պիտակներ. Կամ մարկերներ, որոնք ցույց են տալիս, թե ընկերության որ արտադրանքին, ֆունկցիոնալությանը կամ կառուցվածքային բաժինին է պատկանում ծառայությունը: Նրանք օգնում են ձեզ արագ հասկանալ, օրինակ, արդյոք դուք կրճատում եք ֆունկցիոնալությունը, որը մեկ շաբաթ առաջ ձեր գործընկերները ներկայացրել են նույն բիզնես միավորի համար:

VII. Ծառայության սեփականատերը կամ սեփականատերերը. Շատ դեպքերում դա կամ դրանք կարող են ինքնաբերաբար որոշվել PaaS-ի միջոցով, սակայն ապահով կողմում լինելու համար մենք պահանջում ենք, որ մշակողը դրանք ձեռքով նշի:

Վերջապես, լավ պրակտիկա է վերանայել փաստաթղթերը, ինչպես կոդերի վերանայումը:

Շարունակական ինտեգրում

• Պահեստների պատրաստում.
• TeamCity-ում խողովակաշարի ստեղծում:
• Իրավունքների կարգավորում:
• Ծառայությունների սեփականատերերի որոնում: Այստեղ կա հիբրիդային սխեմա՝ ձեռքով նշում և նվազագույն ավտոմատացում PaaS-ից: Լիովին ավտոմատ սխեման ձախողվում է, երբ ծառայություններն աջակցության համար փոխանցվում են մեկ այլ զարգացման թիմին կամ, օրինակ, եթե ծառայության մշակողը դուրս է գալիս:
• Ծառայության գրանցում Atlas-ում (տես վերեւում). Իր բոլոր տերերով ու կախվածություններով։
• Միգրացիաների ստուգում: Մենք ստուգում ենք՝ արդյոք դրանցից որևէ մեկը պոտենցիալ վտանգավոր է։ Օրինակ, դրանցից մեկում հայտնվում է փոփոխվող աղյուսակ կամ այլ բան, որը կարող է կոտրել տվյալների սխեմայի համատեղելիությունը ծառայության տարբեր տարբերակների միջև: Այնուհետև միգրացիան չի կատարվում, այլ տեղադրվում է բաժանորդագրության մեջ. PaaS-ը պետք է ազդանշան տա ծառայության սեփականատիրոջը, երբ այն անվտանգ է օգտագործել:

Թխել

Հաջորդ փուլը փաթեթավորման ծառայություններն են մինչև տեղակայումը:

• Հավելվածի կառուցում. Ըստ դասականների՝ Docker պատկերով։
• Ինքն ծառայության և հարակից ռեսուրսների համար Helm գծապատկերների ստեղծում: Ներառյալ տվյալների բազաների և քեշի համար: Դրանք ստեղծվում են ավտոմատ կերպով՝ համաձայն app.toml կազմաձևի, որը ստեղծվել է CLI-push փուլում:
• Տոմսերի ստեղծում ադմինների համար՝ նավահանգիստները բացելու համար (երբ պահանջվում է):
• Միավորի թեստերի իրականացում և կոդի ծածկույթի հաշվարկ. Եթե ​​ծածկագրի ծածկույթը նշված շեմից ցածր է, ապա, ամենայն հավանականությամբ, ծառայությունը չի գնա ավելի հեռու՝ տեղակայման: Եթե ​​այն գտնվում է ընդունելի շեմին, ապա ծառայությանը կնշանակվի «հոռետեսացնող» գործակից. այնուհետև, եթե ժամանակի ընթացքում ցուցանիշի բարելավում չլինի, ծրագրավորողը ծանուցում կստանա, որ թեստերի առումով առաջընթաց չկա ( և պետք է ինչ-որ բան անել դրա դեմ):
• Հիշողության և պրոցեսորի սահմանափակումների հաշվառում. Մենք հիմնականում գրում ենք միկրոսերվիսներ Golang-ում և դրանք գործարկում ենք Kubernetes-ում: Ուստի մեկ նրբություն կապված է Golang լեզվի յուրահատկության հետ. լռելյայնորեն, երբ գործարկվում է, օգտագործվում են մեքենայի բոլոր միջուկները, եթե դուք հստակորեն չեք սահմանում GOMAXPROCS փոփոխականը, և երբ մի քանի նման ծառայություններ գործարկվում են նույն մեքենայի վրա, դրանք սկսվում են: մրցակցել ռեսուրսների համար՝ միջամտելով միմյանց: Ստորև բերված գրաֆիկները ցույց են տալիս, թե ինչպես է փոխվում կատարման ժամանակը, եթե դուք գործարկում եք հավելվածը առանց վիճաբանության և ռեսուրսների համար մրցավազքի ռեժիմում: (Գծապատկերների աղբյուրներն են այստեղ).

Կատարման ժամանակը, ավելի քիչ, ավելի լավ: Առավելագույնը՝ 643 մս, նվազագույնը՝ 42 մվ: Լուսանկարը սեղմելի է:

Վիրահատության ժամանակն է, ավելի լավ է ավելի քիչ: Առավելագույնը՝ 14091 նս, նվազագույնը՝ 151 նս։ Լուսանկարը սեղմելի է:

Հավաքման նախապատրաստման փուլում դուք կարող եք հստակորեն սահմանել այս փոփոխականը կամ կարող եք օգտագործել գրադարանը automaxprocs Uber-ի տղաներից։

Տեղակայել

• Կոնվենցիաների ստուգում: Նախքան սկսեք մատուցել սպասարկման հավաքները ձեր նախատեսված միջավայրերին, դուք պետք է ստուգեք հետևյալը.
- API-ի վերջնակետեր:
— API-ի վերջնակետերի պատասխանների համապատասխանությունը սխեմային:
- Մատյանների ձևաչափ:
— Ծառայության հարցումների վերնագրերի կարգավորում (ներկայումս դա արվում է netramesh-ի միջոցով)
— Իրադարձությունների ավտոբուսին հաղորդագրություններ ուղարկելիս սեփականատիրոջ նշանի սահմանում: Սա անհրաժեշտ է ավտոբուսի միջոցով ծառայությունների միացմանը հետևելու համար: Դուք կարող եք ավտոբուս ուղարկել և՛ անիմաստ տվյալներ, որոնք չեն մեծացնում ծառայությունների կապը (ինչը լավ է), և՛ բիզնես տվյալներ, որոնք ուժեղացնում են ծառայությունների կապը (ինչը շատ վատ է): Եվ այն պահին, երբ այս կապը դառնում է խնդիր, հասկանալը, թե ով է գրում և կարդում ավտոբուսը, օգնում է պատշաճ կերպով առանձնացնել ծառայությունները:

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

Սինթետիկ թեստեր

• Փակ օղակի փորձարկում. Դրա համար մենք այժմ օգտագործում ենք բաց կոդով Hoverfly.io. Նախ, այն գրանցում է ծառայության իրական ծանրաբեռնվածությունը, այնուհետև, պարզապես փակ հանգույցով, այն ընդօրինակում է այն:

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

Բեռի փորձարկման ժամանակ մենք ստուգում ենք, թե արդյոք ռեսուրսի սպառումը համապատասխանում է սահմանված սահմաններին: Եվ մենք կենտրոնանում ենք առաջին հերթին ծայրահեղությունների վրա:

ա) Մենք նայում ենք ընդհանուր բեռին.
- Շատ փոքր - ամենայն հավանականությամբ, ինչ-որ բան ընդհանրապես չի աշխատում, եթե բեռը հանկարծ մի քանի անգամ իջնի:
- Չափազանց մեծ - պահանջվում է օպտիմալացում:

բ) Մենք դիտարկում ենք կտրվածքն ըստ RPS-ի:
Այստեղ մենք նայում ենք ընթացիկ տարբերակի և նախորդի տարբերությանը և ընդհանուր քանակին: Օրինակ, եթե սերվիսը 100 ռ/վ է արտադրում, ուրեմն կամ վատ է գրված, կամ սա է նրա յուրահատկությունը, բայց ամեն դեպքում, սա պատճառ է սերվիսին շատ ուշադիր նայելու։
Եթե, ընդհակառակը, կան չափազանց շատ RPS, ապա միգուցե ինչ-որ վրիպակ կա, և որոշ վերջնակետեր դադարել են կատարել ծանրաբեռնվածությունը, իսկ մյուսները պարզապես գործարկվել են: return true;

Կանարյան թեստեր

Սինթետիկ թեստերն անցնելուց հետո միկրոսերվիսը փորձարկում ենք փոքր թվով օգտատերերի վրա։ Մենք սկսում ենք ուշադիր, ծառայության նախատեսված լսարանի չնչին մասնաբաժնով` 0,1%-ից պակաս: Այս փուլում շատ կարևոր է, որ մոնիտորինգում ներառվեն ճիշտ տեխնիկական և ապրանքային չափումներ, որպեսզի հնարավորինս արագ ցույց տան խնդիրը ծառայության մեջ։ Դեղձանիկի թեստի նվազագույն ժամանակը 5 րոպե է, հիմնականը՝ 2 ժամ։ Բարդ ծառայությունների համար մենք ժամանակը սահմանում ենք ձեռքով:
Եկեք վերլուծենք.
— լեզվին հատուկ չափումներ, մասնավորապես, php-fpm աշխատողներ.
- սխալներ Sentry-ում;
- արձագանքման կարգավիճակները;
- արձագանքման ժամանակը, ճշգրիտ և միջին;
- ուշացում;
- բացառություններ՝ մշակված և չմշակված.
- արտադրանքի չափումներ.

Սեղմման փորձարկում

Սեղմման փորձարկումը կոչվում է նաև «սեղմող» թեստավորում: Տեխնիկայի անվանումը ներդրվել է Netflix-ում։ Դրա էությունն այն է, որ նախ մենք մեկ օրինակը լցնում ենք իրական տրաֆիկով մինչև ձախողման կետ և դրանով իսկ սահմանում դրա սահմանը: Այնուհետև մենք ավելացնում ենք ևս մեկ օրինակ և բեռնում այս զույգը - կրկին առավելագույնը; առաջին «սեղմումով» տեսնում ենք նրանց առաստաղն ու դելտան։ Եվ այսպես, մենք միացնում ենք մեկ օրինակ և հաշվարկում փոփոխությունների օրինաչափությունը:
Փորձարկման տվյալները «սեղմման» միջոցով նույնպես հոսում են ընդհանուր չափման տվյալների բազա, որտեղ մենք կամ հարստացնում ենք արհեստական ​​բեռնվածության արդյունքները դրանցով, կամ նույնիսկ փոխարինում ենք «սինթետիկները» դրանցով:

Արտադրություն

• scaling. Երբ մենք ծառայություն ենք ներկայացնում արտադրության համար, մենք վերահսկում ենք, թե ինչպես է այն մասշտաբավորվում: Մեր փորձով, միայն պրոցեսորի ցուցիչների մոնիտորինգն անարդյունավետ է: Ավտոմատ մասշտաբը RPS-ի չափանիշով իր մաքուր ձևով աշխատում է, բայց միայն որոշ ծառայությունների համար, օրինակ՝ առցանց հոսքային: Այսպիսով, մենք առաջին հերթին նայում ենք կիրառական արտադրանքի չափանիշներին:

Արդյունքում, մասշտաբով մենք վերլուծում ենք.
- CPU և RAM ցուցիչներ,
- հերթում առկա հարցումների քանակը,
- Արձագանքման ժամանակը,
— կանխատեսում` հիմնված կուտակված պատմական տվյալների վրա:

Ծառայությունը մասշտաբավորելիս նաև կարևոր է վերահսկել դրա կախվածությունները, որպեսզի մենք չմեծացնենք շղթայի առաջին ծառայությունը, և նրանք, որոնց նա հասանելի է, ձախողվի ծանրաբեռնվածության տակ: Ծառայությունների ողջ լողավազանի համար ընդունելի ծանրաբեռնվածություն սահմանելու համար մենք նայում ենք «մոտակա» կախված ծառայության պատմական տվյալները (հիմնվելով CPU-ի և RAM-ի ցուցիչների համակցության վրա՝ զուգորդված հավելվածին հատուկ չափումների հետ) և համեմատում դրանք պատմական տվյալների հետ։ սկզբնավորման ծառայության և այլնի ողջ ընթացքում «կախվածության շղթայում»՝ վերևից ներքև:

Ծառայություն

Միկրոսերվիսը շահագործման հանձնելուց հետո մենք կարող ենք դրան ձգաններ ամրացնել։

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

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

Վահանակ

Մի խոսքով, վահանակը մեր ամբողջ PaaS-ի կառավարման վահանակն է:

• Ծառայության մասին տեղեկատվության մեկ կետ՝ դրա թեստային ծածկույթի տվյալների, պատկերների քանակի, արտադրության պատճենների, տարբերակների և այլնի վերաբերյալ:
• Տվյալների զտման գործիք՝ ըստ ծառայությունների և պիտակների (բիզնեսի միավորներին պատկանող նշիչներ, արտադրանքի ֆունկցիոնալությունը և այլն)
• Հետագծման, անտառահատումների և մոնիտորինգի համար ենթակառուցվածքային գործիքների հետ ինտեգրվելու գործիք:
• Սպասարկման փաստաթղթերի մեկ կետ:
• Ծառայություններում բոլոր իրադարձությունների մեկ տեսակետ:

Ընդհանուր

Նախքան PaaS-ի ներդրումը, նոր ծրագրավորողը կարող է մի քանի շաբաթ ծախսել՝ հասկանալու բոլոր այն գործիքները, որոնք անհրաժեշտ են արտադրության մեջ միկրոսերվիս գործարկելու համար՝ Kubernetes, Helm, մեր ներքին TeamCity-ի առանձնահատկությունները, տվյալների բազաների և քեշերի հետ կապեր ստեղծելը սխալ հանդուրժող ձևով և այլն: Արագ մեկնարկը կարդալու և ծառայությունն ինքնին ստեղծելու համար տևում է մի քանի ժամ:

Այս թեմայով հաղորդում եմ տվել HighLoad++ 2018-ի համար, կարող եք դիտել video и ներկայացում.

Բոնուսային երգ նրանց համար, ովքեր կարդում են մինչև վերջ

Մենք Avito-ում կազմակերպում ենք ներքին եռօրյա դասընթաց ծրագրավորողների համար Քրիս Ռիչարդսոն, միկրոսերվիսային ճարտարապետության փորձագետ: Դրան մասնակցելու հնարավորությունը ցանկանում ենք ընձեռել այս գրառման ընթերցողներից մեկին։ Այստեղ Ուսուցման ծրագիրը տեղադրվել է։

Դասընթացը տեղի կունենա օգոստոսի 5-ից 7-ը Մոսկվայում։ Աշխատանքային օրեր են, որոնք ամբողջությամբ զբաղված են լինելու։ Ճաշը և թրեյնինգը կլինեն մեր գրասենյակում, իսկ ընտրված մասնակիցը ինքն է վճարելու ճանապարհորդության և կացարանի համար:

Մասնակցության համար կարող եք դիմել այս google ձևով. Ձեզնից՝ այն հարցի պատասխանը, թե ինչու է Ձեզ անհրաժեշտ մասնակցել դասընթացին և տեղեկություններ, թե ինչպես կապվել ձեզ հետ: Պատասխանեք անգլերեն, քանի որ Քրիսն ինքն է ընտրելու այն մասնակցին, ով ներկա կլինի դասընթացին։
Մենք կհայտարարենք թրեյնինգի մասնակցի անունը այս գրառման թարմացման և Avito սոցիալական ցանցերում մշակողների համար (AvitoTech in Фейсбуке, Vkontakte, Twitter- ը) ոչ ուշ, քան հուլիսի 19-ը:

Source: www.habr.com