Devo inviare messaggi da un servizio Windows a un servizio di stato Fabric Service di Azure. La connessione di rete non è molto affidabile e non ci devono essere dati persi. Speravo di poter usare NServiceBus con un negozio & avanti per inviare i messaggi. Il mio pensiero è fondamentalmente imperfetto?
Non c'è modo di garantire che nessun dato sia mai perso. Ci sono modi per diminuire la possibilità, e ci sono modi per rilevare quando i dati vengono persi - e questo è il meglio che puoi fare.
Data questa premessa, una connessione TCP è in effetti piuttosto buona in questo senso, poiché garantisce la consegna di un messaggio o un errore.
La domanda si riduce quindi a: cosa fai se c'è un fallimento? Ecco alcune opzioni:
Tutte queste soluzioni si adattano al requisito di "non perdere i dati" una volta compreso che la gestione dei guasti è la migliore che possiamo fare. In effetti puoi persino usarli tutti allo stesso tempo (ricadendo se qualcuno fallisce). Ovviamente hanno costi molto diversi. Quale è appropriato dipende da quanto i dati persi sono preziosi per te e quanto sei disposto a spendere.
Non credo che nservicebus abbia il supporto in questo momento per quello che stai cercando. L'uso del broker del servizio di assistenza azzurro sarebbe altrettanto inaffidabile quanto la connessione di rete, quindi non è una soluzione.
Quello di cui hai bisogno è un outbox memorizzato localmente (da non confondere con la funzione di outbox corrente di nsb) + un tipo di pompa a prova di errore che spinge i messaggi oltre una volta ristabilita la rete. Questo è nella mia lista dei desideri da un po 'di tempo, link , ma non ancora implementato a causa della mancanza di spazio di archiviazione locale funzionalità nella maggior parte dei servizi blu.
Per questo scenario, tuttavia, potrebbe essere creato utilizzando msmq come archivio locale (supponendo che si trovi su un disco non transitorio) & gestione dello stato affidabile del fabric di servizio come negozio remoto sul lato del fabric di servizio. Ma su altri servizi, ad es. servizi cloud sarebbe pericoloso dato che i dischi vengono reimaged di tanto in tanto.
1) Impostare un endpoint NServiceBus con MSMQ sulla scatola con Windows Server. Utilizzerà le funzionalità integrate di archiviazione e inoltro di MSMQ per non perdere i messaggi localmente su quella macchina.
2) Impostare uno o più endpoint di NServiceBus in Fabric Service di Azure. Lì probabilmente userò ASB come trasporto per il servizio di comunicazione di servizio.
3) Utilizzare il gateway NServiceBus per il bridge tra 1) e 2) attraverso un canale HTTP (s). Effettuerà tentativi automatici se la connessione è inattiva e esegue la deduplicazione per fornire esattamente una volta il recapito dei messaggi tramite HTTP (s). È stato specificamente progettato per questi scenari multi-sito.
Leggi altre domande sui tag architecture microservices azure service-bus messaging