Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Migrazione della logica aziendale dal database al livello applicativo
La migrazione della logica di business da procedure, trigger e funzioni archiviati nel database ai servizi a livello di applicazione è un passaggio fondamentale nella scomposizione dei database monolitici. Questa trasformazione migliora l'autonomia del servizio, semplifica la manutenzione e migliora la scalabilità. Questa sezione fornisce indicazioni sull'analisi della logica del database, sulla pianificazione della strategia di migrazione e sull'implementazione della trasformazione mantenendo al contempo la continuità aziendale. Descrive inoltre la definizione di un piano di rollback efficace.
Questa sezione contiene i seguenti argomenti:
Fase 1: analisi della logica aziendale
Quando si modernizzano i database monolitici, è necessario innanzitutto condurre un'analisi completa della logica del database esistente. Questa fase si concentra su tre categorie principali:
-
Le stored procedure spesso contengono operazioni aziendali critiche, tra cui logica di manipolazione dei dati, regole aziendali, controlli di convalida e calcoli. In quanto componenti fondamentali della logica aziendale dell'applicazione, richiedono un'attenta scomposizione. Ad esempio, le procedure archiviate di un'organizzazione finanziaria potrebbero gestire il calcolo degli interessi, la riconciliazione dei conti e i controlli di conformità.
-
I trigger sono componenti chiave del database che gestiscono gli audit trail, la convalida dei dati, i calcoli e la coerenza tra tabelle. Ad esempio, un'organizzazione di vendita al dettaglio potrebbe utilizzare i trigger per gestire gli aggiornamenti dell'inventario in tutto il sistema di elaborazione degli ordini, il che dimostra la complessità delle operazioni automatizzate del database.
-
Le funzioni nei database gestiscono principalmente le trasformazioni dei dati, i calcoli e le operazioni di ricerca. Spesso sono integrate in più procedure e applicazioni. Ad esempio, un'organizzazione sanitaria potrebbe utilizzare funzioni per normalizzare i dati dei pazienti o cercare codici medici.
Ogni categoria rappresenta aspetti diversi della logica aziendale incorporata nel livello del database. È necessario valutarli e pianificarli attentamente per migrarli al livello applicativo.
Durante questa fase di analisi, i clienti in genere devono affrontare tre sfide significative. Innanzitutto, emergono dipendenze complesse attraverso chiamate di procedura annidate, riferimenti tra schemi e dipendenze implicite tra dati. In secondo luogo, la gestione delle transazioni diventa fondamentale, in particolare quando si tratta di transazioni in più fasi e si mantiene la coerenza dei dati tra sistemi distribuiti. In terzo luogo, le considerazioni relative alle prestazioni devono essere valutate attentamente, in particolare per le operazioni di elaborazione in batch, gli aggiornamenti di massa dei dati e i calcoli in tempo reale che attualmente traggono vantaggio dalla vicinanza ai dati.
Per affrontare efficacemente queste sfide, è possibile utilizzare AWS Schema Conversion Tool (AWS SCT) per l'analisi iniziale e quindi utilizzare strumenti dettagliati di mappatura delle dipendenze. Questo approccio consente di comprendere l'intero ambito della logica del database e di creare una strategia di migrazione completa che mantenga la continuità aziendale durante la decomposizione.
Comprendendo a fondo questi componenti e queste sfide, è possibile pianificare meglio il percorso di modernizzazione e prendere decisioni informate sugli elementi a cui dare priorità durante la migrazione verso un'architettura basata su microservizi.
Quando analizzi i componenti del codice del database, crea una documentazione completa per ogni procedura, trigger e funzione archiviati. Inizia descrivendone chiaramente lo scopo e le funzionalità principali, comprese le regole aziendali che implementa. Descrivi in dettaglio tutti i parametri di input e output e annota i relativi tipi di dati e gli intervalli validi. Mappa le dipendenze da altri oggetti del database, sistemi esterni e processi a valle. Definisci chiaramente i limiti delle transazioni e i requisiti di isolamento per mantenere l'integrità dei dati. Documenta qualsiasi aspettativa di prestazioni, compresi i requisiti in termini di tempi di risposta e i modelli di utilizzo delle risorse. Infine, analizza i modelli di utilizzo per comprendere i carichi di picco, la frequenza di esecuzione e i periodi aziendali critici.
Fase 2: Classificazione della logica aziendale
Un'efficace scomposizione del database richiede una categorizzazione sistematica della logica del database in base a dimensioni chiave: complessità, impatto aziendale, dipendenze, modelli di utilizzo e difficoltà di migrazione. Questa classificazione consente di identificare i componenti ad alto rischio, determinare i requisiti di test e stabilire le priorità di migrazione. Ad esempio, procedure archiviate complesse con un elevato impatto aziendale e un utilizzo frequente richiedono un'attenta pianificazione e test approfonditi. Tuttavia, funzioni semplici e utilizzate raramente con dipendenze minime potrebbero essere adatte per le prime fasi di migrazione.
Questo approccio strutturato crea una tabella di marcia di migrazione equilibrata che riduce al minimo le interruzioni aziendali mantenendo al contempo la stabilità del sistema. Comprendendo queste interrelazioni, è possibile migliorare la sequenza delle attività di scomposizione e allocare le risorse in modo appropriato.
Fase 3: migrazione della logica aziendale
Dopo aver analizzato e classificato la logica aziendale, è il momento di migrarla. Esistono due approcci per la migrazione della logica aziendale da un database monolitico: spostare la logica del database al livello dell'applicazione o spostare la logica aziendale su un altro database che fa parte del microservizio.
Se si esegue la migrazione della logica aziendale all'applicazione, le tabelle del database memorizzano solo i dati e il database non contiene alcuna logica aziendale. Questo è l'approccio consigliato. Puoi utilizzare Ispirer
Se si esegue la migrazione della logica aziendale a un altro database, è possibile utilizzare AWS Schema Conversion Tool (AWS SCT) per convertire gli schemi di database e gli oggetti di codice esistenti nel database di destinazione. Supporta servizi di AWS database appositamente progettati, come Amazon DynamoDB, Amazon Aurora e Amazon Redshift. Fornendo un rapporto di valutazione completo e funzionalità di conversione automatizzate, AWS SCT aiuta a semplificare il processo di transizione, consentendoti di concentrarti sull'ottimizzazione della nuova struttura del database per migliorare prestazioni e scalabilità. Man mano che avanzi nel progetto di modernizzazione, è in AWS SCT grado di gestire conversioni incrementali per supportare un approccio graduale, che consente di convalidare e ottimizzare ogni fase della trasformazione del database.
Strategia di rollback per la logica aziendale
Due aspetti critici di qualsiasi strategia di scomposizione sono il mantenimento della compatibilità con le versioni precedenti e l'implementazione di procedure di rollback complete. Questi elementi interagiscono per aiutare a proteggere le operazioni durante il periodo di transizione. Questa sezione descrive come gestire la compatibilità durante il processo di scomposizione e stabilire efficaci funzionalità di rollback di emergenza che proteggano da potenziali problemi.
Mantieni la compatibilità con le versioni precedenti
Durante la decomposizione del database, il mantenimento della compatibilità con le versioni precedenti è essenziale per transizioni fluide. Mantieni temporaneamente attive le procedure di database esistenti implementando gradualmente nuove funzionalità. Usa il controllo delle versioni per tenere traccia di tutte le modifiche e gestire più versioni del database contemporaneamente. Pianifica un periodo di coesistenza prolungato in cui sia il sistema di origine che quello di destinazione devono funzionare in modo affidabile. Ciò offre il tempo necessario per testare e convalidare il nuovo sistema prima di ritirare i componenti precedenti. Questo approccio riduce al minimo le interruzioni dell'attività e fornisce una rete di sicurezza per il ripristino, se necessario.
Piano di rollback di emergenza
Una strategia di rollback completa è essenziale per una scomposizione sicura del database. Implementa i flag di funzionalità nel codice per controllare quale versione della logica di business è attiva. Ciò consente di passare istantaneamente dalla nuova implementazione a quella originale senza modifiche alla distribuzione. Questo approccio offre un controllo granulare sulla transizione e consente di ripristinare rapidamente i processi in caso di problemi. Mantieni la logica originale come backup verificato e mantieni procedure di rollback dettagliate che specificano i fattori scatenanti, le responsabilità e le fasi di ripristino.
Testa regolarmente questi scenari di rollback in varie condizioni per convalidarne l'efficacia e assicurati che i team abbiano familiarità con le procedure di emergenza. I flag di funzionalità consentono inoltre l'implementazione graduale abilitando selettivamente nuove funzionalità per gruppi di utenti o transazioni specifici. Ciò fornisce un ulteriore livello di mitigazione del rischio durante la transizione.
