Ambos parecen una red de procesos de comunicación MPI paralela. Identifico actores con servicios. ¿Son los actores más dinámicos (puede crearlos y matarlos como respirando mientras que la red de servicios es más estática) o qué?
Respuestas:
Modelo de actor: es un modelo matemático para cálculos concurrentes y microservicios, una implementación de arquitectura orientada a servicios. Las similitudes son bastante casuales.
Ciertamente es posible construir microservicios basados en algún modelo de actor y modelar alguna arquitectura de microservicio con modelo de actor, pero eso no significa que sean equivalentes. Reemplace "sistema de microservicio" con "sistema de correo electrónico", y seguirá siendo cierto. Reemplace el "modelo de actor" con "Comunicando procesos secuenciales" (CSP), y también será "verdadero", porque los sistemas de modelo de actor y CSP pueden ser modelados entre sí.
Dado el modelo de actor, puede ir e implementarlo utilizando microservicios, SOA o incluso correo electrónico, pero eso no significa que estén en el mismo nivel de abstracción para comparar realmente.
Además, el modelo de actor enfatiza los búferes (puede considerarse como colas de mensajes en el mundo de los microservicios), por lo que algunos actores / microservicios pueden no estar listos mientras la comunicación inherentemente asíncrona todavía es posible.
En otras palabras, la comparación con el modelo de actor puede aportar algunas ideas creativas a un nivel muy alto de consideración, pero principalmente son manzanas frente a naranjas.
Si el objetivo es comparar el modelo matemático de SOA / microservicios con el modelo de actor, tampoco es trivial, porque: 1) no existe un modelo matemático acordado para SOA, 2) el modelo generalmente incluye el propósito. Y es muy probable que el modelado de SOA / microservicios sea diferente del propósito del modelo de actor. Un ejemplo de intento de modelar SOA aquí .
Por supuesto, uno puede crear un sistema de modelo de actor con microservicios y llamar a cada servicio un actor (consulte la definición estricta de qué modelo de actor es). Pero esto no significa que haya una relación significativa entre los dos en sentido general.
Los microservicios son una forma de organizar el software dividiendo cada área de interés en su propio artefacto desplegable (ejecutable, script, JAR, WAR, etc.). Esto le brinda flexibilidad, por ejemplo, al permitirle escalar implementando más instancias donde sean necesarias. Digamos que los usuarios pasan más tiempo mirando su catálogo que agregando cosas a un carrito de compras; un artefacto desplegable maneja las funciones del catálogo, otro maneja las funciones del carrito de compras: puede ejecutar más copias de los servicios del catálogo para manejar la carga.
También los aísla de los cambios internos. Supongamos que pasa de una base de datos relacional a una base de datos de documentos para almacenar datos de productos; es probable que los servicios de su carrito de compras no tengan que cambiar.
El modelo de actor es un nivel más bajo que el artefacto desplegable, más sobre qué tipos de objetos ha implementado el servicio. Continuando con el ejemplo anterior, puede tener los carritos de compras en su sistema representados por actores, por lo que el carrito de cada usuario es un actor distinto, y los mensajes le dicen que agregue elementos, elimine elementos, responda con el contenido actual, agregue envío, eche un vistazo , etc. En este caso, todavía tiene un microservicio y se implementa con el modelo de actor.
Yo diría que la principal diferencia es la granularidad.
Para el modelo de actor es relativamente fino, ya que un actor tiende a representar el equivalente de un objeto en OOP.
Para los microservicios es relativamente de grano grueso, ya que un solo microservicio puede consistir en una gran cantidad de actores u objetos.
Tenga en cuenta que realmente no necesitaría extender su imaginación demasiado para decir que la web moderna es exactamente lo mismo con una granularidad aún mayor ("macro-servicios"); y que (por ejemplo) un servidor HTTP es un macro servicio, un servidor de base de datos es un macro servicio, un navegador web es un macro servicio, etc.
Es casi lo mismo: piezas aisladas que se comunican. Solo cambia el tamaño de las piezas (y, por lo tanto, el número de piezas).
Los microservicios se escalan horizontalmente creando múltiples réplicas, cada una de las cuales es capaz de atender solicitudes debido a la naturaleza sin estado del servicio. Son resistentes al fracaso en virtud de su naturaleza apátrida.
Los actores escalan moviéndolos a particiones con menos carga o más recursos disponibles. Son con estado . Son resistentes al fracaso porque, dependiendo del marco del actor, otro actor podría hacerse girar dinámicamente o se podría mantener una copia de seguridad del actor en todo momento para lidiar con el fracaso del actor principal.
Una vez más, los microservicios también pueden tener estado, pero va en contra de los principios de diseño de los microservicios.