Akka oscura i broker di messaggi JMS / AMQP? [chiuso]

Chiuso . Questa domanda è basata sull'opinione . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che possa essere risolta con fatti e citazioni modificando questo post .

Chiuso 4 anni fa .

Ho trascorso l'ultima settimana a immergermi nei documenti di Akka e finalmente ho capito quali sono i sistemi di attori e i problemi che risolvono.

La mia comprensione (ed esperienza con) i broker di messaggi JMS / AMQP tradizionali è che esistono per fornire quanto segue:

Elaborazione asincrona tra produttore e consumatore; e
Garanzia di consegna dei messaggi, inclusa persistenza, tentativi e fallback

Ma Akka non lo fornisce, senza tutte le infrastrutture necessarie e le spese operative?

In Akka, tutte le comunicazioni degli attori sono asincrone e non bloccanti; e
In Akka, SupervisorStrategiesesistono per realizzare nuovi tentativi, fallback ed escalation. Gli attori possono essere configurati per persistere praticamente in qualsiasi tipo di negozio, se anche questo è un requisito.

Quindi questo mi chiedo: se la mia app utilizza Akka, ho mai bisogno di inserire i broker JMS / AMQP (ad esempio ActiveMQ, RabbitMQ, Kafka) nella foto? In altre parole, c'è mai un caso d'uso in cui una nuova app basata su Akka giustificherebbe anche l'introduzione di un nuovo cluster di broker JMS / AMQP? Perché o perché no?

L'unico argomento sarebbe che forse la mia app Akka deve integrarsi con un altro sistema. Ma in quel caso, il modulo Akka-Camel consente ad Akka di attingere all'esauriente, quasi infinita lista di capacità di integrazione di Camel (TCP, FTP, ZeroMQ, l'elenco potrebbe continuare all'infinito ...).

Pensieri?

— smeeb
fonte

Il tuo ultimo paragrafo non è un motivo per cui Akka non rende obsoleti i broker di messaggi? Ad esempio, sto lavorando a un'applicazione Java che interagisce con le applicazioni C ++ remote tramite un broker di messaggi conforme a JMS. Potrei scrivere la mia applicazione Java usando Akka-Camel, ma avrei ancora bisogno del broker a causa dell'applicazione C ++.

— Thomas Owens

Ahhh grazie @ThomasOwens (+1) ma hai (giustamente) frainteso la mia domanda. Cambierò il testo in pochi minuti in modo che sia più ovvio. Quello che sto davvero chiedendo è: se sto creando un'app Akka, avrei mai bisogno di introdurre anche un nuovo broker JMS / AMQP? Penso che la risposta sia "no", perché Akka + Camel (di nuovo penso ) risolva tutti i problemi normalmente risolti da un broker. Nel tuo esempio, il broker JMS esiste già come modo per comunicare con l'app C ++; Non lo sto aggiungendo con la mia nuova app Akka. E così il modulo Akka-Camel si occuperà della messaggistica per me.

— smeeb,

Forse sono frainteso, ma Camel non sostituisce JMS (ad esempio), ma fornisce un'interfaccia che può essere utilizzata per inviare messaggi tramite JMS. È possibile sostituire JMS con AMQP, RabbitMQ o XMPP. Nel mio esempio, anche se le mie applicazioni Java + Akka e C ++ fossero nuove di zecca, per poter comunicare su JMS, avrei comunque bisogno di introdurre una sorta di coda di messaggi conforme a JMS e quindi potrei usare Akka-Camel per comunicare con esso. Camel non fornisce un broker, significa solo comunicare attraverso un numero di protocolli. Akka-Camel fornisce un'interfaccia più familiare sull'interfaccia di Camel.

— Thomas Owens

Grazie ancora @ThomasOwens (+1) - Penso che stai solo pensando troppo a questo :-). Nel tuo esempio esiste un'app C ++ esistente , forse un sistema legacy, e esiste un broker compatibile con JMS che l'app C ++ utilizza già per l'integrazione con il mondo esterno. In questo caso, la mia nuova app Akka dovrebbe - proprio come hai detto tu - utilizzare il modulo Akka-Camel per produrre / consumare messaggi da / verso questo broker. Ma questo non è quello che chiedo qui! Mi chiedo se c'è mai un motivo per cui avrei bisogno di costruire 2 cose : (1) la mia nuova app Akka e (2) un broker JMS / AMQP, allo stesso tempo ...

— smeeb

Hai citato le infinite capacità di integrazione di Camel ma non può integrarsi con Nothing. Deve esserci qualcosa per integrarsi, altrimenti ti stai godendo il supporto per un mucchio di servizi che non stai eseguendo. Avvia JMS o un server HTTP o FTP o qualcosa del genere se desideri utilizzare Camel per integrarti con qualcosa. Altrimenti fornisce beatamente infinite capacità di integrazione senza integrarsi con nulla.

— Jimmy Hoffa,

Modello dell'attore

Il modello dell'attore è la strategia informatica per la creazione di applicazioni che gestiscono molti calcoli simultanei e l'elaborazione con stato. Non è l'unica strategia ma è un approccio molto ben collaudato, semplice e affidabile che sposta il calcolo in attori , che comunicano attraverso messaggi che elaborano uno alla volta e in ordine.

Akka è un framework che implementa il modello di attore e ti permette di costruire sistemi di attori con tutte le infrastrutture e le funzionalità già costruite (come usare JQuery invece di javascript).

messaggistica

I sistemi di messaggi sono applicazioni in grado di inviare e recuperare messaggi. Esistono molte varietà, dalle code di base al software per grandi aziende con argomenti, pub / sub, persistenza e altre funzionalità, ma l'obiettivo finale è lo stesso. Salvare alcuni byte da qualche parte e recuperarli di nuovo in seguito, con una sorta di ordinamento. Il caso d'uso principale oggi è quello di disaccoppiare i sistemi e consentire l'elaborazione asincrona a diverse pianificazioni o velocità. RabbitMQ, NATS, Kafka, ecc. Sono tutti esempi di sistemi di messaggi.

Confronto

Il modello Actor e il framework Akka sono strumenti di basso livello che rappresentano un ottimo modo per creare applicazioni , come le code dei messaggi.

Puoi usare Akka invece di una coda di messaggi? Sicuro. Se stai creando software che utilizza già il modello attore, probabilmente non hai bisogno di una coda di messaggi esterna, in particolare per l'invio di messaggi all'interno dello stesso thread o applicazione. Puoi utilizzare le funzionalità di Akka Remoting per persino inviare messaggi ad altri sistemi di attori in esecuzione su altre macchine.

Tuttavia, ciò rende obsoleti i sistemi di messaggistica? Assolutamente no. Solo perché puoi codificare tutto ciò da solo non significa che devi farlo, specialmente quando un modello di attore non è un bene per il tuo problema o hai bisogno di lingue, applicazioni, API esterne, sistemi operativi, database ecc. Diversi per comunicare tra loro (siano essi sistemi di attori o meno).

Se hai solo bisogno di passare alcuni messaggi tra due sistemi, usa una coda di messaggi. Se hai bisogno di elaborazione con stato scalabile e di messaggi a bassa latenza all'interno della stessa applicazione, usa il modello attore. Entrambi esistono a livelli completamente diversi e il modo in cui li usi dipende dalla soluzione che stai costruendo.

C'è una grande risposta su SO su questo stesso modello di attore vs messaggistica: /programming/5693346/when-to-use-actors-instead-of-messaging-solutions-such-as-websphere-mq- o-TIBCO

— Mani Gandham
fonte