Microservice domanda di JOIN

"molti di noi stanno semplicemente scrivendo i nostri programmi in modalità microservizio". Presta attenzione a questa affermazione, perché il "modo microservizio" non è assolutamente univoco e direi che molte volte è sbagliato. La ragione di ciò è che molti sviluppatori creano microservizi basati su entità: Utente, Blog, Commento, Categoria, Pagamento, ecc. Questo tipo di design crea una rete di relazioni in cui tutti i servizi hanno dipendenze su tutti gli altri servizi e i requisiti per creare query vengono visualizzati i join relativi ai dati di più servizi.

Quindi, direi, la prima cosa che dovresti fare è accettare che i limiti del tuo servizio siano errati. Un servizio dovrebbe essere in grado di raggiungere i propri obiettivi di business senza richiedere dati da altri servizi. Ho la strong sensazione che questa sia la tua situazione. Ciò significa che dovresti riuscire a eseguire una query in un singolo servizio e restituire un elenco di ID risultato. Quindi utilizzare questi ID per interrogare un altro o più servizi per creare le informazioni complete che devono essere restituite all'utente (ad esempio, il nome utente, la reputazione dell'utente e il testo del post del blog risulteranno probabilmente in 3 diversi servizi) .

Ora, se sei sicuro al 100% che i limiti del servizio siano corretti e trovi ancora situazioni in cui devi eseguire query su più servizi, hai un paio di opzioni:

1. Creazione di un motore di ricerca: potrebbe essere possibile eseguire diverse ricerche in parallelo a più servizi e combinare i risultati oppure eseguire una ricerca in un servizio e quindi chiamare altri servizi per filtrare i risultati del precedente.
2. Utilizza un servizio di ricerca: questo servizio aggrega i dati di più servizi e li indicizza in modo da consentire ricerche efficienti. Ciò è utile se si desidera eseguire query complesse come la ricerca full text su tutti i blog e i commenti, le ricerche basate su più categorie o tag, utenti, ecc. Questi servizi normalmente ordinano i risultati in base alla percentuale della corrispondenza. Se le ricerche sono complesse, è meglio utilizzare un servizio di terze parti e non provare a crearne di propri.

Riguardo la tua ultima domanda "O dovrei accettare l'inefficienza se vado sul percorso dei microservizi?" Direi che un'applicazione di microservizi correttamente progettata non dovrebbe essere più inefficiente di un monolite, considerando "efficienza" non solo la velocità di una singola query, ma una proprietà dell'intera applicazione (prestazioni, stabilità, manutenibilità, ecc.). Se il tuo design del microservice non è migliore del tuo design monolitico, scegli sicuramente il monolite.

Se hai bisogno di un join sui dati di due microservizi, il tuo progetto Microservices non è semplicemente corretto. I dati che logicamente funzionano insieme nel tuo sistema appartengono allo stesso Microservice.

Un'altra alternativa consiste nel duplicare i dati del microservice utente in altri microservizi secondo necessità utilizzando gli eventi E.g. relazioni in post (ma non in indirizzi) e indirizzi in fatturazione (ma non in relazioni). Nota che in questo modo puoi finire con una grande palla di fango distribuita (tm) abbastanza veloce.

Se il tuo servizio blog accetta una lista di userIds come input, cioè

select posts where userid in (1,2,3,4)

quindi non ci sono particolari inefficienze.