Izskatās, ka mikroservisu popularitāte ir pagājusi. Mēs vairs nelasām vairākkārt nedēļā rakstus "Kā es pārvērsu savu monolītu 150 servisos". Tagad es biežāk dzirdu saprātīgas domas: "Es nenoniecinu monolītu, es vienkārši rūpējos par efektivitāti". Mēs pat esam novērojuši dažas migrācijas no mikroservisiem atpakaļ uz monolītu. Pārejot no viena liela lietojuma uz vairākiem mazākiem pakalpojumiem, jums būs jārisina vairākas jaunas problēmas. Īsi izskaidrosim tās.

Iestatīšana: no pamata ķīmijas uz kvantu mehāniku

Pamatu datu bāzes un lietojuma ar fona procesu iestatīšana bija diezgan skaidrs process. Es publicēju readme vietnē Github — un bieži vien pēc stundas, maksimāli divām, viss strādā, un es uzsāku jaunu projektu. Koda pievienošana un palaišana, vismaz sākotnējā vidē, tiek veikta pirmajā dienā. Bet, ja mēs uzdrošināmies uz mikroservisiem, sākotnējā palaišanas laiks pieaug debesīs. Jā, tagad mums ir Docker ar orķestrāciju un K8 mašīnu klasteri, bet sākuma programmētājam tas viss ir ievērojami sarežģītāk. Daudziem jaunajiem speciālistiem tas ir slogs, kas patiešām ir lieka sarežģītība.

Sistēmu ir grūti saprast

Pavērsīsimies pie mūsu jaunā speciālista. Ar monolītām lietojumprogrammām kļūdu gadījumā to bija viegli izsekot un nekavējoties pāriet pie atkļūdošanas. Tagad mums ir pakalpojums, kas sazinās ar citu pakalpojumu, kas ievieto kaut ko rindā ziņojumu autobusā, kas apstrādā citu pakalpojumu — un šeit rodas kļūda. Mums jāapvieno visas šīs sastāvdaļas, lai beigās uzzinātu, ka pakalpojums A darbojas versijā 11, bet pakalpojums E jau gaida versiju 12. Tas ļoti atšķiras no maniem parastajiem konsolidētajiem žurnāliem: jāizmanto interaktīvs terminālis/atkļūdošanas rīks, lai izietu cauri procesam soli pa solim. Atkļūdošana un izpratne būtībā ir kļuvusi sarežģītāka.

Ja nevaram atkļūdīt, iespējams, mēs tos testēsim

Nepārtraukta integrācija un nepārtraukta izstrāde pašlaik kļūst par normu. Lielākā daļa jauno lietojumprogrammu, ko es redzu, katrā jaunā laidienā automātiski veido un izpilda testus, un prasa, lai testi izietu un tiktu pārskatīti pirms reģistrācijas. Tie ir lieliski procesi, no kuriem nevajadzētu atteikties, un tie ir bijis liels solis daudzu uzņēmumu attīstībā. Bet tagad, lai patiešām pārbaudītu pakalpojumu, man ir jāuzsāk pilna darba versija manai aplikācijai. Atcerieties to jauno inženieri ar 150 pakalpojumu K8 klasterī? Nu, tagad mēs mācīsim mūsu CI sistēmu, kā uzsākt visas šīs sistēmas, lai pārbaudītu, vai viss tiešām strādā. Iespējams, tas ir pārāk liels darbs, tāpēc mēs vienkārši izolēti pārbaudīsim katru daļu: esmu pārliecināts, ka mūsu specifikācijas ir pietiekami labas, API ir tīri, un pakalpojumu pārtraukums ir izolēts un neietekmē citus.

Visiem kompromisiem ir pamatots iemesls. Pareizi?

Ir daudz iemeslu, lai pārietu uz mikroservisiem. Esmu redzējis, ka to dara, lai nodrošinātu lielāku elastību, lai mērogotu komandas, lai uzlabotu veiktspēju un nodrošinātu labāku darbības noturību. Taču reālajā dzīvē mēs esam ielikusi desmitgades rīku un monolītu izstrādes praksi, kas joprojām attīstās. Es strādāju ar profesionāļiem dažādās tehnoloģijās. Parasti mēs runājam par mērogošanu, jo viņi saskaras ar PostgreSQL datu bāzes viena mezgla ierobežojumiem. Lielāko daļu sarunu aizņem datu bāzu mērogošana.

Bet mani vienmēr interesē viņu arhitektūra. Kurā pārejas posmā uz mikroservisiem viņi atrodas? Ir interesanti redzēt, kā arvien vairāk inženieru apgalvo, ka viņi ir apmierināti ar savu monolītu lietojumprogrammu. Daudziem mikroservisi būs izdevīgi, un ieguvumi atsvers šķēršļus migrācijas ceļā. Bet personīgi, lūdzu, man tāda mana monolītā lietojumprogramma, vieta pludmalē — un es esmu pilnīgi laimīgs.

Avots: habr.com