19 september in Moskou de eerste thematische bijeenkomst HUG (Highload++ User Group), die gewijd was aan microservices. Er was een presentatie ‘Operating Microservices: Size Matters, Even If You Have Kubernetes’, waarin we Flants uitgebreide ervaring met het uitvoeren van projecten met microservice-architectuur deelden. Allereerst zal het nuttig zijn voor alle ontwikkelaars die erover nadenken om deze aanpak in hun huidige of toekomstige project te gebruiken.
Even voorstellen (50 minuten, veel informatiever dan het artikel), evenals het belangrijkste fragment daaruit in tekstvorm.
NB: Video en presentatie zijn ook beschikbaar aan het einde van dit bericht.
Introductie
Meestal heeft een goed verhaal een begin, een hoofdplot en een oplossing. Dit rapport lijkt meer op een opmaat, en bovendien tragisch. Het is ook belangrijk op te merken dat het de kijk van een buitenstaander op microservices biedt. exploitatie.
Ik begin met deze grafiek, waarvan de auteur (in 2015) Martin Fowler:
Het laat zien hoe, in het geval van een monolithische toepassing die een bepaalde waarde bereikt, de productiviteit begint af te nemen. Microservices onderscheiden zich doordat de initiële productiviteit ervan lager is, maar naarmate de complexiteit toeneemt, is de achteruitgang in efficiëntie voor hen niet zo merkbaar.
Ik zal aan deze grafiek toevoegen voor het geval dat Kubernetes wordt gebruikt:
Waarom is een applicatie met microservices beter? Want zo’n architectuur stelt serieuze eisen aan de architectuur, die weer prima gedekt worden door de mogelijkheden van Kubernetes. Aan de andere kant zal een deel van deze functionaliteit nuttig zijn voor een monoliet, vooral omdat de typische monoliet van vandaag niet bepaald een monoliet is (details volgen later in het rapport).
Zoals u kunt zien, verschilt de uiteindelijke grafiek (wanneer zowel monolithische als microservice-applicaties zich in de infrastructuur met Kubernetes bevinden) niet veel van de oorspronkelijke. Vervolgens zullen we het hebben over applicaties die worden beheerd met Kubernetes.
Nuttige en schadelijke microservices
En hier is het hoofdidee:
Wat is normaal microservice-architectuur? Het zou u echte voordelen moeten opleveren, waardoor uw werkefficiëntie toeneemt. Als we teruggaan naar de grafiek, is het hier:
Als je haar belt bruikbaar, dan zal er aan de andere kant van de grafiek zijn schadelijk microservices (verstoort het werk):
Terugkomend op het “hoofdidee”: moet ik überhaupt op mijn ervaring vertrouwen? Sinds begin dit jaar ben ik gaan kijken 85 projecten. Het waren niet allemaal microservices (ongeveer een derde tot de helft had een dergelijke architectuur), maar dit is nog steeds een groot aantal. Wij (bedrijf Flant) als uitbesteders zien een grote verscheidenheid aan applicaties ontwikkeld, zowel in kleine bedrijven (met 5 ontwikkelaars) als in grote bedrijven (~500 ontwikkelaars). Een bijkomend voordeel is dat we deze applicaties door de jaren heen live zien en evolueren.
Waarom microservices?
Op de vraag over de voordelen van microservices is er van de reeds genoemde Martin Fowler:
- duidelijke grenzen van modulariteit;
- onafhankelijke inzet;
- vrijheid om technologieën te kiezen.
Ik heb veel met softwarearchitecten en -ontwikkelaars gesproken en gevraagd waarom ze microservices nodig hebben. En ik maakte mijn lijst met hun verwachtingen. Dit is wat er gebeurde:
Als we enkele van de punten ‘in sensaties’ beschrijven, dan:
- duidelijke grenzen van modules: hier hebben we een vreselijke monoliet, en nu wordt alles netjes gerangschikt in Git-repository's, waarin alles "op de planken" ligt, het warme en het zachte niet gemengd zijn;
- implementatie-onafhankelijkheid: we zullen diensten zelfstandig kunnen uitrollen zodat de ontwikkeling sneller gaat (nieuwe features parallel publiceren);
- ontwikkelingsonafhankelijkheid: we kunnen deze microservice aan het ene team/ontwikkelaar geven, en die aan het andere, waardoor we sneller kunnen ontwikkelen;
- боgrotere betrouwbaarheid: als er gedeeltelijke degradatie optreedt (één op de twintig microservices valt uit), dan stopt slechts één knop met werken en blijft het systeem als geheel functioneren.
Typische (schadelijke) microservice-architectuur
Om uit te leggen waarom de werkelijkheid niet is wat we verwachten, zal ik een presentatie geven collectief een beeld van een microservice-architectuur gebaseerd op ervaringen uit veel verschillende projecten.
Een voorbeeld hiervan is een abstracte webwinkel die gaat concurreren met Amazon of in ieder geval OZON. De microservice-architectuur ziet er als volgt uit:
Om een combinatie van redenen worden deze microservices op verschillende platforms geschreven:
Omdat elke microservice autonomie moet hebben, hebben veel ervan hun eigen database en cache nodig. De uiteindelijke architectuur is als volgt:
Wat zijn de gevolgen ervan?
Fowler heeft dit ook — over de “betaling” voor het gebruik van microservices:
En we zullen zien of onze verwachtingen zijn waargemaakt.
Duidelijke grenzen van modules...
Maar Hoeveel microservices moeten we eigenlijk repareren?de wijziging door te voeren? Kunnen we er zelfs achter komen hoe alles werkt zonder een gedistribueerde tracer (elk verzoek wordt immers door de helft van de microservices verwerkt)?
Er is een patroon"“, en hier bleek het een verspreide brok aarde te zijn. Om dit te bevestigen, volgt hier een geschatte illustratie van hoe verzoeken verlopen:
Onafhankelijkheid van implementatie...
Technisch gezien is het gelukt: we kunnen elke microservice afzonderlijk uitrollen. Maar in de praktijk moet je er rekening mee houden dat het altijd uitrolt veel microservices, en waar we rekening mee moeten houden de volgorde van uitrol. Op een goede manier moeten we doorgaans in een apart circuit testen of we de release in de juiste volgorde uitrollen.
Vrijheid om technologie te kiezen...
Zij is. Vergeet niet dat vrijheid vaak grenst aan wetteloosheid. Het is hier heel belangrijk om technologieën niet alleen maar te kiezen om ermee te ‘spelen’.
Onafhankelijkheid van ontwikkeling...
Hoe maak je een testlus voor de hele applicatie (met zoveel componenten)? Maar je moet het wel up-to-date houden. Dit alles leidt tot het feit dat werkelijke aantal testcircuits, die we in principe kunnen bevatten, blijkt minimaal te zijn.
Wat dacht je ervan om dit allemaal lokaal uit te rollen?.. Vaak blijkt dat de ontwikkelaar zijn werk zelfstandig doet, maar wel ‘at random’, omdat hij gedwongen wordt te wachten tot het circuit vrij is om te testen.
Aparte schaalverdeling...
Ja, maar het is beperkt op het gebied van het gebruikte DBMS. In het gegeven architectuurvoorbeeld zal Cassandra geen problemen hebben, maar MySQL en PostgreSQL wel.
Боgrotere betrouwbaarheid...
Niet alleen leidt het falen van één microservice in werkelijkheid vaak tot verstoring van de correcte werking van het hele systeem, maar er doet zich ook een nieuw probleem voor: elke microservice fouttolerant maken is erg moeilijk. Omdat microservices verschillende technologieën gebruiken (memcache, Redis, enz.), moet je voor elk alles doordenken en implementeren, wat natuurlijk mogelijk is, maar enorme middelen vereist.
Meetbaarheid laden...
Dit is heel goed.
De "lichtheid" van microservices...
We hebben niet alleen enorm netwerk-overhead (het aantal aanvragen voor DNS neemt toe, enz.), maar ook vanwege de vele subquery's die we zijn gestart gegevens repliceren (winkelcaches), wat leidde tot een aanzienlijke hoeveelheid opslagruimte.
En hier is het resultaat van het voldoen aan onze verwachtingen:
Maar dat is niet alles!
Omdat:
- Hoogstwaarschijnlijk hebben we een berichtenbus nodig.
- Hoe maak je een consistente back-up op het juiste moment? De enige echt optie is om hiervoor het verkeer uit te zetten. Maar hoe doe je dit in de productie?
- Als we het hebben over het ondersteunen van meerdere regio's, dan is het organiseren van duurzaamheid in elk van deze regio's een zeer arbeidsintensieve taak.
- Het probleem van het maken van gecentraliseerde veranderingen doet zich voor. Als we bijvoorbeeld de PHP-versie moeten updaten, zullen we ons moeten committeren aan elke repository (en dat zijn er tientallen).
- De groei van de operationele complexiteit is exponentieel.
Wat te doen met dit alles?
Begin met een monolithische toepassing. Fowlers ervaring dat bijna alle succesvolle microservice-applicaties begonnen als een monoliet die te groot werd en vervolgens kapot ging. Tegelijkertijd ondervonden bijna alle systemen die vanaf het allereerste begin als microservices waren gebouwd, vroeg of laat ernstige problemen.
Een andere waardevolle gedachte is dat je, om een project met een microservice-architectuur succesvol te laten zijn, het heel goed moet weten en vakgebied, en hoe u microservices kunt maken. En de beste manier om een vakgebied te leren is door een monoliet te maken.
Maar wat als we ons al in deze situatie bevinden?
De eerste stap bij het oplossen van welk probleem dan ook is het ermee eens zijn en begrijpen dat het een probleem is, waar we niet meer onder willen lijden.
Als we in het geval van een overwoekerde monoliet (wanneer we geen mogelijkheid meer hebben om er extra middelen voor aan te schaffen) deze inkorten, dan blijkt in dit geval het tegenovergestelde verhaal: wanneer buitensporige microservices niet langer helpen, maar belemmeren - snij overtollig materiaal af en vergroot!
Voor het hierboven besproken collectieve beeld bijvoorbeeld...
Weg met de meest twijfelachtige microservices:
Combineer alle microservices die verantwoordelijk zijn voor het genereren van frontend:
... in één microservice, geschreven in één (modern en normaal, zoals je zelf denkt) taal/framework:
Het zal één ORM (één DBMS) hebben en eerst een paar applicaties:
... maar over het algemeen kun je daar veel meer overboeken, met het volgende resultaat:
Bovendien draaien we dit in Kubernetes allemaal in aparte instances, waardoor we de belasting toch apart kunnen meten en schalen.
Samenvattend
Kijk naar het grotere geheel. Heel vaak ontstaan al deze problemen met microservices omdat iemand zijn taak op zich heeft genomen, maar “met microservices wilde spelen”.
In het woord "microservices" is het gedeelte "micro" overbodig.. Ze zijn alleen ‘micro’ omdat ze kleiner zijn dan een enorme monoliet. Maar beschouw ze niet als iets kleins.
En laten we voor een laatste gedachte terugkeren naar de oorspronkelijke grafiek:
Er is een briefje op geschreven (rechtsboven) komt neer op het feit dat de vaardigheden van het team dat uw project maakt, staan altijd voorop — ze zullen een sleutelrol spelen bij uw keuze tussen microservices en een monoliet. Als het team niet over voldoende vaardigheden beschikt, maar wel microservices gaat maken, zal het verhaal zeker fataal zijn.
Video's en dia's
Video van de toespraak (~50 minuten; helaas geeft deze niet de talrijke emoties van de bezoekers weer, die grotendeels de sfeer van het rapport bepaalden, maar zo is het wel):
Presentatie van het rapport:
PS
Andere rapporten op onze blog:
- «» (Dmitry Stolyarov; 28 mei 2018 bij RootConf);
- «» (Dmitry Stolyarov; 7 november 2017 op HighLoad++);
- «» (Dmitry Stolyarov; 6 juni 2017 bij RootConf);
- «» (Dmitry Stolyarov; 8 november 2016 op HighLoad++);
- «» (Dmitry Stolyarov; 31 mei 2016 bij RootConf).
Mogelijk bent u ook geïnteresseerd in de volgende publicaties:
- «";
- «";
- «.
Bron: www.habr.com