I microservizi rappresentano un modo per suddividere un'applicazione di grandi dimensioni in moduli liberamente accoppiati che comunicano tra loro tramite una semplice API.
Ultimamente solo le persone stupide non hanno parlato di microservizi. Questo sta diventando sempre più popolare. Lo stile architettonico modulare sembra particolarmente adatto agli ambienti basati su cloud e sta diventando sempre più popolare. Prima di entrare nei dettagli, diamo una visione d'insieme di tutto . Pertanto: i microservizi sono un modo per suddividere un grande progetto in moduli piccoli, indipendenti e liberamente accoppiati. I moduli indipendenti sono responsabili di attività chiaramente definite e discrete e comunicano tra loro attraverso un'API semplice e accessibile. In altre parole, i microservizi sono semplicemente uno stile architettonico diverso per la progettazione di applicazioni complesse, principalmente web. Ma cosa c'è di così negativo nelle soluzioni architettoniche esistenti come la SOA (Service Oriented Architecture)? La maggior parte delle soluzioni aziendali moderne scritte utilizzando la SOA sembrano funzionare abbastanza bene. Potrebbe essere un ottimo momento per parlare di alcune delle sfide che il settore si trova ad affrontare in questi giorni... Cominciamo con un semplice esempio. Diciamo che devo eseguire un'applicazione classica scritta in Java. Per prima cosa svilupperò l'interfaccia utente, poi il livello della logica aziendale, con diversi componenti che interagiranno con l'interfaccia utente, e infine il livello del database, che sarà accessibile al database persistente. Ora, a seconda del fatto che voglio eseguire l'applicazione, creerò un WAR/EAR/JAR e lo monterò su un server (come JBoss, Tomcat o WebLogic). Dato che tutto questo viene fatto in uno, ottengo un'applicazione monolitica, il che significa che tutti i componenti sono in un unico posto... Esempio nell'immagine:
Molto probabilmente hai già familiarità con questo approccio e lo hai utilizzato, ma l'idea è di utilizzare questo esempio per mostrare quali sfide dovranno affrontare gli sviluppatori utilizzando questa soluzione architetturale. Applicazione monolitica: sfide sfide
Man mano che l'applicazione cresce, aumenta anche la quantità di codice scritto, che potrebbe sovraccaricare l'ambiente di sviluppo ogni volta che è necessario aprirla. Ciò riduce sicuramente l'efficienza dello sviluppatore.
Poiché tutto deve essere montato in un unico posto, ciò porta al fatto che il passaggio ad un altro linguaggio di programmazione o il passaggio ad altre tecnologie diventa un grosso problema. Ad esempio, hai scritto un'applicazione in Java e dopo un po' è uscito Kotlin e non vedevi l'ora di riscriverla, perché era stata pubblicizzata come più interessante, migliore e più veloce. Con un'applicazione monolitica, anche solo pensare al refactoring causerà notevoli difficoltà, per non parlare del processo stesso. Attualmente ci sono molte applicazioni realizzate in questo modo e il numero di righe di codice è semplicemente incredibile.
Se uno qualsiasi dei componenti smette di funzionare per qualsiasi motivo , anche l'intera applicazione si bloccherà. Immagina solo che esista un'applicazione web con moduli come autorizzazione, pagamento, cronologia, ecc. E per qualche motivo uno di loro si rompe. Questo è semplicemente uno shock per le aziende e, di conseguenza, per gli sviluppatori.
Il ridimensionamento di un'applicazione monolitica può essere ottenuto solo generando un'altra applicazione dello stesso tipo. Ma cosa succede se è necessario ridimensionare solo un componente e non l'intera applicazione? Quante risorse verranno sprecate?...
Ciò può avere un grande impatto sul processo di sviluppo e sul processo di installazione dell'applicazione. Quanto più grande è l'applicazione, tanto più importante è che gli sviluppatori possano dividerla in parti di lavoro più piccole. Poiché tutti i moduli in un'applicazione monolitica sono collegati tra loro, gli sviluppatori non possono lavorare/montare questi moduli indipendentemente gli uni dagli altri. Poiché gli sviluppatori dipendono gli uni dagli altri, il tempo di sviluppo aumenta.
Allo stesso tempo, siamo pronti a considerare e comprendere il significato dei microservizi, ovvero come possono essere utilizzati per ripristinare la flessibilità persa con lo stile SOA. God Microservices in soccorso Una delle caratteristiche più importanti di qualsiasi soluzione architetturale è la scalabilità. Mentre stavo imparando i microservizi per la prima volta, ho visto che tutto era così simile alle citazioni del libro “The Art of Scalability”. Questo è un ottimo inizio e un ottimo luogo di discussione. Questo libro definisce il cosiddetto modello "Scalability Cube", che descrive un sistema di scalabilità tridimensionale:
Come puoi vedere, l'asse X descrive il "scaling orizzontale" (che abbiamo visto è disponibile anche per architetture monolitiche), l'asse Y rappresenta il ridimensionamento nel senso di separare diverse componenti del servizio . L'idea dell'asse Z si capisce quando i dati vengono divisi e l'applicazione invia richieste esattamente dove si trovano i dati. Cioè, non sono tutti nello stesso posto. L’idea dell’asse Y è quella su cui ci concentreremo più nel dettaglio. Questo asse rappresenta una scomposizione funzionale . In questa strategia, diverse funzioni possono essere considerate come servizi indipendenti. Pertanto, montando l'intera applicazione solo quando tutto è finito, gli sviluppatori possono montare i singoli servizi indipendentemente l'uno dall'altro e non aspettare che gli altri finiscano di lavorare sui propri moduli. Ciò non solo migliorerà i tempi di sviluppo, ma offrirà anche la flessibilità di modificare e ricablare senza doversi preoccupare del resto dei componenti dell'applicazione. Confrontiamo questo diagramma con quello monolitico precedente:
Microservizi: vantaggi I vantaggi dei microservizi sembrano essere più che sufficienti per convincere sviluppatori aziendali come Amazon, Netflix, Ebay a iniziare a utilizzare questo approccio. A differenza delle applicazioni architetturali monolitiche, i microservizi:
Migliora l'isolamento dei guasti dei componenti: le applicazioni di grandi dimensioni possono continuare a funzionare in modo efficiente anche in caso di guasto di un singolo modulo.
Elimina l'impegno dell'applicazione verso uno stack tecnologico: se vuoi provare un nuovo stack tecnologico su qualche servizio, vai avanti. Le dipendenze saranno molto più leggere rispetto a quelle monolitiche e sarà anche molto più semplice ripristinare tutto. Meno codice è presente in un'applicazione, più facile sarà il suo funzionamento.
Rende molto più semplice per i nuovi dipendenti comprendere la funzionalità del servizio.
Microservizi: caratteristiche di montaggio e virtualizzazione Ora capiamo cosa sono i microservizi. E il vantaggio più grande è che è montato da più di un archivio WAR/EAR/JAR. Ma come si installa? Il modo migliore per montare i microservizi all'interno dei contenitori. Un contenitore è un sistema operativo virtuale completamente configurato con l'ambiente necessario configurato, che aiuta a isolare l'accesso alle risorse del sistema hardware su cui è installato il contenitore. La soluzione più famosa sul mercato è ovviamente Docker . Anche le macchine virtuali di IaaS (infrastruttura come servizio) come AWS possono funzionare bene per il montaggio di microservizi, ma microservizi relativamente leggeri potrebbero non utilizzare tutte le risorse presenti nella macchina virtuale, il che può ridurre la redditività di utilizzo. Puoi anche montare i tuoi microservizi utilizzando il pacchetto OSGI (Open Service Gateway Initiative). In questo caso, tutti i microservizi verranno eseguiti in un'unica JVM, ma ciò comporta problemi di compromesso tra controllo e isolamento. Microservizi: svantaggi Solo perché “è tutto fantastico” e “non l’abbiamo mai visto prima” non significa che non ci siano svantaggi. Di seguito è riportato un elenco delle possibili aree problematiche che l'architettura dei microservizi comporta:
Lo sviluppo di sistemi distribuiti può essere difficile. Con questo intendo che tutti i componenti ora sono servizi indipendenti: è necessario gestire con molta attenzione le richieste che passano tra i moduli. Potrebbe verificarsi uno scenario in cui un modulo non risponde, costringendoti a scrivere codice aggiuntivo per evitare l'arresto anomalo del sistema. Ciò può essere più difficile se le chiamate remote sono sensibili alla latenza .
Database multipli e gestione delle transazioni possono essere una vera seccatura.
testare le applicazioni di microservizi può essere complicato. Utilizzando un'applicazione monolitica, dobbiamo solo eseguire l'archivio WAR/EAR/JAR sul server e assicurarci che sia connesso al database. E nei microservizi, ogni singolo servizio deve essere avviato prima che possa iniziare il test.
Le applicazioni di montaggio possono essere complicate. Potrebbero richiedere un coordinamento attorno a più servizi che potrebbero non essere facili da montare come un contenitore WAR.
.... Naturalmente, con gli strumenti e gli approcci giusti questi svantaggi possono essere evitati. Ma loro stessi richiedono supporto e non risolvono completamente tutti i problemi. L'articolo è stato tradotto dal sito Web CloudAcademy . Traduzione gratis. Ognuno è libero di esprimere tutto il proprio pensiero nei commenti. Verranno sicuramente letti. Articolo originale Il mio account Github
GO TO FULL VERSION