Det ser ut til at hypetoppen innen mikrotjenester er bak oss. Vi leser ikke lenger flere ganger i uken innlegg som «Hvordan jeg migrerte min monolitt til 150 tjenester». NÄ hÞrer jeg oftere fornuftige tanker: «Jeg hater ikke monolitter, jeg er bare opptatt av effektivitet». Vi har til og med sett noen migrasjoner . NÄr man gÄr fra én stor applikasjon til flere mindre tjenester mÄ man hÄndtere flere nye problemer. La oss skissere dem sÄ kort som mulig.
Installasjon: fra grunnleggende kjemi til kvantemekanikk
Oppsett av den grunnleggende databasen og applikasjonen med bakgrunnsprosess var en ganske klar prosess. Jeg publiserer readme pĂ„ Github â og ofte, innen en time, maks et par timer, fungerer alt, og jeg begynner et nytt prosjekt. Legging og kjĂžring av koden, i det minste for utviklingsmiljĂžet, gjĂžres pĂ„ den fĂžrste dagen. Men hvis vi vĂ„ger oss pĂ„ mikrotjenester, skyter tiden for fĂžrste oppstart i vĂŠret. Ja, nĂ„ har vi Docker med orkestrering og en klynge av K8-maskiner, men for en nybegynner-programmĂžr er alt dette langt mer komplisert. For mange juniorer er dette en byrde som virkelig er unĂždvendig kompleks.
Systemet er ikke lett Ä forstÄ
La oss ta et Ăžyeblikk for Ă„ se pĂ„ vĂ„r junior. Med monolittiske applikasjoner, nĂ„r det oppstod en feil, var det lett Ă„ spore den og gĂ„ direkte til feilsĂžking. NĂ„ har vi en tjeneste som snakker med en annen tjeneste, som legger noe i kĂž pĂ„ meldingsbussen, som behandler en annen tjeneste â og sĂ„ oppstĂ„r feilen. Vi mĂ„ sette sammen alle disse delene for til slutt Ă„ finne ut at tjeneste A kjĂžrer pĂ„ versjon 11, mens tjeneste E allerede venter pĂ„ versjon 12. Dette er veldig forskjellig fra min standard konsoliderte logg: jeg mĂ„ bruke en interaktiv terminal/debugger for Ă„ gĂ„ gjennom prosessen trinn for trinn. FeilsĂžking og forstĂ„else har i hovedsak blitt vanskeligere.
Hvis det ikke kan debugges, kan det hende vi tester dem
Kontinuerlig integrasjon og kontinuerlig utvikling har nÄ blitt vanlig. De fleste nye applikasjoner jeg ser, bygger og kjÞrer automatisk tester med hver ny utgivelse, og krever at testene mÄ bestÄ og bli gjennomgÄtt fÞr registrering. Dette er utmerkede prosesser som ikke bÞr overses, og de har representert et stort skifte for mange selskaper. Men nÄ, for virkelig Ä teste tjenesten, mÄ jeg opprette en full arbeidsversjon av applikasjonen min. Husk den nye ingeniÞren med K8-klyngen av 150 tjenester? Vel, nÄ skal vi lÊre CI-systemet vÄrt hvordan vi kan aktivere alle disse systemene for Ä sjekke at alt faktisk fungerer. Det er sannsynligvis for mye arbeid, sÄ vi vil bare teste hver del isolert: Jeg er sikker pÄ at spesifikasjonene vÄre er gode nok, APIene er rene, og tjenestenekt er isolert og ikke vil pÄvirke de andre.
Alle kompromisser har en god grunn. Ikke sant?
Det er mange grunner til Ä gÄ over til mikrotjenester. Jeg har sett at dette gjÞres for stÞrre fleksibilitet, for Ä skalere team, for ytelse, for Ä sikre bedre tjenestestabilitet. Men i realiteten har vi investert tiÄr i verktÞyene og praksisene for monolitter, som bare fortsetter Ä utvikle seg. Jeg jobber med fagfolk pÄ tvers av forskjellige teknologier. Vanligvis snakker vi om skalering fordi de mÞter begrensninger med en enkelt Postgres-database-node. StÞrstedelen av samtalen handler om .
Men jeg har alltid vĂŠrt interessert i deres arkitektur. PĂ„ hvilket stadium i overgangen til mikrotjenester befinner de seg? Det er interessant Ă„ se at stadig flere ingeniĂžrer sier at de er fornĂžyde med sine monolittiske applikasjoner. Mange vil ha fordeler av mikrotjenester, og fordelene vil oppveie humpene pĂ„ migrasjonsveien. Men personlig, vĂŠr sĂ„ snill, gi meg min monolittiske applikasjon, et sted pĂ„ stranden â og jeg er helt lykkelig.
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish