Progettazione di microservizi multi-tenant

Stiamo migrando un'applicazione monolitica nell'architettura dei microservizi. A causa di alcuni requisiti normativi, dobbiamo conservare i dati dei clienti di diversi paesi in database separati (specifici per paese). Cioè db US per clienti statunitensi, db UK per clienti britannici ...

I seguenti progetti che stiamo prendendo in considerazione sono i seguenti:

Opzione 1: un'applicazione multi-tenant con supporto multi-tenant ibernato che può essere ridimensionato su N numero di volte in base alla domanda (si pensi ai pod di kubernetes). Una singola istanza di questa applicazione sarà in grado di connettersi a tutti i database.

Opzione 2: distribuire 1 istanza di microservizio per database di paesi. Con un gateway API di fronte a loro instradare il traffico

Se dovessi progettare questo tipo di sistema, quali sarebbero le tue scelte?

microservices

— Ciao mondo
fonte

Penso che dipenderà da quali sono i tuoi requisiti funzionali e non funzionali specifici.

— Robert Harvey,

Database diversi ma la stessa istanza lo sta leggendo? Ciò non viola anche i requisiti normativi?

— Jimmy T.,

L'opzione 1 non sembra troppo allineata con lo stile dell'architettura Microservices.

— Laiv

Citi Kebernetes ma non è chiaro se stai usando i container o meno. Se lo stai facendo con Docker (ad esempio), creeresti semplicemente un'app che si connette a un database. Quindi quando si avvia il contenitore e si specificano i dettagli della connessione tramite parametri e / o configurazione. Avere un'applicazione che si connette a molti database simili crea solo potenziali problemi. Non aggiunge nulla di buono al design.

— JimmyJames,

Risposte:

Penso che l'opzione 2 non sia male, ma potrebbe non essere necessaria. I micro servizi servono a farti gestire le esigenze di più applicazioni.

Un grande fattore qui è se c'è qualche differenza tra i due schemi e se mai ci sarà in futuro.

Di solito, penso che l'uso delle interfacce per i repository non sia necessario; tuttavia, potrebbe valere la pena in questo caso. Le fabbriche di depositi saranno importanti per te.

Il mio problema con l'opzione 1 è che è troppo specifico. Dovresti essere in grado di passare dall'installazione che hai descritto a due istanze separate, ciascuna delle quali punta facilmente al proprio DB. L'applicazione NON CURA DA DOVE OTTIENE I SUOI DATI.

Sebbene lo schema non differisca per i tuoi due diversi database, puoi avere un repository in grado di gestire facilmente entrambi, senza che l'applicazione sappia la differenza:

public class MyEntityRepository : ISavesMyEntity, IGetsMyEntity
{
    public MyEntityRepository(string connectionString)
    {
       _connectionString = connectionString;
    }
}

public class MyEntitySaverFactory
{
    public ISavesMyEntity GetSaver(User user)
    {
        if (user.IsUK)
            return new MyEntityRepository(Config.Get("UKConnString"));
        if (user.IsUS)
            return new MyEntityRepository(Config.Get("USConnString"));
        throw new NotImplementedException();
    }
}

//USE
ISavesMyEntity saver = factory.GetSaver(currentUser);
saver.Save(myEntityInstance);

Se gli schemi DB diventassero sempre disparati tra Stati Uniti e Regno Unito, si dividerebbe quindi la funzionalità in due repository completamente diversi. Questo sarebbe facile, dal momento che tutto ciò che dovresti fare è cambiare la tua fabbrica.

— TheCatWhisperer
fonte

Non capisco perché hai bisogno di questa fabbrica. Perché non passare il percorso ai dettagli di configurazione all'avvio? Con questo è necessario modificare il codice ogni volta che si desidera aggiungere una nuova regione / nazione.

— JimmyJames,

Il problema qui non riguarda gli utenti in paesi separati ... si tratta di database diversi. cosa succede se ci sono schemi diversi? Perché la classe che consuma dovrebbe essere responsabile di capire dove ottenere la stringa di connessione DB?

— TheCatWhisperer,

Non so cosa intendi. Nulla nel codice dovrebbe essere responsabile di "capire" dove ottenere la stringa di connessione. È configurazione. Non vedo perché sia diverso dall'uso della configurazione per i database QA rispetto alla produzione. Non metti se le dichiarazioni in codice per quello, vero?

— JimmyJames,

Questa è un'applicazione che parla con due database.

— TheCatWhisperer,

Penso che tu fraintenda il problema: "dobbiamo conservare i dati dei clienti provenienti da diversi paesi in database separati (specifici per paese)" Non è necessario che una singola "istanza" dell'applicazione parli con due database. Dubito che siano solo due DB. L'OP probabilmente significava "ad es." Quando digitavano "ie"

— JimmyJames il

Vorrei andare con la seconda opzione, dà meno attrito nello sviluppo e nella distribuzione.

Ciò consentirà una migliore scalabilità e disponibilità e migliori opzioni di distribuzione dei tempi di inattività pari a zero, poiché hai distribuito la tua app a 1 (o almeno un'istanza) per regione rispetto ad almeno una per tutto il mondo.

Man mano che i requisiti cambiano, potresti avere una logica di business più specifica per regione e, eventualmente, anche una modifica dei dati, proverei a dividere il codice e i suoi dati per regione, evitando di condividere la logica di business specifica della regione (potresti finire per condividere un codice di base).

Ha senso?

— Sean Farmar
fonte