Facendo riferimento a questo articolo, sarai in grado di farti un'idea migliore dell'architettura del microservizio e di quando utilizzarla. Inoltre, questo articolo è costituito dai seguenti contenuti.

◼ Abbreviazioni dell'art

◼ Introduzione

◼ Ecosistema di microservizi

◼ Architettura monolitica vs architettura a microservizi

◼ Sfide nei microservizi

◼ Quando utilizzare i microservizi

Abbreviazioni

• API: interfaccia di programmazione dell'applicazione
• MS : microservizio
• NoSQL: non solo SQL
• RTE : Ambiente di runtime

L'architettura dei microservizi è un approccio allo sviluppo di applicazioni in cui una grande applicazione è costruita come una suite di servizi modulari (ciò significa che (il microservizio) è un tipo di architettura dell'applicazione in cui l'applicazione è sviluppata come una raccolta di servizi). Ogni modulo supporta un obiettivo aziendale specifico e utilizza un'interfaccia semplice e ben definita per comunicare con altri insiemi di servizi. Inoltre, esiste un minimo indispensabile di servizi di gestione centralizzata, che possono essere scritti in diversi linguaggi di programmazione come java, python, ecc. e utilizzare diverse tecnologie di archiviazione dei dati come relazionale e NoSQL nell'architettura dei microservizi.

Di seguito sono riportate alcune funzionalità/caratteristiche chiave dei microservizi.

• Altamente gestibile e testabile
• Connessione libera (comunicazione tramite un'interfaccia)
• Distribuibile in modo indipendente
• Organizzato attorno alle capacità aziendali
• Di proprietà di un piccolo team (team interfunzionale)

In generale, il sistema dei microservizi contiene le seguenti entità elencate. Alcune di queste entità sono fasi nello sviluppo software standard e alcune di esse sono processi specifici di microservizi che forniranno la spina dorsale per un efficiente sistema di microservizi.

Bilanciamento del carico

La responsabilità principale del bilanciamento del carico è distribuire il carico in entrata tra molte istanze di microservizi. Principalmente ci sono 2 tipi di bilanciamento del carico chiamati client discovery (bilanciamento del carico lato client) e server discovery (bilanciamento del carico lato server). Nella scoperta del client, il client comunica con il registro del servizio ed esegue il bilanciamento del carico. A causa di quel client è necessario essere a conoscenza del registro del servizio. Nella scoperta del server, il client comunica con il bilanciamento del carico e il bilanciamento del carico comunica con il registro del servizio. Pertanto, il servizio client non deve essere a conoscenza del registro del servizio. Osservando i seguenti diagrammi è possibile ottenere una maggiore comprensione di questi 2 tipi di bilanciamento del carico.

Server di rilevamento dei servizi

La funzionalità di individuazione dei servizi consente ai microservizi di registrarsi automaticamente all'avvio invece di tenere traccia manualmente di quali microservizi sono attualmente distribuiti e di quali host e porte sono necessari. Pertanto, se MS1 vuole parlare con MS2, in primo luogo, MS1 ottiene i dettagli dal servizio di registro che appartiene al panorama e poi parla con MS2. Inoltre, quando c'è un altro MS chiamato MS3 che è stato attivo o inattivo nello stesso panorama, il servizio di registro verrà aggiornato automaticamente.

Gateway dell'API

Il gateway API è un server. È un unico punto di ingresso in un sistema. API Gateway incapsula l'architettura del sistema interno. Fornisce un'API personalizzata per ogni cliente. Ha anche altre responsabilità come l'autenticazione, il monitoraggio, il bilanciamento del carico, la memorizzazione nella cache, la modellazione e la gestione delle richieste e la gestione delle risposte statiche. API Gateway è anche responsabile dell'instradamento delle richieste, della composizione e della traduzione del protocollo. Tutte le richieste effettuate dal client passano attraverso il gateway API. Successivamente, il gateway API instrada le richieste al microservizio appropriato.

Il gateway API gestisce la richiesta in due modi:

• Ha instradato o inoltrato le richieste al servizio appropriato.
• Distribuire (diffondere) una richiesta a più servizi.

Ora sappiamo che ci sono molti microservizi in esecuzione su nodi diversi nello stesso ecosistema. Pertanto, è essenziale monitorarli insieme in un unico sistema. Il dashboard di Hystrix e il dashboard di amministrazione di Spring boot sono alcuni esempi di strumenti di monitoraggio. Esistono cinque principi per il monitoraggio dei microservizi:

• Monitora i contenitori e cosa c'è dentro.
• Avviso sulle prestazioni del servizio.
• Monitora i servizi elastici e multi-location.
• Monitora le API.
• Monitorare la struttura organizzativa

Quando implementiamo i microservizi, vengono eseguiti su RTE diversi come JRE e Node.js poiché l'implementazione dei microservizi può essere eseguita utilizzando tecnologie diverse. Inoltre, sai che questi microservizi vengono distribuiti in modo poliglotta. Quindi i nodi non conoscono l'RTE del microservizio distribuito e dobbiamo installarlo manualmente in ogni nodo. Ma quando si tratta di containerizzazione, confezioniamo il nostro RTE con il nostro microservizio. Pertanto possiamo eseguire i microservizi ovunque senza considerare l'RTE e possiamo gestire e aggiornare facilmente questi servizi.

Interruttore

È un'entità molto importante nell'ecosistema dei microservizi. Il più delle volte questo è definito come un modello. Per motivi di comprensione, questo è praticamente simile all'interruttore automatico di casa tua. Ti protegge dal disastro e blocca la propagazione del problema che si è presentato. Lo stesso scenario si sta verificando qui (interruttore automatico in MS) rispetto ai microservizi. Supponiamo che il client invii una richiesta al microservizio del fornitore e mentre arriva la risposta c'è un problema di connessione. A causa di quel client è in attesa di una risposta da molto tempo e potrebbe influire anche su altri servizi. Poiché l'architettura dell'interruttore automatico, il canale problematico viene scartato e il precedente problema di attesa viene risolto. Inoltre, ci sono tre diversi Stati di Circuit Breaker chiamati Closed, Aperto e Mezzo Aperto.

Architettura monolitica vs architettura a microservizi

Prezzo

• Monolitico : Più alto una volta che il progetto si ridimensiona
• Microservce : Superiore nella prima fase di sviluppo

• Monolitico : una base di codice e un database uniti per l'intero prodotto
• Microservce: più file di codice; ogni servizio gestisce una base e un data storage

• Monolitico : l'intera base di codice deve essere distribuita
• Microservizio : ogni microservizio viene distribuito singolarmente

• Monolitico : lo stesso stack di codice
• Microservce: diversi stack (lingua, ambiente di runtime e così via)

Ci sono alcune sfide quando abbiamo a che fare con i microservizi come segue.

• Comunicazione tra processi (tramite rete)
• Transazioni distribuite
• Un gran numero di servizi
• Richiede più automazione

Ora abbiamo una buona conoscenza dei microservizi e delle loro sfide. Vediamo quali scenari sono adatti per i microservizi.

• L'azienda vuole creare subito un codice pulito e leggibile ed evitare debiti tecnici
• L'azienda dispone di risorse umane per lo sviluppo di microservizi
• L'azienda privilegia i guadagni a lungo termine rispetto ai benefici a breve termine
• Un team di sviluppatori utilizza diversi stack e strumenti tecnologici
• La piattaforma deve essere altamente scalabile ed espandersi in diversi mercati