Architettura dei microservizi: un segno distintivo per la competenza

I sistemi monolitici non sono più realizzabili nell'epoca contemporanea della containerizzazione e del cloud computing. C'è stata una crescita nella complessità dei sistemi software negli ultimi anni e i sistemi monolitici stanno diventando sempre più complessi da creare e mantenere.

I componenti del sistema sono prodotti e raggruppati come una singola unità in un sistema monolitico. L'intero sistema dovrebbe essere ridistribuito se un singolo componente è stato modificato. Questo lo rende più difficile da scalare e meno versatile. La struttura interconnessa e interconnessa di un sistema autonomo può essere un duro sforzo per gli sviluppatori durante la creazione di applicazioni complete. I sistemi interessati rendono anche difficile apportare modifiche chiave, adottare nuovi stack tecnologici o spedire aggiornamenti e aggiornamenti. Un'architettura orientata ai servizi, che consiste in una varietà di servizi che possono comunicare tra loro all'interno di un sistema, pone le basi per la transizione dalla programmazione monolitica in primo luogo.

L'architettura del microservizio è stato il passo successivo nel dominio ed è stato un mezzo più unificato, ma granulare, per stabilire una strategia di sviluppo software di successo. L'espressione "Architettura dei microservizi" è emersa negli ultimi anni per descrivere una particolare tecnica di creazione di sistemi software come suite di servizi implementabili in modo indipendente. Sebbene non esista una definizione specifica di questo stile architettonico, esistono diversi tratti simili che circondano l'organizzazione in termini di capacità aziendale, distribuzione automatizzata, intelligence negli endpoint e gestione decentralizzata di linguaggi e dati.

È un approccio di sviluppo software che suddivide un sistema in sezioni più piccole e indipendenti e quindi le collega insieme. I servizi autonomi sono riuniti per soddisfare le esigenze specializzate di un particolare settore. Spotify, Amazon, PayPal, Netflix e Twitter hanno tutti preso atto di questa nuova scoperta e la stanno pubblicizzando ampiamente.

Che cos'è l'architettura dei microservizi?

L'espressione "Architettura dei microservizi" è diventata più popolare negli ultimi anni per riferirsi a un approccio specifico all'architettura dei programmi software come suite di servizi che possono essere implementati indipendentemente l'uno dall'altro. Nonostante il fatto che questo stile architettonico non possa essere definito con precisione, condivide alcune caratteristiche con altri approcci architettonici. Questi includono l'organizzazione basata sulla capacità aziendale, l'implementazione automatizzata, l'intelligence negli endpoint e il controllo decentralizzato di lingue e dati. In altre parole, la capacità dei microservizi di operare in modo indipendente è la forza trainante della loro ascesa ai vertici della scena dello sviluppo software.

L'architettura dei microservizi, più frequentemente denominata semplicemente microservizi, è un paradigma di progettazione utilizzato durante lo sviluppo del software applicativo. I microservizi consentono di scomporre un'applicazione di grandi dimensioni in diverse parti più piccole e autonome, ognuna delle quali è responsabile del proprio insieme univoco di attività. Una singola richiesta utente potrebbe far sì che un'applicazione basata su microservizi effettui molte chiamate ai propri microservizi interni per costruire la propria risposta.

I container sono un ottimo esempio di architettura di microservizi poiché ti liberano dalla necessità di preoccuparti delle dipendenze dei servizi, consentendoti così di concentrarti sullo sviluppo dei servizi stessi. I container sono spesso lo strumento preferito per lo sviluppo di applicazioni cloud native per piattaforme contemporanee sotto forma di microservizi. Il termine "architettura di microservizi" si riferisce a un tipo di architettura dell'applicazione in cui l'applicazione stessa è costruita come una raccolta di servizi. Offre un framework per creare, distribuire e gestire in modo indipendente diagrammi e servizi architetturali per i microservizi.

Necessità dello sviluppo dell'architettura di microservizi e limitazioni dell'architettura monolitica

1. Ridimensionamento dell'applicazione

Poiché le aziende di successo su scala Web sperimentano un'espansione esponenziale, il loro software deve anche consentire una grande scalabilità orizzontale. Occasionalmente, solo una parte del software che è pesante per CPU o I/O deve essere ridimensionata e gestita individualmente (implementata con la programmazione poliglotta). Il software monolitico funziona come una singola entità e viene creato utilizzando un unico linguaggio di programmazione e Tech Stack. Per ottenere il ridimensionamento orizzontale, è necessario ridimensionare l'intera applicazione. Poiché il software monolitico supporta solo un singolo linguaggio di programmazione, è impossibile sviluppare anche un singolo modulo in un diverso linguaggio di programmazione o Tech Stack.

2. Velocità di sviluppo

Al fine di ridurre il time-to-market, ogni azienda al giorno d'oggi desidera uno sviluppo rapido delle funzionalità. In un'applicazione monolitica di grandi dimensioni, complicata e talvolta multimilionaria, l'aggiunta di nuove funzionalità è estremamente lenta a causa dell'enorme carico cognitivo posto sullo sviluppatore. I moduli di enormi programmi monolitici sono strettamente collegati, rendendo più difficile lo sviluppo di nuove funzionalità. Di conseguenza, l'aggiunta di nuove funzionalità a un programma monolitico è spesso lenta e costosa.

3. Ridimensionamento dello sviluppo

Al fine di ottenere un vantaggio competitivo o di cogliere frutti a bassa quota, le aziende cercano spesso di parallelizzare lo sviluppo assumendo più sviluppatori. Gli sviluppatori non possono lavorare in modo indipendente su una base di codice massiccia, monolitica e strettamente connessa e spesso richiedono sincronizzazione e vigilanza aggiuntive per evitare di interferire con il lavoro dell'altro. L'aggiunta di ulteriori sviluppatori non comporta un aumento delle funzionalità e occasionalmente potrebbe comportare meno funzionalità. Allo stesso modo, a causa dell'elevato carico cognitivo richiesto per comprendere l'intera base di codice monolitico, in genere le nuove reclute o neolaureati richiedono una notevole quantità di tempo per creare le prime righe di codice produttivo. Nel 2008, ho avuto un colloquio con un'azienda di telecomunicazioni con sede a Berlino in cui il direttore tecnico mi ha detto con un sorriso compiaciuto che la base di codice C++ dell'azienda includeva milioni di righe e che i nuovi ingegneri possono produrre codice produttivo solo dopo quattro o sei mesi.

4. Ciclo di rilascio

Il ciclo di rilascio dei grandi programmi monolitici è in genere eccessivamente lungo, da sei a due anni e mezzo, con un ritardo aggiuntivo da pochi mesi a diversi anni a causa delle loro dimensioni. I grandi cicli di rilascio spesso pongono un'azienda in uno svantaggio competitivo ai giorni nostri, poiché un nuovo concorrente può entrare nel mercato durante il gap di rilascio.

5. Modularizzazione

Nell'architettura monolitica, la barriera tra i moduli è tipicamente un'interfaccia interna. Non appena la dimensione del programma aumenta, la separazione tra i moduli inizia a rompersi. Di conseguenza, i moduli nell'architettura monolitica sono spesso strettamente legati invece che accoppiati liberamente e altamente coesi. Se confrontiamo lo sviluppo del software con la società, la modularizzazione monolitica è analoga ai principi moralistici e religiosi, che non possono garantire la legge e l'ordine nella società.

6. Modernizzazione

Le app di successo esistenti richiedevano la modernizzazione per una serie di motivi (ad es. sfruttare l'hardware moderno, il browser, la larghezza di banda della rete, lo stack tecnologico o l'attrazione di buoni sviluppatori). La modernizzazione di un programma monolitico può essere costosa e dispendiosa in termini di tempo poiché richiede una modernizzazione Big Bang dell'intera applicazione senza influire sul servizio.

Tipi di microservizi

I microservizi differenziali e integrali sono i due tipi distinti di microservizi.

un. Differenziale

In questa forma di architettura, l'architettura si scompone in servizi indipendenti che sono in grado di separarsi in transazioni. Ciò si traduce nella distribuzione di una singola transazione a molti servizi.

b. Integrante

Le applicazioni di microservizi sono progettate per combinare una moltitudine di microservizi in esperienze utente personalizzate. Questi programmi coprono diverse esigenze distinte, tra cui la gestione del livello di servizio, il provisioning su richiesta e la composizione dinamica.

Caratteristiche dei microservizi

1. Autonomo

Un'architettura di microservizi consente di creare, distribuire, gestire e ridimensionare ogni componente del servizio separatamente dagli altri servizi. I servizi non devono condividere il loro codice o come fanno le cose con altri servizi. Tutta la comunicazione tra le diverse parti avviene tramite API ben definite.

2. Specializzato

Ogni servizio si basa su un diverso insieme di competenze e su un diverso problema. Nel tempo, se gli sviluppatori aggiungono più codice a un servizio, il servizio potrebbe essere suddiviso in servizi più piccoli.

3. Componentizzazione tramite Servizi

Sebbene le architetture di microservizi facciano uso di librerie, il metodo principale con cui componentizzeranno il proprio software è scomporlo in servizi. Le librerie sono componenti collegati in un programma e chiamati utilizzando chiamate di funzione in memoria, mentre i servizi sono componenti fuori processo che comunicano con un meccanismo come una richiesta di servizio Web o una chiamata di procedura remota. Definiamo le librerie come componenti che sono collegati in un programma e chiamati utilizzando chiamate di funzione in memoria. (Questa è un'idea distinta da ciò che viene indicato come oggetto di servizio in molti sistemi OO. A differenza delle librerie, i servizi possono essere distribuiti in modo indipendente, che è uno dei motivi principali per cui vengono utilizzati come componenti anziché come librerie. Un ulteriore Il vantaggio dell'impiego di servizi al posto dei componenti è la generazione di un'interfaccia componente più trasparente Una buona tecnica per stabilire un'interfaccia pubblicata esplicita non esiste nella maggior parte dei linguaggi di programmazione.

La documentazione e la disciplina sono in genere le uniche cose che impediscono ai clienti di violare l'incapsulamento di un componente, il che risulterebbe in un accoppiamento eccessivamente stretto tra i componenti. Utilizzando protocolli di chiamata remota espliciti, i servizi rendono facile per i loro utenti evitarlo. L'utilizzo di servizi di questo tipo comporta alcuni inconvenienti. Poiché le chiamate effettuate in remoto sono più costose di quelle effettuate all'interno dello stesso processo, le API utilizzate in remoto devono avere una granularità più fine, il che potrebbe renderle più difficili da utilizzare. Quando si trascendono i confini di un processo, è più difficile apportare cambiamenti comportamentali, il che rende più difficile se è necessario modificare il modo in cui le responsabilità sono distribuite tra i componenti.

4. Prodotti non Progetti

La maggior parte delle iniziative di sviluppo di applicazioni che incontriamo seguono un paradigma chiamato progetto, in cui l'obiettivo principale è consegnare un pezzo di software che viene poi considerato finito. Al termine del progetto, il software viene consegnato a un'organizzazione di manutenzione e il team responsabile della sua creazione viene sciolto.

I fautori dei microservizi in genere evitano questa architettura a favore del concetto che un team dovrebbe possedere un prodotto per l'intero suo intero ciclo di vita. Il concetto di Amazon di "costruisci, lo gestisci", in cui un team di sviluppo si assume la completa responsabilità del programma mentre viene utilizzato nella produzione, è un'importante fonte di ispirazione per questo. Ciò porta gli sviluppatori a contatto quotidiano con il modo in cui il loro software funziona in produzione e aumenta la comunicazione con i loro utenti, poiché sono tenuti ad assumersi almeno parte del carico di fornire supporto per il programma.

5. Governance decentrata

Inoltre, i team di sviluppo di microservizi preferiscono un approccio distinto agli standard. Preferiscono fornire strumenti utili che altri sviluppatori possono utilizzare per affrontare sfide paragonabili a quelle che stanno incontrando, piuttosto che fare affidamento su una serie di standard codificati. In genere, questi strumenti derivano da implementazioni e condivisi con una comunità più ampia, a volte, ma non sempre, utilizzando un paradigma open source interno. Ora che git e github sono di fatto il sistema di controllo della versione preferito, le tecniche open source stanno diventando sempre più prevalenti all'interno delle organizzazioni.

Netflix è un ottimo esempio di azienda che aderisce a questo principio. La condivisione di codice prezioso e, soprattutto, testato in battaglia come librerie aiuta altri sviluppatori a gestire problemi comparabili in modo simile, consentendo loro di scegliere un metodo diverso se necessario. Le librerie condivise tendono a concentrarsi sulle preoccupazioni comuni dell'archiviazione dei dati, della comunicazione tra processi e dell'automazione dell'infrastruttura, come discusso più dettagliatamente di seguito.

Per la comunità dei microservizi, le spese sono particolarmente indesiderabili.

6. Standard testati in battaglia e standard applicati

È un po' un paradosso perché i team di microservizi preferiscono evitare il tipo di standard rigorosamente imposti dai gruppi di progettazione aziendale, ma utilizzeranno e persino sosterranno standard aperti come HTTP, ATOM e altri microformati.

La distinzione principale è il modo in cui gli standard vengono prodotti e implementati. Gli standard controllati da organizzazioni come l'IETF non diventano standard finché non ci sono diverse implementazioni live di essi nel mondo più ampio, che sono spesso il risultato di iniziative open source di successo.

Questi standard sono un mondo diverso dalla maggior parte degli standard aziendali, che sono spesso prodotti da persone con competenze di programmazione recenti limitate o eccessiva influenza del fornitore.

7. Automazione delle infrastrutture

Un effetto collaterale che abbiamo visto di una maggiore automazione come conseguenza della distribuzione e distribuzione continue è l'introduzione di strumenti utili per aiutare gli sviluppatori e gli addetti alle operazioni. Gli strumenti per la produzione di artefatti, il mantenimento di basi di codice, l'avvio di servizi di base o per l'aggiunta di monitoraggio e registrazione standard sono attualmente relativamente diffusi. L'esempio migliore sul web è senza dubbio la raccolta di strumenti open source di Netflix, anche se ce ne sono altri in particolare Dropwizard che abbiamo ampiamente utilizzato.

Panoramica del meccanismo di comunicazione in un'architettura di microservizi

I servizi che costituiscono un'architettura di microservizi vengono eseguiti su diversi server. Protocolli come HTTP, AMQP e TCP vengono utilizzati per facilitare la comunicazione tra questi numerosi servizi. I due protocolli di maggiore diffusione sono HTTP/REST e la messaggistica asincrona. Il protocollo HTTP viene spesso utilizzato da un'API (Application Programming Interface) REST per i servizi online. I client sono in grado di accedere e modificare le risorse di un'applicazione utilizzando un localizzatore di risorse uniforme insieme a metodi HTTP come GET, POST, PUT e DELETE (URL). Un'API (Application Programming Interface) REST funge da punto di ingresso per la funzionalità di un'applicazione. I clienti comunicano le loro esigenze ai servizi inviando richieste alle API. I client hanno la possibilità di comunicare con i microservizi direttamente o tramite un gateway API.

Viene specificato un unico punto di ingresso per tutte le richieste effettuate ai servizi utilizzando un modello di gateway API. Il gateway API (Application Programming Interface), quando riceve una richiesta da un client, indirizza la richiesta al servizio appropriato.

Il modello del gateway API ha una serie di varianti, una delle quali è il back-end per il modello front-end. Questa progettazione crea un gateway API distinto per ogni tipo di client (ad esempio, un gateway per client mobili e un altro per applicazioni Web).

Si consiglia di mantenere bassi i livelli di comunicazione tra i vari servizi. La comunicazione asincrona è superiore alla comunicazione sincrona in situazioni in cui la comunicazione è un must. Non è necessario che il servizio che ha inviato la richiesta attenda una risposta prima di continuare le proprie operazioni.

Se incorporati nel database, le code di messaggistica e i sistemi di streaming sono buoni modi per abilitare la comunicazione asincrona. Inoltre, quando questi sistemi forniscono semantica transazionale per un'operazione di dati e l'invio di un messaggio, sono in grado di soddisfare entrambi questi requisiti. Per questo motivo, la distribuzione dei microservizi è resa più semplice e scalabile. Quando vengono usate solo le API REST, la comunicazione tra i microservizi è forzata a essere sincrona, il che spesso impedisce la crescita.

A cosa serve l'architettura dei microservizi?

I microservizi sono uno stile architettonico alla moda che mira a progettare sistemi complessi come raccolte di artefatti software a grana fine e liberamente accoppiati chiamati microservizi; ogni microservizio implementa una piccola parte o anche una singola funzione della logica di business delle applicazioni. I microservizi stanno guadagnando popolarità perché mirano a progettare sistemi complessi come raccolte di artefatti software a grana fine e liberamente accoppiati. I microservizi sono spesso impiegati per velocizzare il processo di sviluppo delle applicazioni.

L'idea di micro è stata sviluppata in risposta all'infrastruttura monolitica su cui è stata inizialmente costruita la maggior parte delle organizzazioni, in particolare se l'attività in questione è operativa da almeno dieci anni. Ciascun componente di un'architettura di microservizi include le seguenti funzionalità al posto di una progettazione monolitica:

• CPU unica per esso
• Il proprio sistema operativo e ambiente di runtime
• In molti casi, un team specializzato lavorerà su di esso per garantire che ogni servizio sia distinguibile dagli altri.

Grazie a questo design, ogni servizio è in grado di:

• Eseguire la propria procedura unica
• Comunica in modo indipendente tra loro senza dover fare affidamento sulla comunicazione degli altri microservizi o dell'applicazione nel suo insieme.

C'è un'adozione diffusa di architetture di microservizi basate su Java, in particolare quelle create utilizzando Spring Boot. Inoltre, i microservizi e l'architettura orientata ai servizi vengono spesso confrontati tra loro. I due approcci hanno entrambi lo stesso obiettivo, ovvero suddividere programmi software di grandi dimensioni in parti più gestibili, ma la loro metodologia è diversa. Inoltre, molte aziende sono sotto pressione dai loro rivali per apportare modifiche ai loro sistemi il più rapidamente possibile, riducendo al minimo l'impatto che tali modifiche hanno sulla disponibilità dei loro sistemi. Ciò richiede design, stili architettonici e tecniche di sviluppo adeguati. L'ingegneria del software offre una varietà di paradigmi che possono soddisfare parzialmente tali esigenze. Questi paradigmi scompongono i sistemi software in unità software a grana fine, che migliorano la modularità, la manutenibilità e la riutilizzabilità e, di conseguenza, riducono la quantità di tempo necessaria per immettere un prodotto sul mercato.

In poche parole, offre agilità a lungo termine. I microservizi consentono una migliore manutenibilità in sistemi complessi, di grandi dimensioni e altamente scalabili consentendo la creazione di applicazioni basate su un gran numero di servizi distribuibili in modo indipendente, ognuno dei quali ha il proprio ciclo di vita granulare e autonomo. Ciò si ottiene consentendo la creazione di applicazioni basate su un gran numero di servizi.

I microservizi hanno l'ulteriore vantaggio di poter essere scalati in modo autonomo. Non è necessario disporre di un'unica applicazione monolitica da scalare come entità singola poiché è invece possibile eseguire la scalabilità orizzontale dei singoli microservizi. Sarai in grado di far crescere solo la regione funzionale del programma che richiede potenza di elaborazione o larghezza di banda di rete aggiuntiva per soddisfare la domanda in questo modo, invece di ridimensionare altre parti dell'applicazione che non richiedono il ridimensionamento. Ciò si traduce in un risparmio sui costi dovuto alla ridotta quantità di hardware richiesta.

Ecco alcuni esempi di architettura di microservizi

un. Trasferimento del sito web

È possibile il trasferimento di un sito Web; ad esempio, un sito Web ospitato su una piattaforma monolitica complessa può essere riposizionato su una piattaforma di microservizi basata su cloud e container.

b. Contenuto multimediale

È possibile utilizzare un sistema di storage di oggetti scalabile per archiviare immagini e risorse video e un'architettura di microservizi può essere utilizzata per offrire questi materiali direttamente sul Web o sui dispositivi mobili.

c. Trattative finanziarie e fatturazione

È possibile trattare l'elaborazione dei pagamenti e l'ordine come due distinti servizi distinti. Ciò consente di accettare pagamenti anche in caso di problemi con il sistema di fatturazione.

d. Elaborazione dati

I servizi di elaborazione dati modulari possono migliorare il supporto cloud con l'uso di una piattaforma di microservizi, che può essere utilizzata anche per l'elaborazione dei dati.

Modelli di progettazione per i microservizi

Il linguaggio dei modelli è la tua guida!

a) Modelli di decomposizione

• Bulkhead separa le risorse importanti, come pool di connessioni, memoria e CPU, per ogni carico di lavoro o servizio. Distribuendo le paratie, un singolo carico di lavoro (o servizio) non può utilizzare tutte le risorse, affamando gli altri. Questo approccio migliora la robustezza del sistema eliminando i guasti a cascata causati da un servizio. Questo modello è soprannominato Bulkhead perché ricorda le partizioni sezionate dello scafo di una nave. Partizionare le istanze del servizio in gruppi distinti, in base al carico del cliente e alle esigenze di disponibilità. Questa architettura aiuta a isolare i guasti e consente di preservare la capacità del servizio per alcuni utenti, anche durante un guasto.
• Sidecar installa componenti utili di un'applicazione come contenitore o processo distinto per consentire l'isolamento e l'incapsulamento. Questo modello può anche consentire alle applicazioni di essere composte da componenti e tecnologie disparate. Questo modello è soprannominato Sidecar perché ricorda un sidecar agganciato a una moto. Nella progettazione, il sidecar è accoppiato a un'applicazione padre e offre funzionalità di supporto per l'applicazione. Allo stesso modo, il sidecar segue la stessa durata dell'applicazione padre, essendo compilato e terminato insieme al genitore. Il pattern sidecar è spesso indicato come pattern sidekick ed è l'ultimo pattern di scomposizione che mostriamo nel post.
• Strangler Fig supporta il refactoring incrementale di un'applicazione, sostituendo gradualmente funzionalità specifiche con nuovi servizi.

b) Modelli di integrazione

1. Pattern di microservizi concatenati

Ci saranno diverse dipendenze per singoli servizi o microservizi, ad esempio, il microservizio Sale dipende dai microservizi Prodotti e Ordine. Un modello di progettazione di microservizi concatenati ti aiuterà a fornire una risposta consolidata alla tua richiesta. Un microservizio-1 riceve la richiesta e quindi comunica con un microservizio-2; può anche comunicare con un microservizio-3. Tutte queste chiamate di servizio sono sincrone.

2. Schema aggregatore

Quando si separa l'attività aziendale in molte parti di codice logiche più piccole, diventa fondamentale considerare come verranno uniti i dati forniti da ciascun servizio. Il cliente non può essere ritenuto responsabile per questo.

Il modello Aggregator aiuta ad affrontare questo problema. Descrive come possiamo combinare i dati provenienti da diverse fonti e quindi fornire il risultato finale all'utente. Questo è possibile in due modi:

• Un microservizio composito effettuerà chiamate a tutti i microservizi necessari, aggregherà e modificherà i dati, quindi li restituirà.
• Oltre a partizionare la richiesta su diversi microservizi, un gateway API può anche aggregare i dati prima di fornirli al consumatore.

3. Modello proxy

Offriamo solo microservizi tramite il gateway API. Autorizzo il GW ad acquisire caratteristiche API come la sicurezza e la classificazione delle API. In questo caso, il gateway API è composto da tre moduli API:

• Mobile API, che implementa l'API per il client mobile FTGO
• Browser API, che implementa l'API nell'applicazione JavaScript in esecuzione nel browser
• API pubblica, che implementa l'API per sviluppatori di terze parti

4. Motivo a rami

È possibile che un microservizio debba ottenere i dati necessari da diverse origini, inclusi altri microservizi. Il modello di microservizio branch è un ibrido dei modelli di progettazione Aggregator e Chain. Consente l'elaborazione simultanea di richieste/risposte da due o più microservizi e combina i vantaggi di entrambi. Il microservizio richiamato può essere composto da diversi altri microservizi. Il modello Brach può essere utilizzato anche per richiamare una singola catena di microservizi o più catene dello stesso tipo, a seconda dei requisiti della tua azienda.

Vantaggi dell'architettura dei microservizi

Nel prossimo futuro, la necessità di microservizi aumenterà notevolmente. Utilizzando i microservizi, i programmi legacy vengono aggiornati. Attraverso il refactoring, le app monolitiche possono essere suddivise in microservizi. Ciò porta alla progressiva modernizzazione del software obsoleto ed è preferibile alla riqualificazione del prodotto da zero utilizzando i microservizi. Lo sviluppo di applicazioni potrebbe trarre grandi vantaggi da una progettazione di microservizi. Di seguito sono elencati alcuni dei suoi principali vantaggi:

un. Produttività superiore

È più facile creare e gestire un'applicazione se è partizionata in sezioni più piccole e autosufficienti. A seconda dei requisiti, ogni servizio può essere sviluppato, distribuito e mantenuto in modo indipendente utilizzando più linguaggi di programmazione, tecnologie e ambienti software. Poiché ogni componente modulare di un'applicazione ha una base di codice più piccola, è più semplice rilasciare, ridimensionare, distribuire e testare più servizi e le attività correlate possono essere suddivise tra i team di sviluppo ed eseguite contemporaneamente.

b. Migliore resilienza

Ciascun microservizio in un'architettura di microservizi è un servizio singolo progettato per servire una funzionalità di un'applicazione ed eseguire attività distinte. Ciascun microservizio si collega ad altri servizi utilizzando semplici interfacce per gestire le problematiche aziendali. Dopo aver stabilito una progettazione basata su microservizi, l'intero processo di rilevamento e risoluzione dei problemi relativi alle prestazioni diventa piuttosto semplice.

Inoltre, poiché questa forma di progettazione fornisce un meccanismo di isolamento dei guasti migliorato rispetto a quello dei singoli moduli, le applicazioni più grandi spesso non sono interessate da un singolo guasto. Pertanto, a lungo termine, il rischio di futuri tempi di inattività è notevolmente ridotto poiché gli sviluppatori hanno una finestra di tempo per rilasciare un aggiornamento o sostituire un modulo senza dover riavviare l'intero programma.

c. Scalabilità estesa

I team DevOps possono scegliere lo stack tecnologico ottimale per ciascun modulo senza preoccuparsi dell'incompatibilità se ogni servizio viene creato utilizzando un linguaggio di programmazione o una tecnologia diversi. I singoli servizi possono essere sviluppati in modo indipendente e nuovi componenti possono essere aggiunti senza tempi di inattività o ridistribuzione del sistema. Inoltre, i servizi possono essere suddivisi su più server, mitigando l'effetto sulle prestazioni di componenti altamente esigenti. In pochi secondi, i microservizi possono fornire il ridimensionamento orizzontale.

In realtà, è l'elevato ridimensionamento orizzontale che costringe organizzazioni come Netflix, Spotify, Uber e Google a passare dall'architettura monolitica all'architettura di microservizi. In secondo luogo, se un microservizio è pesante per la CPU, può essere scritto in un linguaggio di programmazione ottimizzato per la CPU (C/C++, Rust), mentre altri microservizi possono essere scritti in un linguaggio interpretato (Java, PHP).

d. Integrazione continua / Consegna continua (CI/CD)

La fornitura continua e l'integrazione sono elementi fondamentali sia della metodologia agile che della filosofia DevOps. Il design del microservizio consente a un team interfunzionale di creare, eseguire il debug, testare, distribuire e aggiornare i servizi in modo indipendente, il che si tradurrà in una più rapida risoluzione dei problemi e distribuzione a lungo termine.

e. Modularizzazione

Nell'architettura di microservizi, la barriera tra i microservizi è costituita da interfacce fisiche (di rete) difficili da incrociare. Di conseguenza, i microservizi ben progettati in genere forniscono una modularizzazione "liberamente connessa, altamente coerente". Se lo sviluppo del software viene confrontato con la società, la modulazione dei microservizi è paragonabile alle leggi nazionali e internazionali con la polizia/le punizioni. Come già sappiamo, regole rigorose nazionali e internazionali possono spesso mantenere l'ordine sociale.

f. Programma di rilascio

L'aspetto più interessante dell'architettura di microservizi è che ogni microservizio può essere distribuito singolarmente. Di conseguenza, il ciclo di rilascio del software per le applicazioni di microservizi è sostanzialmente più breve e, con CI/CD, possono essere effettuate molte versioni ogni giorno.

Disadvantages of Microservices Architecture

un. Increased Complexity of Communication Between the Services

When an application is broken up into smaller parts, it takes more time to send and receive messages. When handling requests between the different modules, developers have to be extra careful. Different systems might talk to each other in different ways, so there might be a need for an interpreter. This can make it harder to set up the whole system all at once. One of the biggest problems with microservices is that it might be hard to switch from a monolith to microservices because it's hard to manage.

This basically means that a lot of services made by a lot of different teams are deployed in a lot of different places, making it very hard to manage them. For example, Monolithic Architecture gives the same answer whether a Web app has a few thousand lines of code or several million lines of code (Enterprise Java or Ruby on Rails or PHP). But in Microservice Architecture, there are many possible solutions depending on the applications and use cases.

So, Microservice Architecture is doomed to fail if the wrong solution is used for the wrong application size or type (like putting a child's clothes on an adult man or the other way around). Also, it's hard to design Microservices because they have a lot more moving parts than Monoliths. Most of the time, a Microservice with bad design is worse than a Monolith.

b. Complex Configuration

Despite being isolated and self-contained, a microservice must be regularly configured, especially when it is moved from development to test to staging to production. This arrangement may be rather intricate. Moreover, if a microservice must utilize other microservices, these bindings must be defined before deployment or even during runtime.

c. Context Boundary Translation

Despite the fact that it would be ideal if all microservices within a MOA used the same data structures and communication protocols to interact with one another, this is typically not the case.

d. More Assets in Return for More Autonomy

MOAs demand a great deal of horsepower. Remember that each MOA microservice has its own runtime environment and data storage. In some instances, even the most streamlined microservice might consume the same amount of resources as a single monolithic program.

e. Unfeasible for Small Applications

Larger applications can benefit from microservices design. However, implementation will likely be more time-consuming and difficult for smaller applications.

f. Relatively Complex Deployment

The deployment might be a difficult and complicated process. During deployment, coordination between numerous services would be required. Deploying a WAR file in a container would not be as straightforward as it sounds.

g. Distributed Debugging

The difficulty of troubleshooting a MOA including hundreds of microservices communicating in concert is one of the downsides of microservices. Tracing the course of a request into and out of a MOA is challenging due to the independence of each container. The MOA is opaque if there is no effective monitoring mechanism in place. Logging the internals of a MOA offers a limited perspective, but MOA monitoring requires a comprehensive view.

h. Contributes to Enhanced Fault Tolerance

Large applications with several services deployed have more fault tolerance in the event that any one module fails. Microservices allow applications to continue functioning even if one service fails. This is because the services are not tightly coupled.

io. Costly

An improper service partition might be expensive. For instance, if an application is improperly partitioned, the services are connected to a certain degree, and they will create numerous inter-service interactions via the network, which can degrade performance.

j. Greater Security Risks

Lastly, because microservices will reside across several environments, computers, and API requests, they provide a greater number of entry points for an attacker to compromise the system.

k. Communication Complexities

Microservices accomplish rigorous modularity and development independence via process/network barriers, as previously mentioned. The disadvantage is that services may only communicate over the physical network, resulting in increased network latency. Microservices may connect with one another in a variety of methods, including synchronous communication using REST, gRPC, and asynchronous communication using Message Queue and Message Broker, each of which has advantages and disadvantages.

Synchronous communication is simpler to build, but it might result in a Distributed Monolith. Asynchronous Communication via Messaging provides greater flexibility at the expense of increased implementation complexity. In Microservice Architecture, choosing the appropriate Communication channel based on the application is equally tough.

l. Configurazione complessa

Nonostante sia isolato e autonomo, un microservizio deve essere configurato regolarmente, soprattutto quando viene spostato dallo sviluppo al test, dallo staging alla produzione. Questa disposizione può essere piuttosto intricata. Inoltre, se un microservizio deve utilizzare altri microservizi, questi collegamenti devono essere definiti prima della distribuzione o anche durante il runtime.

Strumenti per microservizi

1. Sistema operativo

L'aspetto più importante dello sviluppo di un'applicazione è gettare solide basi per essa, che è qualcosa che il sistema operativo è responsabile di fare. Linux è un esempio di questo tipo di sistema operativo che viene utilizzato frequentemente durante il processo di sviluppo dell'applicazione. Avrai accesso a un ambiente di esecuzione autonomo quando utilizzi i container Linux. Ciò ti dà la possibilità di orchestrare un'ampia gamma di servizi, dallo storage e dal networking alla sicurezza e all'autenticazione.

2. Linguaggi di programmazione

Con Emizentech, ora puoi espandere senza problemi il tuo repertorio di programmazione. Questo strumento è sia pratico che aggiornato. In generale, è progettato per l'uso con tutti i linguaggi di programmazione. Inoltre, è compatibile con il bytecode mostrato sul BEAM, chiamato anche Erlang Virtual Machine.

3. Strumenti di gestione e test delle API (gateway API)

L'atto di creare e rilasciare API, far rispettare i loro standard di utilizzo, limitare l'accesso, coltivare la comunità di sviluppatori, raccogliere e analizzare le statistiche di utilizzo e creare report sulle prestazioni sono tutti componenti dell'amministrazione delle API.

In realtà, una piattaforma di gestione delle API è composta dai seguenti elementi:

• Strumenti di sviluppo
• Gateway
• Reportistica e analisi

4. Strumenti di messaggistica (messaggistica e streaming di eventi)

Affinché le comunicazioni avvengano, il sistema di microservizi deve utilizzare servizi indipendenti. Questo è il fattore principale che determina ciò che la coda dei messaggi richiede ai suoi utenti. RabbitMQ e Apache Kafka sono due delle soluzioni più popolari utilizzate ai fini della messaggistica.

LinkedIn è responsabile della creazione della tecnologia nota come Apache Kafka, che è stata successivamente apportata alla comunità Apache.

I modelli vengono utilizzati dallo strumento RabbitMQ per facilitare la comunicazione tra i numerosi microservizi. Inoltre, aiuta nel processo di ridimensionamento simultaneo delle applicazioni.

5. Kit di strumenti

Per dirla più semplicemente, un toolkit è solo una raccolta di strumenti che vengono impiegati durante l'esecuzione di una determinata procedura. Il Toolkit è un componente dell'architettura del microservizio che consente di creare molte app. Per questo motivo, esiste un'ampia varietà di toolkit, ognuno dei quali ha un obiettivo distinto nella sua applicazione. I numerosi strumenti disponibili tra cui scegliere all'interno di Fabric8 e Seneca.

• Fabric8 è una piattaforma come tecnologia di servizio che, con l'assistenza di Git, consente agli sviluppatori di software di creare un sistema di gestione della configurazione per le loro applicazioni.
• Seneca, che opera come nodo, viene utilizzato nel processo di sviluppo di microservizi orientati ai messaggi.

6. Strutture architettoniche e Js Toolkit

Poiché i microservizi sono uno stile architettonico, è essenziale prestare attenzione alla struttura architettonica che utilizzano. Questi sono i framework che vengono utilizzati insieme alle tecnologie attuali per costruire le applicazioni più recenti. Goa e Kong sono ora le strutture architettoniche più popolari.

7. Strumenti di orchestrazione

A causa del modo generale in cui i contenitori ei microservizi funzionano insieme, l'orchestrazione dei contenitori è un argomento molto importante su cui riflettere. Conductor, Kubernetes e Istio sono le tre soluzioni di orchestrazione di microservizi usate più spesso per l'orchestrazione di container. Tuttavia, ci sono molti altri strumenti disponibili. Come parte dell'ecosistema software open source (OSS) gestito da Netflix, il direttore funge da motore di orchestrazione dei microservizi. Il direttore è un programma che viene eseguito nel cloud e utilizza un'implementazione denominata orchestratore di flusso per eseguire varie attività utilizzando i microservizi. Inoltre, semplifica la gestione e la visualizzazione di tutte le interazioni che si verificano tra i microservizi.

8. Strumenti di monitoraggio

Dopo che l'applicazione di microservizi è stata creata, è necessario gestire le attività ad essa associate. Avrai bisogno di strumenti di monitoraggio per i tuoi microservizi per ottenere lo stesso risultato. Prometheus e Log Stash sono le due tecnologie per il monitoraggio dei microservizi utilizzati più frequentemente. Logstash è un ottimo software. È una piattaforma che consente di consolidare, archiviare e manipolare i dati ed è open source.

9. Strumenti senza server

Una componente significativa dei microservizi di SA è la tecnologia serverless, spesso nota come funzione come servizio. Migliora l'efficienza del processo di smantellamento degli oggetti nei loro componenti più fondamentali. Sia Claudia che AWS Lambda sono esempi di strumenti serverless ampiamente utilizzati per lo sviluppo di microservizi. Anche le installazioni di AWS Lambda e API Gateway fanno parte delle responsabilità di Claudia. In aggiunta a questo, Claudia è in grado di automatizzare le attività di installazione e installazione soggette a errori mantenendo la sua funzionalità "pronta all'uso".

10. Contenitori, Docker e Kubernetes

• Contenitori: i contenitori essenzialmente virtualizzano il sistema operativo host (o kernel), isolando le esigenze di un'applicazione da quelle di altri contenitori in esecuzione sullo stesso computer.
• Docker: Docker è composto da diverse parti, tra cui un runtime del contenitore denominato dockerd, un generatore di immagini del contenitore noto come BuildKit e un'interfaccia a riga di comando utilizzata per interagire con il builder, i contenitori e il motore (chiamato docker).
• Kubernetes è una tecnologia di gestione dei container gratuita e open source che combina un gruppo di computer in un unico pool di risorse informatiche. Kubernetes è stato sviluppato da Google. Kubernetes ti consente di strutturare le tue applicazioni sotto forma di gruppi di contenitori, che vengono poi eseguiti dal motore Docker. Kubernetes si occupa di garantire che la tua applicazione continui a funzionare nel modo specificato.

Modelli comuni nell'architettura dei microservizi

un. Modello back-end per front-end (BFF).

BFF fornisce un'interfaccia semplice tra il frontend e i microservizi. In uno scenario ideale, il team di front-end sarà anche responsabile della gestione del BFF. Una singola BFF riguarda esclusivamente una singola interfaccia utente. Di conseguenza, saremo in grado di semplificare i nostri frontend e avere una visualizzazione unica dei dati tramite il suo backend.

b. Entità e modelli aggregati

Un'entità è una cosa distinta in base alla sua identità. Su un sito di e-commerce, ad esempio, un oggetto Prodotto può essere identificato dal nome, dal tipo e dal prezzo del prodotto. Un aggregato è un insieme di cose che dovrebbero essere considerate come una singola unità. Pertanto, per il sito di e-commerce, un Ordine sarebbe la raccolta (aggregata) di cose (entità) che un cliente ha acquistato. Questi modelli vengono utilizzati per classificare in modo significativo i dati.

c. Modelli di individuazione dei servizi

Svolgono un ruolo cruciale nel facilitare la scoperta di servizi e applicazioni. Le istanze del servizio possono variare nel contesto dell'architettura del microservizio a causa di cause quali errori del servizio, scalabilità, interruzione del servizio e aggiornamenti. Questi modelli forniscono strumenti per la scoperta per affrontare questa transitorietà. Utilizzando i controlli dello stato e gli errori del servizio come trigger di ribilanciamento del traffico, il bilanciamento del carico può impiegare tecniche di rilevamento dei servizi.

d. Modelli di microservizi dell'adattatore

Il design di Adapter Microservices si adatta, se necessario, tra un'API orientata al business costruita utilizzando tecniche di messaggistica RESTful o leggere, utilizzando le stesse metodologie basate sul dominio di un tipico microservizio, e un'API legacy o un servizio SOAP classico basato su WS-*. L'adattamento è necessario, ad esempio, quando un team di sviluppo non ha il controllo decentralizzato sull'origine dati di un'applicazione.

e. Modello di applicazione strangolatore

Lo Strangler Pattern è un modello architettonico noto per trasformare lentamente un'applicazione monolitica in microservizi sostituendo una funzionalità specifica con un nuovo servizio.

Anti-pattern nell'architettura dei microservizi

un. Coesione Caos

I servizi devono essere chiaramente allineati a una capacità aziendale e non devono tentare di ottenere risultati al di fuori del loro ambito. La separazione funzionale delle preoccupazioni è fondamentale da gestire per l'architettura; in caso contrario, rovinerebbe agilità, prestazioni e scalabilità, risultando in un'architettura strettamente connessa con entropia di consegna e caos di coesione.

b. Architettura dei servizi a più livelli

Uno degli errori SOA più diffusi è stato l'incomprensione di come realizzare la riutilizzabilità del servizio. I team erano in gran parte interessati alla coesione tecnica piuttosto che alla riutilizzabilità funzionale.

c. Complessità

Un altro fattore importante per supportare l'architettura dei microservizi è la maturità organizzativa. I team di sviluppo devono essere riformati per assumersi maggiori responsabilità per lo stack completo, DevOps, piuttosto che inviare semplicemente ticket di sola andata al team dell'infrastruttura.

d. Strategia di controllo delle versioni scadente

Una strategia di controllo delle versioni inefficace genera codice e dipendenze non gestibili. Di conseguenza, dovrebbe essere in atto un approccio efficiente al controllo delle versioni per l'architettura dei microservizi. Uno degli approcci più basilari consiste nel creare una versione dell'API e includere la versione nell'URL del percorso.

e. Progettazione impropria di modelli di accesso ai dati del carico di lavoro dei microservizi

Modelli di accesso ai dati del carico di lavoro dei microservizi non corretti: l'architettura di un microservizio dipende dal database di un'organizzazione. I modelli di accesso ai dati tra i microservizi devono essere chiaramente separati. È spesso accettabile utilizzare un singolo database in più istanze del servizio, purché i dati si trovino in tabelle/raccolte opportunamente partizionate.

f. Disturbo da dipendenza

Il disturbo da dipendenza è un anti-modello che si sviluppa quando si è consapevoli che i servizi devono essere distribuiti in un ordine specifico per funzionare correttamente. Quando non c'è controllo sulla separazione funzionale delle preoccupazioni, potrebbe sorgere il caos della coesione.

Un buon modo per evitare questo anti-pattern è introdurre un gateway API.

Differenze tra architettura monolitica, di microservizi e orientata ai servizi

Mercati verticali chiave che richiedono microservizi

Sanità: si prevede che il mercato dei microservizi sanitari crescerà da 130 milioni di dollari nel 2015 a 519 milioni di dollari entro il 2025. La necessità di un'implementazione più rapida dei servizi, una più rapida accettazione di nuove tecnologie e una migliore efficienza stanno guidando lo sviluppo nel settore sanitario. Il settore sanitario cerca risposte per le sue esigenze di sicurezza dei dati e conformità normativa, nonché come superare le difficoltà di implementazione.

Bancario, finanziario e assicurativo: Aspen Mesh identifica tre importanti vantaggi dei microservizi per i servizi finanziari: maggiore sicurezza attraverso la creazione di un servizio di identità distinto, consegna più rapida di nuove funzionalità e un livello API più facile da gestire.

Enti pubblici: oltre ai vari vantaggi dell'architettura di microservizi, le aziende governative possono trarre vantaggio dalla sua capacità di progettare funzionalità che corrispondono agli obiettivi aziendali, consentendo ai team IT di stabilire o migliorare i servizi in base alle richieste dei componenti.

Vendita al dettaglio: Amazon ed eBay hanno dimostrato i vantaggi dei microservizi per il settore della vendita al dettaglio, inclusi servizi altamente accessibili e scalabili e una gestione più efficace di bug ed errori.

Media e intrattenimento: nel 2009, Netflix è migrato ai microservizi e attualmente il servizio elabora 2 miliardi di richieste edge ogni giorno utilizzando più di 500 microservizi. La modifica offre velocità, scalabilità e accessibilità.

Esempi di aziende che hanno adottato l'architettura di microservizi

Amazon, Coca-Cola e Zalando, tra gli altri, stanno trasformando le loro infrastrutture IT in un'architettura di microservizi. Inoltre, stanno riorganizzando le loro strutture organizzative interne e spingendo le loro imprese in prima linea nel mercato. L'implementazione dell'architettura di microservizi è divertente quando si acquisiscono conoscenze dai migliori del settore. Ecco alcune delle istanze più efficaci di microservizi.

# 1. Uber

Il concetto di proprietà è stato devastato da dipendenze monolitiche intrecciate. La migrazione è diventata una sfida. I nuovi sviluppatori non sono stati in grado di contribuire al monolito. Piccoli errori hanno portato a risultati catastrofici. Uber ha scelto di implementare servizi basati su cloud. Uber ha sviluppato microservizi per diverse operazioni, tra cui la fatturazione e la gestione di passeggeri e viaggi. I gateway API vengono utilizzati per comunicare con i servizi.

Inoltre, Uber ha stabilito standard mondiali per i suoi microservizi. Forniscono criteri quantitativi per la documentazione, l'affidabilità, la tolleranza agli errori e così via. Queste caratteristiche sono state monitorate utilizzando indicatori commerciali come le visite alle pagine. Ben presto, i loro servizi raggiunsero l'apice dell'eccellenza.

#2. Netflix

Netflix è quindi migrato a un'infrastruttura di dati distribuiti basata su cloud. AWS è stato utilizzato per fornire sistemi scalabili orizzontalmente e servizi/funzionalità aggiuntivi. Nel 2009 Netflix ha iniziato il suo trasferimento, terminato dopo quasi tre anni. Quindi Netflix ha convertito tutte le sue applicazioni rivolte agli utenti in microservizi autonomi. Nel 2012 il restyling è terminato. Entro il 2015, Netflix ha eliminato tutte le interruzioni del servizio ed è stata in grado di elaborare circa 2 miliardi di query API al giorno. Attualmente, Netflix ha oltre 139 milioni di utenti in 190 paesi. Oggi Netflix gestisce circa 700 sistemi di microservizi separatamente.

#3. Amazon

Amazon ha avuto un grande monolite nel 2001. Nel 2021, praticamente tutti hanno familiarità con Amazon Web Services (AWS), una soluzione interna che è diventata un servizio di cloud computing commerciale grazie alla sua superiorità. I microservizi sono eccellenti per l'e-commerce perché possono monitorare l'attività degli utenti, gli acquisti e l'intero funnel di vendita. Secondo il senior product manager di Amazon

Quindi, producono dati utili per ottimizzare la presentazione del prodotto e il processo di vendita stesso. Amazon è una delle prime aziende in cui i microservizi hanno svolto un ruolo significativo nell'alterare l'intera organizzazione. Il colosso mondiale ha ottenuto un successo straordinario in un periodo in cui il design dei monoliti era "la norma" per la costruzione di sistemi informatici.

Tutte le modifiche significative al codice sono state bloccate nel processo di distribuzione per settimane prima di essere rese disponibili agli utenti. Amazon ha utilizzato microservizi per semplificare e ridurre la durata del processo. Separando le strutture in singole app, gli sviluppatori sono stati in grado di determinare dove si trovavano i colli di bottiglia, la natura dei rallentamenti e ricostruire le strutture come architetture orientate ai servizi, ciascuna con un piccolo team dedicato a un singolo servizio.

Quella che era iniziata come una pulizia del sistema ha portato alla crescita di uno dei principali attori online dell'architettura contemporanea. Amazon ha aperto la strada ad altre aziende rilasciando una serie di tecnologie open source, come AWS (Amazon Web Services), che ora sono pervasive.

#4. eBay

Il sistema eBay supporta circa un migliaio di microservizi. Le esperienze di front-end, come il web e le applicazioni native iOS e Android, contattano i servizi intermediari che coordinano le chiamate, che poi comunicano con i servizi di back-end. Ciascuno dei servizi ha un proprio gruppo di sviluppo autonomo. La maggior parte dei microservizi di eBay si è evoluta senza un architetto e il sistema è sempre stato progettato dal basso verso l'alto. La maggior parte delle grandi aziende, come eBay, è approdata a una raccolta di microservizi poliglotti che funzionano in base alle esigenze dei clienti e, ovviamente, sono in continua evoluzione.

#5. SoundCloud

Ogni servizio viene sviluppato e distribuito in modo indipendente, collegandosi ad altri servizi attraverso la rete utilizzando standard di scambio di dati leggeri come JSON o Thrift. Per tutta la durata del turno, i nuovi microservizi non sono stati in grado di alterare il modello relazionale in MySQL o, peggio ancora, di utilizzare un motore di archiviazione diverso. Per circostanze estreme, come la messaggistica da utente a utente in cui un modello basato su thread è stato sostituito con uno simile a una chat, l'azienda ha utilizzato cronjob per sincronizzare database separati.

#6. Spotify

Al fine di prevenire l'inferno di sincronizzazione all'interno dell'azienda, Spotify è progettato su un'architettura di microservizi con team autonomi full-stack responsabili. Spotify utilizza un'architettura di microservizi in cui tutti gli sviluppatori di software scrivono in "territori" chiusi con le proprie capacità uniche. Ogni microservizio ha una responsabilità unica e diretta e, nella maggior parte dei casi, un database e una logica a cui non è possibile accedere da un altro processo.

Che tipo di sfide possono aiutarti a superare i microservizi?

Questa è la soluzione alla domanda “quali difficoltà risolvono i microservizi?”; esaminiamo gli ostacoli che le architetture di microservizi hanno contribuito a superare.

CASO 1 Saldo di eBay recuperato

eBay utilizza quasi mille servizi. Molti servizi front-end inviano chiamate API, mentre i servizi back-end svolgono operazioni amministrative e relative alla spedizione. Inizialmente eBay utilizzava un programma monolitico Perl e C++. Il sito Web di eBay è un prodotto primario, come lo è per molti altri titani di Internet. La necessità di aggiungere diverse funzionalità incrementali al sito Web di eBay ha continuato ad aumentare. Inoltre, questo tipo di sito Web doveva essere accessibile 24 ore al giorno, sette giorni alla settimana, anche se venivano aggiunte nuove funzionalità.

A causa della necessità di ridurre al minimo i tempi di inattività, eBay ha deciso di passare all'architettura dei microservizi. Ciò ha consentito al sito di diventare più stabile e ha promosso l'integrazione asincrona. Sono stati apportati miglioramenti significativi alla flessibilità di distribuzione e alla durata del ciclo di rilascio. Quando i servizi sono stati isolati, l'efficienza delle prestazioni è aumentata e la scalabilità orizzontale è stata semplificata.

CASO 2 Uber ed espansione rapida

Uber, il servizio di taxi più popolare, è iniziato con un unico pacchetto per servire i pendolari a San Francisco, dove è stato inizialmente implementato. Questo software strettamente connesso è stato in grado di gestire la maggior parte, se non tutte, le attività aziendali, inclusi fatturazione, pagamenti e servizi di connessione del conducente. Con lo sviluppo dell'azienda, però, le cose iniziarono a declinare. Uber stava espandendo la sua area di copertura e offrendo altri servizi.

Con l'aggiunta di ulteriori funzionalità, il pacchetto è diventato più coeso. Tutta la logica era contenuta in un unico luogo e le difficoltà iniziarono a emergere. Presto, anche una piccola modifica ha richiesto la ridistribuzione dell'intero programma. L'integrazione continua diventa quasi immediatamente una grande responsabilità.

L'assenza del modello di proprietà era dovuta alle numerose dipendenze interdipendenti del monolito. Pertanto, la migrazione è stata dura. Si è anche verificato che gli sviluppatori appena assunti non sono stati in grado di contribuire al monolito. Anche se si è verificato un errore minore, le conseguenze sono state gravi. Questo è quando hanno preso la decisione di implementare i microservizi. Il loro movimento ha richiesto del tempo. Hanno smontato l'intero servizio e migrato l'applicazione monolitica a un'architettura orientata ai micro servizi creata utilizzando Python, Node.js e Apache Thrift.

CASE 3 Tempo di attività migliorato di Twitter

Era la solita vecchia storia: Twitter utilizzava per la prima volta un design monolitico, che aveva molto senso. Tuttavia, quando più persone si sono registrate su Twitter, sono sorti problemi. L'SDLC è diventato più grande e ingombrante, con tempi di costruzione più lunghi e la sua scalabilità è peggiorata in modo significativo, con la comparsa occasionale di avvisi di errore di capacità eccessiva.

Twitter è ricorso alla modifica dell'architettura in microservizi per risolvere questo problema. Ogni microservizio è stato creato per essere modulare, ben definito e autonomo. Possono testare e distribuire individualmente ogni componente. Potrebbero anche essere misurati in modo indipendente. Presto, gli avvisi di errore sono scomparsi del tutto.

CASO 4 Codice KarmaWifi e Spaghetti

Ci sono persone, gadget e un negozio su Karma. A un certo punto, con un programma monolitico disponibile, il codice relativo all'utente è finito in porzioni relative al dispositivo. Inoltre, le API del negozio hanno seguito le API del dispositivo. Presto divenne difficile determinare cosa fosse cambiato e chi lo avesse cambiato. Sebbene l'obiettivo iniziale fosse quello di dividere il monolito in librerie funzionali, si è scoperto che l'espansione e l'adattamento alle versioni software più recenti sarebbe stato impegnativo. Inoltre, non sarebbero in grado di sperimentare innovazioni future che verranno introdotte sul mercato.

A quel punto, avevano scelto di utilizzare un'architettura basata su microservizi. Quando lo hanno ritenuto essenziale, hanno separato parti dell'applicazione back-end in singoli servizi. Le parti inizialmente erano enormi, ma nel tempo si sono suddivise in servizi più piccoli. Alla fine, ogni microservizio aveva una singola attività e una dimensione massima di cui preoccuparsi.

CASE 5 Prestazioni migliorate di Walmart

L'avventura dei microservizi di Walmart è iniziata con l'acquisizione di una piattaforma DevOps da una piccola azienda chiamata OneOps. Hanno scelto di farne un'iniziativa open source in modo da poter contribuire alla comunità.

Hanno iniziato a utilizzare tecnologie come i database Node.js e Cassandra per creare vari microservizi che potevano essere attivati ​​dinamicamente tramite le API. L'obiettivo era rendere più semplice per gli sviluppatori che lavorano nelle numerose divisioni aziendali di Walmart possedere le proprie app e consentire loro di farlo. Hanno scoperto che questo riduceva la dipendenza da un gruppo IT centralizzato.

In definitiva, la capacità degli sviluppatori di estendere le capacità di back-end delle offerte di eCommerce dell'organizzazione ha contribuito ad aumentare l'agilità aziendale.

Come implementare l'architettura di microservizi su Android e iOS?

1. Passaggio 1: decidi se è davvero ciò di cui la tua azienda ha bisogno.
2. Passaggio 2: se sì, guarda l'infrastruttura già presente.
3. Passaggio 3: prepara il tuo team a utilizzare il metodo.
4. Passaggio 4: se si passa da un sistema monolitico a un sistema di microservizi, verificare con l'amministratore dei dati se è ben informato e comprende l'attività.
5. Passaggio 5: scegli la lingua e il framework per la codifica.
6. Passaggio 6: configurare l'architettura di base con servizi, contenitori e modelli di macchine virtuali.
7. Passaggio 7: dividere il database in molti database più piccoli se l'architettura è un "monolito".
8. Passaggio 8: installa i gateway API.
9. Passaggio 9: traccia il monitoraggio e creane una mappa.
10. Passaggio 10: verifica utilizzando l'automazione.

I microservizi sono il futuro?

L'obiettivo principale di questo articolo è spiegare i concetti ei principi fondamentali dei microservizi. Facendo uno sforzo per raggiungere questo obiettivo, è evidente che consideriamo lo stile dell'architettura dei microservizi un concetto essenziale, un concetto che le applicazioni aziendali dovrebbero esaminare attentamente. Di recente, abbiamo sviluppato una serie di sistemi che utilizzano questo metodo e siamo a conoscenza di altri che apprezzano questo metodo. Amazon, Netflix, The Guardian, il servizio digitale del governo del Regno Unito, realestate.com.au, Forward e comparethemarket.com sono tra coloro di cui siamo a conoscenza che sono i pionieri dello stile architettonico in qualche modo.

Spesso, le effettive ramificazioni delle decisioni architettoniche non sono evidenti fino a diversi anni dopo. Un buon team con una forte spinta alla modularità ha occasionalmente costruito un design monolitico che si è deteriorato nel tempo. Molte persone sostengono che tale deterioramento è meno possibile con i microservizi poiché i limiti del servizio sono evidenti e difficili da correggere. Tuttavia, non possiamo valutare con precisione la maturità delle architetture di microservizi finché non abbiamo un numero sufficiente di sistemi con un'età sufficiente.

Ci sono sicuramente ragioni per prevedere che i microservizi si svilupperanno lentamente. Il successo di qualsiasi sforzo di componentizzazione dipende dal modo in cui il software si adatta bene ai componenti. È difficile determinare dove posizionare i bordi dei componenti. Il design evolutivo riconosce la difficoltà di stabilire confini corretti e, quindi, l'importanza di semplificarne la rielaborazione. Tuttavia, quando i componenti sono servizi con comunicazioni esterne, il refactoring è molto più difficile rispetto a quando si lavora con le librerie in-process.

Lo spostamento del codice oltre i confini del servizio è complesso, tutte le modifiche all'interfaccia devono essere organizzate tra i partecipanti, devono essere stabiliti livelli di compatibilità aggiuntivi e il test è complicato. Se i componenti non si compongono in modo ordinato, stai semplicemente spostando la complessità dall'interno di un componente ai collegamenti tra i componenti. Questo non solo sposta la complessità, ma la sposta anche in un luogo meno esplicito e più difficile da governare. Quando si esamina l'interno di un componente minuscolo e semplice, è facile trascurare i complicati collegamenti tra i servizi e concludere che le cose sono migliori di quanto non siano in realtà.

Infine, c'è da considerare la competenza del team. È più probabile che i team esperti adottino nuove pratiche. Un approccio che ha più successo per un team altamente qualificato, tuttavia, potrebbe non funzionare sempre per un team meno qualificato. Abbiamo visto diversi esempi di team incompetenti che costruiscono strutture monolitiche sciatte, ma ci vorrà del tempo per determinare cosa succede quando si verifica questo tipo di caos con i microservizi. Una squadra scadente produrrà sempre un sistema scadente; è difficile dire se i microservizi migliorino o peggiorino la situazione in questa circostanza.

 Quindi scriviamo questo con cauto ottimismo. Crediamo che i microservizi siano qui per restare!

Perché scegliere EmizenTech?

Emizentech può assisterti nella migrazione della tua applicazione da un'architettura monolitica a un'architettura di microservizi. Possiamo assistervi nel rendere la vostra applicazione aziendale semplice da mantenere e scalabile. Se vuoi crescere e sviluppare la tua attività e stai cercando nuovi modi per farlo, emizentech può aiutarti nel modo giusto assicurandoti una crescita a lungo termine. Puoi anche visitare il nostro sito Web per saperne di più sui microservizi, capire se la tua azienda è pronta e parlare di come implementare questa architettura. È un modo di creare software che si concentra sulla suddivisione di un'applicazione in moduli che fanno solo una cosa e hanno interfacce ben definite.

Le caratteristiche distintive dei nostri servizi sono:

• Un'architettura basata sul dominio per prevenire il fallimento dell'applicazione
• Garantire un elevato grado di scalabilità
• Progettazione decentralizzata di database
• Abilita un semplice isolamento degli errori e
• Abilita la distribuzione continua usando la cultura DevOps.

Pensieri di chiusura

Fai il prossimo passo!

In questo blog, abbiamo fatto uno sforzo per indagare le diverse sfaccettature dell'architettura dei microservizi e le possibilità che presenta. La funzionalità di un sistema applicativo può essere suddivisa in un numero di unità funzionali più piccole quando si utilizza un approccio architetturale noto come microservizi. L'implementazione e la gestione dei servizi sono gestite separatamente l'una dall'altra. Quando i sistemi monolitici vengono suddivisi in parti più piccole utilizzando un'architettura di microservizi, il numero dei singoli componenti aumenta notevolmente.

Pertanto, è necessario avere una gestione efficiente delle dipendenze che esistono tra di loro. Rispetto all'architettura software monolitica, è vero che la creazione e l'esecuzione di un'architettura di microservizi presenta una serie di sfide e richiede un cambio di paradigma. Allo stesso modo, l'architettura di microservizi non è in alcun modo una bacchetta magica in grado di risolvere i problemi di complessità che sorgono in qualsiasi tipo di sistema.

Quando tutto viene preso in considerazione, pensiamo che l'architettura di microservizi sia uno strumento estremamente utile e conveniente per lo sviluppo software contemporaneo. L'architettura di microservizi è l'unica strategia praticabile per le grandi aziende che in genere generano software complicato poiché è l'unico metodo per affrontare efficacemente la complessità e mantenere un vantaggio competitivo sul mercato. L'architettura di microservizi dovrebbe essere utilizzata per lo sviluppo di software sostenibile, che può offrire vantaggi a lungo termine, non solo dalle grandi aziende ma anche dalle piccole e medie imprese.

È importante notare che i primi utenti dell'architettura di microservizi, come Spotify, Netflix, LinkedIn, Amazon e Google, sono stati in grado di ottenere importanti vantaggi competitivi rispetto ai loro rivali grazie all'adozione dell'architettura di microservizi. Lo sviluppo e l'esame di un modello architettonico sono entrambe opzioni praticabili per assistere in questo sforzo. Questo metodo promette di semplificare le cose e semplificare la vita agli sviluppatori senza danneggiare negativamente i profitti, il che è particolarmente importante ora che le aziende stanno entrando in un nuovo periodo di forte concorrenza.

La stragrande maggioranza delle aziende è interessata a migliorare la propria efficienza in termini di costi e, in questo contesto, si prevede che l'architettura serverless acquisirà maggiore popolarità nel corso dei prossimi anni. La potenziale portata dei microservizi nel futuro del mondo sembra essere piuttosto promettente.

I microservizi possono aiutare la tua azienda ad andare avanti? Non esitare a contattarci per una consulenza non vincolante!

Grazie per aver letto!

Domande frequenti sull'architettura dei microservizi