Buen caso de uso para Akka [cerrado]

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)

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.

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

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 ystm 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 esbpero 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.

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 ... :)

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.

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).

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.

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.

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.

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 :-)

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.

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.