Akka il clustering in conflitto

Question

I Akka doc parla di una varietà di tecnologie di Akka apparentemente inter-connessi senza distinguere molto tra di loro:

• Akka Networking
• Akka Remoting
• Akka Clustering
• L'Akka ZeroMQ modulo

Il mio comprensione è quello "Akka Networking" è semplicemente un modulo/lib che consente ad Akka di parlare con i sistemi di attori remoti su TCP. Akka Remoting è un altro modulo/lib (non contenuto nel core Akka JAR) che dà ad Akka l'uso dei protocolli Gossip. E Akka Clustering è ancora un altro modulo/lib che utilizza quindi questi protocolli Gossip per consentire ai sistemi di attori remoti di raggrupparsi insieme e cambiamenti di sharestate in una "scoperta di servizio" virale/"sicura". E il mio di Akka ZeroMQ è che realizza la stessa cosa di Akka Clustering, tranne l'utilizzo di ZeroMQ come base delle connessioni e dei protocolli di rete (invece di Gossip).

Quindi, per prima cosa, se la mia comprensione di questi diversi moduli/librerie non è corretta, per favore inizia correggendomi!

Supponendo che qui sia più o meno il target, la mia preoccupazione principale è che potrei avere Remote Actor System 1 (RAS1) usando Akka Clustering (e quindi Gossip) cercando di comunicare con Remote Actor System 2 (RAS2) che utilizza Akka ZeroMQ. In questo caso, stiamo utilizzando due tecnologie e protocolli di clustering completamente diversi, quindi questo significa che questi due sistemi remoti non possono comunicare tra loro o fare attenzione speciale affinché siano compatibili tra loro ?

Answer 1

Akka Remoting è ciò che consente a un attore di parlare con un altro attore su una macchina diversa. Affinché Akka Remote funzioni, è necessario conoscere l'indirizzo IP specifico (o il nome host), il nome ActorSystem e il percorso attore dell'attore con cui si desidera parlare. Il nome ActorSystem può essere diverso nelle 2 macchine.

Akka Clustering elimina il problema di dover conoscere la macchina specifica con cui si sta parlando (tramite Routing abilitato al cluster o tramite un addetto alla reception che ascolta le macchine che si collegano o escono dal cluster). Il routing compatibile con i cluster consente anche di avere un minimo di istanze X di un attore in esecuzione su qualsiasi macchina nel cluster. Akka Clustering utilizza il protocollo Gossip per mantenere l'elenco dei membri del cluster. Un'applicazione abilitata per il cluster deve conoscere l'indirizzo di almeno un host che deve essere sempre in esecuzione per poter accedere al cluster. Ci potrebbero essere 2, 3 o più, ma l'idea è che almeno uno di loro deve essere sempre attivo. Akka Clustering è costruito su Akka Remoting.

Sebbene non abbia lavorato con Akka ZeroMQ, presumo che funzioni in modo simile ad Akka AMQP. Lo vedo più come un'alternativa a Remoting, nel senso che consente agli attori di diverse macchine di parlare tra loro, con il vantaggio che nessuno degli attori ha bisogno di conoscere alcun dettaglio su eventuali altre macchine in cui gli attori sono in esecuzione. Tuttavia, come con Remoting, è necessario creare manualmente gli attori che ricevono i messaggi, mentre con Clustering il cluster si prende cura di esso (purché i router siano stati configurati correttamente).

Per quanto riguarda la tua ultima domanda. Il modo più semplice con cui riesco a pensare a un Cluster di parlare con Akka ZeroMQ è quello di avere uno (o più?) Attori nel Cluster che parlano con gli attori ZeroMQ (ad esempio, puoi mescolare e abbinare effettivamente). Avere un attore all'interno del Cluster che è in ascolto sulla coda e ne ha un altro che pubblica il messaggio in coda. Una specie di modello di adattatore.