19 septimber yn Moskou de earste tematyske gearkomste HUG (Highload ++ User Group), dy't wijd wie oan mikrotsjinsten. D'r wie in presintaasje "Operearjen fan mikrotsjinsten: grutte is wichtich, sels as jo Kubernetes hawwe," wêryn wy de wiidweidige ûnderfining fan Flant dielde yn it operearjen fan projekten mei mikroservicearsjitektuer. Alderearst sil it nuttich wêze foar alle ûntwikkelders dy't tinke oer it brûken fan dizze oanpak yn har hjoeddeistige as takomstige projekt.
Yntroduksje (50 minuten, folle ynformatyfr as it artikel), en ek it haadúttreksel derút yn tekstfoarm.
NB: Fideo en presintaasje binne ek beskikber oan 'e ein fan dit berjocht.
Ynlieding
Meastal hat in goed ferhaal in begjin, in haadplot en in resolúsje. Dit ferslach is mear as in prelude, en dan ek in tragyske. It is ek wichtich om te notearjen dat it in werjefte fan in bûtensteander jout oer mikrotsjinsten. eksploitaasje.
Ik sil begjinne mei dizze grafyk, wêrfan de skriuwer (yn 2015) Martin Fowler:
It lit sjen hoe't, yn it gefal fan in monolityske tapassing dy't in bepaalde wearde berikt, de produktiviteit begjint te sakjen. Mikrotsjinsten binne oars yn dat de earste produktiviteit mei har is leger, mar as kompleksiteit ferheget, is de degradaasje yn effisjinsje net sa merkber foar har.
Ik sil tafoegje oan dizze grafyk foar it gefal fan it brûken fan Kubernetes:
Wêrom is in applikaasje mei mikrotsjinsten better? Om't sa'n arsjitektuer serieuze easken stelt foar de arsjitektuer, dy't op har beurt perfoarst dekt wurde troch de mooglikheden fan Kubernetes. Oan 'e oare kant sil guon fan dizze funksjonaliteit nuttich wêze foar in monolyt, benammen om't de typyske monolith hjoed net krekt in monolit is (details sille letter yn it rapport wêze).
As jo sjogge, is de definitive grafyk (as sawol monolityske as mikroserviceapplikaasjes yn 'e ynfrastruktuer binne mei Kubernetes) net heul oars as de oarspronklike. Folgjende sille wy prate oer applikaasjes eksploitearre mei Kubernetes.
Nuttige en skealike mikrotsjinsten
En hjir is it haad idee:
Wat is normaal microservice arsjitektuer? It soe jo echte foardielen moatte bringe, jo wurkeffektiviteit ferheegje. As wy weromgean nei de grafyk, hjir is it:
As jo belje har brûkber, dan oan 'e oare kant fan' e grafyk sil der wêze skealik mikrotsjinsten (ynterferinsje mei wurk):
Werom nei it "haadgedachte": moat ik myn ûnderfining überhaupt fertrouwe? Sûnt begjin dit jier haw ik sjoen 85 projekten. Net allegear wiene mikrotsjinsten (sawat in tredde oant de helte fan har hie sa'n arsjitektuer), mar dit is noch altyd in grut oantal. Wy (Flant bedriuw) as outsourcers slagje in breed ferskaat oan applikaasjes te sjen ûntwikkele sawol yn lytse bedriuwen (mei 5 ûntwikkelders) as yn grutte (~ 500 ûntwikkelders). In tafoege foardiel is dat wy dizze applikaasjes yn 'e rin fan' e jierren libje en evoluearje.
Wêrom mikrotsjinsten?
Oan 'e fraach oer de foardielen fan mikrotsjinsten is d'r fan de al neamde Martin Fowler:
- dúdlike grinzen fan modulariteit;
- ûnôfhinklike ynset;
- frijheid om technologyen te kiezen.
Ik haw in protte praat mei software-arsjitekten en ûntwikkelders en frege wêrom't se mikrotsjinsten nedich binne. En ik makke myn list fan har ferwachtingen. Hjir is wat der bard is:
As wy guon fan 'e punten "yn sensaasjes" beskriuwe, dan:
- dúdlike grinzen fan modules: hjir hawwe wy in skriklike monolith, en no sil alles kreas regele wurde yn Git-repositories, wêryn alles "op 'e planken" is, it waarm en it sêfte binne net mingd;
- ûnôfhinklikens fan ynset: wy sille tsjinsten selsstannich útrolje kinne, sadat de ûntwikkeling rapper giet (publisearje nije funksjes parallel);
- Unôfhinklikens fan ûntwikkeling: wy kinne dizze mikrotsjinst jaan oan ien team / ûntwikkelder, en dat oan 'e oare, wêrtroch't wy rapper ûntwikkelje kinne;
- боgruttere betrouberens: as in part degradaasje optreedt (ien microservice fan 20 falt), dan mar ien knop sil ophâlde te wurkjen, en it systeem as gehiel sil fierder te funksjonearjen.
Typyske (skealike) microservice-arsjitektuer
Om út te lizzen wêrom't de werklikheid net is wat wy ferwachtsje, sil ik presintearje kollektyf in byld fan in mikroservice-arsjitektuer basearre op ûnderfining fan in protte ferskillende projekten.
In foarbyld soe in abstrakte online winkel wêze dy't sil konkurrearje mei Amazon of op syn minst OZON. De microservice-arsjitektuer sjocht der sa út:
Om in kombinaasje fan redenen wurde dizze mikrotsjinsten skreaun op ferskate platfoarms:
Sûnt elke mikrotsjinst autonomy moat hawwe, hawwe in protte fan harren har eigen database en cache nedich. De definitive arsjitektuer is as folget:
Wat binne de gefolgen dêrfan?
Fowler hat dit ek - oer de "betelling" foar it brûken fan mikrotsjinsten:
En wy sille sjen oft ús ferwachtingen foldien binne.
Dúdlike grinzen fan modules ...
mar hoefolle mikrotsjinsten moatte wy eins reparearje?om de feroaring út te rollen? Kinne wy sels útfine hoe't alles wurket sûnder in ferdield tracer (ommers, elk fersyk wurdt ferwurke troch de helte fan 'e mikrotsjinsten)?
Der is in patroan "“, en hjir die bliken dat it in ferspraat brok smoargens wie. Om dit te befêstigjen, is hjir in ûngefear yllustraasje fan hoe't fersiken gean:
Unôfhinklikens fan ynset ...
Technysk is it berikt: wy kinne elke mikrotsjinst apart útrolje. Mar yn 'e praktyk moatte jo der rekken mei hâlde dat it altyd rôlet út in protte mikroservices, en wy moatte rekken hâlde de folchoarder fan harren útrol. Op in goede manier moatte wy yn 't algemien yn in apart sirkwy testen oft wy de frijlitting yn' e juste folchoarder rôlje.
Frijheid om technology te kiezen ...
Sy is. Unthâld gewoan dat frijheid faak grinzet oan wetteloosheid. It is hjir heul wichtich om technologyen net te kiezen om gewoan mei har te "spieljen".
Unôfhinklikens fan ûntwikkeling ...
Hoe meitsje ik in testloop foar de heule applikaasje (mei safolle komponinten)? Mar jo moatte it noch by de tiid hâlde. Dit alles liedt ta it feit dat werklike oantal test circuits, dy't wy yn prinsipe befetsje kinne, blykt minimaal te wêzen.
Hoe sit it mei dit alles lokaal ynsette?.. It docht bliken dat de ûntwikkelder syn wurk faak selsstannich docht, mar "willekeurich", om't er twongen wurdt te wachtsjen oant it circuit frij is foar testen.
Aparte skaalfergrutting...
Ja, mar it is beheind yn it gebiet fan 'e brûkte DBMS. Yn it opjûne arsjitektuerfoarbyld sil Cassandra gjin problemen hawwe, mar MySQL en PostgreSQL sille.
Боgruttere betrouberens ...
Net allinich brekt it mislearjen fan ien mikrotsjinst yn 'e realiteit faaks it goede funksjonearjen fan it heule systeem, mar d'r is ek in nij probleem: it meitsjen fan elke mikroservice fouttolerant is heul lestich. Om't mikrotsjinsten ferskate technologyen brûke (memcache, Redis, ensfh.), Foar elk moatte jo alles trochtinke en it útfiere, wat, fansels, mooglik is, mar enoarme boarnen fereasket.
Mjitberens fan lading ...
Dit is echt goed.
De "ljochtheid" fan mikrotsjinsten ...
Wy hawwe net allinnich grutte netwurk overhead (oanfragen foar DNS wurde fermannichfâldige, ensfh.), Mar ek troch de protte subqueries dy't wy begûnen replicate gegevens (winkelcaches), wat late ta in signifikante hoemannichte opslach.
En hjir is it resultaat fan it foldwaan oan ús ferwachtingen:
Mar dat is net alles!
Omdat:
- Meast wierskynlik sille wy in berjochtbus nedich wêze.
- Hoe meitsje in konsekwinte reservekopy op it juste momint yn 'e tiid? De ienige echt opsje is om it ferkear hjirfoar út te skeakeljen. Mar hoe te dwaan dit yn produksje?
- As wy it hawwe oer it stypjen fan ferskate regio's, dan is it organisearjen fan duorsumens yn elk fan har in heul arbeidsintensive taak.
- It probleem fan it meitsjen fan sintralisearre feroarings ûntstiet. Bygelyks, as wy de PHP-ferzje moatte bywurkje, moatte wy ús ynsette foar elke repository (en d'r binne tsientallen fan har).
- De groei yn operasjonele kompleksiteit is, offhand, eksponinsjele.
Wat te dwaan mei dit alles?
Begjin mei in monolityske applikaasje. Fowler syn ûnderfining dat hast alle suksesfolle microservice applikaasjes begûn as in monolith dat waard te grut en waard dan brutsen. Tagelyk hawwe hast alle systemen boud as mikrotsjinsten fan it begjin ôf earder of letter serieuze problemen.
In oare weardefolle gedachte is dat foar in projekt mei in mikroservice-arsjitektuer om suksesfol te wêzen, jo moatte it heul goed witte en fakgebiet, en hoe te meitsjen microservices. En de bêste manier om in fakgebiet te learen is in monolyt te meitsjen.
Mar wat as wy al yn dizze situaasje binne?
De earste stap om elk probleem op te lossen is it dermei iens te meitsjen en te begripen dat it in probleem is, dat wy net mear lije wolle.
As wy yn 't gefal fan in oergroeide monolith (as wy de kâns hawwe om ekstra boarnen foar te keapjen) it snije, dan docht yn dit gefal it tsjinoerstelde ferhaal út: as oermjittige mikrotsjinsten net mear helpe, mar hinderje - oerskot ôfsnije en fergrutsje!
Bygelyks foar it hjirboppe besprutsen kollektive byld ...
Krij de meast twifele mikrotsjinsten kwyt:
Kombinearje alle mikrotsjinsten ferantwurdlik foar frontend-generaasje:
... yn ien mikrotsjinst, skreaun yn ien (modern en normaal, sa't jo sels tinke) taal/ramt:
It sil ien ORM (ien DBMS) hawwe en earst in pear applikaasjes:
... mar yn 't algemien kinne jo dêr folle mear oerdrage, en krije it folgjende resultaat:
Boppedat rinne wy yn Kubernetes dit alles yn aparte eksimplaren, wat betsjut dat wy de lading noch kinne mjitte en apart skaalje.
Gearfetsje
Sjoch nei it gruttere byld. Hiel faak ûntsteane al dizze problemen mei mikrotsjinsten om't immen har taak naam, mar woe "spielje mei mikrotsjinsten".
Yn it wurd "mikrotsjinsten" is it "mikro" diel oerstallich.. Se binne "mikro" allinich om't se lytser binne as in geweldige monolith. Mar tink se net as wat lyts.
En foar in lêste gedachte, litte wy weromgean nei it orizjinele diagram:
In briefke derop skreaun (rjochts boppe) komt del op it feit dat de feardichheden fan it team dat jo projekt makket binne altyd primêr - se sille in wichtige rol spylje yn jo kar tusken mikrotsjinsten en in monolith. As it team net genôch feardigens hat, mar it begjint mikrotsjinsten te meitsjen, sil it ferhaal perfoarst fataal wêze.
Fideo's en dia's
Fideo fan 'e taspraak (~50 minuten; spitigernôch bringt it net de tal fan emoasjes fan 'e besikers oer, dy't foar in grut part de stimming fan it rapport bepale, mar dat is hoe't it is):
Presintaasje fan it rapport:
PS
Oare rapporten op ús blog:
- «» (Dmitry Stolyarov; 28 maaie 2018 by RootConf);
- «» (Dmitry Stolyarov; 7 novimber 2017 op HighLoad++);
- «» (Dmitry Stolyarov; 6 juny 2017 by RootConf);
- «» (Dmitry Stolyarov; 8 novimber 2016 op HighLoad++);
- «» (Dmitry Stolyarov; 31 maaie 2016 by RootConf).
Jo kinne ek ynteressearre wêze yn de folgjende publikaasjes:
- «";
- «";
- «".
Boarne: www.habr.com