Utilizzo di ESB per la sincronizzazione / replica del database

Devi vedere quale sia il problema di root.

• Stai cercando la ridondanza dei dati?

• Cerchi tempi di accesso ai dati minimi?

• Stai cercando di condividere i dati tra ambienti separati?

• Stai cercando di ridurre al minimo le vulnerabilità della sicurezza con accesso ai dati?

Una volta che decidi qual è la priorità più alta, allora puoi lavorare per trovare la soluzione migliore.

Per la ridondanza dei dati e i tempi di accesso, la soluzione più probabile utilizza la replica SQL. L'obiettivo della replicazione (che questi prodotti sono molto buoni) è la ridondanza dei dati e l'amp; minimizzare i tempi di accesso tramite server di database slave. Questa opzione consente a tutti i punti di accedere a quasi gli stessi dati, è sufficiente monitorare il ritardo di replica per assicurarsi che rimanga all'interno dei requisiti aziendali.

Per questioni ambientali separate, credo che sia preferibile un ESB o un'operazione batch automatizzata. Ciò consente di effettuare ulteriori manipolazioni prima / durante le operazioni per garantire che eventuali scostamenti tra i server possano essere risolti al momento dell'importazione dei dati.

Per ridurre al minimo le vulnerabilità della sicurezza, raccomanderei un'operazione batch non automatizzata con un livello appropriato di controlli di sicurezza per garantire la validità dei dati. Non automatizzando questa operazione, consente a un essere umano di confermare che non ci sono problemi in sospeso che potrebbero causare il danneggiamento dei dati.

Per qualsiasi decisione, grande o piccola, è necessario eseguire un'analisi costi-benefici prima di implementare eventuali modifiche. È necessario prendere in considerazione:

1. Tempo di sviluppo
2. Costo di sviluppo
3. Uso futuro della soluzione
4. Prestazione prevista
5. Complessità della soluzione
6. Mantenibilità della soluzione

Prima di tutto, sappi che ESB e Microservices possono significare cose diverse a seconda del contesto. Inoltre, sembra che la gente di solito consideri i microservizi all'interno di un'architettura pull: ci sono API restful e ogni servizio chiama le API di altri servizi per ottenere i dati secondo necessità. L'ESB, d'altra parte, è solitamente associato a un'architettura push: i sistemi mettono i dati in code dove altri sistemi ottengono tali dati successivamente.

L'uso predefinito delle API è di fornire funzionalità di un'applicazione ad altri sistemi e servizi e di nascondere la rappresentazione dei dati di backend dell'applicazione da tutti gli altri servizi. Pertanto, se si costruisse l'app dei dati di prodotto in base a tali principi, si creerebbe un'API all'interno di tale app e quindi si utilizzerà la stessa funzionalità di accesso ai dati (SQL, ORM, ecc.) Come il resto dell'app. Se l'app mobile richiede solo le funzionalità di base per la gestione dei prodotti fornite dall'app, utilizzerà direttamente questa API e non avresti ulteriori separazioni e non sincronizzeresti alcun dato.

Se, d'altra parte, la tua app mobile ha bisogno di dati più raffinati per o con alcune funzionalità aggiuntive, o con prestazioni superiori a quelle che l'app originale può fornire (e non è possibile risolvere questo problema con un semplice reverse della cache -proxy) o la tua vecchia app è vecchia tecnologia e difficile da estendere, solo così avrai un vantaggio per mettere la tua nuova API in un'applicazione separata. E solo allora hai bisogno di trovare un modo per sincronizzare i dati tra entrambi.

Ora, supponendo che quest'ultimo sia il caso, i tuoi mezzi di sincronizzazione dipendono da molte cose:

• I dati vanno solo in un modo o in entrambi i modi?
• In entrambi i casi, l'applicazione esistente ha bisogno di un modo per convalidare e rifiutare dati non validi?
• Quanto spesso cambiano i dati? e quanto velocemente devono essere riflessi i cambiamenti?
• Quali sono le modalità di esportazione e importazione dei dati fornite dall'applicazione esistente? questo è di particolare importanza quando l'app è difficile da estendere!
• Quanto è probabile che cambi il formato dei dati della vecchia app? In un nuovo Architettura basata su microservizi per aggiungere API per incapsulare i dati dell'app il cui formato cambia spesso. In una vecchia app legacy, forse non lo farà nulla cambia altro fino a quando l'app non muore un giorno. (Inoltre, attenzione che noi spesso si aspettano che ciò accada, ma come dice il proverbio: "Il condannato vivere più a lungo. ")

In ogni caso, la prima domanda a cui dovresti rispondere è: la tua nuova API fornisce solo una nuova forma di accesso a dati e funzionalità esistenti o ti fornisce funzionalità e richiede un modulo diverso per archiviare i dati? Utilizza questo e altri criteri per decidere se l'API deve far parte dell'app esistente o di una nuova applicazione.