Tutorial sui microservizi: cos'è ArchiTecnica ed esempio

Cosa sono i microservizi?

Microservices è un modello di architettura orientata ai servizi in cui le applicazioni sono costruite come una raccolta di varie unità di servizio indipendenti più piccole. È un Ingegneria del software approccio che si concentra sulla scomposizione di un'applicazione in moduli a funzione singola con interfacce ben definite. Questi moduli possono essere distribuiti e gestiti in modo indipendente da piccoli team che possiedono l'intero ciclo di vita del servizio.

Il termine "micro" si riferisce alle dimensioni di un microservizio, che deve essere gestibile da un singolo team di sviluppo (da 5 a 10 sviluppatori). In questa metodologia, le applicazioni di grandi dimensioni vengono suddivise nelle unità indipendenti più piccole.

Cos'è monolitico Architecnologia?

In parole semplici, si può dire che l'architettura monolitica è come un grande contenitore in cui tutti i componenti software di un'applicazione sono raggruppati in un unico pacchetto. Analizziamo l'esempio di un negozio online nel contesto di un'architettura monolitica.

Monolitico Architecnologia dell'applicazione eCommerce

In qualsiasi applicazione di e-commerce, ci sono alcune funzionalità standard come Ricerca, RevVisualizzazione e valutazioni e pagamenti. Queste funzionalità sono accessibili ai clienti tramite il loro browser o app. Quando lo sviluppatore del sito di eCommerce distribuisce l'applicazione, si tratta di un'unica unità monolitica. Il codice per diverse funzionalità come Ricerca, RevLe sezioni "Visualizzazioni", "Valutazioni" e "Pagamenti" risiedono sullo stesso server. Per scalare l'applicazione, è necessario eseguire più istanze (server) di queste applicazioni.

Cos'è il Microservizio Architecnologia?

Microservizio Architectura è uno stile di sviluppo architettonico che consente di creare applicazioni come una raccolta di piccoli servizi autonomi sviluppati per un dominio aziendale. È una variante dell'architettura di stile strutturale che aiuta a organizzare le applicazioni come una raccolta di servizi debolmente accoppiati. Il Microservice ArchiLa tecnologia contiene servizi a grana fine e protocolli leggeri.

Prendiamo come esempio un'applicazione di e-commerce sviluppata con architettura a microservizi. In questo esempio di architettura a microservizi, ogni microservizio è focalizzato su una singola funzionalità aziendale. Ricerca, Valutazione e RevI componenti View e Payment hanno ciascuno la propria istanza (server) e comunicano tra loro.

Microservices Architectura

Nel monolitico Archistruttura, tutti i componenti si fondono in un unico modulo. Ma nei microservizi ArchiNella struttura, i microservizi sono suddivisi in moduli individuali (microservizi) che comunicano tra loro, come mostrato nell'esempio di microservizi qui sopra.

La comunicazione tra microservizi è una comunicazione stateless in cui ogni coppia di richiesta e risposta è indipendente. Pertanto, i microservizi possono comunicare senza sforzo. Nel microservizio ArchiNella struttura, i dati sono federati. Ogni microservizio ha il proprio archivio dati separato.

Microservizi e monolitici Architectura

Microservices	Monolitico Architectura
Ogni unità dell'intera applicazione dovrebbe essere la più piccola e dovrebbe essere in grado di raggiungere un obiettivo aziendale specifico.	Un'unica base di codice per tutti gli obiettivi aziendali.
L'avvio del servizio è relativamente rapido.	L'avvio del servizio richiede più tempo.
L'isolamento dei guasti è semplice. Anche se un servizio smette di funzionare, gli altri possono continuare a operare.	Isolare i guasti è difficile. Se una qualsiasi funzionalità non funziona, l'intero sistema si blocca. Per risolvere questo problema, l'applicazione deve essere ricompilata, testata nuovamente e ridistribuita.
Tutti i microservizi dovrebbero essere a basso accoppiamento, in modo che le modifiche apportate a uno non influiscano sugli altri.	L'architettura monolitica è strettamente interconnessa. Le modifiche apportate a un modulo di codice influenzano gli altri.
Le aziende possono destinare maggiori risorse ai servizi che generano un ROI più elevato.	Poiché i servizi non sono isolati, non è possibile allocare le risorse individualmente.
È possibile allocare maggiori risorse hardware al servizio più utilizzato. Nell'esempio di e-commerce citato in precedenza, un numero maggiore di utenti consulta l'elenco dei prodotti ed effettua ricerche rispetto a quelli che effettuano pagamenti, pertanto è possibile allocare più risorse al microservizio di ricerca e di visualizzazione dell'elenco dei prodotti.	La scalabilità delle applicazioni è impegnativa e dispendiosa.
I microservizi rimangono sempre coerenti e continuamente disponibili.	Gli strumenti di sviluppo vengono sovraccaricati poiché il processo deve iniziare da zero.
I dati sono federati. Ciò consente ai singoli microservizi di adottare un modello dati più adatto alle proprie esigenze.	I dati sono centralizzati.
Team piccoli e focalizzati. Sviluppo parallelo e più rapido.	È necessario un team numeroso e un notevole impegno nella sua gestione.
La modifica nel modello dati di un microservizio non influisce sugli altri microservizi.	Una modifica al modello dati influisce sull'intero database.
Interagisce con altri microservizi tramite interfacce ben definite.	Non applicabile.
I microservizi si basano sul principio di concentrarsi sui prodotti, non sui progetti.	Pone l'accento sull'intero progetto.
Nessuna dipendenza incrociata tra basi di codice. È possibile utilizzare tecnologie diverse per microservizi diversi.	Una funzione o un programma dipende da altri.

Sfide dei microservizi

• I microservizi dipendono l'uno dall'altro e dovranno comunicare tra loro.
• Rispetto ai sistemi monolitici ci sono più servizi da monitorare che vengono sviluppati utilizzando strumenti diversi linguaggi di programmazione.
• Trattandosi di un sistema distribuito, si tratta di un modello intrinsecamente complesso.
• I diversi servizi avranno meccanismi separati, il che comporterà un elevato consumo di memoria per i dati non strutturati.
• Una gestione efficace e il lavoro di squadra sono necessari per prevenire problemi a cascata.
• Riprodurre un problema sarà un'impresa difficile quando questo scompare in una versione e ricompare nell'ultima.
• L'implementazione indipendente con i microservizi è complicata.
• L'architettura dei microservizi comporta un notevole sovraccarico operativo.
• La gestione dell'applicazione diventa complessa quando al sistema vengono aggiunti nuovi servizi.
• Per supportare microservizi distribuiti in modo eterogeneo è necessaria una vasta gamma di professionisti qualificati.
• I microservizi sono costosi, poiché è necessario mantenere uno spazio server diverso per le diverse attività aziendali.

SOA e microservizi

I servizi SOA sono gestiti nell'organizzazione tramite un registro che funge da elenco di directory. Le applicazioni devono cercare i servizi nel registro e invocare il servizio. In altre parole, SOA è proprio come un'orchestra dove ogni artista si esibisce con il proprio strumento mentre il direttore musicale dà istruzioni a tutti.

Dall'altro lato, i microservizi rappresentano una forma di architettura orientata ai servizi (SOA) in cui le applicazioni sono costruite come una raccolta di servizi più piccoli anziché come un unico software o applicazione. I microservizi sono come una compagnia di danza in cui ogni ballerino è indipendente e sa cosa deve fare. Quindi, se sbagliano qualche passo, sanno come riprendere la sequenza corretta. Ecco un confronto dettagliato tra SOA e microservizi.

Parametro	SOA	Microservices
Tipo di design	Nella SOA, i componenti software sono esposti al mondo esterno per essere utilizzati sotto forma di servizi.	MicroService fa parte della SOA. È un'implementazione della SOA.
Dipendenza	Le unità aziendali sono dipendenti.	Sono indipendenti l'uno dall'altro.
Dimensioni del software	Le dimensioni del software sono maggiori rispetto a qualsiasi software convenzionale.	Nei microservizi, le dimensioni del software sono sempre ridotte.
Stack di tecnologia	Lo stack tecnologico è inferiore rispetto a Microservice.	Lo stack tecnologico dei microservizi potrebbe essere molto ampio.
Natura della domanda	Di natura monolitica.	Stack completo in natura.
Indipendente e focalizzato	Le applicazioni SOA sono progettate per eseguire più attività aziendali.	Sono progettati per eseguire una singola attività aziendale.
Distribuzione	Il processo di implementazione richiede tempo.	La distribuzione è semplice e richiede meno tempo.
Efficienza dei costi	Più conveniente.	Less conveniente.
Scalabilità	Less rispetto ai microservizi.	Altamente scalabile.
Logica di business	I componenti della logica di business sono memorizzati all'interno di un singolo dominio di servizio, con protocolli di rete semplici (HTTP con XML o JSON) e gestiti tramite API con SDK/Client.	La logica di business può risiedere in domini diversi, con livelli di interconnessione tra i servizi simili a un Service Bus aziendale (Middleware).

Strumenti per microservizi

1) Wiremock: testare i microservizi

WireMock È una libreria flessibile per la creazione di stub e mock di servizi web. Permette di configurare la risposta restituita dall'API HTTP quando riceve una richiesta specifica. Viene utilizzata anche per testare i microservizi.

Download link: http://wiremock.org/

2) Finestra mobile

Docker è un progetto open-source che ci permette di creare, distribuire ed eseguire applicazioni utilizzando i container. Grazie a questi container, gli sviluppatori possono eseguire un'applicazione come un singolo pacchetto. Permette di includere librerie e altre dipendenze in un unico pacchetto.

Download link: https://www.docker.com/

3) Istrix

Hystrix è un sistema di tolleranza ai guasti Java libreria. Questo strumento è progettato per separare i punti di accesso a servizi remoti, sistemi e librerie di terze parti in un ambiente distribuito come i microservizi. Migliora il sistema complessivo isolando i servizi difettosi e prevenendo l'effetto a cascata dei guasti.

Link per il download: https://github.com/Netflix/Hystrix

migliori pratiche dei microservizi Architectura

• Archivio dati separato per ogni microservizio.
• Mantenere il codice a un livello di maturità simile.
• Build separata per ogni microservizio.
• Trattare sempre ciascun server come stateless.

DOMANDE FREQUENTI