Det ser ut til at toppen av hypen for mikrotjenester er bak oss. Vi leser ikke lenger innlegg flere ganger i uken "Hvordan jeg flyttet monolitten min til 150 tjenester." Nå hører jeg mer sunn fornuftstanker: "Jeg hater ikke monolitten, jeg bryr meg bare om effektivitet." Vi observerte til og med flere migrasjoner fra mikrotjenester tilbake til monolitt. Når du går fra en stor applikasjon til flere mindre tjenester, må du løse flere nye problemer. La oss liste dem så kort som mulig.

Innstilling: fra grunnleggende kjemi til kvantemekanikk

Å sette opp en grunnleggende database og applikasjon med en bakgrunnsprosess var en ganske grei prosess. Jeg publiserer readme på Github - og ofte etter en time, et par timer på det meste, fungerer alt, og jeg starter et nytt prosjekt. Å legge til og kjøre kode, i det minste for det opprinnelige miljøet, gjøres på dag én. Men hvis vi våger oss inn i mikrotjenester, skyter den første lanseringstiden i været. Ja, nå har vi Docker med orkestrering og en klynge av K8-maskiner, men for en nybegynner programmerer er alt dette mye mer komplisert. For mange juniorer er dette en belastning som virkelig er en unødvendig komplikasjon.

Systemet er ikke lett å forstå

La oss fokusere på juniorene våre et øyeblikk. Med monolittiske applikasjoner, hvis det oppstod en feil, var det enkelt å spore den opp og umiddelbart gå videre til feilsøking. Nå har vi en tjeneste som snakker med en annen tjeneste som står i kø på en meldingsbuss som behandler en annen tjeneste – og så oppstår det en feil. Vi må sette sammen alle disse delene for til slutt å finne ut at Service A kjører versjon 11, og Service E venter allerede på versjon 12. Dette er veldig forskjellig fra min standard konsoliderte logg: å måtte bruke en interaktiv terminal/debugger for å gå gjennom prosessen steg for steg. Feilsøking og forståelse har i seg selv blitt vanskeligere.

Hvis det ikke kan feilsøkes, vil vi kanskje teste dem

Kontinuerlig integrasjon og kontinuerlig utvikling er nå i ferd med å bli vanlig. De fleste nye apper jeg ser oppretter og kjører tester automatisk med hver nye utgivelse og krever at tester tas og vurderes før registrering. Dette er store prosesser som ikke bør forlates og har vært et stort skifte for mange bedrifter. Men nå, for å virkelig teste tjenesten, må jeg hente opp en fullstendig fungerende versjon av applikasjonen min. Husker du den nye ingeniøren med K8-klyngen med 150 tjenester? Vel, nå skal vi lære CI-systemet vårt hvordan vi henter opp alle disse systemene for å bekrefte at alt virkelig fungerer. Dette er sannsynligvis for mye innsats, så vi vil bare teste hver del isolert: Jeg er sikker på at spesifikasjonene våre er gode nok, API-ene er rene, og en tjenestefeil er isolert og vil ikke påvirke andre.

Alle kompromisser har en god grunn. Ikke sant?

Det er mange grunner til å gå over til mikrotjenester. Jeg har sett dette gjort for større fleksibilitet, for å skalere team, for ytelse, for å gi bedre bærekraft. Men i virkeligheten har vi investert flere tiår i verktøy og praksis for å utvikle monolitter som fortsetter å utvikle seg. Jeg jobber med fagfolk innen ulike teknologier. Vi snakker vanligvis om skalering fordi de går inn i grensene til en enkelt Postgres-databasenode. De fleste samtalene handler om databaseskalering.

Men jeg er alltid interessert i å lære om arkitekturen deres. Hvilket stadium av overgangen til mikrotjenester befinner de seg på? Det er interessant å se flere ingeniører si at de er fornøyde med sin monolittiske applikasjon. Mange mennesker vil ha nytte av mikrotjenester, og fordelene vil oppveie ujevnheter i migrasjonsveien. Men personlig, vennligst gi meg min monolittiske søknad, et sted på stranden - og jeg er helt fornøyd.

Kilde: www.habr.com