Chiedi a te stesso e alla tua attività con molta attenzione, sinceramente e ripetutamente, se veramente deve essere in tempo reale. Come in, davvero istantaneo? Stiamo parlando di atomico, non puoi mai avere quei due server fuori sincrono, nemmeno per un microsecondo? O c'è davvero un qualche tipo di SLA allegato e i dati possono essere stantii per forse alcuni millisecondi, o pochi secondi, o anche pochi minuti?
L'unico modo per ottenere la replica atomica è quello di utilizzare un broker e massicce transazioni distribuite. Questa è l'architettura in stile BizTalk, ed è dolorosamente, insopportabilmente lenta, fragile come cracker di zuppa di un anno e incredibilmente difficile da testare.
Il software di replica commerciale come Golden Gate è quasi tempo reale. È anche molto costoso. Ma quello che ottieni per quel prezzo elevato è la replica attiva-attiva - qualcosa che pochissimi strumenti di replica incorporati supportano - tra molte altre funzionalità di fascia alta che sono molto importanti se stai costruendo un ambiente ad alta disponibilità (diciamo a almeno quattro nove, e non solo durante l'orario lavorativo).
Enterprise Service Bus, almeno quelli che non vendono olio di serpente, sono basati sulla messaggistica e sono il contrario completo di tempo reale. Framework come NServiceBus, Apache Camel, MassTransit e così via, si concentrano principalmente sulla messaggistica asincrona, che significa consistenza finale. Ciò che significa, per alcuni è paradossale, è molto veloce e generalmente più facile da mantenere, ma si rischiano incongruenze fisiche o talvolta logiche tra i servizi. Non ha senso adottare uno di questi se non si ha o non si pensa di costruire un'architettura orientata ai servizi in cui i servizi funzionino tutti in modo indipendente e senza bisogno di dati condivisi.
Non sono sicuro di quale di questi desideri. Molti programmatori e la maggior parte dei manager non tecnici dicono vogliono un'integrazione in tempo reale, ma quando si fermano davvero ad analizzare il problema e il business, si scopre che lo SLA è molto più indulgente di quello. Per prima cosa, il tempo di risposta di un utente sarà misurato in secondi, quindi davvero, a chi importa se le cose non sono coerenti per mezzo secondo? Ciò conta solo in cose come attrezzature mediche o sistemi di trading automatizzati. Inoltre, la concorrenza ottimistica è in circolazione da sempre ed è generalmente "abbastanza buona" per la maggior parte delle applicazioni - in altre parole, puoi permettere che le cose diventino incoerenti l'1% delle volte perché sai che il 99% delle volte starà bene, e per quel fastidioso 1% puoi spingere la decisione indietro all'utente per risolverlo.
Quindi, pensa a ciò di cui hai veramente bisogno e scegli di conseguenza. ESB e SOA sono ottimi se si ha una solida conoscenza del business e delle parti interessate disposte a collaborare. Richiedono anche un grande sforzo nelle aree di analisi e progettazione, quindi se si desidera una soluzione di infrastruttura pura, è meglio utilizzare uno strumento di replica commerciale (o, suppongo, uno open source se ne trovi uno che fa tutto ciò che bisogno). Solo se sei un settore altamente specializzato che richiede coerenza distribuita in tempo reale dovresti prendere in considerazione anche una soluzione basata su broker; non è quasi mai la scelta giusta.
Che tu scelga REST, SOAP, AMQP, Protocol Buffers o qualche altro tipo di messaggistica è quasi del tutto irrilevante per la tua scelta di architettura. Questi sono solo TLA (beh, FLA) usati per descrivere formati . Puoi usare quasi tutti i formati con quasi tutte le architetture. Preoccupati prima dell'architettura, quindi scegli un formato basato su quanto sia ben supportato all'interno di quell'architettura e su quanto sia familiare il tuo team con esso.
Modifica: dal momento che hai chiesto un elenco di domande da porre, ecco le mie:
- Quanto deve essere veloce?
- Ha davvero bisogno di essere in tempo reale?
- È veramente veramente necessario essere in tempo reale?
- Sei sicuro che deve essere in tempo reale?
- Che cosa succederebbe se non fosse in tempo reale?
- Qual è il costo o rischio associato a qualsiasi cosa di brutto?
- Qual è l'intervallo minimo che considereresti in tempo reale?
- A quale ricerca si basa quell'intervallo?
- In che modo è stata convalidata la ricerca?
- Sei davvero disposto a pagare 10 volte tanto in fase di sviluppo e manutenzione per avere una coerenza in tempo reale?