19 September in Moskou die eerste tematiese vergadering HUG (Highload++ User Group), wat aan mikrodienste gewy is. Daar was 'n aanbieding "Operating Microservices: Size Matters, Self If You Have Kubernetes," waarin ons Flant se uitgebreide ervaring in die bedryf van projekte met mikrodiensargitektuur gedeel het. Eerstens sal dit nuttig wees vir alle ontwikkelaars wat daaraan dink om hierdie benadering in hul huidige of toekomstige projek te gebruik.
Bekendstelling (50 minute, baie meer insiggewend as die artikel), asook die hoofuittreksel daaruit in teksvorm.
NB: Video en aanbieding is ook beskikbaar aan die einde van hierdie berig.
Inleiding
Gewoonlik het 'n goeie storie 'n begin, 'n hoofintrige en 'n resolusie. Hierdie verslag is meer soos 'n voorspel, en 'n tragiese een daarby. Dit is ook belangrik om daarop te let dat dit 'n buitestaander se siening van mikrodienste verskaf. uitbuiting.
Ek begin met hierdie grafiek, waarvan die skrywer (in 2015) Martin Fowler:
Dit wys hoe produktiwiteit in die geval van 'n monolitiese toepassing wat 'n sekere waarde bereik, begin afneem. Mikrodienste verskil deurdat die aanvanklike produktiwiteit daarmee laer is, maar namate kompleksiteit toeneem, is die agteruitgang in doeltreffendheid nie vir hulle so opvallend nie.
Ek sal by hierdie grafiek voeg vir die geval van die gebruik van Kubernetes:
Waarom is 'n toepassing met mikrodienste beter? Omdat so 'n argitektuur ernstige vereistes vir die argitektuur stel, wat op sy beurt perfek gedek word deur die vermoëns van Kubernetes. Aan die ander kant sal sommige van hierdie funksionaliteit nuttig wees vir 'n monoliet, veral omdat die tipiese monoliet vandag nie juis 'n monoliet is nie (besonderhede sal later in die verslag wees).
Soos u kan sien, verskil die finale grafiek (wanneer beide monolitiese en mikrodienstoepassings in die infrastruktuur met Kubernetes is) nie baie van die oorspronklike een nie. Volgende sal ons praat oor toepassings wat met Kubernetes bedryf word.
Nuttige en skadelike mikrodienste
En hier is die hoofgedagte:
wat is normaal mikrodiens argitektuur? Dit behoort vir jou werklike voordele te bring, wat jou werkdoeltreffendheid verhoog. As ons teruggaan na die grafiek, hier is dit:
As jy haar bel nuttig, dan sal daar aan die ander kant van die grafiek wees skadelik mikrodienste (inmeng met werk):
Om terug te keer na die "hoofgedagte": moet ek enigsins my ervaring vertrou? Sedert die begin van hierdie jaar het ek gekyk 85 projekte. Nie almal van hulle was mikrodienste nie (ongeveer 'n derde tot die helfte van hulle het so 'n argitektuur gehad), maar dit is steeds 'n groot aantal. Ons (Flant-maatskappy) as uitkontrakteurs kry dit reg om 'n wye verskeidenheid toepassings te sien wat beide in klein maatskappye (met 5 ontwikkelaars) en in groot (~ 500 ontwikkelaars) ontwikkel word. 'n Bykomende voordeel is dat ons sien hoe hierdie toepassings oor die jare leef en ontwikkel.
Hoekom mikrodienste?
Op die vraag oor die voordele van mikrodienste is daar van die reeds genoemde Martin Fowler:
- duidelike grense van modulariteit;
- onafhanklike ontplooiing;
- vryheid om tegnologie te kies.
Ek het al baie met sagteware-argitekte en -ontwikkelaars gepraat en gevra hoekom hulle mikrodienste nodig het. En ek het my lysie van hul verwagtinge gemaak. Hier is wat gebeur het:
As ons sommige van die punte "in sensasies" beskryf, dan:
- duidelike grense van modules: hier het ons 'n verskriklike monoliet, en nou sal alles netjies gerangskik word in Git-bewaarplekke, waarin alles "op die rakke" is, die warm en die sagte word nie gemeng nie;
- ontplooiing onafhanklikheid: ons sal dienste onafhanklik kan uitrol sodat ontwikkeling vinniger gaan (publiseer nuwe kenmerke in parallel);
- ontwikkelingsonafhanklikheid: ons kan hierdie mikrodiens aan een span/ontwikkelaar gee, en die een aan 'n ander, waardeur ons vinniger kan ontwikkel;
- боgroter betroubaarheid: as gedeeltelike agteruitgang plaasvind (een mikrodiens uit 20 val), dan sal net een knoppie ophou werk, en die stelsel as geheel sal voortgaan om te funksioneer.
Tipiese (skadelike) mikrodiensargitektuur
Om te verduidelik hoekom die werklikheid nie is wat ons verwag nie, sal ek aanbied kollektief 'n beeld van 'n mikrodiensargitektuur gebaseer op ervaring van baie verskillende projekte.
'n Voorbeeld sou 'n abstrakte aanlynwinkel wees wat met Amazon of ten minste OZON gaan meeding. Die mikrodiensargitektuur daarvan lyk soos volg:
Om 'n kombinasie van redes word hierdie mikrodienste op verskillende platforms geskryf:
Aangesien elke mikrodiens outonomie moet hê, benodig baie van hulle hul eie databasis en kas. Die finale argitektuur is soos volg:
Wat is die gevolge daarvan?
Fowler het dit ook - oor die "betaling" vir die gebruik van mikrodienste:
En ons sal kyk of daar aan ons verwagtinge voldoen is.
Duidelike grense van modules...
Maar hoeveel mikrodienste moet ons eintlik regmaak?om die verandering uit te voer? Kan ons selfs uitvind hoe alles werk sonder 'n verspreide spoorsnyer (enige versoek word immers deur die helfte van die mikrodienste verwerk)?
Daar is 'n patroon"“, en hier blyk dit 'n verspreide klomp vuil te wees. Om dit te bevestig, is hier 'n benaderde illustrasie van hoe versoeke verloop:
Ontplooiing onafhanklikheid...
Tegnies is dit bereik: ons kan elke mikrodiens afsonderlik uitrol. Maar in die praktyk moet jy in ag neem dat dit altyd uitrol baie mikrodienste, en ons moet in ag neem die volgorde van hul ontplooiing. Op 'n goeie manier moet ons oor die algemeen in 'n aparte stroombaan toets of ons die vrystelling in die regte volgorde uitrol.
Vryheid om tegnologie te kies...
Sy is. Onthou net dat vryheid dikwels grens aan wetteloosheid. Dit is hier baie belangrik om nie tegnologieë te kies net om daarmee te "speel" nie.
Onafhanklikheid van ontwikkeling...
Hoe om 'n toetslus vir die hele toepassing (met soveel komponente) te maak? Maar jy moet dit steeds op datum hou. Dit alles lei tot die feit dat werklike aantal toetsbane, wat ons in beginsel kan bevat, blyk minimaal te wees.
Hoe gaan dit met om dit alles plaaslik te ontplooi?.. Dit blyk dat die ontwikkelaar dikwels sy werk onafhanklik doen, maar "lukraak", omdat hy gedwing word om te wag totdat die kring vry is vir toetsing.
Afsonderlike skaal...
Ja, maar dit is beperk in die area van die DBMS wat gebruik word. In die gegewe argitektuurvoorbeeld sal Cassandra nie probleme hê nie, maar MySQL en PostgreSQL sal.
Боgroter betroubaarheid...
Nie net breek die mislukking van een mikrodiens in werklikheid dikwels die korrekte funksionering van die hele stelsel nie, maar daar is ook 'n nuwe probleem: om elke mikrodiens fouttolerant te maak, is baie moeilik. Omdat mikrodienste verskillende tegnologieë (memcache, Redis, ens.) gebruik, moet jy vir elkeen alles deurdink en implementeer, wat natuurlik moontlik is, maar groot hulpbronne verg.
Laai meetbaarheid...
Dit is regtig goed.
Die "ligtheid" van mikrodienste...
Ons het nie net groot nie netwerk bokoste (versoeke vir DNS vermeerder, ens.), maar ook as gevolg van die baie subnavrae wat ons begin het data te repliseer (winkelkas), wat gelei het tot 'n aansienlike hoeveelheid berging.
En hier is die resultaat van voldoening aan ons verwagtinge:
Maar dit is nie al nie!
Omdat:
- Heel waarskynlik sal ons 'n boodskapbus nodig hê.
- Hoe om 'n konsekwente rugsteun op die regte oomblik in tyd te maak? Die enigste een werklike opsie is om verkeer hiervoor af te skakel. Maar hoe om dit in produksie te doen?
- As ons praat van die ondersteuning van verskeie streke, dan is die organisering van volhoubaarheid in elkeen van hulle 'n baie arbeidsintensiewe taak.
- Die probleem om gesentraliseerde veranderinge aan te bring, ontstaan. Byvoorbeeld, as ons die PHP-weergawe moet opdateer, sal ons ons moet verbind tot elke bewaarplek (en daar is dosyne van hulle).
- Die groei in bedryfskompleksiteit is vanselfsprekend eksponensieel.
Wat om met dit alles te doen?
Begin met 'n monolitiese toepassing. Fowler se ervaring dat byna alle suksesvolle mikrodienstoepassings as 'n monoliet begin het wat te groot geword het en toe gebreek is. Terselfdertyd het feitlik alle stelsels wat van die begin af as mikrodienste gebou is vroeër of later ernstige probleme ondervind.
Nog 'n waardevolle gedagte is dat jy baie goed moet weet vir 'n projek met 'n mikrodiensargitektuur om suksesvol te wees en vakgebied, en hoe om mikrodienste te maak. En die beste manier om 'n vakgebied te leer, is om 'n monoliet te maak.
Maar wat as ons reeds in hierdie situasie is?
Die eerste stap om enige probleem op te los, is om daarmee saam te stem en te verstaan dat dit 'n probleem is, dat ons nie meer wil ly nie.
As ons, in die geval van 'n oorgroeide monoliet (wanneer ons nie meer die geleentheid gehad het om bykomende hulpbronne daarvoor aan te koop nie), dit sny, dan blyk die teenoorgestelde storie in hierdie geval: wanneer oormatige mikrodienste nie meer help nie, maar belemmer - sny oortollige af en vergroot!
Byvoorbeeld, vir die kollektiewe beeld wat hierbo bespreek is ...
Raak ontslae van die mees twyfelagtige mikrodienste:
Kombineer alle mikrodienste wat verantwoordelik is vir frontend-generering:
... in een mikrodiens, geskryf in een (modern en normaal, soos jy self dink) taal/raamwerk:
Dit sal een ORM (een DBMS) hê en eers 'n paar toepassings:
... maar oor die algemeen kan jy baie meer daarheen oordra, wat die volgende resultaat kry:
Boonop loop ons dit alles in Kubernetes in afsonderlike gevalle, wat beteken dat ons steeds die las kan meet en afsonderlik skaal.
Op te som
Kyk na die groter prentjie. Baie dikwels ontstaan al hierdie probleme met mikrodienste omdat iemand hul taak geneem het, maar wou "speel met mikrodienste".
In die woord "mikrodienste" is die "mikro"-deel oorbodig.. Hulle is "mikro" net omdat hulle kleiner as 'n groot monoliet is. Maar moenie aan hulle dink as iets klein nie.
En vir 'n laaste gedagte, kom ons keer terug na die oorspronklike grafiek:
'n Nota daarop geskryf (regs bo) kom daarop neer dat die vaardighede van die span wat jou projek maak, is altyd primêr — hulle sal 'n sleutelrol speel in jou keuse tussen mikrodienste en 'n monoliet. As die span nie genoeg vaardighede het nie, maar dit begin mikrodienste maak, sal die storie beslis noodlottig wees.
Video's en skyfies
Video uit die toespraak (~50 minute; dit dra ongelukkig nie die talle emosies van die besoekers oor wat grootliks die stemming van die berig bepaal het nie, maar dit is hoe dit is):
Verslagaanbieding:
PS
Ander berigte op ons blog:
- «» (Dmitri Stolyarov; 28 Mei 2018 by RootConf);
- «» (Dmitri Stolyarov; 7 November 2017 op HighLoad++);
- «» (Dmitri Stolyarov; 6 Junie 2017 by RootConf);
- «» (Dmitri Stolyarov; 8 November 2016 op HighLoad++);
- «» (Dmitri Stolyarov; 31 Mei 2016 by RootConf).
Jy sal dalk ook belangstel in die volgende publikasies:
- «»;
- «»;
- «".
Bron: will.com