Ho un cliente di grandi dimensioni che si trova di fronte all'applicazione web (.net mvc se questo è importante) che devo suddividere in un numero di servizi. Alcuni di questi servizi saranno quindi condivisi con altre applicazioni.
Al momento tutti i server che ho fanno parte di un cluster web che usiamo per questa app, anche se questo potrebbe cambiare in futuro.
Ciò di cui sto combattendo è decidere tra l'apprendimento di un sistema di Accodamento messaggi come RabbitMQ, che dovrebbe migliorare le prestazioni, e verrà eseguito su tcp / ip, rendendo possibile la rimozione di alcuni di questi servizi chiave dal cluster di server Web, e proseguendo con la creazione di un'API JSON / REST interna. (Che conosciamo già, ma non aiuterà a migliorare le prestazioni.)
Tuttavia, essendo le code RabbitMQ sono unidirezionali, dovrei quindi trovare una strategia per gestire le occasioni in cui il sito web / utente ha bisogno di feedback da uno dei servizi. Il che significa un modo per creare una coda di messaggi di ritorno specifica della sessione, o fare affidamento su RPC, che può quindi influire sul rendimento.
A mio parere RabbitMQ mi offre più flessibilità e opportunità (posso spostare il codice dai server web, gestire code di messaggi e così via), ma crea anche più rischi in quanto è sconosciuto al business e significa che non solo stiamo dividendo la nostra applicazione, ma stiamo aggiungendo un nuovo metodo di comunicazione.
Quindi, qualcuno ha implementato RabbitMQ in uno scenario basato sul Web come questo, e in caso affermativo, ora se ne pentono, e desiderano che si siano attenuti all'utilizzo di REST? (O viceversa)