Բարև, Հաբր: Ձեր ուշադրությանն եմ ներկայացնում հոդվածի հեղինակային թարգմանությունը .
Այն ժամանակ, երբ ՏՏ աշխարհն աստիճանաբար շարժվում է դեպի Kubernetes-ի նման միկրոծառայություններ և գործիքներ, միայն մեկ խնդիր է դառնում ավելի ու ավելի նկատելի. Այս խնդիրը - microservice տարբերակները. Այդուհանդերձ, ՏՏ համայնքը կարծում է, որ ներկայիս իրավիճակը շատ ավելի լավ է, քան նախորդ սերնդի տեխնոլոգիաներ. Այնուամենայնիվ, միկրոսերվիսների տարբերակումը շատ բարդ խնդիր է: Դրա ապացույցներից մեկը կարող է լինել նման հոդվածները .
Եթե այս տեքստը կարդալով դեռ չեք հասկանում խնդիրը, թույլ տվեք բացատրել։ Ենթադրենք, ձեր արտադրանքը բաղկացած է 10 միկրոծառայությունից: Հիմա ենթադրենք, որ այս միկրոսերվիսներից յուրաքանչյուրի համար թողարկվում է 1 նոր տարբերակ։ Միայն 1 տարբերակ - Հուսով եմ բոլորս կարող ենք համաձայնել, որ սա շատ տրիվիալ և աննշան փաստ է։ Այժմ, սակայն, եկեք մեկ այլ հայացք գցենք մեր արտադրանքին: Յուրաքանչյուր բաղադրիչի ընդամենը մեկ նոր տարբերակով մենք այժմ ունենք 2^10 կամ 1024 փոխարկումներ, թե ինչպես կարող է կազմվել մեր արտադրանքը:
Եթե դեռ ինչ-որ թյուրիմացություն կա, թույլ տվեք կոտրել մաթեմատիկան: Այսպիսով, մենք ունենք 10 միկրոծառայություն, որոնցից յուրաքանչյուրը ստանում է մեկ թարմացում: Այսինքն՝ յուրաքանչյուր միկրոսերվիսի համար (հին կամ նոր) ստանում ենք 2 հնարավոր տարբերակ։ Այժմ, արտադրանքի յուրաքանչյուր բաղադրիչի համար մենք կարող ենք օգտագործել այս երկու տարբերակներից որևէ մեկը: Մաթեմատիկորեն դա նույնն է, ինչ մենք ունենանք 10 նիշանոց երկուական թիվ։ Օրինակ, ասենք, որ 1-ը նոր տարբերակն է, իսկ 0-ը հին տարբերակն է, ապա մեկ հնարավոր փոխարկումը կարող է նշանակվել որպես 1001000000, որտեղ 1-ին և 4-րդ բաղադրիչները թարմացվում են, իսկ մյուսները՝ ոչ: Մաթեմատիկայից մենք գիտենք, որ 10 նիշանոց երկուական թիվը կարող է ունենալ 2^10 կամ 1024 արժեք։ Այսինքն՝ մենք հաստատել ենք այն թվի մասշտաբները, որոնց հետ գործ ունենք։
Եկեք շարունակենք մեր պատճառաբանությունը. ի՞նչ կլինի, եթե մենք ունենանք 100 միկրոսերվիս, և յուրաքանչյուրն ունենա 10 հնարավոր տարբերակ: Ամբողջ իրավիճակը դառնում է բավականին տհաճ. մենք հիմա ունենք 10^100 փոխարկում, ինչը հսկայական թիվ է։ Այնուամենայնիվ, ես նախընտրում եմ այս իրավիճակը պիտակավորել այսպես, քանի որ այժմ մենք այլևս թաքնվում ենք ոչ թե «կուբերնետես» բառերի հետևում, այլ խնդրին այնպիսին, ինչպիսին կա:
Ինչու՞ եմ ինձ այդքան գրավում այս խնդիրը: Մասամբ այն պատճառով, որ նախկինում աշխատելով NLP-ի և AI-ի աշխարհում, մենք շատ ենք քննարկել կոմբինատորական պայթյունի խնդիրը մոտ 5-6 տարի առաջ: Միայն տարբերակների փոխարեն ունեինք առանձին բառեր, իսկ ապրանքների փոխարեն՝ նախադասություններ և պարբերություններ։ Եվ չնայած NLP-ի և AI-ի խնդիրները հիմնականում մնում են չլուծված, պետք է խոստովանել, որ վերջին մի քանի տարիների ընթացքում զգալի առաջընթաց է գրանցվել. (Իմ կարծիքով, առաջընթաց կարող է լինելоԱվելի լավ կլիներ, եթե ոլորտի մարդիկ մի փոքր ավելի քիչ ուշադրություն դարձնեին մեքենայական ուսուցմանը և մի փոքր ավելի շատ այլ տեխնիկայի վրա, բայց սա արդեն թեմայից դուրս է):
Եկեք վերադառնանք DevOps-ի և միկրոծառայությունների աշխարհ: Մենք բախվում ենք հսկայական խնդրի՝ դիմակավորվելով որպես փիղ Կունստկամերայում, քանի որ այն, ինչ ես հաճախ եմ լսում, հետևյալն է. Բայց ոչ, ամեն ինչ լավ չի լինի, եթե ամեն ինչ մնա այնպես, ինչպես կա։ Ավելին, այս խնդրի վերլուծական լուծումն ընդունելի չի թվում իր բարդության պատճառով։ Ինչպես NLP-ում, մենք նախ պետք է մոտենանք այս խնդրին՝ նեղացնելով որոնման շրջանակը, այս դեպքում՝ վերացնելով հնացած փոխատեղումները:
Բաներից մեկը, որը կարող է օգնել, այն է, որ ես գրել եմ անցյալ տարի . Կարևոր է նաև նշել, որ լավ մշակված CI/CD գործընթացը մեծապես օգնում է տատանումները նվազեցնելու հարցում: Այնուամենայնիվ, CI/CD-ի հետ կապված գործերի ներկա վիճակը բավականաչափ լավ չէ, որպեսզի լուծի փոխատեղումների խնդիրը՝ առանց հաշվառման և հետևելու բաղադրիչների լրացուցիչ գործիքների:
Մեզ անհրաժեշտ է ինտեգրման փուլում փորձարկման համակարգ, որտեղ մենք կարող ենք որոշել ռիսկի գործոնը յուրաքանչյուր բաղադրիչի համար, ինչպես նաև ունենանք տարբեր բաղադրիչների թարմացման և առանց օպերատորի միջամտության փորձարկման ավտոմատացված գործընթաց՝ տեսնելու, թե ինչն է աշխատում, ինչը ոչ:
Փորձերի նման համակարգը կարող է այսպիսի տեսք ունենալ.
- Մշակողները գրում են թեստեր (սա կրիտիկական փուլ է, քանի որ հակառակ դեպքում մենք չունենք գնահատման չափանիշ, դա նման է մեքենայական ուսուցման տվյալների պիտակավորմանը):
- Յուրաքանչյուր բաղադրիչ (նախագիծ) ստանում է իր սեփական CI համակարգը. այս գործընթացն այժմ լավ զարգացած է, և մեկ բաղադրիչի համար CI համակարգի ստեղծման հարցը հիմնականում լուծված է:
- «Խելացի ինտեգրացիոն համակարգը» հավաքում է տարբեր CI համակարգերի արդյունքները և բաղադրիչների նախագծերը հավաքում վերջնական արտադրանքի մեջ, անցկացնում է թեստավորում և վերջապես հաշվարկում է ամենակարճ ճանապարհը դեպի ցանկալի արտադրանքի ֆունկցիոնալությունը ձեռք բերելու համար՝ հիմնված առկա բաղադրիչների և ռիսկի գործոնների վրա: Եթե թարմացումը հնարավոր չէ, այս համակարգը ծրագրավորողներին տեղեկացնում է առկա բաղադրիչների և դրանցից որն է սխալ առաջացրել: Եվս մեկ անգամ, թեստային համակարգը այստեղ կարևոր նշանակություն ունի, քանի որ ինտեգրացիոն համակարգն օգտագործում է թեստերը որպես գնահատման չափանիշ:
- CD համակարգ, որն այնուհետ տվյալներ է ստանում Smart Integration System-ից և ուղղակիորեն կատարում թարմացումները: Այս փուլն ավարտում է ցիկլը:
Ամփոփելով, ինձ համար այժմ ամենամեծ խնդիրներից մեկը նման «Խելացի ինտեգրացիոն համակարգի» բացակայությունն է, որը կկապեր տարբեր բաղադրիչները ապրանքի մեջ և այդպիսով թույլ կտա ձեզ հետևել, թե ինչպես է արտադրանքն ամբողջությամբ հավաքվում: Ինձ կհետաքրքրի համայնքի կարծիքը այս մասին (սպոյլեր – Ես այժմ աշխատում եմ նախագծի վրա , որը կարող է դառնալ այդպիսի խելացի ինտեգրացիոն համակարգ)։
Վերջին բանը, որ ուզում եմ նշել, այն է, որ, ինձ համար, մոնոլիտը ընդունելի չէ նույնիսկ միջին չափի որևէ նախագծի համար: Ինձ համար մեծ թերահավատություն են առաջացնում իրականացման ժամանակն ու զարգացման որակն արագացնելու փորձերը՝ վերադառնալով մոնոլիտ։ Նախ, մոնոլիտը բաղադրիչների կառավարման նմանատիպ խնդիր ունի. այն տարբեր գրադարանների շարքում, որոնցից բաղկացած է, այնուամենայնիվ, այս ամենն այնքան էլ նկատելի չէ և դրսևորվում է հիմնականում մշակողների ծախսած ժամանակում: Մոնոլիտ խնդրի հետևանքը կոդի մեջ փոփոխություններ կատարելու վիրտուալ անհնարինությունն է և զարգացման չափազանց դանդաղ արագությունը:
Միկրոծառայությունները բարելավում են իրավիճակը, բայց հետո միկրոծառայությունների ճարտարապետությունը ինտեգրման փուլում բախվում է կոմբինատորական պայթյունի խնդրին: Այո, ընդհանուր առմամբ, մենք նույն խնդիրը զարգացման փուլից տեղափոխել ենք ինտեգրացիոն փուլ։ Այնուամենայնիվ, իմ կարծիքով, միկրոծառայությունների մոտեցումը դեռ հանգեցնում է ավելի լավ արդյունքների, և թիմերն ավելի արագ են հասնում արդյունքների (հավանաբար հիմնականում զարգացման միավորի չափի կրճատման պատճառով, կամ խմբաքանակի չափը). Այնուամենայնիվ, մոնոլիտից միկրոսերվիսներին անցնելը դեռևս բավականաչափ չի բարելավել գործընթացը. միկրոսերվիսային տարբերակների համակցված պայթյունը հսկայական խնդիր է, և մենք ունենք շատ ներուժ՝ բարելավելու իրավիճակը, երբ լուծում ենք այն:
Source: www.habr.com