Šķiet, ka mikropakalpojumu ažiotāža virsotne ir aiz muguras. Mēs vairs nelasām ziņas vairākas reizes nedēļā “Kā es pārvietoju savu monolītu uz 150 pakalpojumiem”. Tagad es dzirdu vairāk veselā saprāta domas: "Es neienīstu monolītu, man rūp tikai efektivitāte." Mēs pat novērojām vairākas migrācijas no mikropakalpojumiem atpakaļ uz monolītu. Pārejot no vienas lielas lietojumprogrammas uz vairākiem mazākiem pakalpojumiem, jums būs jāatrisina vairākas jaunas problēmas. Uzskaitīsim tos pēc iespējas īsi.

Iestatījums: no pamata ķīmijas līdz kvantu mehānikai

Pamata datu bāzes un lietojumprogrammas iestatīšana ar fona procesu bija diezgan vienkāršs process. Es publicēju readme vietnē Github — un bieži vien pēc vienas stundas, ne vairāk kā pāris stundām viss darbojas, un es sāku jaunu projektu. Koda pievienošana un palaišana, vismaz sākotnējai videi, tiek veikta pirmajā dienā. Bet, ja mēs iesaistāmies mikropakalpojumos, sākotnējais palaišanas laiks strauji palielinās. Jā, tagad mums ir Docker ar orķestrēšanu un K8 mašīnu kopu, taču iesācējam programmētājam tas viss ir daudz sarežģītāk. Daudziem junioriem tas ir slogs, kas patiešām ir nevajadzīgs sarežģījums.

Sistēmu nav viegli saprast

Uz brīdi pievērsīsimies savam junioram. Izmantojot monolītās lietojumprogrammas, ja radās kļūda, to bija viegli izsekot un nekavējoties pāriet uz atkļūdošanu. Tagad mums ir pakalpojums, kas runā ar citu pakalpojumu, kas kaut ko ievieto rindā ziņojumu kopnē, kas apstrādā citu pakalpojumu, un tad rodas kļūda. Mums ir jāapvieno visi šie elementi, lai galu galā uzzinātu, ka pakalpojumā A darbojas 11. versija, bet pakalpojums E jau gaida versiju 12. Tas ļoti atšķiras no mana standarta konsolidētā žurnāla: lai staigātu, ir jāizmanto interaktīvs terminālis/atkļūdotājs. caur procesu soli pa solim. Atkļūdošana un izpratne pēc būtības ir kļuvusi grūtāka.

Ja to nevar atkļūdot, varbūt mēs tos pārbaudīsim

Nepārtraukta integrācija un nepārtraukta attīstība tagad kļūst par ikdienu. Lielākā daļa jauno lietotņu, ko redzu, automātiski izveido un izpilda testus ar katru jaunu laidienu, un pirms reģistrācijas ir jāveic un jāpārskata testi. Tie ir lieliski procesi, no kuriem nevajadzētu atteikties, un tie ir bijuši lielas pārmaiņas daudziem uzņēmumiem. Bet tagad, lai patiešām pārbaudītu pakalpojumu, man ir jāizveido pilna savas lietojumprogrammas darba versija. Atcerieties to jauno inženieri ar 8 pakalpojumu K150 kopu? Tagad mēs savai CI sistēmai iemācīsim, kā atvērt visas šīs sistēmas, lai pārbaudītu, vai viss patiešām darbojas. Tas, iespējams, ir pārāk daudz pūļu, tāpēc mēs pārbaudīsim katru daļu atsevišķi: esmu pārliecināts, ka mūsu specifikācijas ir pietiekami labas, API ir tīras, un pakalpojuma kļūme ir izolēta un neietekmēs citus.

Visiem kompromisiem ir labs iemesls. Pa labi?

Ir daudz iemeslu, lai pārietu uz mikropakalpojumiem. Esmu redzējis, ka tas tiek darīts, lai nodrošinātu lielāku elastību, komandu mērogošanu, veiktspēju, lai nodrošinātu labāku ilgtspējību. Taču patiesībā mēs esam ieguldījuši gadu desmitiem rīkos un praksē, lai izstrādātu monolītus, kas turpina attīstīties. Strādāju ar dažādu tehnoloģiju profesionāļiem. Mēs parasti runājam par mērogošanu, jo tie saskaras ar viena Postgres datu bāzes mezgla ierobežojumiem. Lielākā daļa sarunu ir par datu bāzes mērogošana.

Bet es vienmēr esmu ieinteresēts uzzināt par viņu arhitektūru. Kurā posmā tie atrodas pārejā uz mikropakalpojumiem? Ir interesanti redzēt, ka vairāk inženieru saka, ka ir apmierināti ar savu monolītu pielietojumu. Daudzi cilvēki gūs labumu no mikropakalpojumiem, un ieguvumi atsvērs migrācijas ceļa nelīdzenumus. Bet personīgi, lūdzu, iedodiet man manu monolīto aplikāciju, vietu pludmalē - un es esmu pilnīgi laimīgs.

Avots: www.habr.com