Ho due microservizi A e B .
Voglio trovare l'elenco di tutti gli non configurati utente per pagina ( Set (B) -Set (A) ).
Come devo fare una ricerca se i dati Utente sono troppo grandi in B Microservice?
Puoi precalcolare il tuo aggregato prima di eseguire una query emettendo eventi o utilizzando il record attivo. Crea aggragate di facile lettura , anche se devi prendersi cura degli aggiornamenti delle entità di base. Questa è una soluzione conveniente.
Tuttavia, nel tuo caso sembra che devi fare un passo indietro e ripensare il tuo design. Potrebbe essere un caso che i tuoi microservizi o tabelle siano suddivisi in modo subottimale.
Non c'è un buon modo per farlo. Poiché i tuoi dati sono suddivisi su più microservizi, devi unire manualmente questi dati. Quindi ci deve essere una parte di codice come:
def find_unconfigured_users():
for user in B.all_users():
if A.has_configured_user(user):
yield user
Questo sarà noioso e lento, ma poiché stai usando i microservizi non hai una scelta ragionevole. (La scelta irragionevole sarebbe quella di accedere direttamente ai dati di B, senza passare attraverso l'interfaccia del microservizio.)
Dove questa funzionalità dovrebbe vivere dipende ... probabilmente, questo dovrebbe essere parte della stessa Microservice A, cioè parte del servizio che si occupa degli utenti configurati.
Quando i dati vengono suddivisi in questo modo su più microservizi, questo potrebbe essere un male necessario o potrebbe essere un'indicazione di un problema più profondo. Domain-Driven Design ha il concetto di un contesto limitato - una parte autonoma del dominio del problema che il tuo sistema software sta tentando di risolvere. Un contesto limitato non dovrebbe essere suddiviso su più microservizi!
Si potrebbe voler controllare quale contesto limitato a cui gli aspetti di un utente appartengono. Perché è necessario gestire utenti configurati e non configurati e perché è distinto dagli utenti in generale? È legittimo se diversi contesti limitati hanno concetti diversi ma correlati di un "Utente", ma devi essere chiaro in che modo si relazionano. Qui, sembra che un'entità Utente sia effettivamente condivisa in diversi contesti, e quindi causando problemi. Forse, la soluzione potrebbe essere quella di includere la configurazione di un utente nel contesto utente principale (B).
"Lo schema è corretto" non è necessariamente un motivo buono per evitare di farlo, ma forse non può essere influenzato da te. Nessuna soluzione tecnologica sarà in grado di risolvere le disfunzioni organizzative, in particolare i microservizi. Dovrai quindi tornare a controllare noiosamente ogni utente, come nel frammento di codice sopra.
È ok (e desiderabile) avere proprietà di un'entità, come Utente, memorizzata in diversi microservizi. Non è necessario il microservizio A per memorizzare tutte le proprietà dell'utente nel microservizio B (Nome, Telefono, e-mail, ecc.) Se A interessa solo IsConfiguredByAgent e altre cose.
Il problema nella progettazione è che non dovresti dover interrogare il Servizio B dal Servizio A per conoscere gli utenti che non sono configurati da un agente. Per fare ciò, è necessario il set completo di utenti anche nel Servizio A. Pertanto, sia il Servizio A che il Servizio B hanno l'elenco completo degli Id Utente, ma memorizzano proprietà diverse rispetto a questi.
È necessario un solo servizio per consentire la creazione e la rimozione degli utenti. Quindi questo servizio può pubblicare un UserCreatedEvent o UserRemovedEvent che trasporta l'UserId e altri servizi possono ascoltare questi eventi per aggiornare il proprio elenco interno di utenti.
Leggi altre domande sui tag database microservices algorithms business-logic database-design