Comunicazione microservizi

Non c'è una risposta generale per questo. Quando si utilizzano i (micro) servizi, si crea un sistema distribuito . I sistemi distribuiti sono molto più complessi di un sistema monolitico proprio perché dobbiamo pensare a cose come fallimenti parziali e mantenimento della coerenza: è bello che abbiate individuato immediatamente questi problemi!

Pertanto, i microservizi non sono sempre una buona scelta, in particolare se non puoi facilmente risolvere i tuoi problemi senza di loro. Tendono a diventare attraenti quando si verificano altri problemi molto grossi (come requisiti organizzativi o scalabilità orizzontale per le prestazioni), in modo che i potenziali svantaggi dei microservizi risultino accettabili in confronto .

Esistono alcune strategie e raccomandazioni generali che possono essere d'aiuto, a seconda dei tuoi esatti requisiti:

• Ogni istanza del servizio dovrebbe essere stateless . Tutti i dati devono essere memorizzati esternamente al servizio. Questo ci permette di:

• Esegui più istanze di un servizio e bilanciamento del carico tra di loro. Ciò ci consente di eseguire il ridimensionamento orizzontale su una granularità per servizio e mantiene la disponibilità in caso di errore di una istanza.

• Definisci chiare transazioni . Un'operazione transazionale non ha effetto finché non è completa. Ciò garantisce che non vi siano operazioni parzialmente eseguite. Se una transazione viene interrotta, può essere ritentata. Poiché ogni istanza di servizio dovrebbe essere senza stato, di solito richiede il supporto di un DB, ma si noti che i DB NoSQL differiscono drasticamente in quali tipi di transazioni supportano.

• Non tutti i processi possono essere modellati come un'unica transazione, soprattutto quando devi interagire con servizi esterni. Qui, suddividere il processo in più passaggi transazionali e tenere traccia dello stato del processo può essere una soluzione.

• Considera se i processi devono essere sincroni (ogni richiesta riceve una risposta) o possono essere asincroni (eventi / lavori / messaggi vengono aggiunti a una coda e elaborato in seguito). Le operazioni asincrone consentono molta più flessibilità. Quindi, aggiungere il lavoro alla coda è un'operazione transazionale che promette che il lavoro verrà elaborato "presto", ad un certo punto nel futuro. Un lavoro viene rimosso dalla coda dopo che è stato elaborato correttamente. Ma l'elaborazione effettiva non fa parte della transazione. Ciò ti consente di riprovare il lavoro in background o di tenerlo attivo fino a quando non sarà nuovamente disponibile un altro servizio.

• Distingui tra errori all'interno del dominio problematico e errori del tuo sistema. I guasti del sistema sono probabilmente temporanei e possono essere risolti riprovando la stessa richiesta in un secondo momento. In HTTP, questa è approssimativamente la differenza tra 400 e 500 codici di risposta. Nelle applicazioni web a pagina singola, un "errore" comune è che il client non ha semplicemente una connessione di rete. Valuta se gli aggiornamenti possono essere accodati per dopo. Per verificare se il servizio è di nuovo disponibile, preferisci una strategia come il backoff esponenziale per evitare il DDOS da solo.

• Considera varie strategie di coerenza per l'aggiornamento contemporaneo dei dati. Un approccio semplice è l'ultimo vince. Tuttavia, questo potrebbe sovrascrivere un cambiamento che è accaduto nel frattempo.

  Un approccio più sofisticato è test-and-set / blocco ottimistico : un aggiornamento contiene sia i vecchi dati che i nuovi dati. I vecchi dati potrebbero semplicemente essere un ID o un hash invece dei dati completi. All'interno della protezione di una transazione, i nuovi dati vengono scritti solo se i dati precedenti rilevanti si trovano nello stato previsto, altrimenti viene restituito un errore. In SQL questo è semplice come un'istruzione UPDATE ... WHERE ... che verifica il vecchio stato. Un errore di solito richiede all'utente (umano) di riconciliare il nuovo stato con la modifica desiderata e inviare nuovamente la modifica.

  Il protocollo HTTP ha il supporto integrato per il blocco ottimistico tramite ETags + l'intestazione If-Match e potrebbe rispondere con uno stato 409 Conflict o 412 Precondition Failed se non è possibile applicare un POST o PUT.

  Avere una strategia chiara per garantire coerenza è importante se una richiesta viene ritentata che è già stata gestita. Per esempio. considera un servizio che ha elaborato correttamente una transazione ma si blocca prima che possa essere inviata la risposta positiva.

What if service B is not available? How should it reflect on the Front end?

Non sono sicuro di cosa intendi per "front end"? Questo servizio è A? In ogni caso, se il servizio A chiama il servizio B e il servizio B fallisce, ci sono due classi di casi. Se l'errore era 4xx, allora il servizio A dovrebbe fallire la richiesta (che lo ha attivato chiamando il servizio B) - probabilmente con un errore 5xx perché è probabile che ci sia un bug con il servizio A.

Se il servizio B ha restituito un errore 5xx (indicando un eventuale errore temporaneo) nell'esecuzione - in genere dovresti avere il servizio di chiamata A che gestisce (che attiva la chiamata al servizio B) non riesce con lo stesso errore 500 da upstream ( indicando se il problema è temporaneo o più permanente per il chiamante).

Se intendevi che il servizioA sia "il front-end", allora la domanda è risposta. Se intendi in generale come visualizzare su un interfaccia utente che stai ricevendo errori dai servizi di back-end, questo dipende dalla natura delle richieste di servizio (chiamate al servizio A dal frontend / gui) - ma di solito una sorta di finestra di dialogo che indica il fallimento è la scelta meno cattiva. Questo è davvero molto più complicato, ma siccome non sono sicuro che sia davvero quello che chiedi, salterò i dettagli lì.

What about the data being passed on? should I assume the it is already lost?

Se chiami qualsiasi servizio e ricevi un errore 4xx o 5xx, dovresti presumere che la tua richiesta non sia stata elaborata. Quindi la risposta breve è - sì - i tuoi dati sono persi.

La risposta leggermente più lunga, è che a volte è una buona scelta architettonica avere il primo 'servizio' che gestisce le richieste dalla GUI - per essere un qualche tipo di servizio di accodamento dei messaggi (ad esempio Apache Kafka), che può gestire i tentativi con i servizi di elaborazione upstream fallire.

What if service B is not available?

Per definizione, il micro servizio deve essere molto indipendente da altri micro servizi. Così indipendente che gli altri micro servizi non si preoccupano di cosa sta succedendo con un altro micro servizio. Ma, alla fine, può avere qualche dipendenza, ma questo non è lo scenario migliore per un micro servizio.

Detto questo, puoi avere due tipi di comunicazioni con un altro micro servizio: Asincrono e Sincrono .

La comunicazione sincrona tra servizi è denominata RPC ( Chiamata procedura remota ). Questo può essere fatto usando una semplice richiesta HTTP per un altro sistema o anche usando un sistema Queue (RabbitMQ, Kafka, ecc.). Come esempio RPC, il servizio A chiama il servizio B e attende la risposta B. Se B non risponde, il servizio A deve sapere cosa farà. Può:

• Ignora . Le informazioni da B non sono così importanti.
• riprova più tardi . Puoi ottenere le informazioni più tardi o mai più. Puoi informare l'utente se necessario e utilizzare una strategia per riprovare più tardi per ottenere le informazioni da B.
• Genera un errore . Il servizio A non può continuare senza le informazioni del servizio B.

Con la comunicazione Asincrona la tua applicazione sarà pronta a sopravvivere senza quelle informazioni dal servizio B e senza sapere cosa sta succedendo con B. Il concetto di comunicazione usa eventi , dove ciascuno il servizio sta ascoltando gli eventi di altri micro servizi che ha interesse e reagisce quando arriva un messaggio (salvando le informazioni nel proprio database, inviando una e-mail, registrando l'evento, ecc.).

Questo modo più popolare per implementare questo evento sui micro servizi è l'utilizzo di alcuni sistemi di messaggistica, come RabbitMQ o Kafka. Queste applicazioni utilizzano il concetto e i messaggi Queue, in cui il servizio può connettersi a queste code e leggere i messaggi dalla coda.

How should it reflect on the Front end? Is the best solution be just prompt a error that the service is unavailable?

Dipende. Se l'informazione è vitale per A, è necessario. Ma forse il tuo servizio può continuare senza le informazioni da B, ma devi avere un percorso sul tuo servizio per cercare di ottenere di nuovo quell'informazione.

What about the data being passed on? should I assume the it is already lost?

I dati non possono essere semplicemente "persi". Se stai utilizzando la comunicazione RPC, puoi riprovare più tardi per inviare le informazioni da B. Ci si aspetta che tu possa riprodurre la stessa richiesta e riprovare più tardi.

Usando la comunicazione Asincrona , le informazioni saranno nelle code in attesa che alcuni servizi le consumino.

TL; DR: Si tratta principalmente di una decisione aziendale. Soddisfare una richiesta digitale è come adempiere ad una telefonata: tutto accade più velocemente. Ti suggerisco di iniziare seguendo le tue regole sul servizio clienti o di lavoro di persona o sul telefono. Ottimizza dove possibile.

Aggiorna la domanda in termini di un dipendente al telefono con un cliente presso un'azienda "solo carta" . Verso la fine della chiamata, il cliente ha dato al dipendente tutto ciò di cui ha bisogno per soddisfare un ordine:

Hey, I need 100 Widgets. My account number is 1234. Ship to the address on file. Use the card on file. It's been authorized by Bill Murray, whose PIN is 5678. And no, I would not like to opt into marketing emails ...

... e ora, il dipendente deve rispondere in modo definitivo alla richiesta. Devono eseguire alcuni passaggi di convalida e documenti di adempimento. Forse l'azienda vuole che:

1. Gestione account chiamate / Esegui nella sala file ...
   1. Recupera il file
   2. Verifica il numero di conto
   3. Verifica che l'account abbia un indirizzo di spedizione
   4. Verifica che l'account contenga informazioni di fatturazione
   5. Verifica il PIN di Bill Murray
2. Chiama la compagnia di spedizioni
   1. Verifica l'indirizzo
3. Chiama il magazzino
   1. Verifica che siano disponibili almeno 100 widget
   2. Metti in attesa 100 widget
4. Prepara un record di ordine formale
   1. Chiama la banca e verifica i fondi / Inizia una transazione
   2. Aggiungi il numero di transazione ai documenti
5. Vai alla stanza della posta
   1. Copia i documenti
   2. Stampa un'etichetta di spedizione
   3. Inserisci la busta con l'etichetta di spedizione
   4. Invia al magazzino
6. Informa il cliente che l'ordine è in

O qualcosa del genere. Ma uhh ...

• Cosa succede se la porta dell'armadio è inceppata?
• Cosa succede se qualcun altro non ha mai restituito il file?
• Cosa succede se la società di spedizioni non è disponibile per verificare l'indirizzo?
• Cosa succede se la linea di magazzino è occupata?
• Cosa succede se la fotocopiatrice è in uso?
• Cosa succede se il dispositivo di spedizione è rotto?
• Il cliente attende al telefono mentre fai tutto questo ?? !!
• COSA SE IL FABBRICATO RAGGIUNGE IL FUOCO !! ?? !! ??

...

Quindi, forse il tuo gruppo dirigente decide che alcune di queste cose sono opzionali, a seconda dello stato dell'account. Forse alcune cose valgono ripetuti tentativi (va bene solo attendere per la fotocopiatrice o ricomporre il magazzino dopo 30 secondi? ). O forse alcuni di loro in definitiva non aggiungono alcun valore ( verifica l'indirizzo?! ). Oppure, decidi che alcuni di questi possono essere eseguiti dopo la chiamata - e puoi richiamare il cliente in caso di problemi (invio al magazzino?). ... E, forse alcuni di loro sono solo degli show-stop.

Ad esempio, se l'edificio prende fuoco, è probabilmente opportuno dire al cliente di richiamare più tardi. E, forse, non hai una buona soluzione per gli ordini di riempimento, quindi, se non puoi confermare e conservare l'inventario, il cliente deve riprovare tra N giorni.

Ora, date le cose che voi e i vostri uomini d'affari avete deciso su come questa telefonata dovrebbe procedere quando sorgono vari problemi e incertezze, iniziare semplicemente ridimensionando le regole verso il basso da 1 a 3 i minuti che si aspettano di aspettare al telefono per 1 o 3 secondi attenderanno il caricamento di una pagina.

Quindi, aumenta o abbassa il livello del servizio digitale in base alla velocità e all'affidabilità relative delle tue dipendenze digitali rispetto alle controparti non digitali.

Potresti scoprire che le interruzioni del servizio a livello di carico sono così rare che ... non hai nemmeno bisogno di un piano robusto. Basta dire al cliente di "richiamare" ogni volta che qualcosa va storto. Dipende da te e / o dalla tua guida.

Sono solo regole aziendali, informate da limitazioni tecniche. Limiti tecnici che, onestamente, spesso rispecchiano abbastanza bene le interazioni umane - solo molto più velocemente.