I microservizi dovrebbero parlarsi?

Sto progettando un'applicazione utilizzando Micro-Services e non sono sicuro del miglior meccanismo da utilizzare per raccogliere dati da più servizi.

Credo che ci siano due opzioni:

• Integrare un meccanismo di comunicazione "interservizi" che consente ai servizi di parlare direttamente. Il gateway API chiamerebbe un singolo servizio, che quindi chiama altri servizi per raccogliere dati, prima di restituire la risposta consolidata al gateway API. L'API restituisce quindi la risposta al chiamante. (Dovrebbero essere chiamate sincrone quando la chiamata al servizio B richiede la risposta dal servizio A. IE Servizi di persona e indirizzo separati.)
• Chiedi al gateway API di chiamare direttamente ciascun servizio e di consolidare i dati all'interno dell'API prima di restituire la risposta.

Mi sto inclinando verso la seconda opzione, poiché avere i servizi che parlano tra loro introdurrebbe l'accoppiamento, nel qual caso potrei anche solo progettare un'applicazione monolitica. Tuttavia, ci sono alcuni gravi inconvenienti che posso pensare in cima alla mia testa con questa opzione:

• Avere l'API che esegue più chiamate a più servizi aumenta il carico sul server API, specialmente quando alcune di queste chiamate stanno bloccando.

• Questo metodo significherebbe che l'API deve essere "consapevole" di ciò che l'applicazione sta cercando di fare (IE Logic dovrebbe essere programmato nell'API per gestire a sua volta la chiamata dei servizi e quindi per consolidare i dati), piuttosto che solo fungere da stupido "endpoint" per i micro-servizi.

Mi piacerebbe sapere qual è l'approccio standard a questo problema e se c'è un'altra terza opzione che mi manca?

In genere sconsiglioi di far comunicare i microservizi l'uno con l'altro, il grosso problema è l'accoppiamento, significa che i servizi sono ora accoppiati tra loro, se uno di essi fallisce il secondo è ora completamente o parzialmente disfunzionale.

Vorrei fare una chiara distinzione tra operazioni di cambio di stato e operazioni di lettura ( Separazione query comando CQS ). Per le operazioni che cambiano stato userei una sorta di infrastruttura di messaggistica e andrei a fuoco e dimenticherei. Per le query utilizzeresti la comunicazione di risposta alla richiesta sincrona e potresti utilizzare un'API http o semplicemente andare direttamente al tuo archivio dati.

Se stai utilizzando la messaggistica, puoi anche guardare pubblicare l'abbonamento per raccogliere eventi tra i servizi.

Un altro punto da considerare è la condivisione (transazionale) dei dati (al contrario delle viste di sola lettura) se si espone il proprio stato interno, il lettore potrebbe ottenere lo stato errato dei dati o la versione errata e anche potenzialmente bloccare i dati?

Ultimo ma non meno importante, prova a fare tutto il possibile per mantenere autonomi i tuoi servizi (almeno a livello logico).

Spero che abbia senso.

Dipende dal motivo per cui hai bisogno di quei dati. Se è per l'interfaccia utente, va benissimo. Inoltre, è come dovrebbe essere. Chris Richardson ha una bella spiegazione di questo concetto e Sam Newman ha un ottimo articolo su un concetto molto simile chiamato Backends for Frontends .

Ma se ne hai bisogno per un po 'di logica, è probabile che i tuoi limiti di servizio siano sbagliati.

Ci sono diverse caratteristiche che il buon senso ci dice che i nostri servizi dovrebbero possedere . Loro sono:

1. Accoppiamento basso. Se si apportano alcune modifiche al servizio A, non si desidera che influiscano sul servizio B.
2. Alta coesione. Se è necessario implementare alcune funzionalità, si desidera influire sul minor numero possibile di servizi.
3. Alta autonomia. Se alcuni servizi falliscono, non si desidera che l'intero sistema sia inattivo.
4. Granularità corretta. Non vuoi che i tuoi servizi siano troppo chiacchieroni, poiché la tua rete è una cosa più complessa di quanto potresti pensare.
5. I servizi dovrebbero comunicare tramite eventi. Non vuoi che il tuo servizio sia consapevole l'uno dell'altro poiché riduce la manutenibilità. Pensa a cosa succede se devi aggiungere un nuovo servizio.
6. Dati decentralizzati. Un servizio non dovrebbe condividere il modo in cui le informazioni vengono archiviate. Proprio come un buon oggetto, espone comportamenti, non dati.
7. Servizio coreografico sull'orchestrazione.

Per raggiungere questo obiettivo, considera i tuoi limiti di servizio come capacità aziendali . Un processo formale di identificazione dei confini del servizio è simile al seguente:

1. Identificare i confini di livello superiore. Mi piace pensarli come passaggi che la tua organizzazione dovrebbe percorrere per raggiungere il suo obiettivo di business, per ottenere il suo valore di business. Puoi avere un'idea dei passaggi di base dando un'occhiata alla catena del valore di Porter .
2. All'interno di ogni servizio, approfondisci. Identificare le unità autonome del bambino con le proprie responsabilità.
3. Pensa al modo in cui comunicano. I servizi corretti comunicano principalmente tramite eventi. Pensa alla tua struttura organizzativa. La comunicazione al loro interno è piuttosto intensa, sebbene in genere vengano esposti alcuni eventi esterni.

Un esempio di applicazione di questo approccio potrebbe essere di qualche interesse.

Mi spingerei anche verso il secondo approccio per impostazione predefinita, anche se forse non nel tuo "gateway API", ma riterrei del tutto ragionevole creare un nuovo micro-servizio il cui unico scopo era orchestrare le richieste ad altri micro-servizi e rappresentare i dati in una forma di livello superiore. In un'architettura di micro-servizi, mi appoggerei a che i micro-servizi "di base" comunichino direttamente tra loro.

Per rendere questo un po 'meno soggettivo, diciamo che un servizio dipende da un altro se il primo richiede dati o servizi dal secondo, direttamente o indirettamente . In termini matematici, vogliamo che questa relazione sia un ordine parziale e non un preordine . In forma di diagramma, se hai tracciato il diagramma delle dipendenze dovresti ottenere un diagramma di Hassee non avere alcun ciclo (diretto). (In un diagramma di Hasse, i bordi sono diretti in modo implicito dal più basso al più alto.) Come ulteriore linea guida, si desidera che i percorsi dall'alto verso il basso siano generalmente più corti. Ciò significa che si desidera dipendere più direttamente dalle cose per impostazione predefinita. I motivi sono che ciò minimizza il numero di cose che possono andare storte per ogni particolare richiesta, minimizza le spese generali e riduce la complessità. Quindi, nel caso "ideale" di questa metrica, il diagramma di Hasse avrebbe solo due livelli. Naturalmente, ci sono molte ragioni per cui potresti voler introdurre servizi intermedi come cache, consolidamento, bilanciamento del carico, gestione degli errori.

Per approfondire la tua seconda preoccupazione di avere l'API Gateway "intelligente", un modello che sta guadagnando trazione ora con framework come Falcor e Relay / GraphQL è quello di fare richieste più specifiche su cosa fare in modo che "API Gateway" possa genericamente eseguire tali specifiche senza dover sapere cosa GetTimelinecomporta. Invece, otterrebbe una richiesta del tipo "richiedi queste informazioni utente al servizio utenti e ottieni questi post dal servizio postale" o qualsiasi altra cosa.

Sospetto che la tua necessità che i servizi si "chiamino" a vicenda indica che stai procedendo con un sistema che non è stato ben progettato, poiché questa necessità che i microservizi si "chiamino" a vicenda è una forma di accoppiamento che raramente appare quando i microservizi sono progettati in modo appropriato.

Sei in grado di spiegare di più sul problema che stai cercando di risolvere? In inglese semplice?