Devo duplicare il modello e il database dei dati master tra i servizi in microservice

Naviga le tue risposte
-1

Siamo una startup fintech che sta tentando di ricostruire monolith php su microservice. Come tipica app Web, usiamo per gestire i dati master nella pagina di amministrazione. Come faccio a distribuire questi dati anagrafici tramite microservice? Costruiamo un servizio di gestione di due API. Uno per il punto di ingresso dell'utente frontend altro per il punto di ingresso dell'utente di amministrazione / backend. Creiamo un servizio di prestito per l'utente front-end e un servizio di amministrazione per l'utente di back-end. Il servizio di prestito utilizzerà i dati di prestito, città, paese che sono anche gestibili dal servizio di amministrazione. Dovremmo duplicare il modello e il database di promo prestito, città e paese dal servizio di amministrazione al servizio di prestito? O dovremmo mettere quei dati anagrafici nel servizio di prestito? Leggo anche del modello di saga che forse possiamo usarlo. Dopo ogni aggiornamento dal servizio di amministrazione si attiverà l'aggiornamento sul servizio loam.

Stiamo ancora progettando e immaginando come implementarlo al meglio. Qualsiasi consiglio o contributo apprezzo molto.

    
posta Tania Rida 12.01.2018 - 13:55
fonte

2 risposte

2

La risposta breve è "No", non dovresti semplicemente duplicare i dati. La cosa giusta da fare dipenderà da come hai progettato la tua architettura di microservice. Ad esempio, se si stesse utilizzando Progettazione guidata da domini, si avrebbe un Contesto Limitato per ciascun servizio che definisce il Modello di Dominio come richiesto da quel servizio. I dati modificati da altri servizi rilevanti per questo servizio possono essere utilizzati sottoscrivendo gli eventi pertinenti pubblicati dai servizi che modificano i dati. Questo articolo riguardante i contesti limitati in Microservices può essere utile a te.

    
risposta data 12.01.2018 - 14:37
fonte
2

Se esegui i microservizi, dovresti identificare il microservizio autoritativo per ogni tipo e / o sottoinsiemi dei dati che hai ora nel monolite. I microservizi non si limitano a prendere in giro la logica di business, ma la proprietà, l'autorità di apportare modifiche e l'accesso all'authority & dati aggiornati pure.

Se si replicano tutti i dati tra più microservizi a ciascuno dei quali è consentito aggiornare in modo ampio i dati, non si tratta di microservizi, è la replica dei dati, che ha le proprie sfide.

Nel calcolo distribuito, è ok avere copie di dati su un nodo che non è autorevole per questo, in parte perché qualsiasi query a un computer remoto restituisce una copia potenzialmente obsoleta non appena viene ricevuta. L'architettura distribuita - come con client-server, microservizi e altri che coinvolgono più server - deve fare i conti con questa potenziale stoltezza.

Le tecniche che possono essere utili sono:

  • timestamp (o numeri di versione) associati ai dati richiesti
  • API che offrono interazioni solide, ad esempio:
    • tutti o non aggiornamenti che aggiornano più cose o nessuno all'interno di una singola fonte
    • aggiornamenti condizionali che annullano se versioni o timestamp o altre aspettative non corrispondono
    • ha organizzato con cura la coerenza finale
    • transazioni distribuite come in 2PC
  • notifiche / eventi tempestivi
risposta data 12.01.2018 - 17:30
fonte

Leggi altre domande sui tag

Devo gettare ArgumentNullException e dovrei testarlo? [duplicare] Riconciliazione dell'interfaccia Principio di segregazione con la necessità di identificare univocamente un oggetto