Qual è la differenza tra il modello di attore e Microservices?

Modello di attore - è un modello matematico per calcoli concorrenti e microservizi: un'implementazione dell'architettura orientata ai servizi. Le somiglianze sono abbastanza coincidenti.

È certamente possibile costruire microservizi basati su alcuni modelli di attori e modellare l'architettura di microservizi con il modello di attore, ma ciò non significa che siano equivalenti. Sostituisci "microservice system" con "email system", e sarà ancora vero. Sostituisci "actor model" con "Communicating sequential processes" (CSP), e sarà anche "true", perché i sistemi di modelli CSP e degli attori possono essere modellati l'uno dall'altro.

Dato un modello di attore puoi andare e implementarlo usando microservizi, SOA, o anche email, ma ciò non significa che siano allo stesso livello di astrazione per confrontarli veramente.

Inoltre, il modello di attore enfatizza i buffer (può essere pensato come code di messaggi nel mondo dei microservizi), quindi alcuni attori / microservizi possono non essere pronti mentre la comunicazione intrinseca asincrona è ancora possibile.

In altre parole, il confronto con il modello di attore può portare a intuizioni creative ad un livello molto elevato di considerazione, ma principalmente è mele contro arance.

Se l'obiettivo è quello di confrontare il modello matematico di SOA / microservizi con il modello di attore, allora anche non banale, perché: 1) non esiste un modello matematico per SOA, 2) di solito concordato include lo scopo. E la modellazione SOA / microservizi è molto probabile che sia diversa dallo scopo del modello di attore. Un esempio di tentativo di modellare SOA qui .

Naturalmente, è possibile creare un sistema modello di attore con microservizi e chiamare ogni servizio un attore (fare riferimento alla definizione rigorosa di quale modello di attore è). Ma questo non significa che ci sia una relazione significativa tra i due in senso generale.

I microservizi sono un modo per organizzare il software suddividendo ogni area di interesse nel proprio artefatto deployable (eseguibile, script, JAR, WAR, ecc.). Ciò ti dà flessibilità, ad esempio consentendoti di ridimensionare distribuendo più istanze dove sono necessarie. Supponiamo che gli utenti trascorrano più tempo a guardare il tuo catalogo piuttosto che aggiungere cose a un carrello della spesa; un artefatto deployable gestisce le funzioni del catalogo, un altro gestisce le funzioni del carrello degli acquisti - è possibile eseguire più copie dei servizi del catalogo per gestire il carico.

Li isola anche dai cambiamenti interni. Supponiamo che tu passi da un database relazionale a un database di documenti per archiviare i dati di prodotto - è probabile che i servizi del tuo carrello acquisti non debbano cambiare.

Il modello dell'attore è un livello inferiore rispetto alla risorsa utilizzabile, più sui tipi di oggetti con cui hai implementato il servizio. Continuando con l'esempio precedente, potresti avere i carrelli della spesa nel tuo sistema rappresentati da attori, quindi il carrello di ogni utente è un attore distinto ei messaggi dicono di aggiungere elementi, rimuovere elementi, rispondere ai contenuti correnti, aggiungere spese di spedizione, check out , ecc. In questo caso, hai ancora un microservizio, ed è implementato con il modello degli attori.

Direi che la differenza principale è di granularità.

Per il modello di attore è relativamente a grana fine, in quanto un attore tende a rappresentare l'equivalente di un oggetto in OOP.

Per i micro-servizi è relativamente grossolana, in quanto un singolo micro-servizio può consistere in un gran numero di attori o oggetti.

Nota che non avresti davvero bisogno di allungare troppo la tua immaginazione per dire che il web moderno è la stessa cosa in una granularità ancora più grande ("macro-servizi"); e che (ad esempio) un server HTTP è un servizio macro, un server database è un servizio macro, un browser web è un servizio macro, ecc.

È tutto più o meno lo stesso - pezzi isolati che comunicano. Sono solo le dimensioni dei pezzi (e quindi il numero di pezzi) che cambiano.

Microservices scala orizzontalmente creando più repliche, ognuna delle quali è in grado di servire le richieste a causa della natura stateless del servizio. Sono resistenti al fallimento in virtù della loro natura apolide.

Scala degli attori spostandoli in partizioni con meno carico o più risorse disponibili. Sono stateful . Sono resilienti al fallimento perché - a seconda del framework dell'attore - un altro attore può essere attivato dinamicamente o un backup hot dell'attore può essere mantenuto in ogni momento per gestire l'errore del protagonista primario.

Anche in questo caso, i microservizi potrebbero essere stateful, ma vanno contro i principi di progettazione dei microservizi.