Ci sono molti approcci che puoi prendere a seconda del problema che stai cercando di risolvere. Non ho capito bene la motivazione alla base di avere un attore di scrittura separato e un attore di calcolatrice. La cosa importante da tenere a mente è che ogni attore è a turni. Se si desidera delegare la responsabilità di salvare lo stato dell'Actor in un sistema di terze parti, questo è OK ma non è necessario. Potresti semplicemente scrivere su un servizio Stateful. Questo servizio può essere interrogato direttamente utilizzando un'API REST di terze parti, ecc. Se necessario.
Si noti che gli attori già gestiscono il loro stato e conservano già 3 copie (configurabili).
Se ritieni di voler mantenere questo stato su un supporto durevole (ad esempio SQL Server, Azure Table Storage o Redis), puoi eseguire il backup dello stato a intervalli regolari.
È piuttosto difficile dire esattamente la motivazione alla base della tua soluzione, ma ho un esempio che ho implementato (usando Akka) che ora sto trasferendo su Service Fabric a causa del sovraccarico che elimina.
- Ho un attore carrello acquisti che può tenere in memoria il carrello di un utente, ottimo perché posso ridimensionarlo all'infinito e il suo stato viene replicato.
In Akka, stavo usando Akka Persistence su MongoDB, ma questo è accompagnato da overhead delle prestazioni di riavvio, ripristino dello stato, gestione di istantanee, ecc. Con Service Fabric, questo overhead va via. Semplicemente non devi preoccuparti dello Stato (entro limiti ragionevoli se non lo corrompi, cioè usa sempre token di cancellazione).
-
Questo attore carrello acquisti controlla l'inventario quando qualcuno vuole acquistare un prodotto (con Akka, stavo verificando l'inventario della memoria persistente nell'archivio mongo).
-
Ora in Service Fabric, l'attore del mio carrello acquisti chiama un
Inventory Actor per un determinato prodotto che sto acquistando per verificare se l'inventario è disponibile.
-
Questo Inventory Actor chiama internamente un servizio stateful che mantiene un dizionario affidabile di inventario. Posso aggiornare facilmente l'inventario senza problemi di threading.
-
A un certo punto, vorrei ottenere il riepilogo dell'inventario di un prodotto (ad esempio quanti in magazzino, quanti venduti ecc.). Per semplificare, aggiorno anche questo Inventario in Redis (non sono sicuro che sia necessario, ma dato che Redis è estremamente veloce, penso che ci potrebbero essere benefici nel mantenere una copia dell'inventario per letture veloci). Tutte le scritture avvengono utilizzando l'Inventory Actor, che a sua volta chiama il servizio Stateful.
Il più grande vantaggio di avere un attore di inventario è che sarà sempre basato su turni. Potrei aver memorizzato l'inventario direttamente nello stato di Inventory Actor, ma ho scelto contro di esso perché potrei voler eventualmente aprire l'inventario per le letture su sistemi diversi.
I servizi di stato ti permettono di farlo. Le letture di inventario basate su turni non avrebbero funzionato molto bene perché stai praticamente aspettando il tuo turno solo per leggere il riepilogo dell'inventario, quindi delegarlo a un servizio Stateful (e Redis) aiuta.
Spero che questo ti dia una certa direzione. Usando questa architettura in Akka sono stato in grado di scalare in modo significativo più che mai immaginato. Con Service Fabric, questo diventerà ancora più semplice in quanto non dovrò preoccuparmi di Gestione cluster, Posizione attore (chiavi di partizione semplice), gestione dello stato ecc.
Speriamo che questo ti fornisca alcune informazioni.
