19 settembre a Mosca il primo meetup tematico HUG (Highload++ User Group), dedicato ai microservizi. Durante l'incontro, è stata presentata la relazione "Gestione dei microservizi: le dimensioni contano, anche se hai Kubernetes", in cui abbiamo condiviso l'ampia esperienza della società "Flant" nella gestione di progetti con architettura a microservizi. Sarà particolarmente utile a tutti gli sviluppatori che stanno considerando di adottare questo approccio nel loro progetto attuale o futuro.
Presentiamo (50 minuti, molto più informativo di un articolo), insieme a un riassunto principale del contenuto in forma testuale.
NB: Il video e la presentazione sono disponibili anche alla fine di questa pubblicazione.
Introduzione
Di solito, una buona storia ha un'introduzione, una trama principale e una conclusione. Questa relazione è più simile a un'introduzione, peraltro tragica. È anche importante notare che offre una visione sui microservizi dal punto di vista sfruttamento.
Inizio con questo grafico, il cui autore (nel 2015) Martin Fowler:
Mostra come, nel caso di un'applicazione monolitica, raggiunta una certa dimensione, la produttività inizia a diminuire. I microservizi si differenziano perché la produttività iniziale con essi è inferiore, ma man mano che aumenta la complessità, la degradazione dell'efficienza non è così evidente.
Aggiungo questo grafico per il caso di utilizzo di Kubernetes:
Perché un'applicazione a microservizi funziona meglio? Perché tale architettura pone serie esigenze all'architettura stessa, che sono eccellentemente soddisfatte dalle capacità di Kubernetes. D'altra parte, parte di questa funzionalità sarà utile anche per il monolite, soprattutto per il motivo che un tipico monolite al giorno d'oggi non è del tutto monolitico (i dettagli verranno presentati nella relazione).
Come si può notare, il grafico finale (una volta che sia le applicazioni monolitiche che quelle a microservizi operano su un'infrastruttura con Kubernetes) non differisce molto dall'originale. Discuteremo in seguito delle applicazioni gestite con Kubernetes.
Microservizi utili e dannosi
E qui la questione principale:
Cos'è un'architettura a microservizi normale? Deve portarti un reale vantaggio, aumentando l'efficienza del lavoro. Se torniamo al grafico, ecco cosa significa:
Se la chiamiamo utile, quindi dall'altra parte del grafico ci sarà microservizi dannosi (intralcia il lavoro): microservizi (creano problemi):
Tornando al "pensiero centrale": vale la pena fidarsi della mia esperienza? Dall'inizio di quest'anno ho guardato 85 progetti. Non tutti erano microservizi (questa architettura era presente in circa un terzo a metà di essi), ma è comunque un numero considerevole. A noi (l'azienda "Flant") come fornitori di servizi riesce di vedere una grande varietà di applicazioni, sviluppate sia in piccole aziende (con 5 sviluppatori) che in grandi (~500 sviluppatori). Un ulteriore vantaggio è che vediamo come queste applicazioni vivono e si sviluppano nel corso degli anni.
Perché i microservizi?
Alla domanda sull'utilità dei microservizi c'è piuttosto concreta
- da parte del già citato Martin Fowler:
- confini chiari di modularità;
- deploy indipendente;
libertà di scelta delle tecnologie.
Ho parlato molto con architetti e sviluppatori di software, chiedendo loro perché hanno bisogno di microservizi. E ho stilato la mia lista delle loro aspettative. Ecco cosa è emerso:
- Se descrivessi "a sensazione" alcuni dei punti, direi che:
- confini chiari dei moduli: ecco, abbiamo un terribile monolite, e ora tutto sarà ordinatamente suddiviso in repository Git, in cui tutto è "in ordine", senza mescolare il caldo con il morbido;
- indipendenza nel deploy: potremo rilasciare i servizi in modo indipendente, affinché lo sviluppo proceda più rapidamente (pubblicare nuove funzionalità in parallelo);
- bunindipendenza nello sviluppo: possiamo affidare questo microservizio a quel team/sviluppatore, e quello a un altro, il che ci consentirà di sviluppare più velocemente;
maggiore affidabilità: se si verifica una degradazione parziale (crolla un microservizio su 20), smetterà di funzionare solo un pulsante, mentre il sistema nel suo complesso continuerà a funzionare.
Architettura di microservizi tipica (dannosa) Per spiegare perché nella realtà le cose non sono così come ci aspettiamo, presenterò un'immagine
collettiva dell'architettura dei microservizi, basata sull'esperienza di molti progetti diversi.
Un esempio sarà un negozio online astratto, che intende competere con Amazon o almeno con OZON. La sua architettura di microservizi appare così:
Per una serie di motivi, questi microservizi sono scritti su piattaforme diverse:
Quali sono le sue conseguenze?
Fowler ha anche un articolo su questo Vediamo se le nostre aspettative sono state giustificate.
Confini chiari dei moduli…
quanti microservizi dobbiamo realmente sistemare
Ma , per implementare una modifica? Possiamo davvero capire come funziona tutto senza un tracer distribuito (dato che ogni richiesta è gestita dalla metà dei microservizi)?Esiste un pattern "
grande palla di fangoIndipendenza nel deployment…
Tecnicamente è stata raggiunta: possiamo aggiornare ogni microservizio separatamente. Ma nella pratica, dobbiamo tenere presente che di solito viene aggiornato
un numero elevato di microservizi , e dobbiamo considerarel'ordine del loro rollout . Idealmente dovremmo testare in un contesto separato se stiamo rilasciando la versione nell'ordine corretto.Libertà di scelta della tecnologia…
C'è. Solo che bisogna ricordare che spesso la libertà confina con l'anarchia. È molto importante non scegliere tecnologie solo per "giocare" con esse.
Indipendenza nello sviluppo…
Come creare un ambiente di test per l'intera applicazione (da un così gran numero di componenti)? E bisogna anche mantenerlo aggiornato. Tutto ciò porta al fatto che
il numero reale di ambienti di test , che possiamo effettivamente mantenere,risulta essere minimo. E implementare tutto questo localmente?.. Risulta che spesso lo sviluppatore svolge il proprio lavoro in modo indipendente, ma "alla cieca", perché costretto ad aspettare che si liberi un ambiente per il test..
Scalabilità separata…
Sì, ma è limitata nell'ambito dei DBMS utilizzati. Nell'esempio presentato, non ci saranno problemi con Cassandra, ma ci saranno con MySQL e PostgreSQL.
M
aggiore affidabilità…unNon solo il guasto di un microservizio danneggia spesso il corretto funzionamento dell'intero sistema, ma c'è anche un nuovo problema:
rendere ogni microservizio tollerante ai guasti è molto complesso . Perché nei microservizi vengono utilizzate tecnologie diverse (memcache, Redis, ecc.), e per ognuna bisogna pensare e implementare tutto, il che, ovviamente, è possibile, ma richiede enormi risorse.. Perché nei microservizi vengono utilizzate diverse tecnologie (memcache, Redis, ecc.), per ciascuna è necessario pianificare e implementare tutto, il che, ovviamente, è possibile, ma richiede enormi risorse.
Misurabilità del carico…
Con questo davvero tutto bene.
La "leggerezza" dei microservizi…
Non solo abbiamo avuto enormi oneri di rete (aumentano le richieste DNS, ecc.), ma a causa di un gran numero di sottoquery abbiamo cominciato a replicare i dati (memorizzare le cache), il che ha portato a un volume significativo di archiviazione.
Ecco come corrisponde alle nostre aspettative:
Ma non è tutto!
Perché:
- Probabilmente avremo bisogno di un bus di messaggi.
- Come fare un backup consistente al momento giusto? L'unica soluzione reale è interrompere il traffico per questo. Ma come farlo in produzione?
- Se si tratta di supportare più regioni, organizzare la resilienza in ognuna di esse è un compito molto impegnativo.
- Si presenta il problema di apportare modifiche centralizzate. Ad esempio, se dobbiamo aggiornare la versione di PHP, sarà necessario fare un commit in ogni repository (e ce ne sono decine).
- La crescita della complessità operativa risulta esponenziale.
Cosa fare con tutto ciò?
Iniziate con un'applicazione monolitica. L'esperienza di Fowler indica che praticamente tutte le applicazioni microservizi di successo sono iniziate come monoliti che sono diventati troppo grandi, dopo di che sono stati suddivisi. Allo stesso tempo, praticamente tutti i sistemi costruiti come microservizi sin dall'inizio, prima o poi, hanno affrontato seri problemi.
Un'altra considerazione preziosa è che affinché un progetto con architettura microservizi abbia successo, è necessario conoscere molto bene sia l'area tematica che come costruire microservizi. E il modo migliore per conoscere l'area tematica è realizzare un monolite.
Ma cosa fare se ci troviamo già in questa situazione?
Il primo passo per risolvere qualsiasi problema è accettarlo e comprendere che è un problema, che non vogliamo più soffrire.
Se nel caso di un monolite ingrandito (quando abbiamo esaurito la possibilità di acquistare risorse per esso) lo tagliamo, in questo caso si presenta la storia opposta: quando un'eccessiva microservizi non aiuta più, ma ostacola — ritagliate l'eccesso e raggruppate!
Ad esempio, per l'immagine collettiva sopra...
Liberatevi dei microservizi più discutibili:
Unite tutti i microservizi responsabili per la generazione del frontend:
… in un microservizio, scritto in uno (moderno e adeguato, come ritenete voi) linguaggio/framework:
Avrà un solo ORM (un solo DBMS) e inizialmente un paio di applicazioni:
… in realtà si può trasferire molto di più, ottenendo un risultato del genere:
In Kubernetes avviamo tutto questo come istanze separate, e questo significa che possiamo ancora misurare il carico e scalarle singolarmente.
In sintesi
Guarda il quadro in modo più ampio. Molto spesso, tutti questi problemi con i microservizi sorgono perché qualcuno ha preso il proprio compito, ma voleva "giocare ai microservizi".
Nella parola "microservizi" la parte "micro" è superflua. Sono "micro" solo perché più piccoli di un grande monolito. Ma non bisogna pensarli come a qualcosa di piccolo.
E per la riflessione finale, torniamo alla grafica iniziale:
La nota scritta a it (in alto a destra) sintetizza il fatto che le competenze del team che realizza il vostro progetto sono sempre primarie — saranno proprio loro a giocare un ruolo chiave nella vostra scelta tra microservizi e monoliti. Se il team non ha le abilità necessarie, ma inizia a fare microservizi, la storia sarà sicuramente fatale.
Video e slide
Video della presentazione (~50 minuti; sfortunatamente, non cattura le numerose emozioni dei partecipanti, che hanno in gran parte definito l'umore del discorso, ma così è):
Presentazione della relazione:
P.S.
Altre presentazioni nel nostro blog:
- «» (Dmitrij Stolyarov; 28 maggio 2018 a RootConf);
- «» (Dmitrij Stolyarov; 7 novembre 2017 a HighLoad++);
- «» (Dmitrij Stolyarov; 6 giugno 2017 a RootConf);
- «» (Dmitrij Stoliarov; 8 novembre 2016 a HighLoad++);
- «» (Dmitrij Stoliarov; 31 maggio 2016 a RootConf).
Probabilmente vi interesseranno anche le seguenti pubblicazioni:
- «»;
- «»;
- «».
Fonte: habr.com
