OK, per prima cosa diamo la mia visione di una tipica architettura microservice, dall'alto verso il basso:
- L'interfaccia utente utilizza i microservizi tramite un proxy. Il proxy funziona come un router e un aggregatore che espone l'API di alto livello ai tuoi microservizi
- Il livello proxy aggregherà i microservizi e li combinerà per soddisfare il compito di alto livello.
- Microservices. Adempiono compiti specifici molto piccoli, ad esempio gli utenti possono essere distribuiti in diversi microservizi, in genere con un archivio dati isolato.
- Bus eventi, coda di messaggi o qualcosa di simile, fornisce l'infrastruttura per il trasferimento di messaggi, coerenza, bilanciamento del carico e talvolta repliche di dati.
Puoi posizionare il bilanciamento del carico, eseguire il failover su ogni livello o sul livello che ti piace di più.
Penso che il reporting sia un dominio molto ampio. Devi prima tagliarlo in piccoli pezzi per decidere dove metterli ciascuno. Almeno, pensa al problema come a tre argomenti molto ampi.
- Rapporti in tempo reale, ovvero rapporti di dati in tempo reale, come elenco di ordini, dati di monitoraggio, stato. Richiede l'accesso ai dati in tempo reale.
- Rapporti aggregati o riepilogati nel tempo, ovvero i totali per i periodi passati. Può essere letto da dati di sola lettura replicati.
- Rapporti di data mining, ovvero rapporti che dovranno analizzare tutti i dati passati (archiviati?). Richiederanno un data warehouse, un lago dati, tu lo chiami. Richiedono di elaborare o pre-elaborare i dati e archiviarli in un data store speciale, solitamente mediante l'elaborazione incrementale nel tempo.
Ora, vedi che i rapporti dovranno correlare tutti i dati di diversi microservizi.
- Per i rapporti in tempo reale, è probabilmente necessario inserire contratti sui microservizi necessari.
- Per i report aggregati o riepilogativi nel tempo, è possibile accedere direttamente alle repliche di lettura esistenti dei microservizi necessari e gestire la modifica dello schema nel livello di reporting. Questo è se il periodo delle repliche di lettura corrisponde alle tue esigenze di segnalazione.
- Per il data mining, OLAP, è meglio ottenere un data scientist nel tuo team di reporting, perché dovrai affrontare problemi reali con i big data.
A seconda dell'importanza delle tue esigenze di reporting, dovrai distribuire parte nei microservizi, crearne di specializzati e sincronizzarti con la tua strategia di dati, ad esempio quanto saranno grandi le finestre di dati in tempo reale, quanto grandi saranno i tuoi dati storici la finestra sarà, e con quale frequenza verranno archiviati i dati.
Ora, la creazione del report e la generazione di un file PDF o Excel appartengono al livello di reporting. E io uso la parola layer di proposito. Le segnalazioni necessitano di microservizi per raccogliere dati (probabilmente consumando altri microservizi, accesso a repliche di sola lettura o dati archiviati), elaborazione di report, generazione di file e così via. Devono esporre interfacce di alto livello al livello proxy che devono essere utilizzate dall'interfaccia utente, come selezionare un report, riempire i parametri del report, recuperare un file.
risposta
- Crea un livello di segnalazione.
- Per la raccolta dei dati: consumare microservizi per report semplici in tempo reale, poiché l'aggregazione dei microservizi aumenterà di complessità e le prestazioni ne risentiranno. Creare una strategia per accedere direttamente alle repliche di sola lettura. Creare un data warehouse, un data lake e ottenere un data scientist se si hanno a che fare con i big data. Esplora i database del grafico come Graph Engine www.graphengine.io o Neo4j neo4j.com
- Per l'elaborazione dei rapporti: crea i microservizi necessari che consumano i dati dai microservizi di raccolta dei dati e utilizza il proprio archivio dati isolato per l'esito del rapporto.
- UI: crea i tuoi microservizi di alto livello sul livello proxy.
