Il Book Building Microservices descrive in dettaglio gli stili citati da @RogerAlsing nella sua risposta.
A pagina 43 sotto Orchestrazione vs Coreografia il libro dice:
Quando iniziamo a modellare una logica sempre più complessa, dobbiamo affrontare il problema della gestione dei processi aziendali che si estendono oltre i confini dei singoli servizi. E con i microservizi, raggiungeremo questo limite prima del solito. [...] Quando si tratta di implementare effettivamente questo flusso, ci sono due stili di architettura che potremmo seguire. Con l'orchestrazione, ci affidiamo a un cervello centrale per guidare e guidare il processo, proprio come il direttore d'orchestra. Con la coreografia, informiamo ogni parte del sistema del suo lavoro e lasciamo che elabori i dettagli, come tutti i ballerini che trovano la loro strada e reagiscono agli altri intorno a loro in un balletto.
Il libro procede quindi a spiegare i due stili. Lo stile dell'orchestrazione corrisponde più all'idea SOA dei servizi di orchestrazione / attività , mentre lo stile coreografico corrisponde alle stupide pipe e agli endpoint intelligenti menzionati nell'articolo di Martin Fowler.
Stile orchestrazione
Sotto questo stile, il libro sopra menziona:
Pensiamo a come sarebbe una soluzione di orchestrazione per questo flusso. Qui, probabilmente la cosa più semplice da fare sarebbe fare in modo che il nostro servizio clienti funga da cervello centrale. Al momento della creazione, parla con la banca punti fedeltà, il servizio e-mail e il servizio postale [...], attraverso una serie di chiamate di richiesta / risposta. Il servizio clienti stesso può quindi tracciare dove si trova un cliente in questo processo. Può verificare se l'account del cliente è stato impostato, l'email inviata o la posta consegnata. Possiamo prendere il diagramma di flusso [...] e modellarlo direttamente in codice. Potremmo persino usare strumenti che lo implementano per noi, magari usando un motore di regole adeguato. A tale scopo esistono strumenti commerciali sotto forma di software di modellizzazione dei processi aziendali. Supponendo che utilizziamo la richiesta / risposta sincrona, potremmo persino sapere se ogni fase ha funzionato [...] L'aspetto negativo di questo approccio di orchestrazione è che il servizio clienti può diventare troppo un'autorità governativa centrale. Può diventare l'hub nel mezzo di una rete e un punto centrale in cui la logica inizia a vivere. Ho visto questo approccio sfociare in un piccolo numero di servizi intelligenti "divini" che dicono ai servizi anemici basati su CRUD cosa fare.
Nota: suppongo che quando l'autore menziona gli strumenti si riferisca a qualcosa come BPM (ad es. Activity , Apache ODE , Camunda ). È un dato di fatto, il sito Web dei modelli di flusso di lavoro ha un fantastico set di modelli per eseguire questo tipo di orchestrazione e offre anche dettagli di valutazione di diversi strumenti del fornitore che aiutano a implementarlo in questo modo. Non penso che l'autore implichi che è necessario utilizzare uno di questi strumenti per implementare questo stile di integrazione, tuttavia è possibile utilizzare altri framework di orchestrazione leggeri, ad esempio Spring Integration , Apache Camel o Mule ESB
Tuttavia, altri libri che ho letto sull'argomento dei microservizi e in generale la maggior parte degli articoli che ho trovato sul web sembrano sfavorire questo approccio di orchestrazione e suggeriscono invece di usare quello successivo.
Stile coreografico
Sotto lo stile delle coreografie l'autore dice:
Con un approccio coreografico, potremmo invece far sì che il servizio clienti emetta un evento in modo asincrono, affermando che il cliente è stato creato. Il servizio di posta elettronica, il servizio postale e la banca di punti fedeltà si iscrivono quindi solo a questi eventi e reagiscono di conseguenza [...] Questo approccio è significativamente più disaccoppiato. Se è necessario un altro servizio per raggiungere la creazione di un cliente, deve solo iscriversi agli eventi e svolgere il proprio lavoro quando necessario. Il rovescio della medaglia è che la visione esplicita del processo aziendale che vediamo nel [flusso di lavoro] ora si riflette solo implicitamente nel nostro sistema [...] Ciò significa che è necessario un lavoro aggiuntivo per garantire che sia possibile monitorare e tenere traccia delle cose giuste è accaduto. Per esempio, sapresti se la banca dei punti fedeltà ha avuto un bug e per qualche motivo non ha creato l'account corretto? Un approccio che mi piace affrontare con questo è quello di costruire un sistema di monitoraggio che corrisponda esplicitamente alla visione del processo aziendale in [il flusso di lavoro], ma che quindi segua ciò che ciascuno dei servizi fa come entità indipendenti, permettendoti di vedere strane eccezioni mappate sul flusso di processo più esplicito. Il [diagramma di flusso] [...] non è la forza trainante, ma solo un obiettivo attraverso il quale possiamo vedere come si comporta il sistema. In generale, ho scoperto che i sistemi che tendono maggiormente all'approccio coreografico sono accoppiati più liberamente, e sono più flessibili e suscettibili di cambiamento. Tuttavia, è necessario svolgere un lavoro extra per monitorare e tracciare i processi oltre i confini del sistema. Ho trovato le implementazioni maggiormente orchestrate estremamente fragili, con un costo di cambiamento più elevato. Con questo in mente, preferisco fortemente puntare su un sistema coreografato, in cui ogni servizio è abbastanza intelligente da capire il suo ruolo nell'intera danza.
Nota: fino ad oggi non sono ancora sicuro che la coreografia sia solo un altro nome per l' architettura guidata dagli eventi (EDA), ma se l'EDA è solo un modo per farlo, quali sono gli altri modi? (Vedi anche Cosa intendi con "Event-Driven"? E The Meanings of Event-Driven Architecture ). Inoltre, sembra che cose come CQRS ed EventSourcing risuonino molto con questo stile architettonico, giusto?
Ora, dopo questo arriva il divertimento. Il libro sui microservizi non presuppone che i microservizi saranno implementati con REST. È un dato di fatto nella prossima sezione del libro, continuano a considerare le soluzioni basate su RPC e SOA e infine il REST. Un punto importante qui è che i microservizi non implicano il REST.
Quindi, che dire di HATEOAS? (Hypermedia come motore dello stato dell'applicazione)
Ora, se vogliamo seguire l'approccio RESTful, non possiamo ignorare HATEOAS o Roy Fielding sarà molto contento di dire nel suo blog che la nostra soluzione non è veramente REST. Vedi il suo post sul blog sull'API REST Deve essere Hypertext Driven :
Mi sento frustrato dal numero di persone che chiamano qualsiasi interfaccia basata su HTTP un'API REST. Cosa bisogna fare per rendere chiaro lo stile architettonico REST sull'idea che l'ipertesto sia un vincolo? In altre parole, se il motore dello stato dell'applicazione (e quindi l'API) non è guidato dall'ipertesto, non può essere RESTful e non può essere un'API REST. Periodo. C'è qualche manuale rotto da qualche parte che deve essere riparato?
Quindi, come puoi vedere, Fielding pensa che senza HATEOAS non stai veramente costruendo applicazioni RESTful. Per Fielding, HATEOAS è la strada da percorrere quando si tratta di servizi di orchestrazione. Sto solo imparando tutto questo, ma per me, HATEOAS non definisce chiaramente chi o quale sia la forza trainante dietro effettivamente seguire i collegamenti. In un'interfaccia utente che potrebbe essere l'utente, ma nelle interazioni computer-computer, suppongo che debba essere fatto da un servizio di livello superiore.
Secondo HATEOAS, l'unico collegamento che il consumatore dell'API deve veramente conoscere è quello che avvia la comunicazione con il server (ad es. POST / ordine). Da questo punto in poi, REST eseguirà il flusso, poiché, nella risposta di questo endpoint, la risorsa restituita conterrà i collegamenti ai successivi stati possibili. Il consumatore dell'API decide quindi quale collegamento seguire e sposta l'applicazione allo stato successivo.
Nonostante quanto sia bello, il client deve ancora sapere se il link deve essere POSTATO, MESSO, OTTENUTO, PATCH, ecc. E il cliente deve ancora decidere quale payload deve passare. Il cliente deve ancora essere consapevole di cosa fare se fallisce (riprovare, compensare, annullare, ecc.).
Sono abbastanza nuovo in tutto questo, ma per me, dal punto di vista di HATEOA, questo cliente o consumatore API è un servizio di alto livello. Se lo pensiamo dal punto di vista di un essere umano, puoi immaginare un utente finale su una pagina web, decidere quali link seguire, ma il programmatore della pagina web deve decidere quale metodo utilizzare per invocare i link, e quale payload passare. Quindi, a mio avviso, in un'interazione computer-computer, il computer assume il ruolo di utente finale. Ancora una volta questo è ciò che chiamiamo un servizio di orchestrazioni.
Suppongo che possiamo usare HATEOAS con l'orchestrazione o la coreografia.
Il modello gateway API
Un altro modello interessante è suggerito da Chris Richardson che ha anche proposto quello che ha chiamato un modello gateway API .
In un'architettura monolitica, i client dell'applicazione, come i browser Web e le applicazioni native, inviano richieste HTTP tramite un bilanciamento del carico a una delle N istanze identiche dell'applicazione. Ma in un'architettura a microservizi, il monolito è stato sostituito da una raccolta di servizi. Di conseguenza, una domanda chiave a cui dobbiamo rispondere è con cosa interagiscono i clienti?
Un client applicativo, come un'applicazione mobile nativa, potrebbe fare richieste HTTP RESTful ai singoli servizi [...] In superficie questo potrebbe sembrare attraente. Tuttavia, è probabile che vi sia una significativa discrepanza nella granularità tra le API dei singoli servizi e i dati richiesti dai clienti. Ad esempio, la visualizzazione di una pagina Web potrebbe potenzialmente richiedere chiamate a un gran numero di servizi. Amazon.com, ad esempio,
descrive come alcune pagine richiedono chiamate a oltre 100 servizi. Fare molte richieste, anche attraverso una connessione Internet ad alta velocità, per non parlare di una rete mobile a larghezza di banda inferiore e latenza più elevata, sarebbe molto inefficiente e si tradurrebbe in un'esperienza utente scadente.
Un approccio molto migliore è che i client facciano un piccolo numero di richieste per pagina, forse solo una, su Internet a un server front-end noto come gateway API.
Il gateway API si trova tra i client dell'applicazione e i microservizi. Fornisce API su misura per il client. Il gateway API fornisce un'API a grana grossa ai client mobili e un'API a grana più fine ai client desktop che utilizzano una rete ad alte prestazioni. In questo esempio, i client desktop effettuano più richieste per recuperare informazioni su un prodotto, mentre un client mobile effettua una singola richiesta.
Il gateway API gestisce le richieste in arrivo inviando richieste a un numero di microservizi sulla LAN ad alte prestazioni. Netflix, ad esempio,
descrive in che
modo ogni richiesta viene inviata in media a sei servizi back-end. In questo esempio, le richieste a grana fine da un client desktop vengono semplicemente inoltrate al servizio corrispondente, mentre ogni richiesta a grana grossa da un client mobile viene gestita aggregando i risultati della chiamata a più servizi.
Il gateway API non solo ottimizza la comunicazione tra i client e l'applicazione, ma incapsula anche i dettagli dei microservizi. Ciò consente ai microservizi di evolversi senza influire sui client. Ad esempio, due microservizi potrebbero essere uniti. Un altro microservizio potrebbe essere suddiviso in due o più servizi. Solo il gateway API deve essere aggiornato per riflettere queste modifiche. I clienti non sono interessati.
Ora che abbiamo esaminato il modo in cui il gateway API media tra l'applicazione e i suoi client, vediamo ora come implementare la comunicazione tra microservizi.
Sembra abbastanza simile allo stile di orchestrazione di cui sopra, solo con un intento leggermente diverso, in questo caso, sembra essere tutto incentrato sulle prestazioni e sulla semplificazione delle interazioni.
.