Ջոշ Էվանսը խոսում է Netflix միկրոծառայությունների քաոսային և գունեղ աշխարհի մասին՝ սկսած հենց հիմունքներից՝ միկրոծառայությունների անատոմիայից, բաշխված համակարգերի հետ կապված մարտահրավերներից և դրանց առավելություններից: Հիմնվելով այս հիմքի վրա՝ նա ուսումնասիրում է մշակութային, ճարտարապետական և գործառնական պրակտիկաները, որոնք հանգեցնում են միկրոծառայության վարպետության:
Ի տարբերություն գործառնական դրեյֆի, ծառայության միջազգայնացման համար նոր լեզուների ներդրումը և նոր տեխնոլոգիաները, ինչպիսիք են բեռնարկղերը, գիտակցված որոշումներ են շրջակա միջավայրին նոր բարդություն ավելացնելու համար: Իմ գործառնությունների թիմը ստանդարտացվել է Netflix-ի լավագույն տեխնոլոգիական ճանապարհային քարտեզի վրա, որը մշակվել է Java-ի և EC2-ի վրա հիմնված կանխորոշված լավագույն փորձի մեջ, բայց երբ բիզնեսը մեծացավ, մշակողները սկսեցին ավելացնել նոր բաղադրիչներ, ինչպիսիք են Python-ը, Ruby-ը, Node-JS-ը և Docker-ը:
Ես շատ հպարտ եմ, որ մենք առաջինն ենք պաշտպանել, որ մեր արտադրանքը լավ աշխատի առանց հաճախորդների բողոքների սպասելու: Ամեն ինչ սկսվեց բավական պարզ. մենք ունեինք գործող ծրագրեր Python-ում և մի քանի back-office հավելվածներ Ruby-ում, բայց ամեն ինչ շատ ավելի հետաքրքիր դարձավ, երբ մեր վեբ մշակողները հայտարարեցին, որ պատրաստվում են հրաժարվել JVM-ից և պատրաստվում են տեղափոխել համացանցը: հավելված Node ծրագրային հարթակում: js. Docker-ի ներդրումից հետո ամեն ինչ շատ ավելի բարդացավ: Մենք հետևեցինք տրամաբանությանը, և այն տեխնոլոգիաները, որոնք մենք ստեղծեցինք, իրականություն դարձան, երբ դրանք ներդրեցինք հաճախորդների համար, քանի որ դրանք շատ իմաստալից էին: Ես ձեզ կասեմ, թե ինչու է այդպես:
API Gateway-ն իրականում ունի հիանալի սցենարներ ինտեգրելու ունակություն, որոնք կարող են հանդես գալ որպես վերջնակետ UI մշակողների համար: Նրանք փոխակերպեցին այս սկրիպտներից յուրաքանչյուրն այնպես, որ փոփոխություններ կատարելուց հետո նրանք կարողանան դրանք տեղակայել արտադրության մեջ, այնուհետև օգտագործողի սարքերում, և այս բոլոր փոփոխությունները համաժամանակացվեցին API-ի դարպասում աշխատող վերջնակետերի հետ:
Այնուամենայնիվ, սա կրկնեց նոր մոնոլիտ ստեղծելու խնդիրը, որտեղ API ծառայությունը ծանրաբեռնված էր կոդով այնպես, որ տեղի ունեցան ձախողման տարբեր սցենարներ: Օրինակ, որոշ վերջնակետեր հեռացվել են, կամ սկրիպտները պատահականորեն ստեղծել են ինչ-որ բանի այնքան շատ տարբերակներ, որ տարբերակները զբաղեցրել են API ծառայության ողջ հասանելի հիշողությունը:
Տրամաբանական էր վերցնել այս վերջնակետերը և հանել դրանք API ծառայությունից: Դա անելու համար մենք ստեղծեցինք Node.js բաղադրիչները, որոնք աշխատում էին որպես փոքր հավելվածներ Docker կոնտեյներներում: Սա մեզ թույլ տվեց մեկուսացնել այս հանգույցների հավելվածների հետևանքով առաջացած ցանկացած խնդիր և խափանում:
Այս փոփոխությունների արժեքը բավականին մեծ է և բաղկացած է հետևյալ գործոններից.
- Արտադրողականության գործիքներ. Նոր տեխնոլոգիաների կառավարումը պահանջում էր նոր գործիքներ, քանի որ UI թիմը, օգտագործելով շատ լավ սցենարներ արդյունավետ մոդել ստեղծելու համար, ստիպված չէր շատ ժամանակ ծախսել ենթակառուցվածքը կառավարելու վրա, նրանք միայն պետք է գրեին սցենարներ և ստուգեին դրանց ֆունկցիոնալությունը:
Հնարավորությունների պատկերացում և տեսակավորում – Հիմնական օրինակն այն նոր գործիքներն են, որոնք անհրաժեշտ են աշխատանքի վարորդի մասին տեղեկատվությունը բացահայտելու համար: Պետք էր իմանալ, թե որքան է զբաղված պրոցեսորը, ինչպես է օգտագործվում հիշողությունը, և այդ տեղեկատվության հավաքագրումը պահանջում է տարբեր գործիքներ: - Հիմնական պատկերների մասնատում. պարզ բազային AMI-ն դարձել է ավելի մասնատված և մասնագիտացված:
- Հանգույցի կառավարում. Չկա ոչ մի արդի ճարտարապետություն կամ տեխնոլոգիա, որը թույլ է տալիս կառավարել հանգույցները ամպի մեջ, այնպես որ մենք կառուցեցինք Titus՝ բեռնարկղերի կառավարման հարթակ, որն ապահովում է բեռնարկղերի մասշտաբային և հուսալի տեղակայում և ամպային ինտեգրում Amazon AWS-ի հետ:
- Գրադարանի կամ հարթակի կրկնօրինակում: Պլատֆորմի նույն հիմնական ֆունկցիոնալությամբ նոր տեխնոլոգիաներ տրամադրելու համար պահանջվում էր այն կրկնօրինակել ամպի վրա հիմնված Node.js մշակողների գործիքներում:
- Ուսուցման կոր և արդյունաբերական փորձ: Նոր տեխնոլոգիաների ներդրումն անխուսափելիորեն ստեղծում է նոր մարտահրավերներ, որոնք պետք է հաղթահարել և դրանցից դասեր քաղել:
Այսպիսով, մենք չկարողացանք սահմանափակվել մեկ «ասֆալտապատ ճանապարհով» և ստիպված էինք անընդհատ նոր ուղիներ կառուցել մեր տեխնոլոգիաները զարգացնելու համար։ Ծախսերը ցածր պահելու համար մենք սահմանափակեցինք կենտրոնացված աջակցությունը և կենտրոնացանք JVM-ի, նոր հանգույցների և Docker-ի վրա: Մենք առաջնահերթություն տվեցինք արդյունավետ ազդեցությանը, թիմերին տեղեկացրինք իրենց որոշումների արժեքի մասին և խրախուսեցինք նրանց փնտրել ուղիներ՝ վերաօգտագործելու իրենց կողմից արդեն իսկ մշակված բարձր ազդեցություն ունեցող լուծումները: Մենք օգտագործել ենք այս մոտեցումը ծառայությունը օտար լեզուներով թարգմանելիս՝ ապրանքը միջազգային հաճախորդներին հասցնելու համար: Օրինակները ներառում են հաճախորդի համեմատաբար պարզ գրադարաններ, որոնք կարող են ստեղծվել ավտոմատ կերպով, այնպես որ բավականին հեշտ է ստեղծել Python տարբերակ, Ruby տարբերակ, Java տարբերակ և այլն:
Մենք անընդհատ հնարավորություններ էինք փնտրում օգտագործելու ապացուցված տեխնոլոգիաներ, որոնք իրենց ապացուցել են մեկ տեղում և այլ նմանատիպ իրավիճակներում:
Եկեք խոսենք վերջին տարրի մասին՝ փոփոխությունների կամ տատանումների: Տեսեք, թե ինչպես է մեր արտադրանքի սպառումը անհամաչափ տատանվում շաբաթվա օրվա և ժամի ընթացքում ամբողջ օրվա ընթացքում: Կարելի է ասել, որ առավոտյան ժամը 9-ը Netflix-ի համար ամենադժվար ժամանակն է, երբ համակարգի ծանրաբեռնվածությունը հասնում է առավելագույնին։
Ինչպե՞ս կարող ենք հասնել ծրագրային ապահովման նորարարությունների ներդրման բարձր արագության, այսինքն՝ անընդհատ նոր փոփոխություններ կատարելով համակարգում՝ առանց ծառայությունների մատուցման ընդհատումներ առաջացնելու և մեր հաճախորդներին անհարմարություններ պատճառելու։ Netflix-ը դրան հասավ Spinnaker-ի՝ ամպի վրա հիմնված նոր գլոբալ կառավարման և շարունակական առաքման (CD) հարթակի օգտագործման միջոցով:
Քննադատաբար, Spinnaker-ը նախագծված էր մեր լավագույն փորձը ինտեգրելու համար, որպեսզի բաղադրիչները արտադրության մեջ տեղակայելիս մենք կարողանանք արտադրանքն ուղղակիորեն ինտեգրել մեր մեդիա առաքման տեխնոլոգիայի մեջ:
Մենք կարողացանք մեր առաքման խողովակաշարում ներառել երկու տեխնոլոգիա, որոնք մենք բարձր ենք գնահատում. կանարների ավտոմատ վերլուծություն և փուլային տեղակայում: Կանարյան վերլուծությունը նշանակում է, որ մենք երթևեկության մի կաթիլ ուղղում ենք դեպի կոդի նոր տարբերակ, իսկ արտադրության երթևեկի մնացած մասը անցնում ենք հին տարբերակով: Այնուհետև մենք ստուգում ենք, թե ինչպես է նոր կոդը հաղթահարում առաջադրանքը՝ ավելի լավ կամ վատ, քան գոյություն ունեցողը:
Շարունակական տեղակայումը նշանակում է, որ եթե մի տարածաշրջանում տեղակայումը խնդիրներ ունի, մենք անցնում ենք մեկ այլ տարածաշրջանում տեղակայման: Այս դեպքում վերը նշված ստուգաթերթը պետք է ներառվի արտադրական խողովակաշարում: Ես ձեզ որոշ ժամանակ կխնայեմ և խորհուրդ կտամ դիտել իմ նախորդ ելույթը՝ Engineering Global Netflix Operations in Cloud-ում, եթե դուք հետաքրքրված եք այս թեմայի մեջ ավելի խորությամբ զբաղվելու համար: Ելույթի տեսագրությունը կարելի է դիտել՝ հետևելով սլայդի ներքևի հղմանը։
Զրույցի վերջում հակիրճ կխոսեմ Netflix-ի կազմակերպման և ճարտարապետության մասին։ Հենց սկզբում մենք ունեինք էլեկտրոնային առաքում կոչվող սխեմա, որը NRDP 1.x մեդիա հոսքի առաջին տարբերակն էր: Այստեղ կարող է օգտագործվել «backstream» տերմինը, քանի որ սկզբում օգտագործողը կարող էր միայն ներբեռնել բովանդակություն՝ հետագայում սարքում նվագարկելու համար: Netflix-ի առաջին թվային առաքման հարթակը, դեռ 2009-ին, այսպիսի տեսք ուներ.
Օգտատիրոջ սարքը պարունակում էր Netflix հավելվածը, որը բաղկացած էր UI ինտերֆեյսից, անվտանգության մոդուլներից, ծառայության ակտիվացումից և նվագարկումից՝ հիմնված NRDP հարթակի վրա՝ Netflix Ready Device Platform:
Այն ժամանակ օգտատիրոջ միջերեսը շատ պարզ էր։ Այն պարունակում էր այն, ինչ կոչվում էր Queque Reader, և օգտատերը գնում էր կայք՝ Queque-ում ինչ-որ բան ավելացնելու և այնուհետև դիտում ավելացված բովանդակությունը իր սարքում: Դրականն այն էր, որ ճակատային թիմը և հետևի թիմը պատկանում էին նույն Էլեկտրոնային առաքման կազմակերպությանը և ունեին սերտ աշխատանքային հարաբերություններ: Օգտակար բեռը ստեղծվել է XML-ի հիման վրա: Միևնույն ժամանակ ստեղծվել է Netflix API-ն DVD բիզնեսի համար, որը խրախուսում է երրորդ կողմի հավելվածներին ուղղորդել տրաֆիկը դեպի մեր ծառայություն:
Այնուամենայնիվ, Netflix API-ն լավ պատրաստված էր մեզ օգնելու նորարարական օգտատիրոջ միջերեսով, որը պարունակում է ամբողջ բովանդակության մետատվյալներ, տեղեկություններ այն մասին, թե ինչ ֆիլմեր են եղել, ինչը հնարավորություն է ստեղծել դիտումների ցուցակներ ստեղծելու համար: Այն ուներ ընդհանուր REST API՝ հիմնված JSON սխեմայի, HTTP արձագանքման կոդը, նույնը, որն օգտագործվում է ժամանակակից ճարտարապետության մեջ, և OAuth անվտանգության մոդելը, որն այն ժամանակ պահանջվում էր առջևի հավելվածի համար: Սա հնարավորություն տվեց հոսքային բովանդակության առաքման հանրային մոդելից անցնել մասնավորի:
Անցման հետ կապված խնդիրը մասնատումն էր, քանի որ այժմ մեր համակարգը գործում էր երկու ծառայություն՝ հիմնված բոլորովին այլ գործողության սկզբունքների վրա՝ մեկը Rest-ի, JSON-ի և OAuth-ի, մյուսը՝ RPC-ի, XML-ի և օգտագործողի անվտանգության մեխանիզմի վրա, որը հիմնված է NTBA նշանային համակարգի վրա: Սա առաջին հիբրիդային ճարտարապետությունն էր:
Մեր երկու թիմերի միջև, ըստ էության, կար firewall, քանի որ սկզբում API-ն այնքան էլ լավ չէր չափվում NCCP-ի հետ, և դա հանգեցրեց թիմերի միջև շփման: Տարբերությունները եղել են ծառայությունների, արձանագրությունների, սխեմաների, անվտանգության մոդուլների մեջ, և մշակողները հաճախ ստիպված են եղել անցնել բոլորովին այլ համատեքստերի միջև:
Այս կապակցությամբ զրույց ունեցա ընկերության ավագ ինժեներներից մեկի հետ, ում հարցրեցի. «Ո՞րը պետք է լինի ճիշտ երկարաժամկետ ճարտարապետությունը», և նա հակահարված տվեց. «Դուք հավանաբար ավելի մտահոգ եք. կազմակերպչական հետևանքների մասին. ի՞նչ կլինի, եթե մենք ինտեգրենք այս բաները, և դրանք կոտրեն այն, ինչ մենք սովորել ենք լավ անել: Այս մոտեցումը շատ տեղին է Քոնուեյի օրենքին. «Կազմակերպությունները, որոնք նախագծում են համակարգերը սահմանափակված են այնպիսի դիզայնով, որը կրկնում է այդ կազմակերպության հաղորդակցման կառուցվածքը»: Սա շատ վերացական սահմանում է, ուստի ես նախընտրում եմ ավելի կոնկրետ. «Ցանկացած ծրագրային ապահովում արտացոլում է այն կազմակերպչական կառուցվածքը, որը ստեղծել է այն»: Ահա իմ ամենասիրած մեջբերումը Էրիկ Ռայմոնդից. «Եթե ունես ծրագրավորողների չորս թիմ, որոնք աշխատում են կոմպիլյատորի վրա, դու կհայտնվես չորս անցանց կոմպիլյատորով»: Դե, Netflix-ն ունի չորս անցանց կոմպիլյատոր, և մենք այդպես ենք աշխատում:
Կարելի է ասել, որ այս դեպքում պոչը թափահարում է շանը։ Մեր առաջնահերթությունը լուծումը չէ, այլ կազմակերպությունը, կազմակերպությունն է, որը առաջնորդում է մեր ունեցած ճարտարապետությունը: Աստիճանաբար, ծառայությունների խցիկից, մենք տեղափոխվեցինք դեպի մի ճարտարապետություն, որը մենք անվանեցինք Blade Runner, քանի որ այստեղ մենք խոսում ենք եզրային ծառայությունների և NCCP-ի ունակության մասին՝ առանձնացվելու և ուղղակիորեն ինտեգրվելու Zuul պրոքսիին, API-ի դարպասին և համապատասխան ֆունկցիոնալին: «կտորները» վերածվել են նոր միկրոծառայությունների՝ ավելի առաջադեմ անվտանգության, վերարտադրման, տվյալների տեսակավորման և այլնի հնարավորություններով:
Այսպիսով, կարելի է ասել, որ գերատեսչական կառույցները և ընկերության դինամիկան կարևոր դեր են խաղում համակարգի նախագծման ձևավորման գործում և հանդիսանում են փոփոխությանը նպաստող կամ խոչընդոտող գործոն: Microservices ճարտարապետությունը բարդ է և օրգանական, և դրա առողջությունը հիմնված է կարգապահության և ներդրված քաոսի վրա:
Մի փոքր գովազդ
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, , մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):
Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին
Source: www.habr.com