Come gestite i concetti condivisi in un'architettura di microservizi?

Sto cercando modelli architettonici per un'applicazione che sto sviluppando e un approccio al microservizio sembra che sarebbe una buona scelta ma non sono sicuro di come gestire le interazioni tra i servizi.

L'applicazione si occupa principalmente di utenti, profili di proprietà di utenti, foto e tag che rappresentano uno o più profili in una foto. Ci sarebbero presumibilmente metodi per restituire foto caricate da un utente, restituire foto che contengono un determinato profilo con tag, ecc.

Questo è il mio primo tentativo di progettare un'architettura basata su microservizi e vengo da una storia ispirata a un modello di dominio monolitico . In quel mondo, i controller avrebbero ricucito questi oggetti di dominio ma ho problemi a capire come funzionerebbe in modo microservizio.

— anjunatl
fonte

Di solito, i servizi chiamano altri servizi quando devono accedere ai propri dati. Ogni pezzo di dati dovrebbe appartenere a un particolare servizio che sarà l'unico punto di accesso per accedere a questi dati e modificarli. Alcuni servizi saranno semplici e di solito corrispondono strettamente al tuo modello di dominio (ad es. Un servizio per la gestione degli utenti) mentre altri saranno di alto livello e utilizzeranno i dati di altri servizi (ad es. La visualizzazione di un elenco di foto insieme alle informazioni sugli utenti che le hanno caricate ).

Nel tuo caso d'uso, dovresti iniziare dall'esterno e pensare a quali operazioni vuoi rendere disponibili al tuo utente tramite un'API (se si tratta di un servizio back-end) o quali operazioni dovrebbero essere disponibili nella GUI se si tratta di un'applicazione web. Si noti che la parte GUI è spesso un'applicazione normale con i propri controller: le operazioni possono essere chiamate tramite REST (come in AngularJS), ma questi endpoint sono progettati solo per l'uso dell'applicazione GUI e non sono microservizi nel senso comune.

Supponiamo di voler visualizzare le foto insieme alle informazioni sui caricatori. È possibile disporre di un servizio utente che restituisce informazioni su un utente in base all'ID utente e un servizio fotografico in grado di elencare le foto (ad es. Cercando secondo alcuni criteri). L'elenco delle foto conterrebbe per ogni foto l'ID dell'utente che carica. In questo modo questi due servizi non sono accoppiati: il servizio fotografico conosce solo gli ID utente ma nulla sui dati dell'utente stesso. Oltre a questi due servizi, è possibile creare un terzo servizio con un'operazione come "elenca le foto con informazioni sugli uploader" che chiamerebbe gli altri due servizi e combinerebbe i dati restituiti. In alternativa, questa operazione potrebbe essere eseguita dall'applicazione Web anziché da un servizio.

— Michał Kosmulski
fonte

Questo mi ha aiutato moltissimo. Ho iniziato scrivendo un paio di casi d'uso dell'interfaccia utente che avrebbero esercitato lo stack e tutto è andato per il verso giusto.

— Anjunatl

In questo esempio particolare, dovremmo fare ad es. 10 chiamate al servizio utenti per ottenere i dati dell'utente se abbiamo 10 foto nella nostra lista? Non aggiungerebbe un sacco di spese generali?

— Ricardo Souza,

@rcdmk È possibile aggiungere un endpoint REST che ottiene un elenco di più ID come input e restituisce più foto come output. Questo viene spesso fatto in pratica per motivi di prestazioni. A volte, il design delle API è un compromesso tra purezza e considerazioni pratiche.

— Michał Kosmulski,

@ MichałKosmulski Ho bisogno di iniziare la discussione, ma il design StackExchange li scoraggia :) Quello che non mi piace dell'approccio microservizio in questo esempio particolare è che la query diretta al database sottostante (dove sono memorizzati utenti e immagini) potrebbe essere molto più efficiente. Immagina se questi servizi a monte dipendono da altri servizi a monte e così via. La query diretta nell'archivio dati è molto più sicura. solo i miei 5 centesimi - niente di più. Ancora una volta mi piacerebbe avere una discussione produttiva sull'argomento, ma StackExachange non è un buon posto per quello (puoi consigliare i forum di discussione sui microservizi?)

— Ajukraine,

@ajukraine Penso che ci siano chat su stackexchange che potrebbero essere un buon posto per le discussioni. Per quanto riguarda le prestazioni: 1. I microservizi comportano un costo per le prestazioni e 2. I microservizi vanno bene per alcune situazioni ma non per altre. Per quanto riguarda le dipendenze: nelle archotectures dei microservizi si effettuano spesso copie locali di dati e si utilizza la messaggistica asincrona per ridurre il numero di dipendenze. È un vero cambiamento di architettura, non solo la modifica automatica di ciascun modulo di un'applicazione in un'applicazione separata.

— Michał Kosmulski,

L'applicazione si occupa principalmente di utenti, profili di proprietà di utenti, foto e tag che rappresentano uno o più profili in una foto. Ci sarebbero presumibilmente metodi per restituire foto caricate da un utente, restituire foto che contengono un determinato profilo con tag, ecc.

Bene, il servizio profili non dovrebbe funzionare con l'oggetto utente. Potrebbe conoscere solo l'ID dell'utente per il quale viene richiesto di restituire i dati, non di più. In questo modo non sarà necessaria l'interazione tra il servizio utente e il servizio profili.

Se ciò non risponde alla tua domanda, potresti chiarirla descrivendo la situazione esatta con cui hai a che fare?

— Vladislav Rastrusny
fonte

Questa e la risposta di Michal mi hanno aiutato a capirlo ma il suo suggerimento mi ha aiutato a mappare i servizi di cui avevo bisogno. Ero bloccato nella mentalità della necessità di rappresentare un oggetto completo anziché solo un riferimento all'oggetto (oggetto utente vs ID utente). Molto apprezzato, grazie!

— anjunatl

@anjunatl Welcome;)

— Vladislav Rastrusny il