Buen caso de uso para Akka [cerrado]


605

He escuchado muchas delirios sobre el marco de Akka (plataforma de servicio Java / Scala), pero hasta ahora no he visto muchos ejemplos reales de casos de uso para los que sería bueno. Por lo tanto, me interesaría saber acerca de las cosas que los desarrolladores lo han utilizado con éxito.

Solo una limitación: no incluya el caso de escribir un servidor de chat. (¿por qué? ya que esto se ha usado en exceso como ejemplo para muchas cosas similares)


10
¿No es más fácil comenzar con el problema y encontrar una solución para él, que tener una solución y buscar un problema para aplicarlo? Supongo que, en lugar de usar RMI, Akka y sus actores parecen mucho más fáciles / más simples para escribir código.
Kennet

67
Sí, si tuviera un problema específico que resolver. No estoy buscando una "excusa para usar Akka" de ninguna manera, pero estoy interesado en aprender un poco más. Esto también puede ayudar a resolver problemas futuros, pero principalmente es para el proceso de aprendizaje continuo.
StaxMan

Hay una pregunta relacionada, pero sobre la aplicación de AKKA para la aplicación existente + algunos casos de uso: stackoverflow.com/questions/16595685/…
ses

2
Akka es una mejor solución sobre JMS o un sistema de colas de mensajes distribuidos estilo MQ. Esa es la mejor manera de entenderlo por mí mismo, quien recientemente hizo exactamente la misma pregunta: "Entiendo cómo usarlo y ver dónde podría usarlo, pero no puedo ver dónde esto proporcionaría una ventaja real". Los supuestos centrales de diseño detrás de Akka son mucho mejores que aquellos detrás de JMS / MQ, específicamente en relación con el aislamiento del proceso, el diseño sin bloqueo y el manejo de reintentos / fallas. En segundo lugar, la API es mucho más elegante que las herramientas JMS / MQ.
user2684301

2
@ usuario2684301 hmmh. Encuentro que la respuesta es un poco injusta, en forma de manzanas a naranjas. Los MQ son (lógicamente) bloques de construcción simples que hacen mucho menos que Akka, y no los compararía lado a lado. Pero supongo que si lo leo como "en comparación con los sistemas distribuidos creados con JMS, escritos de forma declarativa", entonces tendría más sentido.
StaxMan

Respuestas:


321

Lo he usado hasta ahora en dos proyectos reales con mucho éxito. ambos están en el campo de información de tráfico casi en tiempo real (tráfico como en automóviles en autopistas), distribuidos en varios nodos, integrando mensajes entre varias partes, sistemas de backend confiables. Todavía no tengo la libertad de dar detalles sobre los clientes, cuando obtenga la autorización, tal vez se pueda agregar como referencia.

Akka realmente ha avanzado en esos proyectos, a pesar de que comenzamos cuando estaba en la versión 0.7. (estamos usando scala por cierto)

Una de las grandes ventajas es la facilidad con la que puede componer un sistema a partir de actores y mensajes casi sin repeticiones, se escala extremadamente bien sin todas las complejidades del enhebrado enrollado a mano y obtiene mensajes asincrónicos que pasan entre objetos casi de forma gratuita.

Es muy bueno para modelar cualquier tipo de manejo de mensajes asíncronos. Preferiría escribir cualquier tipo de sistema de servicios (web) en este estilo que cualquier otro estilo. (¿Alguna vez ha intentado escribir un servicio web asíncrono (lado del servidor) con JAX-WS? Eso es mucha plomería). Entonces, diría que cualquier sistema que no quiera colgarse en uno de sus componentes porque todo se llama implícitamente usando métodos sincrónicos, y ese componente se está bloqueando en algo. Es muy estable y la solución de supervisor let-it-crash + a la falla realmente funciona bien. Todo es fácil de configurar mediante programación y no es difícil realizar una prueba unitaria.

Luego están los excelentes módulos complementarios. El módulo Camel realmente se conecta bien a Akka y permite un desarrollo tan fácil de servicios asincrónicos con puntos finales configurables.

Estoy muy contento con el marco y se está convirtiendo en un estándar de facto para los sistemas conectados que creamos.


14
¿Cuál es el beneficio de este enfoque en comparación con el uso de un backend de mensajería (por ejemplo, ActiveMQ) para la transmisión de mensajes en su opinión?
magiconair

27
Los productos MQ son realmente para un caso de uso diferente. diferentes garantías y muy diferentes prestaciones. Los productos MQ necesitan mucha configuración, no usaría colas en dicho producto de la misma manera que usaría objetos. Los actores son ciudadanos de primera clase en akka, los usas a tu antojo, de forma similar a cómo usarías los objetos, por lo que hay mucho menos gastos generales tanto en tu modelo de programación como en la configuración. Los productos MQ que usaría más para integrarse con otros sistemas externos, no para construir los 'componentes internos' de un sistema, que es algo para lo que usaría actores.
Raymond Roestenburg el

26
La nueva URL para el caso de estudio de DBP es downloads.typesafe.com/website/casestudies/…
Bas

2
Partiendo de @RaymondRoestenburg re: sistemas MQ y alternativas. RabbitMQ, por ejemplo, se basa en un lenguaje de programación basado en actores, Erlang. Esa es una forma de pensar sobre la relación (y distinción) entre actor y MQ. Mientras tanto, Apache Spark no está basado en el trabajo y la cola ni en el actor, PERO se puede usar con Akka: Typesafe demuestra cómo usar Spark Streaming con Akka .
driftcatcher

66
@RaymondRoestenburg Olvidó mencionar que el modelo de actor tal como está promueve una estructura tipo espagueti. El libro "Akka en acción" que escribió es la mejor demostración de esta "característica". Los ejemplos de código tratan historias bastante básicas. Sin embargo, el flujo de trabajo es muy difícil de comprender y seguir desde el código. Un problema relacionado es que el código de Akka estará IRREVERSIBLE en toda la lógica de su negocio de la manera más intrusiva que pueda imaginar. Mucho más que cualquier otro marco no actor. Es simplemente imposible escribir un flujo de trabajo básico sin diseccionarlo en diferentes secciones separadas.
Raptado

222

Descargo de responsabilidad: soy el PO de Akka

Además de ofrecer una mezcla heterogénea de concurrencia que es mucho más simple de razonar y corregir (actores, agentes, concurrencia de flujo de datos) y con control de concurrencia en forma de STM.

Aquí hay algunos casos de uso que podría considerar:

  1. Procesamiento de transacciones (juegos en línea, finanzas, estadísticas, apuestas, redes sociales, telecomunicaciones, ...)
    • escalar, escalar, tolerancia a fallas / HA
  2. Servicio de back-end (cualquier industria, cualquier aplicación)
    • servicio REST, SOAP, cometd, etc.
    • actuar como centro de mensajes / capa de integración
    • escalar, escalar, tolerancia a fallas / HA
  3. Complemento / paralelismo de complemento (cualquier aplicación)
    • Correcto
    • Simple de trabajar y entender
    • Simplemente agregue los frascos a su proyecto JVM existente (use Scala, Java, Groovy o JRuby)
  4. Procesamiento por lotes (cualquier industria)
    • Integración en camello para conectar con fuentes de datos por lotes
    • Los actores dividen y conquistan las cargas de trabajo por lotes
  5. Centro de comunicaciones (telecomunicaciones, medios web, medios móviles)
    • escalar, escalar, tolerancia a fallas / HA
  6. Servidor de juegos (juegos en línea, apuestas)
    • escalar, escalar, tolerancia a fallas / HA
  7. BI / minería de datos / procesamiento de propósito general
    • escalar, escalar, tolerancia a fallas / HA
  8. inserte aquí otros casos de uso agradables

10
Entiendo los beneficios de Futures y STM pero no encuentro buenos casos de uso para los actores. Para un servidor de juegos o apuestas, ¿cuál es la ventaja de usar Actores frente a múltiples servidores de aplicaciones detrás de un equilibrador de carga?
Martin Konicek

8
@ViktorKlang POs! = Tech Lead. Trabajan juntos, pero son roles diferentes.
taylorcressy

79

Un ejemplo de cómo lo usamos sería en una cola prioritaria de transacciones con tarjeta de débito / crédito. Tenemos millones de estos y el esfuerzo del trabajo depende del tipo de cadena de entrada. Si la transacción es de tipo CHECK, tenemos muy poco procesamiento, pero si es un punto de venta, entonces hay mucho que hacer, como fusionar con metadatos (categoría, etiqueta, etiquetas, etc.) y proporcionar servicios (alertas por correo electrónico / sms, detección de fraude, saldo bajo de fondos, etc. Según el tipo de entrada, componimos clases de varios rasgos (llamados mixins) necesarios para manejar el trabajo y luego realizar el trabajo. Todos estos trabajos entran en la misma cola en tiempo real desde diferentes instituciones financieras. Una vez que los datos se limpian, se envían a diferentes almacenes de datos para persistencia, análisis o se envían a una conexión de socket, o para levantar al cometa actor. Los actores que trabajan constantemente están equilibrando la carga del trabajo para que podamos procesar los datos lo más rápido posible. También podemos incluir servicios adicionales, modelos de persistencia y para puntos críticos de decisión.

El mensaje de estilo Erlang OTP que pasa a JVM es un gran sistema para desarrollar sistemas en tiempo real sobre los hombros de bibliotecas y servidores de aplicaciones existentes.

Akka te permite hacer pasar mensajes como lo harías en un tradicional pero con velocidad! También le brinda herramientas en el marco para administrar la gran cantidad de grupos de actores, nodos remotos y tolerancia a fallas que necesita para su solución.


1
Entonces, ¿es justo decir que es el caso de (algunas) solicitudes de latencia larga, donde un solo hilo por solicitud no se escalaría bien?
StaxMan

77
Creo que la parte importante de la programación de actores en general es el flujo de mensajes. Una vez que comience a conceptualizar en flujos de datos que no tienen efectos secundarios, solo desea que ocurran tantos flujos por nodo como sea posible. Esto es muy diferente de High Performance Computing si tiene trabajos semi homogéneos que no envían mensajes y tardan mucho tiempo en procesarse. Creo que una implementación de Fibonacci basada en actores es un ejemplo muy limitante, ya que no muestra por qué usar actores, sino solo que los actores paralizan taks. Piense en arquitectura basada en eventos para casos de uso.
Wade Arnold

44
La arquitectura dirigida por eventos es una forma diferente de pensar sobre los problemas. Vale la pena leer Erlang OTP en acción de Manning si estás pensando en codificar en Akka. Muchas de las construcciones en akka están influenciadas por Erlang OTP y el libro le brinda los principios de por qué Jonas Boner construyó la api de akka de la manera que lo hizo. ¡Akka es una gran montaña en la que estás parado! Si sus actores son persistentes a través de los cambios de estado, ¿realmente necesita 10k escribe un segundo sostenido
Wade Arnold

8
Wade, ¿cómo manejan ustedes las garantías de mensajes? usted menciona: (alertas por correo electrónico / sms, detección de fraude, saldo bajo de fondos, etc.), ¿supongo que se envían potencialmente a actores remotos? ¿Cómo se asegura que esas operaciones realmente ocurrieron? ¿Qué pasa si el nodo falla al procesar una alerta de fraude? ¿Se ha ido para siempre? ¿Tiene un sistema eventualmente consistente que lo limpia? ¡Gracias!
James

2
Buena pregunta James. Es obvio que encaja en un sistema donde la respuesta no es necesaria con urgencia. Por ejemplo, puede procesar facturas de tarjetas de crédito; calcular; enviar correo electrónico, etc. Realmente me pregunto cómo se manejan estas cosas (transacciones) cuando se necesita una respuesta. Al final; si se realiza una solicitud externa (usuario de internet; un representante del centro de llamadas, etc.); él o ella espera una respuesta. ¿Cómo puedo estar seguro de que las subtareas (que se ejecutan de forma asíncrona) se ejecutan; en una transacción xa para que pueda devolver la respuesta?
Kaan Yy

44

Utilizamos Akka para procesar llamadas REST de forma asincrónica: junto con el servidor web asíncrono (basado en Netty) podemos lograr una mejora de 10 veces en el número de usuarios atendidos por nodo / servidor, en comparación con el hilo tradicional por modelo de solicitud de usuario.

¡Dígale a su jefe que su factura de alojamiento de AWS va a caer por el factor de 10 y es obvio! Shh ... aunque no se lo digas a Amazon ... :)


3
Y se me olvidó mencionar que la naturaleza monádica de akka futuros, lo que conduce a código paralelo mucho más limpio que nos miles de personas en el mantenimiento del código salvaron ...
piotrga

8
¿Supongo que las llamadas son de alta latencia y bajo rendimiento? ¿Como hacer llamadas a otros servidores, esperando respuesta (proxy)?
StaxMan el

38

Estamos usando Akka en un proyecto Telco a gran escala (desafortunadamente no puedo revelar muchos detalles). Los actores de Akka se implementan y acceden de forma remota mediante una aplicación web. De esta manera, tenemos un modelo RPC simplificado basado en el protobuffer de Google y logramos paralelismo con Akka Futures. Hasta ahora, este modelo ha funcionado brillantemente. Una nota: estamos utilizando la API de Java.


¿Podrías contarnos un poco más por favor? Afaik Futures no se puede enviar por cable (en serie). ¿Utiliza muchos futuros y pocos actores o una mezcla entre los dos o ...? ¿Utiliza protobuf para toda la serialización y lo envía como mensaje a los actores?
Aktau

Parece que podría haberse manejado con la misma facilidad sin Akka.
Erik Kaplun

1
TDC es la compañía Telco en el caso de Fiaddesio.
Roman Kagan

37

Si abstraes el servidor de chat en un nivel, entonces obtienes la respuesta.

Akka proporciona un sistema de mensajería similar a la mentalidad de "dejar que se cuelgue" de Erlang.

Entonces, los ejemplos son cosas que necesitan diferentes niveles de durabilidad y confiabilidad de la mensajería:

  • Servidor de chat
  • Capa de red para un MMO
  • Bomba de datos financieros
  • Sistema de notificación para un iPhone / móvil / cualquier aplicación
  • Servidor REST
  • Tal vez algo parecido a WebMachine (supongo)

Lo bueno de Akka son las opciones que ofrece para la persistencia, su implementación STM, el servidor REST y la tolerancia a fallas.

No se moleste con el ejemplo de un servidor de chat, piense en él como un ejemplo de una determinada clase de solución.

Con toda su excelente documentación, siento que una brecha es esta pregunta exacta, casos de uso y ejemplos. Teniendo en cuenta que los ejemplos no son triviales.

(Escrito con la única experiencia de ver videos y jugar con la fuente, no he implementado nada usando akka).


2
Gracias. No quise decir que el servidor de chat es necesariamente malo, solo que quisiera ejemplos complementarios; Es más fácil tener una mejor idea del potencial.
StaxMan

¿Tienes curiosidad por saber cómo encaja el servidor REST aquí? ¿Lo está mencionando en el contexto del servidor asíncrono de estilo Node.js? Gracias por compartir los ejemplos de casos de uso. Los encontré útiles.
software.wikipedia

24

Usamos Akka en varios proyectos en el trabajo, el más interesante de los cuales está relacionado con la reparación de accidentes de vehículos. Principalmente en el Reino Unido, pero ahora se está expandiendo a los EE. UU., Asia, Australasia y Europa. Utilizamos actores para garantizar que la información de reparación de accidentes se proporcione en tiempo real para permitir la reparación segura y rentable de vehículos.

La pregunta con Akka es realmente más "qué no puedes hacer con Akka". Su capacidad para integrarse con marcos potentes, su poderosa abstracción y todos los aspectos de tolerancia a fallas lo convierten en un conjunto de herramientas muy completo.


Entonces, ¿qué aspecto le gusta más si tuviera que elegir? ¿Integración existente para otros marcos, tolerancia automática a fallas u otra cosa?
StaxMan

66
Desde una perspectiva personal, es el nivel de abstracción elevado que Akka trae a la mesa lo que más me gusta. Desde una perspectiva empresarial, son las capacidades de integración. Tengo que
ganarme la

¿Podría explicar cómo es el flujo de mensajes? Es el usuario la persona en un taller de reparación e ingresa los detalles sobre el bloqueo en un formulario http y luego envía los datos al servidor. ¿Esto crea un mensaje manejado por akka? ¿Qué hacer con este mensaje? ¿Extraer la información ingresada para consultar la base de datos y luego poner en cola la respuesta para enviarla nuevamente a la interfaz web?
surfmuggle

24

Puedes usar Akka para diferentes tipos de cosas.

Estaba trabajando en un sitio web, donde migré la pila de tecnología a Scala y Akka. Lo usamos para casi todo lo que sucedió en el sitio web. Aunque podría pensar que un ejemplo de Chat es malo, todos son básicamente lo mismo:

  • Actualizaciones en vivo en el sitio web (por ejemplo, vistas, me gusta, ...)
  • Mostrando comentarios de usuarios en vivo
  • Servicios de notificación
  • Búsqueda y todo tipo de servicios.

Especialmente las actualizaciones en vivo son fáciles ya que se reducen a lo que es un ejemplo de Chat. La parte de servicios es otro tema interesante porque simplemente puede elegir usar actores remotos e incluso si su aplicación no está agrupada, puede implementarla en diferentes máquinas con facilidad.

También estoy usando Akka para una aplicación de enrutador automático de PCB con la idea de poder escalar desde una computadora portátil a un centro de datos. Mientras más poder le des, mejor será el resultado. Esto es extremadamente difícil de implementar si intenta usar la concurrencia habitual porque Akka también le brinda transparencia de ubicación.

Actualmente como un proyecto de tiempo libre, estoy construyendo un marco web utilizando solo actores. Una vez más, los beneficios son la escalabilidad de una sola máquina a un grupo completo de máquinas. Además, el uso de un enfoque basado en mensajes hace que su servicio de software esté orientado desde el principio. Tienen todos esos componentes agradables, hablando entre sí pero no necesariamente conociéndose, viviendo en la misma máquina, ni siquiera en el mismo centro de datos.

Y desde que Google Reader se apagó, comencé con un lector RSS, usando Akka, por supuesto. Se trata de servicios encapsulados para mí. Como conclusión: el modelo de actor en sí es lo que debe adoptar primero y Akka es un marco muy confiable que lo ayuda a implementarlo con muchos beneficios que recibirá en el camino.


Hola Joe, ¿podrías explicar cómo se usan los mensajes para actualizar el sitio? ¿Tiene un sistema para el autor del contenido? crea un nuevo artículo y pulsa guardar. ¿Crea esto un mensaje que se envía a varios servidores que manejan el tráfico entrante? Cada servidor procesa el mensaje de actualización tan pronto como puede. ¿Cada nueva solicitud del navegador obtiene una versión actualizada de la página? Gracias
surfmuggle

18

Estamos utilizando akka con su complemento camel para distribuir nuestro análisis y procesamiento de tendencias para twimpact.com . Tenemos que procesar entre 50 y 1000 mensajes por segundo. Además del procesamiento de múltiples nodos con camello, también se utiliza para distribuir el trabajo en un solo procesador a varios trabajadores para obtener el máximo rendimiento. Funciona bastante bien, pero requiere cierta comprensión de cómo manejar las congestiones.


¿también estás usando la tolerancia a fallas de Akka?
Erik Kaplun

¿Qué tal Spark Streaming si tenemos acceso al clúster Spark?
skjagini

18

Estaba probando mis manos en Akka (API de Java). Lo que intenté fue comparar el modelo de concurrencia basado en actores de Akka con el modelo de concurrencia simple de Java (clases java.util.concurrent).

El caso de uso fue un simple mapa canónico que reduce la implementación del recuento de caracteres. El conjunto de datos era una colección de cadenas generadas aleatoriamente (400 caracteres de longitud), y calcula el número de vocales en ellas.

Para Akka utilicé un BalancedDispatcher (para el equilibrio de carga entre subprocesos) y RoundRobinRouter (para mantener un límite en mis actores de función). Para Java, utilicé una técnica de unión de horquilla simple (implementada sin ningún algoritmo de robo de trabajo) que mapearía / reduciría las ejecuciones y uniría los resultados. Los resultados intermedios se mantuvieron en colas de bloqueo para que incluso la unión fuera lo más paralela posible. Probablemente, si no me equivoco, imitaría de alguna manera el concepto de "buzón" de los actores de Akka, donde reciben mensajes.

Observación: Hasta cargas medias (~ 50000 entrada de cadena) los resultados fueron comparables, variando ligeramente en diferentes iteraciones. Sin embargo, a medida que aumente mi carga a ~ 100000, colgaría la solución Java. Configuré la solución Java con 20-30 subprocesos bajo esta condición y falló en todas las iteraciones.

Aumentar la carga a 1000000 también fue fatal para Akka. Puedo compartir el código con cualquier persona interesada en realizar una verificación cruzada.

Entonces, para mí, parece que Akka se amplía mejor que la solución multiproceso Java tradicional. Y probablemente la razón es la magia bajo el capó de Scala.

Si puedo modelar un dominio problemático como un mensaje impulsado por un evento que pasa uno, creo que Akka es una buena opción para la JVM.

Prueba realizada en: Versión Java: 1.6 IDE: Eclipse 3.7 Windows Vista 32 bit. 3 GB de ram. Procesador Intel Core i5, velocidad de reloj de 2.5 GHz

Tenga en cuenta que el dominio del problema utilizado para la prueba se puede debatir y traté de ser tan justo como lo permitía mi conocimiento de Java :-)


3
"Puedo compartir el código con cualquier persona interesada en realizar una verificación cruzada". Me gustaría si no te importa.
n1r3

3
También me gustaría el código, ¿puedes publicar un enlace de github?
Gautam

Gracias por su interés. Lamentablemente, tengo algunos problemas para configurar un repositorio de github. Si me puede dar sus correos electrónicos, puedo enviar por correo el código fuente. Y lamenta una respuesta tardía!
sutanu dalui

@sutanudalui ¿Todavía tiene el código, si es así, puedo compartir mi correo electrónico?
Jay

16

Utilizamos Akka en sistemas de diálogo hablado ( primetalk ). Tanto interna como externamente. Para ejecutar simultáneamente muchos canales de telefonía en un solo nodo del clúster, obviamente es necesario tener un marco de subprocesamiento múltiple. Akka funciona simplemente perfecto. Tenemos una pesadilla previa con la concurrencia de Java. Y con Akka es como un columpio: simplemente funciona. Robusto y confiable. 24 * 7, sin parar.

Dentro de un canal tenemos una secuencia de eventos en tiempo real que se procesan en paralelo. En particular: - largo reconocimiento automático de voz - se realiza con un actor; - productor de salida de audio que mezcla algunas fuentes de audio (incluida la voz sintetizada); - la conversión de texto a voz es un conjunto separado de actores compartidos entre canales; - procesamiento semántico y de conocimiento.

Para hacer interconexiones de procesamiento de señales complejas, usamos SynapseGrid . Tiene el beneficio de la verificación en tiempo de compilación de DataFlow en los complejos sistemas de actores.


14

Recientemente he implementado el ejemplo canónico de reducción de mapas en Akka: recuento de palabras. Así que es un caso de uso de Akka: mejor rendimiento. Fue más un experimento de los actores de JRuby y Akka que cualquier otra cosa, pero también muestra que Akka no es solo Scala o Java: funciona en todos los idiomas además de JVM.


¿Sabes qué es responsable de un mejor rendimiento (y también en comparación con qué alternativa)? ¿Se debe al uso de JRuby en JVM (frente a Ruby nativo), debido a la escalabilidad de E / S sin bloqueo u otra cosa?
StaxMan

2
La comparación que escribí fue: Jruby secuencial VS Jruby con actores. Por lo tanto, lo único que puede ser responsable de una ejecución más rápida es la participación de los actores. No participaron E / S en los experimentos (se carga un archivo desde el disco, pero se realiza antes de que se establezca el temporizador de referencia).
Daniel Ribeiro

Recientemente he implementado un ejemplo de reducción de mapa, pero es simplemente vainilla java github.com/chaostheory/jibenakka
chaostheory
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.