19 settembre in Mosca a prima riunione tematica HUG (Highload++ User Group), chì era dedicata à i microservizi. Ci hè stata una presentazione "Microservizi operativi: a dimensione importa, ancu s'ellu avete Kubernetes", in quale avemu spartutu l'esperienze larga di Flant in prughjetti operativi cù l'architettura di microservizi. Prima di tuttu, serà utile à tutti i sviluppatori chì pensanu à utilizà stu approcciu in u so prughjettu attuale o futuru.
Introducendu (50 minuti, assai più informativu chè l'articulu), è ancu u principale estratto da ellu in forma di testu.
NB: Video è presentazione sò ancu dispunibili à a fine di stu post.
Introduzione
Di solitu una bona storia hà un principiu, una trama principale è una risoluzione. Stu rapportu hè più cum'è un preludiu, è un tragicu in questu. Hè impurtante ancu di nutà chì furnisce una vista di l'esterno di i microservizi. sfruttamentu.
Cumincià cù stu graficu, l'autore di quale (in 2015) Martin Fowler:
Mostra cumu, in u casu di una applicazione monolitica chì righjunghji un certu valore, a produtividade principia à calà. I microservizi sò diffirenti in quantu a produtividade iniziale cun elli hè più bassu, ma cum'è a cumplessità aumenta, a degradazione di l'efficienza ùn hè micca cusì notevule per elli.
Aghju aghjunghje à questu graficu per u casu di usu di Kubernetes:
Perchè una applicazione cù microservizi hè megliu? Perchè una tale architettura presenta esigenze serii per l'architettura, chì à u turnu sò perfettamente coperti da e capacità di Kubernetes. Per d 'altra banda, una parte di sta funziunalità serà utile per un monolitu, soprattuttu perchè u monolitu tipicu oghje ùn hè micca esattamente un monolitu (i dettagli seranu più tardi in u rapportu).
Comu pudete vede, u graficu finali (quandu l'applicazioni monolitiche è microservizi sò in l'infrastruttura cù Kubernetes) ùn hè micca assai sfarente di l'uriginale. Dopu parlemu di l'applicazioni operate cù Kubernetes.
Microservizi utili è dannosi
È quì hè l'idea principale:
Chì ghjè nurmale architettura di microserviziu? Duverebbe purtà un veru beneficiu, aumentendu a vostra efficienza di u travagliu. Se vulemu à u graficu, quì hè:
Se la chjamate utile, tandu da l'altra parte di u graficu ci sarà dannosu microservices (interferisce cù u travagliu):
Riturnà à l'"idea principale": deve esse fiducia in a mo sperienza? Dapoi u principiu di questu annu aghju cercatu 85 prughjetti. Ùn sò micca tutti i microservizi (circa un terzu à a mità di elli avianu una tale architettura), ma questu hè sempre un gran numaru. Avemu (cumpagnia Flant) cum'è outsourcers riesce à vede una larga varietà di applicazioni sviluppate sia in picculi imprese (cù 5 sviluppatori) sia in grandi (~ 500 sviluppatori). Un benefiziu aghjuntu hè chì vedemu queste applicazioni vive è evoluzione annantu à l'anni.
Perchè i microservizi?
À a quistione di i benefici di i microservizi ci hè da u digià citatu Martin Fowler:
- cunfini chjaru di modularità;
- implementazione indipendente;
- libertà di sceglie tecnulugia.
Aghju parlatu assai à l'architetti è i sviluppatori di software è aghju dumandatu perchè anu bisognu di microservizi. È aghju fattu a mo lista di e so aspettative. Eccu ciò chì hè accadutu:
Se discrimu alcuni di i punti "in sensazioni", allora:
- cunfini chjaru di i moduli: quì avemu un monolitu terribili, è avà tuttu serà ben dispostu in i repositori Git, in quale tuttu hè "nantu à i scaffali", u caldu è u dolce ùn sò micca mischiati;
- indipindenza di implementazione: puderemu sparghje i servizii indipindentamente in modu chì u sviluppu và più veloce (publicà novi funziunalità in parallelu);
- indipendenza di sviluppu: pudemu dà stu microserviziu à una squadra / sviluppatore, è quellu à l'altru, grazia à quale pudemu sviluppà più veloce;
- боaffidabilità più grande: se a degradazione parziale hè accaduta (un microserviziu di 20 cascate), allora solu un buttone cesserà di travaglià, è u sistema in generale cuntinuerà à funziunà.
Architettura tipica (dannusu) di microserviziu
Per spiegà perchè a realità ùn hè micca ciò chì aspittemu, vi prisintà cullettivu una maghjina di una architettura di microserviziu basatu annantu à l'esperienza di parechji prughjetti diffirenti.
Un esempiu seria una tenda in linea astratta chì hà da cumpete cù Amazon o almenu OZON. A so architettura di microserviziu s'assumiglia cusì:
Per una cumminazione di ragioni, sti microservizi sò scritti nantu à diverse piattaforme:
Siccomu ogni microserviziu deve avè l'autonomia, assai di elli necessitanu a so propria basa di dati è cache. L'architettura finale hè a siguenti:
Chì sò e so cunsequenze ?
Fowler hà ancu questu - nantu à u "pagamentu" per l'usu di i microservizii:
È videremu se e nostre aspettative sò state soddisfatte.
Limpia i limiti di i moduli...
ma quanti microservizi avemu veramente bisognu di riparà?per fà u cambiamentu? Pudemu ancu capisce cumu tuttu funziona senza un tracciatore distribuitu (dopu tuttu, ogni dumanda hè trattata da a mità di i microservizi)?
Ci hè un mudellu "", è quì hè diventatu un pezzu di terra distribuitu. Per cunfirmà questu, quì hè una illustrazione apprussimativa di cumu si passanu e dumande:
indipendenza di implementazione...
Tecnicamente, hè stata ottenuta: pudemu sparghje ogni microserviziu separatamente. Ma in a pratica, avete bisognu di piglià in contu chì sempre stende tanti microservizi, è ci vole à piglià in contu l'ordine di u so rollout. In una bona manera, in generale, avemu bisognu di pruvà in un circuitu separatu s'ellu stendemu a liberazione in l'ordine currettu.
Libertà di sceglie a tecnulugia ...
Ella hè. Ricurdatevi chì a libertà spessu cunfina cù l'anarchia. Hè assai impurtante quì per ùn sceglie tecnulugii solu per "giocà" cun elli.
L'indipendenza di u sviluppu ...
Cumu fà un ciclu di prova per tutta l'applicazione (cù tanti cumpunenti)? Ma avete sempre bisognu di mantene a data. Tuttu chistu porta à u fattu chì numeru attuale di circuiti di prova, chì pudemu in principiu cuntene, risulta esse minimu.
E implementate tuttu questu in u locu? .. Risulta chì spessu u sviluppatore faci u so travagliu indipindente, ma "à l'aleatoriu", perchè hè obligatu à aspittà finu à chì u circuitu hè liberu di pruvà.
Scala separata...
Iè, ma hè limitata in l'area di u DBMS utilizatu. In l'esempiu di l'architettura datu, Cassandra ùn hà micca prublemi, ma MySQL è PostgreSQL.
Боpiù affidabilità...
Micca solu u fallimentu di un microserviziu in realtà spessu rompe u funziunamentu currettu di tuttu u sistema, ma ci hè ancu un novu prublema: rende ogni microserviziu tolerante à i difetti hè assai difficiule. Perchè i microservizi utilizanu diverse tecnulugia (memcache, Redis, etc.), per ognunu avete bisognu di pensà à tuttu è implementà, chì, sicuru, hè pussibule, ma esige risorse enormi.
Misurabilità di carica ...
Questu hè veramente bonu.
A "leggerezza" di i microservizi...
Ùn avemu micca solu enormi overhead di a rete (i dumandesi di DNS si multiplicanu, etc.), ma ancu per via di e numerose subqueries chì avemu principiatu replicate dati (magazzini cache), chì hà purtatu à una quantità significativa di almacenamiento.
È quì hè u risultatu di risponde à e nostre aspettative:
Ma ùn hè micca tuttu !
Perchè:
- Probabilmente avemu bisognu di un bus di messagiu.
- Cumu fà una copia di salvezza coherente à u mumentu ghjustu in u tempu? U solu reale L'opzione hè di disattivà u trafficu per questu. Ma cumu fà questu in a produzzione?
- Se parlemu di sustene parechje regioni, allora l'urganizazione di a sustenibilità in ognuna di elli hè un compitu assai intensivu di travagliu.
- U prublema di fà cambiamenti centralizati si presenta. Per esempiu, s'ellu ci vole à aghjurnà a versione PHP, avemu bisognu di impegnà à ogni repository (è ci sò decine di elli).
- A crescita di a cumplessità operativa hè, offhand, esponenziale.
Chì fà cù tuttu questu?
Cumincià cù una applicazione monolitica. L'esperienza di Fowler chì quasi tutte l'applicazioni di microserviziu riesciuti cuminciaru cum'è un monolitu chì hè diventatu troppu grande è hè stata poi rotta. À u listessu tempu, quasi tutti i sistemi custruiti cum'è microservizi da u principiu, prima o dopu, anu avutu prublemi seri.
Un altru pensamentu preziosu hè chì per un prughjettu cù una architettura di microserviziu per esse successu, duvete sapè assai bè è u sughjettu, è cumu fà i microservizii. È u megliu modu per amparà un sughjettu hè di fà un monolitu.
Ma chì si simu digià in questa situazione ?
U primu passu per risolve ogni prublema hè d'accordu cun ellu è capisce chì hè un prublema, chì ùn vulemu più soffre.
Se, in u casu di un monolitu overgrown (quandu avemu scappatu di l'uppurtunità di cumprà risorse supplementari per questu), l'avemu tagliatu, allora in questu casu a storia cuntraria hè: quandu i microservizi eccessivi ùn aiutanu più, ma impediscenu - tagliate l'eccessu è ingrandisce!
Per esempiu, per l'imaghjini cullettivi discututi sopra...
Sbarazzarsi di i microservizi più discutibili:
Unisce tutti i microservizi rispunsevuli di a generazione di frontend:
... in un microserviziu, scrittu in una lingua / quadru (moderna è normale, cum'è tù stessu pensate):
Avarà un ORM (un DBMS) è prima un paru di applicazioni:
... ma in generale pudete trasferisce assai più quì, ottenendu u risultatu seguente:
Inoltre, in Kubernetes eseguimu tuttu questu in casi separati, chì significa chì pudemu ancu misurà a carica è scala per separatamente.
Per riassume
Fighjate à a stampa più grande. Assai spessu, tutti questi prublemi cù i microservizi si sviluppanu perchè qualchissia hà pigliatu u so compitu, ma vulia "giocà cù i microservizi".
In a parolla "microservices" a parte "micro" hè redundante.. Sò "micro" solu perchè sò più chjuchi di un monolitu enormu. Ma ùn pensate micca à elli cum'è qualcosa di picculu.
È per un pensamentu finale, vultemu à u graficu originale:
Una nota scritta sopra (in cima à destra) si riduce à u fattu chì e cumpetenze di a squadra chì face u vostru prughjettu sò sempre primariu - ghjucanu un rolu chjave in a vostra scelta trà i microservizii è un monolitu. Se a squadra ùn hà micca abbastanza cumpetenze, ma cumencia à fà i microservizi, a storia serà definitivamente fatale.
Videos è slides
Video da u discorsu (~ 50 minuti; sfurtunatamenti, ùn trasmette micca e numerose emozioni di i visitori, chì largamente determinanu l'umore di u rapportu, ma hè cusì):
Presentazione di u rapportu:
PS
Altri rapporti nantu à u nostru blog:
- «» (Dmitry Stolyarov; 28 di maghju 2018 à RootConf);
- «» (Dmitry Stolyarov; 7 di nuvembre 2017 nantu à HighLoad++);
- «» (Dmitry Stolyarov; 6 di ghjugnu 2017 à RootConf);
- «» (Dmitry Stolyarov; 8 di nuvembre 2016 nantu à HighLoad++);
- «» (Dmitry Stolyarov; 31 di maghju 2016 à RootConf).
Pudete ancu esse interessatu in e seguenti publicazioni:
- «";
- «";
- «».
Source: www.habr.com