Hack & beers lleida seguridad en desarrollo fullstack
Desarrollando aplicaciones reactivas con Akka y Scala
1.
2.
3.
4. El modelo de actores
• Modelo matemático de computación concurrente
• Su primitiva es el Actor
• Unidad fundamental de computación o cómputo
• Basado en comunicaciones asíncronas
• “La motivación era la posibilidad de realizar procesamiento paralelo
masivo en docenas, cientos o miles de microprocesadores, cada
uno con su memoria local y procesador de comunicaciones,
capaces de comunicarse a través de una red de alta velocidad”
5. El modelo de actores
• Su filosofía, todo es un actor.
• Un actor
• Procesa
• Almacena
• Comunica
• Un actor actúa frente al estímulo de un mensaje. Axiomas:
• Crear nuevos actores
• Enviar mensajes a actores conocidos
• Cambiar su comportamiento para el siguiente mensaje
• Desacoplar el mensajero del receptor, fue el avance fundamental del
modelo
• Todo comunicación es asíncrona
• El receptor es identificado a través de una dirección
6. El modelo de actor
• Erlang adopta el modelo de actores
• Un actor es una abstracción de concurrencia
• Threads
• Locks
• Un mensaje a la vez
• Una solución para el desafío de la programación multicore
• Comunicación asíncrona a través de mensajes
• Como la comunicación es asíncrona, poseen un mailbox para recibir mensajes
• Pattern Matching de mensajes
• Un actor mantiene su estado de manera interna
• Estado cambiable (Mutable state) es privado
• Estado compartido no puede ser cambiado (immutable shared state)
• Puede cambiar su estado a través de mensajes
7. Scala es un lenguaje de programación multi-
paradigma, diseñado para expresar patrones comunes de
programación en forma concisa, elegante y con tipos
seguros. Integra características de lenguajes
funcionales y orientados a objetos. Corre sobre la
JVM y es compatible con las aplicaciones JAVA.
2003
object HolaMundo {
def main(args: Array[String]) = println("Hola mundo")
}
10. Jonas Bonér, creador del proyecto AKKA, que
cumplió 5 años, el 12 de Julio de 2014
Nace como un intento de portar Erlang OTP a Scala
11. AKKA
• Diosa de la fertilidad, de la fuerza, de la sexualidad
femenina y de las cosechas en la mitología finlandesa y
lapona
• Casada con Ukko
• Se decía que cuando copulaba con su marido se provocaba
la lluvia en la tierra.
• Se le invocaba también para ritos de magia y canalización.
• Era también el nombre que se utilizaba para cualquier
espíritu femenino tanto en la mitología finlandesa como la
lapona.
12. Akka es un framekork y un ambiente de ejecución, para desarrollar
aplicaciones con alta concurrencia, distribuidas, resilientes y
basadas en mensajes, en la JVM
14. Como funciona un actor
ActorSystem ActorRef
MessageDispatcher
Mailbox ActorMessageQueue
Invoca
Recupera
el mensaje
Ejecuta
Publica el
mensaje
Despacha
Crea
16. Consideraciones
• No bloquear, no bloquear, no bloquear
• Usar Futures para código bloqueante
• Aísla el problema de la concurrencia, para escalar crear instancias
múltiples
• Recordar es un mensaje a la vez
• Deben seguir el principio de responsabilidad única
• Son a prueba de fallas
• Supervisores (Más adelante)
17. Rápido y Furioso 50 millones de msj/seg en una
máquina
Bajísimo uso de memoria;
~2.5 millones de actores por
cada GB de heap
1000 nodos en cluster < 4
minutos en GCP. Pruebas
sobre 2400 nodos.
19. Tipos de aplicaciones
• Domain Driven
/
Cliente 1 Cliente 2
Cuenta Corriente Tarjeta de Crédito
Crédito
Hipotecario
Cuenta Corriente
20. Tipos de aplicaciones
• Trabajo distribuido
• Típicamente los actores son sin estado
• El uso de routers, permite distribuir la carga entre distintas
instancias de actores y el enrutamiento
• Groups y Pools (Ver clusters)
25. Routers
• ScatterGatherFirstCompletedOf
• Se envía el mensaje a todas las instancias, pero solo la primera respuesta
es recibida, el resto se descarta.
• Consistent hash routing
• Permite seleccionar la instancia de acuerdo a un hash.
• Por ejemplo permite enviar a un actor cercano y así evitar latencia.
• BalancingDispatcher
• Obsoleto !!!!
26. Event Bus
“Actor”
Productor
“Actor”
Tópico
“Actor”
Suscriptor
“Actor”
Suscriptor
“Actor”
Suscriptor
1
1
1
Mensajes no eventos
Eventos son “hechos” que
se publican en un tópico
Los sistemas basados en
eventos, se focalizan en
fuentes de eventos
direccionables.
Un mensaje siempre tiene
un receptor específico,
puede ser un actor, un
tópico o alguna otra cosa
Un mensaje puede
tener como contenido,
un evento (payload).
Los sistemas basados en
mensajes, se focalizan en
receptores direccionables.
2
27. Supervisor
• Es el mecanismo para resiliencia o tolerancia a
fallas
• Basado en excepciones
• Un supervisor puede:
• Escalar (Scalate)
• Continuar (Resume)
• Reiniciar (Restart)
• Detener (Stop)
• … un actor
• Y un supervisor es…, un actor
28. Supervisor
• Existen una estrategia por omisión
• Escalar se usa si la estrategia definida no maneja la excepción
• Cuando no existe una estrategia para el supervisor las
siguientes excepciones son controladas por omisión:
• ActorInitializationException detiene el actor hijo fallido
• ActorKilledException detiene el actor hijo fallido
• Exception reinicializa el hijo actor fallido.
• Otro tipo de excepciones descendientes de Throwable son
propagadass al actor padre hasta llegar a la raíz, donde sino existen
otras estrategias se ocupa la por omisión.
30. Cluster
• Nodo (Member Node)
• Un miembro lógico del cluster
• Varios nodos por máquina
• Definido por hostname:port:uid
• Membresía (Membership). Un conjunto de nodos agrupados a través del
servicio de membresía.
• Líder. Nodo único que actúa como líder, administra la convergencia del
cluster y las transiciones de estados de membresía.
• Semilla (Seed Node). Las semillas son los puntos de contacto para los
nuevos nodos que se unen al cluster.
• Gossip. La membresía del cluster está basada en Dynamo / Ryak. La
membresía es comunicada utilizado un protocolo Gossip (“Copuchento”),
donde el estado es diseminado de manera aleatoria, con preferencia a los
miembros que no han visto la última versión
31. Become
• “Cambiar su comportamiento para el siguiente mensaje”
class Bipolar extends Actor {
import context._
def enojado: Receive = {
case "foo" => sender() ! ”Ya estoy enojado :-|"
case "bar" => become(feliz)
case _ => unbecome()
}
def feliz: Receive = {
case "bar" => sender() ! ”Ya esto feliz :-)"
case "foo" => become(enojado)
case _ => unbecome()
}
def receive = {
case "foo" => become(enojado)
case "bar" => become(feliz)
}
}