Tundub, et mikroteenuste buumi tipp on möödas. Me ei loe enam mitu korda nädalas postitusi "Kuidas ma muutsin oma monolüüdi 150 teenuseks". Nüüd kuulen järjest enam mõistlikke mõtteid: "Ma ei jäta monolüüdi maha, ma lihtsalt hoolin efektiivsusest". Oleme isegi näinud mitmeid migratsioone . Suurelt rakenduselt väiksematele teenustele minnes tuleb lahendada mitu uusi probleeme. Loetleme need võimalikult lühidalt.
Seadistamine: alates põhirektsioonist kvantmehhaanikani
Põhiandmebaasi ja taustaprotsessiga rakenduse seadistamine oli üsna selge protsess. Jagasin readme'i GitHubis - ja sageli ühe tunni, maksimaalselt paar tunni pärast töötas kõik ning ma alustasin uut projekti. Koodi lisamine ja käivitamine, vähemalt algkeskkonna jaoks, toimub samal päeval. Kuid kui me julgeme mikroteenustele minna, tõuseb esialgne käivitamise aeg taevasse. Jah, nüüd on meil Docker koos orkestreerimisega ja K8 masinate klaster, kuid kõigile algajatele programmeerijatele on see oluliselt keerulisem. Paljudele noorematele arendajatele on see koorem, mis on tõeliselt tarbetu keerukus.
Süsteemi on keeruline mõista
Võtame hetkeks meie noore arendaja. Monolüütiliste rakendustega oli vea korral kergesti jälgitav ja lihtne alustada silumist. Nüüd on meil teenus, mis suhtleb teise teenusega, mille kaudu midagi järjekorda pannakse sõnumite bussis, mis töötleb teist teenust - ja seal tekib viga. Me peame kõik need osad kokku panema, et lõpuks teada saada, et teenus A töötab versioonis 11, samas kui teenus E ootab juba versiooni 12. See on täiesti erinev minu tavapärasest konsolideeritud logist: pean kasutama interaktiivset terminali/silumist, et minna protsessis samm-sammult edasi. Silumine ja mõistmine on tegelikult keerulisemaks muutunud.
Kui ei saa siluda, siis võib-olla katsetame neid
Pidev integratsioon ja pidev arendus on muutumas tavapäraseks. Enamik uusi rakendusi, mida ma näen, loovad iga uue väljaandega automaatselt testid ja nõuavad, et testid läbiksid ja vaadataks üle enne registreerimist. Need on suurepärased protsessid, millest ei saa loobuda, need on olnud suur muutus paljudele ettevõtetele. Kuid nüüd, et tõeliselt teenust testida, pean ma tõstma oma rakenduse täiskomplekti üles. Kas mäletate seda uut inseneri, kellel on 150 teenusega K8 klaster? Noh, nüüd õpetame meie CI-süsteemile, kuidas kõik need süsteemid üles tõsta, et kontrollida, kas kõik tegelikult töötab. Tõenäoliselt on see liiga palju vaeva, seega testime lihtsalt iga osa eraldi: olen kindel, et meie spetsifikatsioonid on piisavalt head, API-d puhtad ja teenuse tõrge on eraldatud ja ei mõjuta teisi.
Kõikidel kompromissidel on mõjuv põhjus. Õigus?
On palju põhjuseid, miks liikuda mikroteenustele. Olen näinud, et seda tehakse suurema paindlikkuse, meeskondade skaleerimise, tootlikkuse ja töö paremaks vastupidavuseks. Kuid tegelikkuses oleme investeerinud kümneid aastaid monoliitsete arendustööriistade ja praktikate arendamisse, mis jätkavad arengut. Töödan professionaalidega erinevates tehnoloogiates. Tavaliselt räägime skaleerimisest, kuna nad seisavad silmitsi Postgresi andmebaasi ühe sõlme piirangutega. Suur osa vestlustest on seotud .
Aga mind huvitab alati nende arhitektuur. Millisel ülemineku etapis mikroteenustele nad on. On huvitav tähele panna, et üha rohkem insenere ütleb, et nad on oma monoliitrakendusega rahul. Paljudele toovad mikroteenused kasu ja eelised kaaluvad üles migratsiooniteed kütused. Kuid isiklikult, palun tooge mulle minu monoliitne rakendus, koht rannas - ja olen täiesti õnnelik.
Allikas: habr.com
