Թվում է, թե միկրոսերվիսների գովազդի գագաթնակետը ետևում է: Մենք այլևս շաբաթը մի քանի անգամ չենք կարդում «Ինչպես ես իմ մոնոլիտը տեղափոխեցի 150 ծառայության» գրառումները։ Այժմ ես ավելի շատ առողջ դատողություններ եմ լսում. «Ես չեմ ատում մոնոլիտը, ես միայն մտածում եմ արդյունավետության մասին»: Մենք նույնիսկ մի քանի միգրացիա նկատեցինք միկրոսերվիսներից վերադառնալ մոնոլիտ. Մեկ մեծ հավելվածից մի քանի փոքր ծառայությունների անցնելիս ստիպված կլինեք լուծել մի քանի նոր խնդիրներ: Թվարկենք դրանք հնարավորինս հակիրճ:

Պարամետրը՝ հիմնական քիմիայից մինչև քվանտային մեխանիկա

Հիմնական տվյալների բազայի և հավելվածի ստեղծումը ֆոնային գործընթացով բավականին պարզ գործընթաց էր: Ես հրատարակում եմ readme-ը Github-ում, և հաճախ մեկ ժամվա ընթացքում, առավելագույնը մի քանի ժամվա ընթացքում, ամեն ինչ աշխատում է, և ես սկսում եմ նոր նախագիծ: Կոդի ավելացումն ու գործարկումը, գոնե սկզբնական միջավայրի համար, կատարվում է առաջին օրը: Բայց եթե մենք ձեռնամուխ լինենք միկրոծառայությունների մեջ, սկզբնական մեկնարկի ժամանակը բարձրանում է: Այո, հիմա մենք ունենք Docker նվագախմբով և K8 մեքենաների կլաստերով, բայց սկսնակ ծրագրավորողի համար այս ամենը շատ ավելի բարդ է: Շատ կրտսերների համար սա բեռ է, որն իսկապես անհարկի բարդություն է:

Համակարգը հեշտ չէ հասկանալ

Եկեք մի պահ կենտրոնանանք մեր կրտսերի վրա։ Միաձույլ հավելվածների դեպքում, եթե սխալ տեղի ունեցավ, հեշտ էր հետևել դրան և անմիջապես անցնել վրիպազերծմանը: Այժմ մենք ունենք ծառայություն, որը խոսում է մեկ այլ ծառայության հետ, որը հերթագրում է ինչ-որ բան հաղորդագրության ավտոբուսում, որը մշակում է մեկ այլ ծառայություն, և հետո սխալ կա: Մենք պետք է հավաքենք այս բոլոր մասերը, որպեսզի ի վերջո պարզենք, որ ծառայությունը A-ն աշխատում է 11-րդ տարբերակին, և ծառայությունը E-ն արդեն սպասում է 12-րդ տարբերակին: Սա շատ տարբեր է իմ ստանդարտ համախմբված մատյանից. քայլելու համար պետք է օգտագործեմ ինտերակտիվ տերմինալ/վրիպազերծիչ: գործընթացի միջոցով քայլ առ քայլ: Վրիպազերծումը և ըմբռնումն ի սկզբանե ավելի դժվար է դարձել:

Եթե ​​այն հնարավոր չէ կարգաբերել, միգուցե մենք փորձարկենք դրանք

Շարունակական ինտեգրումն ու շարունակական զարգացումն այժմ սովորական են դառնում: Նոր հավելվածներից շատերը, որոնք ես տեսնում եմ, ավտոմատ կերպով ստեղծում և փորձարկում են յուրաքանչյուր նոր թողարկման հետ, և պահանջում են թեստեր անցնել և վերանայել նախքան գրանցումը: Սրանք հիանալի գործընթացներ են, որոնցից չի կարելի հրաժարվել և մեծ տեղաշարժ են եղել շատ ընկերությունների համար: Բայց հիմա, իսկապես ծառայությունը փորձարկելու համար, ես պետք է քաշեմ իմ հավելվածի ամբողջական աշխատանքային տարբերակը: Հիշու՞մ եք 8 ծառայությունների K150 կլաստերով այդ նոր ինժեներին: Դե, հիմա մենք կսովորեցնենք մեր CI համակարգին, թե ինչպես առաջացնել այս բոլոր համակարգերը՝ ստուգելու համար, որ ամեն ինչ իսկապես աշխատում է: Սա, հավանաբար, չափազանց մեծ ջանք է, ուստի մենք պարզապես կփորձարկենք յուրաքանչյուր մաս առանձին-առանձին. ես վստահ եմ, որ մեր բնութագրերը բավականաչափ լավն են, API-ները մաքուր են, և ծառայության ձախողումը մեկուսացված է և չի ազդի մյուսների վրա:

Բոլոր փոխզիջումները լավ պատճառ ունեն։ Ճիշտ?

Շատ պատճառներ կան միկրոսերվիսներ տեղափոխվելու համար: Ես տեսել եմ, որ դա արվում է ավելի մեծ ճկունության, թիմերի մասշտաբի, կատարողականի, ավելի լավ կայունություն ապահովելու համար: Բայց իրականում մենք տասնամյակներ ներդրել ենք գործիքների և պրակտիկայի մեջ՝ զարգացնելու մոնոլիտներ, որոնք շարունակում են զարգանալ: Աշխատում եմ տարբեր տեխնոլոգիաների մասնագետների հետ։ Մենք սովորաբար խոսում ենք մասշտաբի մասին, քանի որ դրանք անցնում են Postgres տվյալների բազայի մեկ հանգույցի սահմաններում: Խոսակցությունների մեծ մասը վերաբերում է տվյալների բազայի մասշտաբավորում.

Բայց ես միշտ հետաքրքրված եմ իմանալ նրանց ճարտարապետության մասին: Միկրոծառայությունների անցնելու ո՞ր փուլում են գտնվում։ Հետաքրքիր է տեսնել, որ ավելի շատ ինժեներներ ասում են, որ գոհ են իրենց մոնոլիտ կիրառությունից: Շատ մարդիկ կշահեն միկրոծառայություններից, և օգուտները կգերազանցեն միգրացիոն ճանապարհի բախումները: Բայց անձամբ, խնդրում եմ, տվեք ինձ իմ մոնոլիտ հավելվածը, մի տեղ ծովափին, և ես լիովին երջանիկ եմ:

Source: www.habr.com