Bus di messaggistica / servizio persistente: fai il mio o rischi la curva di apprendimento?

Question

Abbiamo un'applicazione client che deve inviare messaggi a un server per varie notifiche. Affinché il client possa essere eseguito occasionalmente connesso, vado con un approccio a coda di messaggi. L'elaborazione della coda eliminerà i messaggi dalla coda e chiamerà un servizio Web che li inserirà in un'altra coda per essere infine elaborati. Questa domanda riguarda l'ambiente client; l'ambiente server è già stato deciso.

Non voglio usare MSMQ perché non abbiamo il controllo su tutti i PC client al fine di installare / configurare e proteggere MSMQ correttamente, e perché il supporto è più impegnativo a causa della qualità degli strumenti per indagare i contenuti delle code MSMQ. SQL Server 2005 Express è su tutti i computer e viene utilizzato per archiviare i dati per la nostra applicazione.

Attualmente ho due opzioni:

1. Scrivi una coda di messaggi persistente abbastanza semplice che memorizza i messaggi in una tabella dopo averli serializzati, quindi usa ThreadPool.QueueUserWorkItem per farli elaborare dai gestori configurati su ciascun tipo di messaggio. Tutto in un System.Transactions.TransactionScope , quindi vengono rimossi dalla coda persistente solo se elaborati correttamente.
2. Usa NServiceBus (questo è il bus di servizio con cui siamo andati in team, quindi MassTransit ecc. non sono opzioni) sul client, con un trasporto di Service Broker che utilizza il database locale.

Ho poca esperienza con i bus di servizio (non ho ancora la terminologia del bus di servizio), quindi sono preoccupato per la curva di apprendimento rispetto alla scrittura di qualcosa di molto più semplice che soddisfa i miei requisiti nel modo in cui ne ho bisogno ( la distribuzione è una grande considerazione).

Qualcuno ha qualche pensiero?

Answer 1

Alla fine ho scritto un messagebus di base configurato con il mio SqlTransport in modo che i messaggi vengano serializzati e salvati in una tabella del database di SQL Server, prima che vengano generati eventi e venga segnalato un thread separato per elaborare i messaggi.

Answer 2

Beh, non so che suggerirò MSMQ, ma suggerirò che ci sono molti casi limite a cui pensare per "roll your own".

Anche con un approccio al pool di thread, tieni presente che potrebbero esserci problemi di ordinazione, se ti interessa: due elementi pubblicati in sequenza nei pool di thread possono non essere eseguiti in ordine, a causa della gestione dei pool di thread oggetti di lavoro.

Dovrai anche pensare alla persistenza dei messaggi, e per quanto tempo dovrebbero esistere, come rilevare lo stato di non consegna "fatale" e cosa fare in quel caso.

Esistono anche un certo numero di potenziali casi limite in scenari in cui l'app si interrompe nello stesso momento in cui accoda un messaggio; ad esempio, potrebbe non avere il riconoscimento che il messaggio è stato messo in coda, anche se lo era. Sì, puoi accettare il riconoscimento della coda, ma puoi entrare continuamente in cerchie ...

Perché non solo rilevare l'app quando viene connessa e inviare tutti i dati a quel punto?

Answer 3

Avendo scritto il nostro bus di servizio, posso dirti che non è un'impresa banale e ti imbatterai negli stessi casi limite che tutti gli altri implementatori hanno già incontrato. kyoryu ne riporta due molto importanti.

Il fatto che tu tiri il tuo dipende anche dalle abilità che hai in casa e in futuro avrai per mantenere la soluzione.

Un'altra considerazione è l'eventuale scala del sistema e i suoi requisiti di affidabilità. La soluzione interna sarà sufficientemente scalabile?

Il nostro bus di messaggi peer-to-peer, Zebus, basato su ZeroMq (trasporto), Cassandra (scoperta e persistenza dei pari) e Protobuf (serializzazione).

1. Nessuna distribuzione client come sul client è solo una libreria
2. Persistenza dei messaggi viene fornito anche usando Cassandra e gestisce molti casi limite diversi (questo viene regolarmente testato nel nostro ambiente di produzione)
3. Si comporta bene e poiché si tratta di una soluzione senza broker non vi sono colli di bottiglia per prestazioni singole
4. Non esistono singoli punti di errore poiché la Directory può essere utilizzata con un archivio dati disponibile come Cassandra

È open source e testato in produzione https://github.com/Abc-Arbitrage/Zebus