19 settembre a Mosca il primo incontro tematico HUG (Highload++ User Group), dedicato ai microservizi. Si è tenuta una presentazione "Operating Microservices: Size Matters, Even If You Have Kubernetes", in cui abbiamo condiviso la vasta esperienza di Flant nella gestione di progetti con architettura a microservizi. Innanzitutto sarà utile a tutti gli sviluppatori che stanno pensando di utilizzare questo approccio nel loro progetto attuale o futuro.
Introduzione (50 minuti, molto più informativo dell'articolo), nonché il suo estratto principale in forma testuale.
NB: Video e presentazione sono disponibili anche alla fine di questo post.
Introduzione
Di solito una buona storia ha un inizio, una trama principale e una conclusione. Questo rapporto è piuttosto un preludio, e per di più tragico. È anche importante notare che fornisce una visione esterna dei microservizi. Operativo.
Inizierò con questo grafico, il cui autore (nel 2015) Martin Fowler:
Mostra come, nel caso di un’applicazione monolitica che raggiunge un certo valore, la produttività inizia a diminuire. I microservizi sono diversi in quanto la produttività iniziale con essi è inferiore, ma con l’aumentare della complessità, il degrado dell’efficienza non è così evidente per loro.
Aggiungerò a questo grafico nel caso di utilizzo di Kubernetes:
Perché un'applicazione con microservizi è migliore? Perché un'architettura del genere pone seri requisiti per l'architettura, che a loro volta sono perfettamente coperti dalle capacità di Kubernetes. D'altra parte, alcune di queste funzionalità saranno utili per un monolite, soprattutto perché il tipico monolite odierno non è esattamente un monolite (i dettagli saranno riportati più avanti nel rapporto).
Come puoi vedere, il grafico finale (quando nell'infrastruttura con Kubernetes sono presenti sia applicazioni monolitiche che di microservizi) non è molto diverso da quello originale. Successivamente parleremo delle applicazioni gestite tramite Kubernetes.
Microservizi utili e dannosi
Ed ecco l'idea principale:
Ciò che è normale architettura a microservizi? Dovrebbe portarti vantaggi reali, aumentando l’efficienza del tuo lavoro. Se torniamo al grafico, eccolo qui:
Se la chiami utile, quindi dall'altra parte del grafico ci sarà dannoso microservizi (interferisce con il lavoro):
Tornando all’“idea principale”: dovrei fidarmi della mia esperienza? Dall'inizio di quest'anno ho guardato 85 progetti. Non tutti erano microservizi (circa un terzo o la metà di essi avevano tale architettura), ma si tratta comunque di un numero elevato. Noi (la società Flant) come outsourcer riusciamo a vedere un'ampia varietà di applicazioni sviluppate sia in piccole aziende (con 5 sviluppatori) che in quelle grandi (~ 500 sviluppatori). Un ulteriore vantaggio è che vediamo queste applicazioni vivere ed evolversi nel corso degli anni.
Perché i microservizi?
Alla domanda sui vantaggi dei microservizi c'è dal già citato Martin Fowler:
- confini chiari della modularità;
- distribuzione indipendente;
- libertà di scelta delle tecnologie.
Ho parlato molto con architetti e sviluppatori di software e ho chiesto perché hanno bisogno dei microservizi. E ho fatto la mia lista delle loro aspettative. Ecco cosa è successo:
Se descriviamo alcuni punti “nelle sensazioni”, allora:
- confini chiari dei moduli: qui abbiamo un terribile monolite, e ora tutto sarà sistemato ordinatamente nei repository Git, in cui tutto è “sugli scaffali”, il caldo e il morbido non sono mescolati;
- indipendenza di distribuzione: saremo in grado di implementare i servizi in modo indipendente in modo che lo sviluppo proceda più velocemente (pubblicare nuove funzionalità in parallelo);
- indipendenza dello sviluppo: possiamo dare questo microservizio ad un team/sviluppatore, e quello ad un altro, grazie al quale possiamo sviluppare più velocemente;
- боmaggiore affidabilità: se si verifica un degrado parziale (un microservizio su 20 cade), solo un pulsante smetterà di funzionare e il sistema nel suo insieme continuerà a funzionare.
Architettura di microservizi tipica (dannosa).
Per spiegare perché la realtà non è quella che ci aspettiamo, presenterò collettivo un'immagine di un'architettura di microservizi basata sull'esperienza di molti progetti diversi.
Un esempio potrebbe essere un negozio online astratto che competerà con Amazon o almeno con OZON. La sua architettura di microservizi è simile alla seguente:
Per una serie di motivi, questi microservizi sono scritti su piattaforme diverse:
Poiché ogni microservizio deve avere autonomia, molti di essi necessitano del proprio database e della propria cache. L'architettura finale è la seguente:
Quali sono le sue conseguenze?
Anche Fowler ha questo — sul “pagamento” per l’utilizzo dei microservizi:
E vedremo se le nostre aspettative saranno soddisfatte.
Confini chiari dei moduli...
Ma quanti microservizi dobbiamo effettivamente correggere?per implementare il cambiamento? Riusciamo a capire come funziona il tutto senza un tracciante distribuito (dopotutto, qualsiasi richiesta viene elaborata dalla metà dei microservizi)?
C'è uno schema"“, e qui si è scoperto che si trattava di un pezzo di terra distribuito. A conferma di ciò, ecco un'illustrazione approssimativa di come vanno le richieste:
Indipendenza di distribuzione...
Tecnicamente il risultato è stato raggiunto: possiamo implementare ciascun microservizio separatamente. Ma in pratica bisogna tenere conto del fatto che si srotola sempre molti microservizi, e dobbiamo tenerne conto l'ordine del loro lancio. In generale, dobbiamo testare in un circuito separato se stiamo lanciando il rilascio nell'ordine corretto.
Libertà di scegliere la tecnologia...
Lei è. Ricorda solo che la libertà spesso confina con l’illegalità. È molto importante qui non scegliere le tecnologie solo per “giocare” con esse.
Indipendenza dello sviluppo...
Come creare un ciclo di test per l'intera applicazione (con così tanti componenti)? Ma è comunque necessario tenerlo aggiornato. Tutto ciò porta al fatto che numero effettivo di circuiti di prova, che in linea di principio possiamo contenere, risulta minimo.
Che ne dici di implementare tutto questo localmente?... Si scopre che spesso lo sviluppatore fa il suo lavoro in modo indipendente, ma “a caso”, perché è costretto ad aspettare che il circuito sia libero per i test.
Ridimensionamento separato...
Sì, ma è limitato nell'ambito del DBMS utilizzato. Nell'esempio di architettura fornito, Cassandra non avrà problemi, ma MySQL e PostgreSQL sì.
Боmaggiore affidabilità...
Non solo il fallimento di un microservizio in realtà spesso interrompe il corretto funzionamento dell’intero sistema, ma c’è anche un nuovo problema: rendere ogni microservizio tollerante ai guasti è molto difficile. Poiché i microservizi utilizzano tecnologie diverse (memcache, Redis, ecc.), Per ognuna è necessario pensare a tutto e implementarlo, il che, ovviamente, è possibile, ma richiede enormi risorse.
Carica misurabilità...
Questo è veramente buono.
La “leggerezza” dei microservizi...
Non solo abbiamo enormi sovraccarico della rete (si moltiplicano le richieste di DNS, ecc.), ma anche per le tante subquery che abbiamo avviato replicare i dati (cache del negozio), che ha portato a una quantità significativa di spazio di archiviazione.
Ed ecco il risultato che ha soddisfatto le nostre aspettative:
Ma non è tutto!
perché:
- Molto probabilmente avremo bisogno di un bus di messaggi.
- Come eseguire un backup coerente al momento giusto? L'unico реальный l'opzione è disattivare il traffico per questo. Ma come farlo in produzione?
- Se parliamo di sostenere diverse regioni, organizzare la sostenibilità in ciascuna di esse è un compito ad alta intensità di manodopera.
- Si pone il problema di apportare modifiche centralizzate. Ad esempio, se dobbiamo aggiornare la versione PHP, dovremo impegnarci in ciascun repository (e ce ne sono dozzine).
- La crescita della complessità operativa è, di fatto, esponenziale.
Cosa fare con tutto questo?
Inizia con un'applicazione monolitica. L'esperienza di Fowler che quasi tutte le applicazioni di microservizi di successo sono nate come un monolite diventato troppo grande e poi rotto. Allo stesso tempo, quasi tutti i sistemi costruiti fin dall’inizio come microservizi prima o poi hanno riscontrato seri problemi.
Un altro pensiero prezioso è che affinché un progetto con un'architettura a microservizi abbia successo, è necessario saperlo molto bene e area tematica e come creare microservizi. E il modo migliore per apprendere un argomento è creare un monolite.
Ma cosa succede se ci troviamo già in questa situazione?
Il primo passo per risolvere qualsiasi problema è accettarlo e capire che è un problema, che non vogliamo più soffrire.
Se, nel caso di un monolite troppo cresciuto (quando abbiamo esaurito l'opportunità di acquistare risorse aggiuntive per esso), lo tagliamo, allora in questo caso si scopre la storia opposta: quando i microservizi eccessivi non aiutano più, ma ostacolano - tagliare l'eccesso e ingrandire!
Ad esempio, per l'immagine collettiva discussa sopra...
Sbarazzati dei microservizi più discutibili:
Combina tutti i microservizi responsabili della generazione del frontend:
... in un microservizio, scritto in un linguaggio/framework (moderno e normale, come tu stesso pensi):
Avrà un ORM (un DBMS) e prima un paio di applicazioni:
... ma in generale lì puoi trasferire molto di più, ottenendo il seguente risultato:
Inoltre, in Kubernetes eseguiamo tutto questo in istanze separate, il che significa che possiamo ancora misurare il carico e ridimensionarlo separatamente.
riassumendo
Guarda il quadro più ampio. Molto spesso, tutti questi problemi con i microservizi sorgono perché qualcuno ha accettato il proprio compito, ma voleva “giocare con i microservizi”.
Nella parola “microservizi” la parte “micro” è ridondante.. Sono “micro” solo perché sono più piccoli di un enorme monolite. Ma non pensate a loro come a qualcosa di piccolo.
E per un'ultima considerazione, torniamo al grafico originale:
Una nota scritta sopra (in alto a destra) si riduce al fatto che le competenze del team che realizza il tuo progetto sono sempre primarie — giocheranno un ruolo chiave nella scelta tra microservizi e monolite. Se il team non ha abbastanza competenze, ma inizia a creare microservizi, la storia sarà sicuramente fatale.
Video e diapositive
Video del discorso (~50 minuti; sfortunatamente non trasmette le numerose emozioni dei visitatori, che hanno in gran parte determinato l'atmosfera del rapporto, ma è così):
Presentazione del rapporto:
PS
Altre segnalazioni sul nostro blog:
- «» (Dmitry Stolyarov; 28 maggio 2018 su RootConf);
- «» (Dmitry Stolyarov; 7 novembre 2017 su HighLoad++);
- «» (Dmitry Stolyarov; 6 giugno 2017 su RootConf);
- «» (Dmitry Stolyarov; 8 novembre 2016 su HighLoad++);
- «» (Dmitry Stolyarov; 31 maggio 2016 su RootConf).
Potrebbero interessarti anche le seguenti pubblicazioni:
- «";
- «";
- «'.
Fonte: habr.com