spinner

¿Qué son los sistemas de actores? Una breve aproximación

Eso, ¿qué son los sistemas de actores? Parece una pregunta fácil pero, como probablemente te imaginas, tiene su complejidad. El concepto de sistemas de actores nació a principios de los 70 para abordar las problemáticas de procesamiento paralelo masivo basado en la programación concurrente. Actualmente, los sistemas de actores se  consideran un paradigma que define una serie de reglas sobre cómo deben comportarse e interactuar los componentes de dicho sistema.

Siguiendo la línea de otros posts del blog de BBVA Next Technologies, en los que damos algunos consejos para  hacer tu día a día más fácil (con posts como el reciente ‘Cinco claves para que tu post sea más legible’, por ejemplo), en este artículo vamos a hablar de los sistemas de actores y cuáles pueden resultarte más útiles según sea tu caso.

Pero empecemos por el principio. Un sistema de actores está formado principalmente por tres componentes:

1. Los mensajes: siempre son asíncronos y contienen información de cualquier tipo.
2.Los buzones: los lugares en los que los actores reciben la información para ser procesada
3.El actor: un proceso, en general sin estado, que se encarga de realizar una acción según la información recibida por el mensaje.

En este artículo vamos a explicar qué son los sistemas de actores y cómo pueden ayudarnos a realizar complejos procesamientos paralelos de manera simple, construir bloques de procesamiento acotados y resilentes, facilitar
las actualizaciones de partes del sistema  (actores de un cierto tipo), mejorar la tolerancia a fallos y permitir de manera simple la adopción de patrones de throttling y circuit breaking para evitar el deterioro de los sistemas.

Ejemplo de un sistema de actores

Por el principio: ¿que es un actor?

Básicamente un actor es un proceso con una dirección. Esta dirección es a la que se envía el mensaje al actor y es equivalente a una dirección de email. Un actor puede tener una o varias direcciones asociadas o bien se puede asignar una única dirección a varios actores.

Además de esto un actor realiza tareas sencillas:

  • Almacena información
  • Procesa información
  • Recibe mensajes de otros actores
  • Envía mensajes a otros actores
  • Crea nuevos actores

Los mensajes que un actor envía a otros son, en general, asíncronos y no se garantiza su orden. Un actor (instancia de) solo procesa un mensaje cada vez, aunque si tenemos varios actores escuchando en la misma dirección se producirá un procesamiento paralelo de mensajes. Cada actor, a su vez, tiene un buzón, al que llegan los mensajes para su procesamiento asíncrono.

Una característica interesante de los sistemas de actores es que son agnósticos del lugar en el que se ejecuta el actor. Es decir, si la implementación del paradigma es lo suficientemente potente, los actores pueden residir en diferentes nodos y el sistema de actores se encargará de enrutar el mensaje al destino esperado.

Todas estas características permiten un escalado horizontal del sistema en un momento dado, por un pico de carga generando nuevos actores distribuidos para atender al mismo y decrecer posteriormente cuando la situación vuelva a la normalidad.

¿Por qué usar sistemas de actores?

Dicho concepto ha tomado fuerza en los últimos tiempos por considerarse una buena solución para microservicios, programación reactiva, event sourcing, domain driven design y especialmente gracias a Spark y el Big Data.

Los sistemas de actores actualmente permiten abordar la tolerancia a fallos usando el patrón reactivo “Let it Crash” para el manejo de fallos. Este “prefiere” que un actor se caiga y realizar posteriormente un reintento (si llegara a tener sentido), en lugar de intentar controlar cualquier caso de error utilizando programación defensiva.

¿Cuándo no se debe usar?

En sistemas que requieran real time o transaccionalidad hay que evaluar si este sistema es el más adecuado para abordar el problema, dado que requerirá de un esfuerzo extra para garantizar requisitos de este tipo.

El componente clave del sistema de actores: el mensaje

Es una unidad básica de información que viaja por el sistema de actores y que implica que el actor que la reciba tenga un cierto comportamiento relativo a la misma. Dicha información puede ser de dos tipos: negocio (contendrá información relativa a procesar y referente a un caso de uso del sistema) y control (indicará al actor que debe realizar una cierta acción como morir, pausarse, lanzar nuevos actores…).

Los buzones, el pegamento que une todo

Los buzones son el punto de entrada de los mensajes al actor correspondiente. Nos permiten controlar el flujo de los mismos que llegan al actor, evitar problemas de bloqueos y descartar ciertos mensajes si fuera necesario. Los buzones se pueden implementar de diferentes maneras dependiendo de nuestras necesidades, por ejemplo:

1. Pueden ser volátiles si no nos importa la posibilidad de perderlos.
2. Apoyarse en un sistema de colas clásico como RabbitMQ si necesitamos por ejemplo evitar pérdida de mensajes.
3. Apoyarse en un sistema de streaming como Kafka si necesitamos en nuestra arquitectura características más avanzadas de este tipo.

Implementaciones

Para cubrir este paradigma actualmente existen dos implementaciones interesantes: AKKA, una implementación para la JVM y que puede ser utilizada principalmente con Java y Scala, y ProtoActor, es una implementación que puede ser utilizada principalmente desde Go y .NET
Es el runtime en el que esta basado Spark y nos proporciona todas las características anteriormente indicadas, así como nos permitirá abordarlas desde el paradigma de programación funcional que nos ofrece Scala.

En el caso de AKKA, esta implementación está bastante madura. Prueba de ello son la gran cantidad de casos de estudio disponibles en la web. Además, para un conocimiento más exhaustivo de cómo funciona este runtime podemos acudir a Typesafe, pues tiene un montón de ejemplos de cómo usarlo.

AKKA logo

Logo de AKKA. Fuente: https://akka.io

 

En lo que respecta a ProtoActor, es otra opción que disponemos para implementar un sistema de actores, el proyecto está fundado por Roger Johansson, el cual estuvo desarrollando la versión .NET de AKKA hasta que decidió salir del proyecto.

proto actor logo

Logo de ProtoActor. Fuente: http://proto.actor

Su enfoque es más sencillo que el de Typesafe y su curva de aprendizaje es menos pronunciada que la de AKKA al no estar tan focalizado en la programación funcional.

¿Que implementación usar?

Dependiendo de tus necesidades de arquitectura puedes decidirte por una u otra. Por un lado, la implementación ProtoActor es más ligera al estar basada en Go y en el hecho de los creadores fueran «mantenedores» de AKKA. Net, asimismo, es una garantía de calidad.

Por otro lado, AKKA dispone de una empresa como Typesafe detrás y una comunidad fuerte desarrollando sobre la plataforma frameworks tan interesantes como Lagom o engines como Spark

Desde mi punto de vista elegiría una implementación u otra dependiendo diferentes factores. Si es complejo o crítico preferiría utilizar algo con una comunidad fuerte detrás como AKKA. Sin embargo, si se trata de un sistema más simple o que requiere apurar el consumo de CPU utilizaría la implementación de ProtoActor.

Conclusión

Los sistemas de actores, como hemos visto, son elementos muy útiles que nos ayudan a resolver problemas complejos y que están viviendo un auge en los últimos años. Con esta breve guía espero haberos aclarado cuáles pueden serviros de más utilidad en función de la situación que tengáis que resolver.

Imagen de portada: Unsplash/Mathyas Kurmann

¿Quieres saber que más cosas hacemos en BBVA Next Technologies?

Utilizamos cookies propias y de terceros para mejorar nuestros servicios, brindarle una grata experiencia y mostrar a los usuarios publicidad relacionada con sus preferencias mediante el análisis de sus hábitos de navegación. Si continúa navegando por este sitio web, consideramos que acepta su uso. Puede cambiar la configuración u obtener más información accediendo a nuestra política de cookies aquí.