In che modo Polyglot Persistence gestisce i dati relazionali?

"Persistenza Polyglot" è solo un nome di fantasia per "archivi di dati eterogenei" (che suppongo sia anche un nome di fantasia). Puoi risolvere il problema in diversi modi:

1. Avere "Una tabella per domarli tutti": una specifica chiave primaria in un database specifico è l'identificatore principale per una particolare entità,

2. Avere tabelle di mappatura che mappano le chiavi di un archivio dati sulle chiavi di un altro,

3. Utilizza chiavi globalmente univoche, come GUID.

(...) microservices working with their own databases

Come sempre con le decisioni di architettura, c'è un compromesso tra i vari obiettivi. Uno degli obiettivi chiave dei microservizi consiste nell'avere componenti dispiegabili in modo indipendente. Ad un estremo, questo significa separare non solo le basi del codice, ma anche la rispettiva persistenza dei dati.

Sebbene sia fattibile in alcuni scenari, contesterò questo approccio se i microservizi appartengono allo stesso sistema di back-end. In tal caso sembra perfettamente valido che diversi microservizi condividano i loro dati nello stesso database, purché abbiano ambiti e responsabilità ben definiti - e comunque raggiungano l'obiettivo della deployabilità indipendente.

I would assume an Order would need a way to reference a given Customer in its storage model, which I believe a relational database handles well, but if these microservices truly have independent databases, how is this handled?

Ogni microservizio deve offrire un modo per l'identità dell'oggetto correlato: alcune chiavi di riferimento, ad es. come un campo external_ref . La chiave di riferimento dovrebbe essere indipendente dal modello attuale o dalla chiave primaria del database dei microservizi (estranei) in modo da mantenere i servizi disaccoppiati da modifiche interne, migrazioni dei dati, ecc. In genere, le chiavi utilizzate sono scrive le chiavi o chiavi naturali / commerciali .

Esempio

Ordina il servizio di microservizi a un oggetto Cliente

• la risorsa /order/<key> conterrà un customer_ref , ad es. della forma <foreign service>:<foreign key> , in particolare customer:123456

• la risorsa /customer/<key> può contenere una raccolta di ordini di cui è a conoscenza, ad esempio come relazione customerdb.Orders (customer_id, order_ref), dove order_ref ha la stessa forma di cui sopra, order:abc3566 ( Sto usando abc3566 per indicare che gli schemi chiave non devono essere uguali).

Utilizzando questo approccio, un mediatore di servizi nella tua architettura può risolvere tali _ref in una chiamata di servizio effettiva e restituire il rispettivo oggetto straniero. Tieni presente che sto assumendo chiaramente un set di microservizi in stile REST, ma il principio si applica a qualsiasi altro tipo di servizio.

Pubblicazioni

In genere ci sono diversi problemi che ne derivano:

• Come unire i dati in modo efficiente?

  In un modello relazionale, i join vengono eseguiti dal database e quindi sono relativamente efficienti. Per ottenere lo stesso risultato, è necessario suddividere il risultato di entrambi i servizi in un sottoinsieme minimo e unire il lato client dei dati. Le strategie tipiche prevedono anche il caching per evitare di interrogare gli stessi dati (potenzialmente piuttosto statici) più e più volte.

• Come mantenere un set di dati di microservizi esenti da ridondanze?

  In sostanza, si applica lo stesso concetto di qualsiasi progetto di database relazionale. Tuttavia, a causa delle strategie di memorizzazione nella cache, a volte vengono introdotte ridondanze di dati che devono essere gestite. Un approccio è quello di introdurre webhook (cioè callback) in modo che un servizio possa notificare un servizio dipendente delle modifiche.

• Come limitare l'impatto di tale architettura sulla complessità? (in particolare gestione delle dipendenze, implementazione, test)

  Come sempre con qualsiasi decisione di architettura, ci sono dei compromessi nei microservizi. Spetta all'architetto (s) valutare il pro & contro di tale approccio. Nel corso del tempo, troveremo astrazioni e strutture che trattano le complessità più comuni in un modo che essenzialmente rimuoverà gli aspetti negativi mantenendo i vantaggi.

Se stai progettando i servizi per essere veramente indipendenti, allora dovranno servire a funzioni di identità ... modi per identificare in modo univoco le entità, in modo che possano essere riferite esternamente. Dopotutto, il servizio è il limite e non è previsto che lo veda attraverso il negozio sottostante. Quella identità non dovrebbe davvero cambiare di fronte alla mutazione delle entità, quindi non dovrebbe essere composta da dati mutabili, come il nome di un cliente o il nome di un dipendente.

Una particolare applicazione che utilizza l'identità può mapparla o può usarla come fornita. Ogni applicazione sviluppata sarebbe libera di mappare o utilizzare l'identità in modo coerente con il suo scopo. Non c'è motivo di assumere una sorta di mappatura globalizzata / centralizzata. Se una mappatura centralizzata sembra giusta, allora un archivio centralizzato e relazionale per tutti i microservizi deve sentirsi ancora più giusto.

Diventa complicato se i servizi devono supportare garanzie ... come "Non distruggerò questa entità finché non la rilasci" - che potrebbe essere una promessa lunga o breve. Questo è un po 'come esternare dichiarativamente l'idea di una chiave straniera. Le applicazioni dovrebbero essere in grado di rilasciare la protezione sulle entità quando tutti i riferimenti vengono rimossi; e questo può complicarsi.

Ad esempio, immagina il servizio s che serve l'entità e e l'applicazione a vuole fare riferimento a e e vuole una garanzia che e non perirà, quindi a ha bisogno di un modo unico per fare riferimento alla protezione contestuale di e . In questo modo, a può informare s quando e non è più necessario. Il conteggio dei riferimenti (in s o in a ) non è sufficiente.

Forse, s può semplicemente deprecare e e non distruggerlo, forse contrassegnarlo come cancellato logicamente. Ciò ovvia alla complessità di esternalizzare la relazione con le chiavi esterne, ma rende i dati disponibili più a lungo di quanto potrebbe altrimenti.

Un'altra strategia a potrebbe impiegare è semplicemente superare il fatto che un'entità referenziata non è più lì. Neanche questo è così semplice.

In breve: le applicazioni che fanno affidamento su una molteplicità di microservizi hanno il loro lavoro da ritagliare per loro - i servizi possono o no giocare bene in un tale ambiente. Ci si chiede se la gioia di scegliere il proprio data store quando costruisce un servizio sia superata dalla complessità visitata dai consumatori del servizio. Le strategie scelte saranno dettate dalla capacità di adattare il comportamento del servizio alle esigenze delle applicazioni. Se parliamo di microservizi da "là fuori", allora le applicazioni dovranno essere molto più robuste e potrebbero persino decidere di replicare parti sostanziali dei dati forniti dal servizio.