Entrambi sembrano paralleli MPI che comunicano rete di processi. Identifico gli attori con i servizi. Gli attori sono più dinamici (puoi crearli e ucciderli come respiri mentre la rete di servizi è più statica) o cosa?
Risposte:
Modello di attore - è un modello matematico per calcoli simultanei e microservizi - un'implementazione dell'architettura orientata ai servizi. Le somiglianze sono abbastanza casuali.
È certamente possibile creare microservizi basati su un modello di attore e modellare un'architettura di microservizi con un modello di attore, ma ciò non significa che siano equivalenti. Sostituisci "microservice system" con "email system", e sarà comunque vero. Sostituisci "modello attore" con "Comunicare i processi sequenziali" (CSP) e sarà anche "vero", perché i sistemi CSP e i modelli di attore possono essere modellati l'uno dall'altro.
Dato il modello di attore puoi andare e implementarlo usando microservizi, o SOA o persino e-mail, ma ciò non significa che siano allo stesso livello di astrazione per confrontare veramente.
Inoltre, il modello di attore enfatizza i buffer (possono essere pensati come code di messaggi nel mondo dei microservizi), quindi alcuni attori / microservizi possono non essere pronti mentre è ancora possibile una comunicazione intrinsecamente asincrona.
In altre parole, il confronto con il modello di attore può portare ad alcuni spunti creativi con un livello di considerazione molto elevato, ma principalmente si tratta di mele vs arance.
Se l'obiettivo è quello di confrontare il modello matematico di SOA / microservizi con il modello di Actor, anche questo non è banale, perché: 1) non esiste un modello matematico concordato per SOA, 2) il modello solitamente include lo scopo. E la modellazione SOA / microservizi è molto probabilmente diversa dallo scopo del modello dell'attore. Un esempio di tentativo di modellare SOA qui .
Naturalmente, si può creare un sistema modello attore con microservizi e chiamare ogni servizio un attore (fare riferimento alla definizione rigorosa di cosa sia il modello attore). Ma ciò non significa che esista una relazione significativa tra i due in senso generale.
I microservizi sono un modo per organizzare il software suddividendo ciascuna area di interesse nel proprio artefatto distribuibile (eseguibile, script, JAR, WAR, ecc.). Ciò ti offre flessibilità, ad esempio consentendoti di ridimensionare distribuendo più casi in cui sono necessari. Supponiamo che gli utenti trascorrano più tempo a guardare il tuo catalogo che ad aggiungere cose a un carrello della spesa; un artefatto distribuibile gestisce le funzioni del catalogo, un altro gestisce le funzioni del carrello: è possibile eseguire più copie dei servizi di catalogo per gestire il carico.
Inoltre li isola dalle modifiche interne. Supponi di passare da un database relazionale a un database di documenti per l'archiviazione dei dati dei prodotti: è probabile che i servizi del carrello non debbano cambiare.
Il modello dell'attore è di livello inferiore rispetto al manufatto distribuibile, più sui tipi di oggetti con cui hai implementato il servizio. Continuando con l'esempio sopra, potresti avere i carrelli della spesa nel tuo sistema rappresentati da attori, quindi ogni carrello dell'utente è un attore distinto e i messaggi gli dicono di aggiungere articoli, rimuovere articoli, rispondere con i contenuti attuali, aggiungere spedizione, check out , ecc. In questo caso, hai ancora un microservizio ed è implementato con il modello dell'attore.
Direi che la differenza principale è la granularità.
Per il modello dell'attore è relativamente a grana fine, in quanto un attore tende a rappresentare l'equivalente di un oggetto in OOP.
Per i micro-servizi è relativamente a grana grossa, in quanto un singolo micro-servizio può consistere in un gran numero di attori o oggetti.
Nota che non avresti davvero bisogno di estendere troppo la tua immaginazione per dire che il web moderno è esattamente la stessa cosa con una granularità ancora maggiore ("macroservizi"); e che (ad es.) un server HTTP è un servizio macro, un server di database è un servizio macro, un browser web è un servizio macro, ecc.
È più o meno la stessa cosa: pezzi isolati che comunicano. È solo la dimensione dei pezzi (e quindi il numero di pezzi) che cambia.
I microservizi si ridimensionano orizzontalmente creando più repliche, ognuna delle quali è in grado di soddisfare le richieste a causa della natura apolide del servizio. Sono resistenti al fallimento in virtù della loro natura apolide.
Gli attori scalano spostandoli in partizioni con meno carico o più risorse disponibili. Sono di stato . Sono resistenti al fallimento perché - a seconda della struttura dell'attore - un altro attore potrebbe essere girato in modo dinamico o un backup caldo dell'attore potrebbe essere mantenuto in ogni momento per far fronte al fallimento dell'attore principale.
Anche in questo caso, i microservizi potrebbero anche essere dichiarati, ma vanno contro i principi di progettazione dei microservizi.