19. September zu Moskau déi éischt thematesch Reunioun HUG (Highload++ User Group), déi fir Mikroservicer gewidmet war. Et war eng Presentatioun "Operating Microservices: Size Matters, Even If You Have Kubernetes", an där mir dem Flant seng extensiv Erfarung an der Operatiounsprojeten mat der Mikroservicearchitektur gedeelt hunn. Als éischt wäert et nëtzlech sinn fir all Entwéckler déi drun denken dës Approche an hirem aktuellen oder zukünftege Projet ze benotzen.
Aféierung (50 Minutten, vill méi informativ wéi den Artikel), souwéi den Haaptextrakt dovunner an Textform.
NB: Video a Presentatioun sinn och um Enn vun dësem Post verfügbar.
Aféierung
Normalerweis huet eng gutt Geschicht en Ufank, en Haaptplott an eng Opléisung. Dëse Bericht ass méi wéi e Optakt, an en trageschen deemno. Et ass och wichteg ze bemierken datt et en Aussebléck vu Mikroservicer ubitt. Ausbeutung.
Ech fänken un mat dëser Grafik, den Auteur vun deem (am 2015) Martin Fowler:
Et weist wéi, am Fall vun enger monolithescher Applikatioun, déi e gewësse Wäert erreecht, d'Produktivitéit ufänkt ze falen. Mikroservicer sinn anescht, datt déi initial Produktivitéit mat hinnen manner ass, awer wéi d'Komplexitéit eropgeet, ass d'Degradatioun vun der Effizienz fir si net sou merkbar.
Ech addéieren dës Grafik fir de Fall vu Kubernetes ze benotzen:
Firwat ass eng Applikatioun mat Mikroservicer besser? Well sou eng Architektur stellt sérieux Ufuerderunge fir d'Architektur, déi am Tour perfekt vun de Fäegkeete vu Kubernetes ofgedeckt sinn. Op der anerer Säit wäert e puer vun dëser Funktionalitéit nëtzlech sinn fir e Monolith, besonnesch well den typesche Monolith haut net genau e Monolith ass (Detailer ginn méi spéit am Bericht).
Wéi Dir gesitt, ass déi lescht Grafik (wann souwuel monolithesch wéi och Mikroservice Uwendungen an der Infrastruktur mat Kubernetes sinn) net ganz anescht wéi déi ursprénglech. Als nächst wäerte mir iwwer Uwendungen schwätzen, déi mat Kubernetes operéiert ginn.
Nëtzlech a schiedlech Mikroservicer
An hei ass d'Haaptidee:
Wat ass normal Mikroservice Architektur? Et sollt Iech real Virdeeler bréngen, Är Aarbechtseffizienz erhéijen. Wa mir zréck op d'Grafik goen, hei ass et:
Wann Dir hir rufft nëtzlech, da gëtt et op der anerer Säit vun der Grafik schiedlech Mikroservicer (interferéiert mat der Aarbecht):
Zréck op d'"Haaptidee": Soll ech meng Erfahrung iwwerhaapt vertrauen? Zënter Ufank vun dësem Joer hunn ech gekuckt 85 Projeten. Net all vun hinnen waren Mikroservicer (ongeféier en Drëttel bis d'Halschent vun hinnen haten esou eng Architektur), awer dëst ass nach ëmmer eng grouss Zuel. Mir (Flant Firma) als Outsourcer verwalten eng breet Varietéit vun Uwendungen ze gesinn entwéckelt souwuel a klenge Firmen (mat 5 Entwéckler) wéi a grousse (~ 500 Entwéckler). En zousätzleche Virdeel ass datt mir dës Uwendungen iwwer d'Jore live gesinn an evoluéieren.
Firwat Mikroservicer?
Op d'Fro iwwer d'Virdeeler vu Mikroservicer gëtt et vum schonn ernimmte Martin Fowler:
- kloer Grenze vun der Modularitéit;
- onofhängeg Détachement;
- Fräiheet Technologien ze wielen.
Ech hu vill mat Software Architekten an Entwéckler geschwat a gefrot firwat se Mikroservicer brauchen. An ech hunn meng Lëscht vun hiren Erwaardungen gemaach. Hei ass wat geschitt ass:
Wa mir e puer vun de Punkte "a Sensatiounen" beschreiwen, dann:
- kloer Grenze vu Moduler: hei hu mir e schreckleche Monolith, an elo gëtt alles ordentlech an Git Repositories arrangéiert, an deenen alles "op de Regaler" ass, déi waarm an déi mëll sinn net gemëscht;
- Deployment Onofhängegkeet: Mir wäerten fäeg sinn Servicer onofhängeg auszerollen, sou datt d'Entwécklung méi séier geet (nei Features parallel publizéieren);
- Entwécklung Onofhängegkeet: mir kënnen dëse Mikroservice un engem Team / Entwéckler ginn, an deen een aneren, dank deem mir méi séier kënne entwéckelen;
- боgréisser Zouverlässegkeet: wann deelweis Degradatioun geschitt (eent Mikroservice vun 20 fällt), da wäert nëmmen ee Knäppchen ophalen ze schaffen, an de System als Ganzt wäert weider funktionnéieren.
Typesch (schiedlech) Mikroservicearchitektur
Fir ze erklären firwat d'Realitéit net ass wat mir erwaarden, wäert ech presentéieren kollektiv e Bild vun enger Mikroservicearchitektur baséiert op Erfahrung vu ville verschiddene Projeten.
E Beispill wier en abstrakte Online Store dee mat Amazon oder op d'mannst OZON konkurréiere wäert. Seng Mikroservicearchitektur gesäit esou aus:
Aus enger Kombinatioun vu Grënn sinn dës Mikroservicer op verschiddene Plattforme geschriwwe ginn:
Well all Mikroservice muss Autonomie hunn, brauche vill vun hinnen hir eege Datebank a Cache. Déi definitiv Architektur ass wéi follegt:
Wat sinn hir Konsequenzen?
De Fowler huet dat och - iwwer d'"Bezuelung" fir d'Benotzung vu Mikroservicer:
A mir wäerte kucken ob eis Erwaardungen erfëllt goufen.
Kloer Grenze vu Moduler ...
mä wéivill Mikroservicer brauche mir tatsächlech ze fixéieren?d'Ännerung auszerollen? Kënne mir iwwerhaapt erausfannen wéi alles ouni verdeelt Tracer funktionnéiert (schliisslech gëtt all Ufro vun der Halschent vun de Mikroservicer veraarbecht)?
Et gëtt e Muster "“, an hei huet sech erausgestallt, datt et e verdeelt Drecksklump war. Fir dëst ze bestätegen, hei ass eng geschätzte Illustratioun wéi Ufroe goen:
Deployment Onofhängegkeet ...
Technesch ass et erreecht ginn: mir kënnen all Mikroservice separat ausrollen. Awer an der Praxis musst Dir berücksichtegen datt et ëmmer rullt vill Mikroservicer, a mir mussen Rechnung huelen d'Uerdnung vun hirer Ausféierung. Op eng gutt Manéier musse mir allgemeng an engem getrennten Circuit testen ob mir d'Verëffentlechung an der korrekter Uerdnung ausrollen.
Fräiheet fir Technologie ze wielen ...
Hatt ass. Denkt just drun datt d'Fräiheet dacks un Gesetzlosegkeet grenzt. Et ass ganz wichteg hei net Technologien ze wielen just fir mat hinnen ze "spillen".
Onofhängegkeet vun der Entwécklung ...
Wéi maachen ech eng Testschleife fir déi ganz Applikatioun (mat sou vill Komponenten)? Awer Dir musst et nach ëmmer um neiste Stand halen. All dëst féiert zu der Tatsaach, datt tatsächlech Zuel vun Test Circuiten, déi mir am Prinzip enthalen kënnen, stellt sech minimal aus.
Wéi wier et iwwer dëst alles lokal ze deployéieren?.. Et stellt sech eraus datt dacks den Entwéckler seng Aarbecht onofhängeg mécht, awer "zoufälleg", well hie gezwongen ass ze waarden bis de Circuit fräi ass fir ze testen.
Separat Skala ...
Jo, awer et ass limitéiert am Beräich vum benotzte DBMS. Am gegebene Architektur Beispill wäert d'Cassandra keng Probleemer hunn, awer MySQL a PostgreSQL wäerten.
Боméi Zouverlässegkeet ...
Net nëmmen de Feeler vun engem Mikroservice an der Realitéit brécht dacks de richtege Fonctionnement vum ganze System, awer et gëtt och en neie Problem: all Mikroservice Feeler-tolerant ze maachen ass ganz schwéier. Well Mikroservicer verschidden Technologien benotzen (Memcache, Redis, asw.), fir jidderee musst Dir alles iwwerdenken an ëmsetzen, wat natierlech méiglech ass, awer enorm Ressourcen erfuerdert.
Belaaschtbarkeet ...
Dëst ass wierklech gutt.
D'"Liichtegkeet" vu Mikroservicer ...
Mir hunn net nëmmen enorm Reseau iwwerhead (Ufroe fir DNS multiplizéieren, etc.), awer och duerch déi vill Ënnersufroen déi mir ugefaang hunn replizéieren Daten (Store Cache), wat zu enger bedeitender Quantitéit u Späichere gefouert huet.
An hei ass d'Resultat fir eis Erwaardungen ze treffen:
Mee dat ass net alles!
Well:
- Wahrscheinlech brauche mir e Message Bus.
- Wéi maachen ech e konsequente Backup am richtege Moment an der Zäit? Den eenzegen real Optioun ass de Verkéier fir dëst auszeschalten. Mä wéi dëst an der Produktioun ze maachen?
- Wa mir schwätzen iwwer d'Ënnerstëtzung vu verschiddene Regiounen, dann ass d'Organisatioun vun der Nohaltegkeet an all eenzel vun hinnen eng ganz Aarbechtsintensiv Aufgab.
- De Problem fir zentraliséiert Ännerungen ze maachen entsteet. Zum Beispill, wa mir d'PHP-Versioun aktualiséieren, musse mir fir all Repository engagéieren (an et ginn Dosende vun hinnen).
- De Wuesstum vun der operationeller Komplexitéit ass, offhand, exponentiell.
Wat maache mat all deem?
Start mat enger monolithescher Applikatioun. Fowler Erfahrung datt bal all erfollegräich Mikroservice Uwendungen als Monolith ugefaang hunn, deen ze grouss gouf an duerno gebrach ass. Zur selwechter Zäit hu bal all Systemer, déi als Mikroservicer vun Ufank un gebaut goufen, fréier oder spéider eescht Problemer erlieft.
En anere wäertvolle Gedanken ass datt fir e Projet mat enger Mikroservicearchitektur erfollegräich ze sinn, musst Dir ganz gutt wëssen a Sujet Beräich, a wéi microservices ze maachen. An de beschte Wee fir e Fachberäich ze léieren ass e Monolith ze maachen.
Awer wat wa mir schonn an dëser Situatioun sinn?
Den éischte Schrëtt fir all Problem ze léisen ass domat averstanen ze sinn an ze verstoen datt et e Problem ass, datt mir net méi wëllen leiden.
Wann, am Fall vun engem iwwerwältegend Monolith (wann mir d'Méiglechkeet hunn fir zousätzlech Ressourcen dofir ze kafen), schneiden mir et, da stellt sech an dësem Fall d'Géigendeel eraus: wann exzessiv Mikroservicer net méi hëllefen, awer behënneren - iwwerschësseg ofschneiden a vergréisseren!
Zum Beispill, fir de kollektive Bild hei uewe diskutéiert ...
Gitt vun de meeschte zweifelhafte Mikroservicer lass:
Kombinéiert all Mikroservicer verantwortlech fir Frontend Generatioun:
... an ee Mikroservice, an enger (moderner an normaler, wéi Dir selwer mengt) Sprooch/Kader geschriwwen:
Et wäert een ORM (een DBMS) hunn an als éischt e puer Uwendungen:
... awer am Allgemengen kënnt Dir vill méi dohinner transferéieren, an dat folgend Resultat kritt:
Ausserdeem, a Kubernetes lafe mir dat alles a getrennten Instanzen, dat heescht datt mir nach ëmmer d'Laascht moossen an se separat skaléieren.
Ze resuméieren
Kuckt de gréissere Bild. Ganz dacks entstinn all dës Probleemer mat Mikroservicer, well een seng Aufgab geholl huet, awer wollt "mat Mikroservicer spillen".
Am Wuert "Mikroservicer" ass de "Mikro" Deel iwwerflësseg.. Si sinn "Mikro" nëmme well se méi kleng sinn wéi e risege Monolith. Denkt awer net un se als eppes Klenges.
A fir e leschte Gedanken, loosst eis zréck op déi ursprénglech Diagramm:
Eng Notiz drop geschriwwen (uewen riets) kacht op d'Tatsaach, datt d'Fäegkeete vum Team dat Äre Projet mécht sinn ëmmer primär - si wäerten eng Schlësselroll an Ärer Wiel tëscht Mikroservicer an engem Monolith spillen. Wann d'Team net genuch Fäegkeeten huet, awer et fänkt un Mikroservicer ze maachen, wäert d'Geschicht definitiv fatal sinn.
Videoen a Rutschen
Video vun der Ried (~50 Minutten; leider vermëttelt et net déi vill Emotiounen vun de Besucher, déi d'Stëmmung vum Bericht gréisstendeels bestëmmt hunn, awer dat ass wéi et ass):
Presentatioun vum Rapport:
PS
Aner Berichter op eisem Blog:
- «» (Dmitry Stolyarov; Mee 28, 2018 bei RootConf);
- «» (Dmitry Stolyarov; 7. November 2017 op HighLoad++);
- «» (Dmitry Stolyarov; Juni 6, 2017 bei RootConf);
- «» (Dmitry Stolyarov; 8. November 2016 op HighLoad++);
- «» (Dmitry Stolyarov; Mee 31, 2016 bei RootConf).
Dir kënnt och un de folgende Publikatiounen interesséiert sinn:
- «";
- «";
- «".
Source: will.com