Abbiamo una soluzione distribuita che è attualmente in fase di progettazione. Ci sono alcuni punti di integrazione in cui alcune applicazioni richiedono dati da qualcun altro e viceversa. Potremmo risolvere scrivendo le interfacce REST e fornendo funzionalità CRUD in modo che le app possano condividere i dati tra loro. Oppure possiamo usare qualcosa come nanomsg o zeroMQ per inviare messaggi avanti e indietro.
Abbiamo anche requisiti H / A in cui vogliamo fare il master per padroneggiare la replica tra i server db primari e secondari per garantire che se uno scende, l'altro può dare il calcio d'inizio.
Ecco la domanda. Alcuni membri del team pensano che dovremmo scegliere un metodo di condivisione dei dati, come il master per la masterizzazione della replica ... e basta usarlo su tutta la linea per "condividere" i dati. È vero che possiamo farlo, ma penso che ogni caso dovrebbe essere analizzato e trattato separatamente in base a criteri specifici come:
- i database in questione sono identici? se lo sono, il master da padroneggiare è appropriato, come nel nostro scenario High Availability.
- nel caso di sistemi disparati, quanti dati stiamo passando avanti e indietro? se sono molti dati ... forse un messaggio bus è migliore. invia semplicemente una notifica per dire "c'è un cambiamento ... ecco l'id di modifica. Vai a prenderlo".
- Quanto spesso cambiano i dati? Questo importa? Penso che sia una API REST sia un bus dei messaggi saranno in grado di gestire molte transazioni.
Non sono sicuro di cos'altro pensare. Sembra che la creazione di una soluzione di message bus sia molto più impegnativa di una REST api in ogni database. Ma potrei sbagliarmi. Quali altre cose dovremmo prendere in considerazione?
Grazie.