Tundub, et microservice'ide buum on saanud oma lõpu. Me ei loe enam mitu korda nädalas postitusi "Kuidas ma muutsin oma monoliidi 150 teenuseks". Nüüd kuulen ma tihemini mõistlikke mõtteid: "Ma ei vihka monoliiti, ma lihtsalt hoolin efektiivsusest". Oleme isegi наблюдали mitmeid migratsioone . Üleminekul ühest suurest rakendusest väiksemate teenuste juurde peate lahendama mitmeid uusi probleeme. Loetleme need võimalikult lühidalt.
Installeerimine: põhikeemiast kvantmehaanika juurde
Põhi andmebaasi ja rakenduse seadistamine taustaprotsessiga oli täpselt määratletud tegevus. Avaldan readme Githubis — ja sageli juba tunni, maksimaalselt paari tunni pärast, kõik töötab ning alustan uut projekti. Koodi lisamine ja käivitamine, vähemalt algse keskkonna jaoks, toimub juba esimesel päeval. Kuid kui me julgeme minna mikroteenuste peale, tõuseb algse käivitamise aeg järsult. Jah, nüüd on meil Docker orkestreerimise ja K8 masinaklastriga, kuid algajale programmistile on see kõik tunduvalt keerulisem. Paljudele noorematele spetsialistidele on see koorem, mis tegelikult on ülearune keerukus.
Süsteemi mõistmine ei ole lihtne
Peatame hetkeks meie noore spetsialisti peale. Monoliitsete rakendustega oli vea korral lihtne jälgida ja kohe tõrkeotsingule asuda. Nüüd on meil teenus, mis suhtleb teise teenusega, mis paneb midagi sõnumite bussile järjekorda, mis töötab teise teenusega - ja siin tekib viga. Peame kokku koguma kõik need osad, 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 tavalisest konsolideeritud ajakirjast: pean kasutama interaktiivset terminali/debuginstrumenti, et samm-sammult läbi protsessi minna. Tõrkeotsing ja arusaamine on sisuliselt muutunud keerulisemaks.
Kui ei saa tõrkeotsingut teha, siis testime neid.
Jätkuv integratsioon ja jätkuv arendus on praegu muutumas igapäevaseks. Enamik uusi rakendusi, mida ma näen, koostavad iga uue versiooniga automaatselt testid ja nõuavad, et testid läheksid läbi ja vaadataks üle enne registreerimist. Need on suurepärased protsessid, millest ei saa loobuda, need on saanud paljude ettevõtete jaoks suureks muudatuseks. Kuid nüüd, et oma teenust tõeliselt testida, pean ma käivitama oma rakenduse täisversiooni. Kas mäletate seda uut inseneri 150 teenuse K8 klastriga? Noh, nüüd õpime oma CI süsteemi, kuidas käivitada kõik need süsteemid, et kontrollida, kas kõik tõeliselt 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 on puhtad, ja teenuse talitlushäire on isoleeritud ja ei mõjuta teisi.
Kõigil kompromissidel on tõsine põhjus. Eks?
Mikroteenuste kasutamiseks on palju põhjuseid. Olen näinud, et seda tehakse suurema paindlikkuse, meeskondade skaleerimise, jõudluse ja parema töökindluse tagamiseks. Kuid tegelikkuses oleme investeerinud aastakümneid monoliitide arendustööriistadesse ja praktikatese, mis jätkuvalt arenevad. Töötab professionaalidega erinevates tehnoloogiates. Tavaliselt räägime skaleerimisest, sest nad puutuvad kokku Postgresi üksiku andmebaasi sõlme piirangutega. Suur osa vestlustest on pühendatud .
Aga mind huvitab alati nende arhitektuur. Millisel üleminekuetapil mikroteenustele nad on. On huvitav jälgida, kuidas üha rohkem insenere ütleb, et nad on oma monoliitse rakendusega rahul. Paljud saavad mikroteenustest kasu ja eelised kaaluvad üles ülemineku raskused. Kuid isiklikult tahan väga oma monoliitset rakendust, kohta rannas – ja olen täiesti õnnelik.
Allikas: habr.com
