Scomporre un monolite in SOA e infrangere l'integrità referenziale

6

Quando si rompe una grande applicazione monolitica con un RDBMS monolitico in un'architettura orientata ai servizi con molti database, come si fa a gestire l'interruzione dell'integrità dei dati?

Ho una grande applicazione monolitica. Il mio team ha convenuto che è utile suddividere questo monolite in servizi specifici per il dominio e abbracciare più di un'architettura orientata ai servizi. Con il nostro monolite, abbiamo un enorme database RDBMS. Il team è diviso sull'opportunità di ritagliare tabelle specifiche del dominio nei propri database. Alcuni sono preoccupati di infrangere l'integrità referenziale e il rischio che ciò comporta. Tuttavia, altri sono OK con questo rischio.

Qualcuno ha esperienza con questo problema e può condividere qualche consiglio? Uno dei miei obiettivi è quello di facilitare la scalabilità orizzontale (aggiungere più server DB) anziché verticale (rinforzando un singolo enorme server DB). Ad un certo punto del futuro, potrei immaginare che alcuni servizi potrebbero essere più adatti a un DB di documenti noto come data store NoSQL piuttosto che a un RDBMS, e certamente, l'integrità basata su RDMBS tradizionale sarebbe difficile. (Quindi approcci come archiviare le tabelle in schemi separati sullo stesso database probabilmente non saranno appropriati.)

    
posta Andy 06.06.2017 - 21:56
fonte

3 risposte

6

L'integrità referenziale è una preoccupazione che suggerisce che esistono dipendenze implicite tra i domini. Una cosa che penso che le persone che hanno bevuto i microservizi kool-aid spesso fraintendano è che questi tipi di dipendenze e le questioni ad essi collegate non scompaiono magicamente una volta abbattuto il monolite. È positivo che le persone siano preoccupate e se ti impegni in questo percorso, vorrai assicurarti che tali preoccupazioni siano affrontate.

Se vi è un accoppiamento molto stretto tra due o più domini da una prospettiva di business, potresti voler considerare se debbano davvero essere separati in DB separati. Potrebbe non valerne la pena.

Se hai bisogno di mantenere l'integrità tra due entità, un paio di cose potrebbero aiutare:

  1. Usa sempre le chiavi surrogate. Non ci dovrebbero essere motivi per cambiare le chiavi prive di significato e se le tue chiavi non cambiano mai, si evita una grande quantità di problemi del RI.
  2. Non eliminare mai le chiavi e utilizzare le eliminazioni "soft". Anche l'aggiunta di righe e il loro aggiornamento non sono sempre utili. Per lo meno saprai cosa significano le cose quando sono collegate.
risposta data 06.06.2017 - 22:33
fonte
2

Sarei attento a pensare di condividere un database con un altro servizio. Ogni volta che viene apportata una modifica al database, è ora possibile verificare che la modifica non influisca su nessun altro servizio che utilizza tale database. Sei tornato a fare rilasci monolitici in cui i test vengono eseguiti su ogni servizio per vedere se è possibile rilasciare. Questo verrà aggravato se il servizio è di proprietà di un altro team poiché le modifiche al database richiedono ora una comunicazione tra team che rallenta lo sviluppo e crea problemi di pianificazione, ecc.

Uno dei vantaggi di SOA e microservizi è che i confini sono a livello di API che rimane relativamente stabile tra le versioni. Ciò consente a un microservice di rilasciare individualmente senza la necessità di testare l'intero sistema. Avere un database separato per servizio consente a questo tipo di sviluppo di procedere.

In termini di integrità referenziale, dipenderà dal tuo dominio. Se l'integrità referenziale è mission-critical per la tua azienda, allora potrei proporre di trovare luoghi meno granulari per dividere il tuo monolitico. Ad esempio, potresti avere un servizio che rappresenta tutta la logica di dominio e le relazioni delle entità del dominio principale. Potresti avere servizi di supporto, come un servizio di posta elettronica, un servizio di autenticazione, ecc. Il tuo servizio di dominio potrebbe non essere "micro", ma se l'integrità referenziale è importante, non rischiare andando troppo granulare nella progettazione del servizio. p>

Se rilassate la vostra integrità referenziale per essere infine coerente / mantenuta, allora si apre un mondo completamente nuovo. È possibile disporre di servizi che costituiscono il sistema di registrazione per determinati concetti / entità di dominio e quindi denormalizzare i dati per query veloci in altre parti del sistema. Questa condivisione di dati richiede tempo per propagarsi, ma per la maggior parte dei domini non è un problema. Devi decidere se è ok mostrare o eseguire la convalida con questi dati eventualmente coerenti.

Se disponi di regole aziendali che devono essere eseguite andando a più servizi per essere convalidati ed eseguiti, il tuo dominio potrebbe non essere una buona scelta per SOA. Se invece la tua azienda rappresenta flussi di lavoro, in cui ogni servizio compie qualche passo in un flusso aziendale più ampio, questo sarebbe un caso d'uso molto migliore. Ho trovato che il posto migliore per rompere un monolite è in contesti limitati. A volte questi servizi finiscono per essere abbastanza grandi, ma è così che viene modellato il dominio. Sarà doloroso se diventerai troppo granulare poiché genererai un gran numero di richieste di rete per rispondere alle richieste o eseguire una manipolazione dei dati che richiede alcuni join nel tuo monolite. Inoltre, non avrai l'integrità referenziale in quanto potresti effettuare una chiamata per convalidare un record esistente in un altro servizio e farlo eliminare subito dopo il completamento della chiamata.

Modifica:

Un modo per mantenere la coerenza finale tra i record consiste nell'avere un processo che ricerca i record orfani o che collega i record insieme. È possibile fornire agli utenti un posto per pulire questi record orfani nell'interfaccia utente per consentire loro di agire. Al momento della query è possibile rilevare i problemi e informare l'utente per consentire loro di risolvere il problema.

È possibile utilizzare strumenti come rabbitmq o Kafka come meccanismo per servizi di condivisione di dati che alla fine saranno coerenti.

Ad esempio, potrei avere un archivio coerente di nomi completi dell'utente dal servizio utente nel mio servizio, in modo che non sia necessario interrogare costantemente il servizio utente per visualizzare il nome completo. Potrei ascoltare gli eventi che arrivano attraverso kafka dal servizio utente al fine di costruire il mio negozio alla fine coerente. Ora le ricerche complete sul nome sono veloci nel mio servizio al costo della duplicazione dei dati.

L'integrità qui sarà strong in quanto i nomi completi dell'utente probabilmente non cambieranno così spesso. Altri set di dati che cambiano molto potrebbero avere meno integrità in quanto la coda / kafka potrebbe essere dietro.

Ogni servizio che possiede un record è responsabile dell'integrità di quel record. Le relazioni con altri record dovranno essere più flessibili. Come servizio al consumatore di un record di un altro servizio, dovrai ascoltare e adattare i cambiamenti che si verificano al record all'interno del proprio servizio, poiché ha l'ultima parola sullo stato corrente del record.

    
risposta data 06.06.2017 - 23:24
fonte
1

Prima di tutto, ci sono molti modi in cui potresti dividere il monolite. Se si dispone di vincoli mission-critical con entità corrispondenti che si trovano in servizi diversi, si ha identificato i limiti del servizio in modo errato .

Ci sono alcune caratteristiche che vuoi che i tuoi servizi posseggano. Apparentemente i tuoi servizi dovrebbero avere un accoppiamento basso. Non vuoi che il tuo monolite diventi uno distribuito. Non vuoi che l'intero sistema scenda a causa di un bug in alcuni servizi. Volete che i vostri servizi abbiano un'elevata coesione: se avete bisogno di apportare alcune modifiche strettamente correlate nel vostro codice sorgente, volete che tutto il codice risieda in un unico posto. Questi due sono probabilmente i tratti più importanti. Tutto il resto può essere concluso da loro. Quelli sono l'alta autonomia di servizio, la comunicazione tramite eventi, i dati decentralizzati e la coreografia di servizio al posto dell'orchestrazione.

Bene, questo suona bene e bene, ma quali sono i passi concreti da intraprendere ? Quello che finalmente sono arrivato è il seguente. Definisco le capacità aziendali del mio sistema, fondamentalmente le sue responsabilità di livello superiore. Ma non confondere la struttura organizzativa con le capacità di business. Idealmente, coincidono, ma questo non è il caso più spesso. Quindi annota le tue capacità di business di livello superiore. Ci dovrebbero essere circa 5-7 di loro. Non più di 10, penso. Quindi approfondisci ciascuno di essi. In cosa consistono le responsabilità unilaterali? Non pensare alla programmazione quando lo fai. Ti decomponi solo nello spazio dei problemi. Le capacità di business che si ottengono rifletteranno il tuo dominio, quindi saranno intrinsecamente accoppiati liberamente. Nessun vincolo verrà violato. C'è una metafora che mi aiuta con quella decomposizione: evoco come il mio attuale dominio sembrava (o avrebbe avuto) un secolo fa. Quali sono i limiti veramente mission-critical? Quali vincoli sono solo il risultato di un malinteso sul dominio? Scommetto che il tuo dominio è più coerente alla fine di quanto pensi.

Dopo aver terminato la decomposizione delle funzionalità, è possibile associare questo risultato allo spazio della soluzione. Io chiamo le entità soluzione-spazio che corrispondono alle capacità dello spazio dei problemi "business-services". È il confine logico in cui risiede la capacità aziendale. Esistono regole aziendali, processi aziendali, persone coinvolte e decisioni specifiche, applicazioni utilizzate da queste persone e dati aziendali gestiti su persone.

Quindi, dopo questo, decidi finalmente cosa vuoi automatizzare. Quindi i tuoi servizi tecnici e SOA avranno una relazione 1: 1 con il tuo servizio aziendale.

Ecco un esempio di ciò di cui ho scritto.

Quindi, seguendo questo approccio non esiste un problema come la violazione dell'integrità dei dati.

Spero di esserti stato utile.

    
risposta data 26.09.2017 - 15:48
fonte

Leggi altre domande sui tag