Det ser ud til, at toppen af ​​hype for mikrotjenester er bag os. Vi læser ikke længere indlæg flere gange om ugen "Sådan flyttede jeg min monolit til 150 tjenester." Nu hører jeg flere tanker om sund fornuft: "Jeg hader ikke monolitten, jeg bekymrer mig bare om effektivitet." Vi observerede endda flere migrationer fra mikrotjenester tilbage til monolit. Når du går fra én stor applikation til flere mindre tjenester, skal du løse flere nye problemer. Lad os liste dem så kort som muligt.

Indstilling: fra grundlæggende kemi til kvantemekanik

Opsætning af en grundlæggende database og applikation med en baggrundsproces var en ret ligetil proces. Jeg udgiver readme på Github - og ofte efter en time, højst et par timer, virker alt, og jeg starter et nyt projekt. Tilføjelse og kørsel af kode, i det mindste for det oprindelige miljø, sker på dag ét. Men hvis vi begiver os ud i mikrotjenester, skyder den indledende lanceringstid i vejret. Ja, nu har vi Docker med orkestrering og en klynge af K8-maskiner, men for en nybegynder programmør er alt dette meget mere kompliceret. For mange juniorer er dette en byrde, der i sandhed er en unødvendig komplikation.

Systemet er ikke let at forstå

Lad os fokusere på vores junior et øjeblik. Med monolitiske applikationer, hvis der opstod en fejl, var det nemt at spore den og straks gå videre til fejlretning. Nu har vi en tjeneste, der taler med en anden tjeneste, der sætter noget i kø på en beskedbus, der behandler en anden tjeneste – og så opstår der en fejl. Vi er nødt til at sætte alle disse brikker sammen for til sidst at finde ud af, at Service A kører version 11, og Service E venter allerede på version 12. Dette er meget forskelligt fra min standard konsoliderede log: at skulle bruge en interaktiv terminal/debugger for at gå gennem processen trin for trin. Fejlretning og forståelse er i sagens natur blevet sværere.

Hvis det ikke kan fejlsøges, tester vi dem måske

Kontinuerlig integration og kontinuerlig udvikling er nu ved at blive hverdagskost. De fleste nye apps, jeg ser, opretter og kører automatisk test med hver ny udgivelse og kræver, at tests tages og gennemgås før registrering. Det er store processer, som ikke bør opgives og har været et stort skift for mange virksomheder. Men nu, for virkelig at teste tjenesten, er jeg nødt til at hente en fuld fungerende version af min applikation. Kan du huske den nye ingeniør med K8-klyngen med 150 tjenester? Nå, nu vil vi lære vores CI-system, hvordan man henter alle disse systemer frem for at verificere, at alt virkelig fungerer. Dette er sandsynligvis for meget, så vi vil bare teste hver del isoleret: Jeg er overbevist om, at vores specifikationer er gode nok, API'erne er rene, og en servicefejl er isoleret og vil ikke påvirke andre.

Alle kompromiser har en god grund. Højre?

Der er mange grunde til at flytte til mikrotjenester. Jeg har set dette gjort for større fleksibilitet, for at skalere teams, for ydeevne, for at give bedre bæredygtighed. Men i virkeligheden har vi investeret årtier i værktøjer og praksis for at udvikle monolitter, der fortsætter med at udvikle sig. Jeg arbejder med fagfolk inden for forskellige teknologier. Vi taler normalt om skalering, fordi de løber ind i grænserne for en enkelt Postgres-databaseknude. De fleste samtaler handler om database skalering.

Men jeg er altid interesseret i at lære om deres arkitektur. Hvilken fase af overgangen til mikrotjenester er de på? Det er interessant at se flere ingeniører sige, at de er tilfredse med deres monolitiske applikation. Mange mennesker vil drage fordel af mikrotjenester, og fordelene vil opveje bumpene i migrationsvejen. Men personligt, giv mig venligst min monolitiske ansøgning, et sted på stranden - og jeg er fuldstændig glad.

Kilde: www.habr.com