¿Qué es akka? ¿Cómo se puede explicar de manera simplista? ¿Por qué es importante para crear aplicaciones web?

Para comprender akka, primero debe comprender el modelo de actor (aunque, tenga en cuenta que el kit de herramientas de Akka contiene mucho más que solo actores. También tiene agentes, agrupación y, a partir de 2.4.2, una implementación de flujos reactivos y un http biblioteca).

Los actores son unidades de computación, y usted se comunica con ellos a través de mensajes. Cada actor tiene cierta lógica comercial local, pero es más o menos una caja negra para el código externo. Puede enviar mensajes a un actor o recibir un mensaje de un actor, pero no puede acceder directamente a su lógica interna. Se ve algo como esto

De acuerdo, no del todo, imagina una versión robótica perfecta de eso.

Cada actor tiene un buzón que es tanto una cola como un policía de tráfico. Los mensajes son enviados por otros actores y pueden acumularse en la cola, pero exactamente un mensaje puede ingresar al bloque lógico de un actor. Eso significa que el código dentro del actor está protegido contra problemas de concurrencia.

Eso, por supuesto, significa que todos los demás tendrán que esperar hasta que sea su turno para que se procese su mensaje (en el diagrama anterior, si Brad recibe mensajes de Angelina y Jennifer, los leerá en el orden recibido, uno por vez ) Eso puede estar bien en algunos casos (piense en una secuencia, donde necesita un orden predecible).

Si necesita un procesamiento paralelo, lo más probable es que necesite un grupo de actores (el club de fans de Brad probablemente sea manejado por más de un actor) que pueda procesar los mensajes dirigidos a Brad. Cuando usa un grupo de actores, puede tener un solo buzón (el buzón del club de fans) atendido por múltiples actores, pero aún así solo un mensaje puede ingresar a cualquier actor (asistente).

Dado que la comunicación se realiza a través de mensajes asincrónicos, puede escalar dando forma a las colas de mensajes (agregando más horas de trabajo), agregando más actores a sus grupos (contratando más asistentes) o controlando la contrapresión (cuánto correo se entrega).

Los actores son generalmente baratos, y no es raro que las aplicaciones tengan cientos de miles de actores en un momento dado.

Si desea participar en una discusión sobre los actores en general, puede obtenerlo de la boca del caballo:

Hewitt, Meijer y Szyperski: The Actor Model (todo lo que quería saber, pero tenía miedo de preguntar) (Canal 9)

Akka es tanto un principio de diseño como una plataforma de concurrencia.

Para usar Akka, debe escribir su aplicación en el patrón Actor, lo que significa que todo debe ser inmutable. No hay métodos a los que recurras en objetos externos, pero les pasas un objeto a tus actores. La mayoría de las veces, se utiliza una clase de caso para esto. Además, no tendrá acceso a la clase subyacente de un actor. Lo único que obtienes es un ActorRef al que puedes enviar tus mensajes. No es posible tirar. Solo empujando.

¿Por qué es esta una mejor plataforma de concurrencia? No implica el bloqueo que elimina el problema de bloqueo. Además, los actores son muy baratos y no tienen hilos. Es decir, un Actor puede vivir de cualquier Hilo que quiera y no desperdicie hilos. Entonces, si un actor no está manejando un mensaje, no ocupa un hilo. Además de eso, es realmente escalable, tanto en núcleos como en varias máquinas.

Un simple ExecutionContext estaría durmiendo en contraste con tus actores. Con los actores, cada actor solo debe tener una responsabilidad, esto tiene que ver con una cadena de supervisión que no cubriré ahora. Eso puede ser demasiado difícil por ahora.

La respuesta de Simon es excelente, pero usted pidió una explicación simplista por la cual supongo que se refiere a conciso. Espero poder ser conciso sin simplificar demasiado.

Akka se basa en un Actores que se construyen en una jerarquía de padres a hijos, etc. Puede saber dónde dirigir un mensaje si conoce la ruta desde el padre hacia abajo. Cada actor tiene su propio URI que es independiente de donde reside físicamente. akka: // body / arm / hand / thumb podría ser una estructura de este tipo. Esto también divorcia el direccionamiento en los actores de su ubicación física real. Mi robot puede tener controladores separados para el cuerpo, el brazo, la mano y el pulgar que se comunican a través de CAN, TCP y / o bluetooth, pero como programador que habla a través de los actores, no necesito preocuparme por eso.

Cada interacción con los actores es a través de mensajes y los hilos se ocultan perfectamente fuera de la vista. Todos los mensajes son asíncronos en relación con los hilos que ejecutan su código.


Esa es una descripción simple y detalles de glosses y omisiones.

Como Simon señala en su respuesta más completa, el enhebrado basado en actores facilita el desarrollo en gran medida.

Su pregunta es ¿por qué es importante construir aplicaciones web? La respuesta es que es más una tecnología de nivel empresarial que una tecnología de nivel web. Akka se puede ver en dos niveles: la biblioteca principal de actores y la plataforma.

La parte central es la biblioteca estándar de concurrencia de patrones de actor para el lenguaje Scala que reemplaza el paquete “scala.actors.Actor” ahora en desuso. Básicamente, cualquier software jvm puede programar con mensajes inmutables que pasan como abstracción para la concurrencia utilizando la biblioteca central de akka y puede beneficiarse de patrones claros y utilidades de cómo escribir dicho programa. Es liviano con muy pocas dependencias y puede integrarse en cualquier aplicación jvm para usarlo como una biblioteca de concurrencia avanzada. Como desarrollador, envuelve su lógica en actores que se envían mensajes entre sí sin usar bloqueos o métodos sincronizados de programación concurrente tradicional. (Editar: vea los últimos párrafos para algunos de los problemas de la programación concurrente tradicional).

Luego está akka la plataforma. Todavía programas en actores pero obtienes mucho más. Despliega a sus actores iniciando servidores a través de la configuración y obtiene agrupaciones y puede escalar su procesamiento en muchos servidores. La plataforma utiliza netty para el transporte de red y los servidores se envían mensajes entre sí y tratan con servidores que se bloquean o se unen al clúster. Obtiene integración con los servicios de mensajería y las bibliotecas de procesamiento de archivos por lotes a través de algo como apache camel. Por lo tanto, puede construir una plataforma de procesamiento de datos grandes o el backend a un sitio grande usando la plataforma akka.

La misma compañía TypeSafe que está detrás de OpenSouce Akka también está detrás de OpenSource Play! marco web Entonces, si escribes una aplicación web, ¡usarías Play! como el marco web y un clúster de akka para alojar su lógica de negocio de escala detrás de él. Eso es si quieres ir todo con la pila TypeSafe. (Editar: cualquier servlet java podría hablar con un sistema akka con unas pocas líneas de código, pero seamos sinceros, si vas a lo grande con un nuevo backend akka vas a estar en condiciones de utilizar un marco web moderno sin bloqueo con integración aparentemente sin sentido .)

Si usted es más un desarrollador web tipo roll-your-own, entonces podría usar socko como el servidor web basado en akka y usar json a través de sockets web desde el navegador al servidor. Socko es básicamente un servidor web construido a partir de la biblioteca principal de akka que utiliza netty como capa de transporte web. Luego, envía mensajes json entre el código de su navegador y los actores del lado del servidor que envuelven su lógica empresarial. Echa un vistazo a esta aplicación de demostración de scrum poker https://github.com/simbo1905/spr … que es una aplicación web akka simple y mínima escrita en Scala como actores Akka con sockets web HTML5 que hacen que todo “todo es un mensaje” sea muy natural, lo que hace que la programación con actores muy naturales. (Editar: si estaba creando una aplicación móvil nativa, entonces Websockets to Socko ahora es muy viable. Esa demostración hace sondeos donde el navegador no es compatible con Websockets, pero son solo las aplicaciones de Android de dos años de antigüedad donde necesita la solución para que se elimine gradualmente el próximo año.)

(Editar: Olvidé decir por qué deberías usarlo. Se sabe que la programación de simultaneidad es muy difícil. El manejo de errores es difícil en todos los hilos. El registro de todos los datos en los hilos es difícil. Evitar la contención en los bloqueos es difícil. Ver lo que realmente está sucediendo en el sistema en ejecución es difícil. Deadlock y livelock bajo carga son difíciles de reproducir y difíciles de arreglar. Tener a alguien que informe un error de concurrencia en su sistema es lo más aterrador y puede equivaler a cancelar sus vacaciones y reescribir su código como emergencia para sacúdete un bicho duro. Goggle “heisenbug” y aprende a temerlos. Akka no es mágico y aún puedes terminar con un bicho en el que un mensaje solo circula en círculos entre tus actores y nunca se procesa como una forma de bicho livelock. Sin embargo, ese es un “error en banda” en su flujo de datos, que es la forma principal en la que programa más fácil de encontrar. Akka eleva el listón de cuánta funcionalidad concurrente podemos construir antes de alcanzar un nivel de complejidad donde los problemas difíciles comienzan a morder nosotros. En ese sentido, es un cambio de juego.

Dicho esto, ya lo he visto aplicado una vez donde no era la herramienta correcta para el trabajo. En mi humilde opinión, si necesita una herramienta para usar los 16 núcleos en todos sus servidores en una gran granja de servidores, vale la pena aprender Scala para poder usar todas las funciones avanzadas de akka; tal como lo hice)