C贸digo del ejemplo (GitHub)
AKKA es un toolkit que utiliza el modelo actor para proporcionar una plataforma en la que construir aplicaciones concurrentes y escalables. Adopta el modelo 鈥let it crash鈥 para la tolerancia a fallos, que se usa con gran 茅xito para construir aplicaciones capaces de 鈥auto repararse鈥 en sistemas que nunca se detienen.
Los actores son objetos que encapsulan estados y funciones y que se comunican exclusivamente a trav茅s de mensajes.
Las tareas asignadas a un actor pueden ser descompuestas en tareas m谩s peque帽as que se asignen a otros actores. Para ello, crear谩 nuevos actores hijo a los cuales asignar谩 subtareas y supervisar谩. Cada actor en un sistema tiene un 煤nico padre, el cual es el actor que le ha creado. Todos los actores de un sistema son susceptibles de crear hijos a los que pasar谩n a supervisar autom谩ticamente.
Cuando el actor termina su tarea, notifica al padre que esta est谩 terminada. Si ocurre un error, tambi茅n el padre es notificado del mismo. En este caso, el padre tiene distintas opciones, entre las que est谩 reiniciar o parar el actor hijo o escalar el fallo. Todo depende del comportamiento deseado.
Toda la vida del actor ocurre dentro de un sistema de actores. Este sistema proporciona el entorno necesario para crear y ejecutar actores, as铆 como para mantener una referencia a ellos. Tambi茅n es responsable de la creaci贸n del primer actor, /user: 鈥the guardian actor鈥, que ser谩 el padre de nuestros actores. Aunque este es nuestro 鈥減unto de entrada鈥 al sistema de actores, existen otros actores que el sistema crea.
Como he mencionado, toda comunicaci贸n con un actor se realiza a trav茅s de mensajes. Estos se comparan con la actual definici贸n de funciones que tiene el actor para buscar la que se corresponda con el mensaje y ser谩 esa la ejecutada.
El actor dispone de una cola donde llegan los mensajes (Mailbox) y este nos asegura que los mensajes ser谩n ejecutados por el actor en el mismo orden en que fueron encolados. Esta cola permite que no exista una dependencia entre actores, ya que la comunicaci贸n es totalmente as铆ncrona.
Uno de los mayores retos a la hora de usar AKKA es la definici贸n de la arquitectura de actores que se usar谩. Normalmente, a la hora de definir la funcionalidad de un sistema, se har铆a a trav茅s de la definici贸n de una serie de m茅todos en una interfaz para despu茅s completarlos mediante su implementaci贸n.
Cuando usamos actores, no podemos definir una API al uso y, para definir el comportamiento de nuestra aplicaci贸n, deberemos usar una serie de 鈥減rotocolos鈥 en lugar de interfaces. Estos protocolos est谩n compuestos por los mensajes que un actor est谩 capacitado para procesar y por los que el actor emitir谩.
Normalmente, los mensajes se agrupan por categor铆as o patrones. Resulta m谩s f谩cil as铆 elegir entre ellos. Estos mensajes se suelen definir como clases internas est谩ticas y finales con acceso p煤blico (public static final class), as铆 es m谩s f谩cil reconocer el protocolo de cada actor de un sistema.
Los mensajes enviados entre actores en AKKA utilizan una caracter铆stica de env铆o conocida por at-most-once-delivery (al menos se env铆a una vez). Esta caracter铆stica asegura que todos los mensajes ser谩n enviados 0 o 1 vez exactamente. Esto es, los mensajes pueden perderse, pero nunca duplicarse.
Esta caracter铆stica permite una f谩cil implementaci贸n y un alto rendimiento frente a otras como at-least-once-delivery o exactly-once-delivery.
Tiene una menor sobrecarga de implementaci贸n porque puede usarse el conocido como fire-and-forget sin necesidad de mantener el estado del receptor o en el mecanismo de transporte.
Como conclusi贸n, indicar que este tipo implementaciones puede ser interesante en entornos donde la escalabilidad y la disponibilidad de los sistemas (resilencia) son puntos muy importantes, pero llevarlos a entornos donde esas premisas no sean cr铆ticas puede ocasionar m谩s problemas que soluciones aporta. En este enlace pod茅is encontrar el c贸digo fuente de una peque帽a POC que se ha realizado para acompa帽ar a este post.
Es una simple aplicaci贸n que registra una serie de valores burs谩tiles y permite su consulta. El sistema no entra a exponer c贸mo recuperar los valores burs谩tiles, simplemente estos (un peque帽o conjunto de ellos) son cargados en el arranque del sistema. Tambi茅n expone, como parte de su protocolo, los mensajes necesarios para el registro de un nuevo valor o la actualizaci贸n de uno ya existente.
Otra de las funciones expuestas por su protocolo es, claro est谩, la consulta de la cotizaci贸n de un determinado valor. Para ello, tiene definidos dos mensajes, el de consulta y su respuesta.
Todo ello est谩 integrado en una aplicaci贸n construida con Springboot y expuesto a trav茅s de unos simples m茅todos REST. Aunque este 鈥渆nvoltorio鈥 puede ocasionar algo de ruido a la hora de exponer un simple ejemplo con AKKA, lo hemos cre铆do m谩s oportuno que mostrarlo a trav茅s de una clase main.