Ecco un riassunto di ciò che hai detto dalla mia comprensione (per favore conferma):
- Hai N microservices, dove N ~ = 10 (potrebbe crescere). Chiamiamoli consumatori
- Ogni microservizio richiede richiede dati
- I dati richiesti sono memorizzati 1 database
- Ogni microservizio richiede questi dati in modo diverso
Per supportare questi requisiti, proponi che uno specifico microservizio gestisca i dati richiesti dai consumatori. Inoltre, questo nuovo produttore manterrà la logica aziendale necessaria per i consumatori.
Prima di rispondere alle 3 domande, ricorda che un microservizio può essere disaccoppiato così tanto da diventare un anti-microservizio. Ad esempio, creare una nuova applicazione con uno stack tecnologico specifico solo per mantenere il nome di un utente in cui un altro manterrà le informazioni personali non è l'ideale. Quindi, invece di vedere il tuo problema da un punto di vista tecnico, incorpora l'aspetto commerciale di esso.
-
Abbiamo una logica (business) aggiunta a tutti i microservizi del Caller che possono avere modifiche logiche minori e ottenere i dati dal microservice che mantiene i dati?
- Se la logica di business è specifica per i chiamanti, dovrebbe rimanere nei chiamanti e lasciare che l'operatore fornisca solo le informazioni nel database.
-
Creo più endpoint (con un contratto separato) da un singolo microservizio con logica centralizzata per il lavoratore e gestisco i dati?
- Se si desidera utilizzare un'architettura di microservizio, questi dati devono essere gestiti da un solo microservizio, l'operatore. Chiunque desideri che i dati (e possano modificarli) lo richiedano dal lavoratore. Gli endpoint multipli sarebbero i diversi contratti richiesti da altri servizi o possibili umani. cioè ottenere un elenco dei dati disponibili, eliminare alcuni dati, aggiornare i dati.
-
Avere un unico endpoint e unire più contratti di microservizi e con logica centralizzata per il lavoratore e conservare i dati?
- Dipende molto da ciò di cui i chiamanti hanno bisogno. Se per ogni nuovo chiamante, si riutilizza lo stesso endpoint dal worker e si aggiunge la nuova logica nel worker, è possibile interrompere la compatibilità tra gli altri chiamanti e il worker. Funziona se non è necessaria la logica per l'endpoint e invia esclusivamente informazioni e i chiamanti applicano la propria logica ai dati.
Tutto sommato, rivisita qual è esattamente la logica aziendale necessaria per chiamante. Se solo il lavoratore può applicare questa logica, quindi utilizzare diversi endpoint (contratti). Se la logica è inerente ai chiamanti, spostare la logica verso i chiamanti e mantenere l'endpoint il più semplice possibile. Di conseguenza, tale endpoint può essere riutilizzato fino a quando un nuovo chiamante ha bisogno di una nuova API dal worker.
REST vs Kafka
Per quanto riguarda la tua ultima domanda, considera questi:
- Kafka è una tecnologia che utilizza un modello di sottoscrizione editore
- REST è un'architettura che è possibile utilizzare per rappresentare i dati nel tempo
Direi di utilizzare il modello di sottoscrizione dell'editore solo se hai bisogno che la tua applicazione ti avvisi e / o ti venga notificato qualcosa. Nel tuo caso, se i tuoi chiamanti usano Kafka, in pratica staranno aspettando notifiche di aggiornamento sui dati dal lavoratore. Ciò significa anche che devono persistere i dati dalla loro parte. Se sia i chiamanti che i worker si trovano nello stesso sistema, questa è una complessità non necessaria (se si desidera solo leggere i dati da un database).