19 september i Moskva det första tematiska mötet HUG (Highload++ User Group), som ägnades åt mikrotjänster. Det var en presentation "Operating Microservices: Size Matters, Even If You Have Kubernetes", där vi delade med oss av Flants omfattande erfarenhet av att driva projekt med mikrotjänstarkitektur. Först och främst kommer det att vara användbart för alla utvecklare som funderar på att använda detta tillvägagångssätt i sitt nuvarande eller framtida projekt.
Introducerar (50 minuter, mycket mer informativ än artikeln), samt huvudutdraget ur den i textform.
OBS: Video och presentation finns också i slutet av detta inlägg.
Inledning
Vanligtvis har en bra historia en början, en huvudintrig och en upplösning. Det här betänkandet är mer som ett förspel och en tragisk sådan. Det är också viktigt att notera att det ger en utomståendes syn på mikrotjänster. utnyttjande.
Jag börjar med den här grafen, vars författare (2015) Martin Fowler:
Den visar hur, vid en monolitisk applikation som når ett visst värde, börjar produktiviteten sjunka. Mikrotjänster är olika genom att den initiala produktiviteten med dem är lägre, men när komplexiteten ökar är effektivitetsförsämringen inte så märkbar för dem.
Jag lägger till detta diagram för fallet med att använda Kubernetes:
Varför är en applikation med mikrotjänster bättre? Eftersom en sådan arkitektur ställer allvarliga krav på arkitekturen, som i sin tur täcks perfekt av Kubernetes möjligheter. Å andra sidan kommer en del av denna funktionalitet att vara användbar för en monolit, särskilt eftersom den typiska monoliten idag inte är precis en monolit (detaljer kommer senare i rapporten).
Som du kan se är den slutliga grafen (när både monolitiska och mikrotjänstapplikationer finns i infrastrukturen med Kubernetes) inte mycket annorlunda än den ursprungliga. Därefter kommer vi att prata om applikationer som drivs med Kubernetes.
Användbara och skadliga mikrotjänster
Och här är huvudidén:
vad är vanligt mikrotjänstarkitektur? Det borde ge dig verkliga fördelar och öka din arbetseffektivitet. Om vi går tillbaka till grafen så är den här:
Om du ringer henne användbar, så kommer det att finnas på andra sidan av grafen skadlig mikrotjänster (stör arbetet):
Återgå till "huvudidén": ska jag överhuvudtaget lita på min erfarenhet? Sedan början av detta år har jag tittat 85 projekt. Inte alla av dem var mikrotjänster (ungefär en tredjedel till hälften av dem hade en sådan arkitektur), men det är fortfarande ett stort antal. Vi (Flantföretag) som outsourcar lyckas se ett brett utbud av applikationer utvecklade både i små företag (med 5 utvecklare) och i stora (~500 utvecklare). En extra fördel är att vi ser dessa applikationer leva och utvecklas under åren.
Varför mikrotjänster?
Till frågan om fördelarna med mikrotjänster finns från den redan nämnda Martin Fowler:
- tydliga gränser för modularitet;
- oberoende distribution;
- frihet att välja teknik.
Jag har pratat mycket med mjukvaruarkitekter och utvecklare och frågat varför de behöver mikrotjänster. Och jag gjorde min lista över deras förväntningar. Här är vad som hände:
Om vi beskriver några av punkterna "i sensationer", då:
- tydliga gränser för moduler: här har vi en fruktansvärd monolit, och nu kommer allt att ordnas snyggt i Git-förråd, där allt är "på hyllorna", det varma och det mjuka blandas inte;
- oberoende av driftsättning: vi kommer att kunna rulla ut tjänster oberoende så att utvecklingen går snabbare (publicera nya funktioner parallellt);
- utvecklingsoberoende: vi kan ge denna mikrotjänst till ett team/utvecklare och den till en annan, tack vare vilken vi kan utvecklas snabbare;
- боstörre tillförlitlighet: om partiell försämring inträffar (en mikrotjänst av 20 faller) slutar bara en knapp att fungera och systemet som helhet kommer att fortsätta att fungera.
Typisk (skadlig) mikrotjänstarkitektur
För att förklara varför verkligheten inte är vad vi förväntar oss kommer jag att presentera kollektiv en bild av en mikrotjänstarkitektur baserad på erfarenheter från många olika projekt.
Ett exempel skulle vara en abstrakt webbutik som kommer att konkurrera med Amazon eller åtminstone OZON. Dess mikrotjänstarkitektur ser ut så här:
Av en kombination av skäl skrivs dessa mikrotjänster på olika plattformar:
Eftersom varje mikrotjänst måste ha autonomi behöver många av dem sin egen databas och cache. Den slutliga arkitekturen är som följer:
Vilka är dess konsekvenser?
Fowler har detta också — om "betalningen" för att använda mikrotjänster:
Och vi får se om våra förväntningar uppfylldes.
Rensa gränser för moduler...
Men hur många mikrotjänster behöver vi egentligen fixa?att rulla ut förändringen? Kan vi ens ta reda på hur allt fungerar utan en distribuerad spårare (trots allt behandlas varje begäran av hälften av mikrotjänsterna)?
Det finns ett mönster"”, och här visade det sig vara en fördelad smutsklump. För att bekräfta detta, här är en ungefärlig illustration av hur förfrågningar går:
Implementeringsoberoende...
Tekniskt sett har det uppnåtts: vi kan rulla ut varje mikrotjänst separat. Men i praktiken måste man ta hänsyn till att det alltid rullar ut många mikrotjänster, och vi måste ta hänsyn till det ordningen för deras utbyggnad. På ett bra sätt behöver vi generellt testa i en separat krets om vi rullar ut releasen i rätt ordning.
Frihet att välja teknik...
Hon är. Kom bara ihåg att frihet ofta gränsar till laglöshet. Det är väldigt viktigt här att inte välja teknik bara för att "leka" med dem.
Oberoende av utveckling...
Hur gör man en testloop för hela applikationen (med så många komponenter)? Men du måste fortfarande hålla den uppdaterad. Allt detta leder till det faktum att faktiska antalet testkretsar, som vi i princip kan innehålla, visar sig vara minimal.
Vad sägs om att distribuera allt detta lokalt?.. Det visar sig att utvecklaren ofta gör sitt arbete självständigt, men "slumpmässigt", eftersom han tvingas vänta tills kretsen är fri för testning.
Separat skalning...
Ja, men det är begränsat inom området för DBMS som används. I det givna arkitekturexemplet kommer Cassandra inte att ha problem, men MySQL och PostgreSQL kommer.
Боstörre tillförlitlighet...
Inte bara felet i en mikrotjänst i verkligheten bryter ofta hela systemets korrekta funktion, utan det finns också ett nytt problem: att göra varje mikrotjänst feltolerant är mycket svårt. Eftersom mikrotjänster använder olika teknologier (memcache, Redis, etc.), för varje måste du tänka igenom allt och implementera det, vilket naturligtvis är möjligt, men kräver enorma resurser.
Belastningsmätbarhet...
Det här är riktigt bra.
Mikrotjänsternas "lätthet"...
Vi har inte bara enorma nätverksoverhead (förfrågningar om DNS ökar, etc.), men också på grund av de många underfrågor vi startade replikera data (butikscacher), vilket ledde till en betydande mängd lagring.
Och här är resultatet av att uppfylla våra förväntningar:
Men det är inte allt!
eftersom:
- Troligtvis kommer vi att behöva en meddelandebuss.
- Hur gör man en konsekvent säkerhetskopiering vid rätt tidpunkt? Den enda verklig alternativet är att stänga av trafiken för detta. Men hur gör man detta i produktionen?
- Om vi pratar om att stödja flera regioner, så är det en mycket arbetskrävande uppgift att organisera hållbarhet i var och en av dem.
- Problemet med att göra centraliserade förändringar uppstår. Till exempel, om vi behöver uppdatera PHP-versionen måste vi förbinda oss till varje arkiv (och det finns dussintals av dem).
- Tillväxten i operationell komplexitet är direkt exponentiell.
Vad ska man göra med allt detta?
Börja med en monolitisk applikation. Fowlers erfarenhet att nästan alla framgångsrika mikrotjänstapplikationer började som en monolit som blev för stor och sedan gick sönder. Samtidigt upplevde nästan alla system byggda som mikrotjänster från första början förr eller senare allvarliga problem.
En annan värdefull tanke är att för att ett projekt med en mikrotjänstarkitektur ska bli framgångsrikt måste du veta mycket väl och ämnesområde, och hur man gör mikrotjänster. Och det bästa sättet att lära sig ett ämnesområde är att göra en monolit.
Men vad händer om vi redan är i den här situationen?
Det första steget för att lösa ett problem är att hålla med om det och förstå att det är ett problem, att vi inte vill lida längre.
Om vi, i fallet med en övervuxen monolit (när vi har slut på möjligheten att köpa ytterligare resurser för den), skär den, så visar sig i det här fallet den motsatta historien: när överdrivna mikrotjänster inte längre hjälper, men hindrar - skär bort överskott och förstora!
Till exempel, för den samlade bilden som diskuteras ovan...
Bli av med de mest tvivelaktiga mikrotjänsterna:
Kombinera alla mikrotjänster som ansvarar för frontend-generering:
... till en mikrotjänst, skriven i ett (modernt och normalt, som du själv tror) språk/ramverk:
Den kommer att ha en ORM (en DBMS) och först ett par applikationer:
... men i allmänhet kan du överföra mycket mer dit och få följande resultat:
Dessutom kör vi allt detta i Kubernetes i separata instanser, vilket innebär att vi fortfarande kan mäta belastningen och skala dem separat.
För att sammanfatta
Titta på den större bilden. Mycket ofta uppstår alla dessa problem med mikrotjänster för att någon tog sin uppgift, men ville "leka med mikrotjänster".
I ordet "mikrotjänster" är "mikro"-delen överflödig.. De är "mikro" bara för att de är mindre än en enorm monolit. Men se dem inte som något litet.
Och för en sista tanke, låt oss återgå till det ursprungliga diagrammet:
En lapp skriven på den (överst till höger) kokar ner till det faktum att kompetensen hos teamet som gör ditt projekt är alltid primära — de kommer att spela en nyckelroll i ditt val mellan mikrotjänster och en monolit. Om teamet inte har tillräckligt med färdigheter, men det börjar göra mikrotjänster, kommer historien definitivt att bli ödesdiger.
Videor och bilder
Video från talet (~50 minuter; tyvärr förmedlar det inte besökarnas många känslor, som till stor del avgjorde stämningen i rapporten, men det är så det är):
Presentation av rapporten:
PS
Andra rapporter på vår blogg:
- «» (Dmitry Stolyarov; 28 maj 2018 på RootConf);
- «» (Dmitry Stolyarov; 7 november 2017 på HighLoad++);
- «» (Dmitry Stolyarov; 6 juni 2017 på RootConf);
- «» (Dmitry Stolyarov; 8 november 2016 på HighLoad++);
- «» (Dmitry Stolyarov; 31 maj 2016 på RootConf).
Du kan också vara intresserad av följande publikationer:
- «";
- «";
- «".
Källa: will.com