Cosa sono i microservizi? La tua prossima architettura software

Quasi tutti i sistemi informatici eseguono più attività utilizzando risorse condivise e una delle domande della programmazione informatica è quanto strettamente i bit di codice che eseguono tali attività dovrebbero essere legati l'uno all'altro. Una risposta sempre più diffusa è il concetto di microservizio : una piccola parte discreta di funzionalità che interagisce con altri microservizi per creare un sistema più grande.

Sebbene l'idea di base di avere tali componenti discreti non sia nuova, il modo in cui vengono implementati i microservizi li rende una base naturale per entrambe le moderne applicazioni basate su cloud. I microservizi si integrano anche con la filosofia devops, che incoraggia il lancio rapido e continuo di nuove funzionalità.

Cosa sono i microservizi?

Il "micro" nei microservizi implica che si tratta di piccole applicazioni. A volte è vero, ma un modo migliore per pensarci è che dovrebbero essere grandi solo quanto necessario per fare una cosa specifica o risolvere un problema particolare. Quel problema dovrebbe essere concettuale, non tecnico. Come afferma Microsoft, "i microservizi dovrebbero essere progettati attorno alle capacità aziendali, non a livelli orizzontali come l'accesso ai dati o la messaggistica". Comunicano con altri microservizi e utenti esterni tramite API relativamente stabili per creare un'applicazione più ampia.

Pertanto, la funzionalità interna di un singolo microservizio può essere ottimizzata o aggiornata radicalmente senza influire sul resto del sistema. Questo a sua volta si lega al modo in cui i negozi devops cercano di operare: se le funzioni specifiche di un'applicazione più ampia sono segmentate in parti di codice discrete e indipendenti, è più facile vivere il mantra devops di CI / CD (integrazione continua e consegna continua) . Inoltre, API ben definite semplificano il test automatico dei microservizi.

Architettura dei microservizi vs. architettura monolitica

Sentirai spesso parlare di microservizi in termini di "architettura di microservizi ". Questa frase comprende non solo i microservizi stessi, ma componenti per la gestione e l'individuazione dei servizi, nonché un gateway API che gestisce la comunicazione tra i microservizi e il mondo esterno.

Una "applicazione monolitica" è l'opposto di ciò che sono i microservizi. È un retonimo per un'applicazione in cui tutto il codice è in un grande file eseguibile binario. Come spiega TechTarget, un'applicazione monolitica è più difficile da scalare e più difficile da migliorare. Ma poiché è costruito come una singola applicazione coesiva, non richiede la stessa gestione di un'architettura di microservizi.

Concetti limitati: come definire un microservizio

Torniamo per un momento al nostro precedente comandamento secondo cui i microservizi dovrebbero fare una cosa specifica. È facile a dirsi, ma in pratica la funzionalità è spesso intrecciata e disegnare le divisioni è più difficile di quanto sembri. L'analisi del dominio e la progettazione basata sul dominio sono gli approcci teorici che ti aiuteranno a suddividere il tuo compito di grande immagine in singoli problemi che un microservizio può risolvere. In questo processo, delineato in una serie illuminante di post di blog di Microsoft, crei un modello astratto del tuo dominio aziendale e nel processo scopri i contesti limitati , che raggruppano insieme funzionalità che interagiscono con il mondo in un modo specifico.

Ad esempio, potresti avere un contesto limitato per la spedizione e un altro per gli account. Un oggetto fisico del mondo reale avrebbe sia un prezzo che un posto dove deve andare, ovviamente, ma i contesti limitati rappresentano modi specifici in cui la tua applicazione pensa e interagisce con quegli oggetti. Ogni microservizio dovrebbe esistere interamente all'interno di un singolo contesto delimitato, sebbene alcuni contesti delimitati potrebbero comprendere più di un microservizio.

Microservizi vs. architettura orientata ai servizi vs. servizi Web

A questo punto, se sei un professionista IT che lavora nel settore da un po 'di tempo, potresti pensare che molto di questo suona familiare. L'idea di piccoli programmi individuali che lavorano insieme potrebbe ricordarvi sia la SOA (architettura orientata ai servizi) che i servizi Web , due parole d'ordine degli inebrianti giorni del Web 2.0 degli anni 2000. Sebbene in un certo senso non ci sia davvero nulla di nuovo sotto il sole, ci sono importanti distinzioni tra questi concetti e microservizi. Datamation ha una buona ripartizione delle differenze, ma eccone una versione breve:

  • In un'architettura orientata ai servizi, i singoli componenti sono relativamente strettamente accoppiati, spesso condividono risorse come lo storage e comunicano attraverso un software specializzato chiamato bus di storage aziendale . I microservizi sono più indipendenti, condividono meno risorse e comunicano tramite protocolli più leggeri. Vale la pena notare che i microservizi sono nati dall'ambiente SOA e talvolta sono considerati una sorta di SOA o un successore del concetto.
  • Un servizio Web è un insieme di funzionalità pubblicamente accessibile a cui altre applicazioni possono accedere tramite il Web; probabilmente l'esempio più diffuso è Google Maps, che il sito web di un ristorante potrebbe incorporare per fornire indicazioni ai clienti. Questa è una connessione molto più lenta di quella che vedresti in un'architettura di microservizi.

Comunicazione di microservizi

Uno slogan che sentirai spesso usato sulle architetture di microservizi è che dovrebbero includere "endpoint intelligenti e dumb pipe". In altre parole, i microservizi dovrebbero mirare a utilizzare metodi di comunicazione di base e consolidati piuttosto che un'integrazione complessa e stretta. Come notato, questa è un'altra cosa che distingue i microservizi da SOA.

In generale, la comunicazione tra i microservizi dovrebbe essere asincrona , nel senso che i thread di codice non vengono bloccati in attesa di risposte. (Va comunque bene utilizzare protocolli di comunicazione sincrona come HTTP, sebbene protocolli asincroni come AMQP (Advanced Message Queuing Protocol) siano comuni anche nelle architetture di microservizi.) Questo tipo di accoppiamento libero rende un'architettura di microservizi più flessibile di fronte al guasto dei singoli componenti o parti della rete, che è un vantaggio fondamentale.

Microservizi, Java e Spring Boot e Spring Cloud

Alcuni dei primi lavori sui microservizi sono nati nella comunità Java; Martin Fowler è stato uno dei primi sostenitori. Una conferenza Java del 2012 in Polonia ha caratterizzato una delle prime presentazioni più importanti sull'argomento, intitolata "Micro services - Java, the Unix Way". Ha raccomandato di applicare i principi che hanno guidato lo sviluppo delle prime applicazioni Unix negli anni '70 ("Write programmi che fanno una cosa e la fanno bene: scrivere programmi per lavorare insieme ") allo sviluppo Java.

Come risultato di questa storia, ci sono molti framework Java che ti consentono di creare microservizi. Uno dei più popolari è Spring Boot, progettato specificamente per i microservizi; L'avvio è esteso da Spring Cloud, che come suggerisce il nome, ti consente di distribuire anche quei servizi nel cloud. Pivotal Software, lo sviluppatore di Spring, ha un buon tutorial su come iniziare con lo sviluppo di microservizi utilizzando questi framework.

Microservizi e contenitori: Docker, Kubernetes e oltre

La tecnologia di base che è andata più lontano per ottenere i microservizi nel mainstream sono i contenitori .  Un contenitore è simile a un'istanza VM, ma invece di includere un intero sistema operativo autonomo, un contenitore è solo uno spazio utente isolato che fa uso del kernel del sistema operativo host, ma altrimenti mantiene il codice in esecuzione al suo interno autonomo. I container sono molto più piccoli delle istanze VM e sono facili da distribuire rapidamente, localmente o nel cloud, e possono essere attivati ​​o ridotti per soddisfare la domanda e le risorse disponibili.

Il fascino dei contenitori per i microservizi dovrebbe essere ovvio: ogni singolo microservizio può essere eseguito nel proprio contenitore, il che riduce in modo significativo il sovraccarico di gestione dei servizi. La maggior parte delle implementazioni di container dispone di strumenti di orchestrazione complementari che automatizzano la distribuzione, la gestione, la scalabilità, il networking e la disponibilità delle applicazioni basate su container. È la combinazione di microservizi piccoli e facili da costruire e contenitori facili da distribuire che rende possibile la filosofia devops. Esistono diverse implementazioni del concetto di contenitore, ma di gran lunga il più popolare è Docker, che è generalmente associato a Kubernetes come piattaforma di orchestrazione.

La primavera, sebbene popolare, è legata alla piattaforma Java. I sistemi basati su contenitori, d'altra parte, sono poliglotti: qualsiasi linguaggio di programmazione supportato dal sistema operativo può essere eseguito in un contenitore, il che offre maggiore flessibilità ai programmatori. In effetti, un grande vantaggio dei microservizi è che ogni singolo servizio può essere scritto in qualsiasi lingua abbia più senso o con cui gli sviluppatori si trovano più a proprio agio. In effetti, un servizio potrebbe essere completamente ricostruito in una nuova lingua senza influire sul sistema nel suo complesso, purché le sue API rimangano stabili. DZone ha un articolo che discute i pro e i contro di Spring Cloud e Kubernetes per i microservizi. 

Modelli di progettazione di microservizi

Indipendentemente dal linguaggio che utilizzi per sviluppare microservizi, dovrai affrontare problemi che altri sviluppatori hanno riscontrato in precedenza. I modelli di progettazione sono soluzioni formalizzate e astratte a problemi ricorrenti nell'informatica e alcuni di essi sono specifici per i microservizi. Devopedia ha un ottimo elenco, che include:

  • Registro dei servizi: per connettere i client alle istanze disponibili dei microservizi
  • Circuit Breaker: per evitare che i servizi in errore vengano chiamati ripetutamente
  • Fallback: per fornire un'alternativa a un servizio non riuscito
  • Sidecar: per fornire un servizio ausiliario al contenitore principale, ad esempio per la registrazione, la sincronizzazione dei servizi o il monitoraggio
  • Adattatore: per standardizzare o normalizzare l'interfaccia tra il contenitore principale e il mondo esterno
  • Ambassador: per connettere il contenitore principale al mondo esterno, ad esempio per il proxy di connessioni localhost a connessioni esterne

Microservizi e cloud : AWS e Azure

Come notato sopra, uno dei vantaggi dell'utilizzo dei contenitori è che possono essere facilmente distribuiti nel cloud, dove sono disponibili risorse di elaborazione flessibili in modo da poter massimizzare l'efficienza dell'applicazione. Come puoi immaginare, i principali fornitori di cloud pubblico sono tutti ansiosi che tu utilizzi le loro piattaforme per eseguire le tue app basate su microservizi. Per ulteriori informazioni, controlla le risorse di Amazon, Microsoft e Google.