Pregunta

He oído un montón de exaltar Akka marco (plataforma de servicios Java / Scala), pero hasta el momento no se han visto muchos ejemplos reales de casos de uso que serían buenos para. Así que estaría interesado en escuchar acerca de lo que los desarrolladores lo han utilizado con éxito.

Sólo una limitación: Por favor no incluya caso de escribir un servidor de chat. (¿Por qué? Ya que este ha sido usado en exceso como un ejemplo para muchas cosas similares)

¿Fue útil?

Solución

Me lo han utilizado hasta ahora en dos proyectos reales con mucho éxito. Ambos se encuentran en el campo cerca de la información de tráfico en tiempo real (como en el tráfico de vehículos en las carreteras), distribuidos en varios nodos, la integración de mensajes entre varias partes, los sistemas de back-end fiables. No estoy en libertad de dar detalles sobre los clientes, sin embargo, cuando lo haga llegar permiso tal vez puede ser añadido como una referencia.

Akka realmente ha tirado a través de estos proyectos, a pesar de que empezamos cuando estaba en la versión 0.7. (Estamos utilizando Scala por cierto)

Una de las grandes ventajas es la facilidad con la que se puede componer un sistema de actores y mensajes con casi ninguna boilerplating, se escala muy bien sin todas las complejidades de rosca enrollado a mano y se obtiene de mensajes asíncronos que pasa entre los objetos casi de forma gratuita.

Es muy buena en el modelado de cualquier tipo de tratamiento de mensajes asíncrono. Yo preferiría escribir cualquier tipo de sistema de servicios (web) en este estilo que cualquier otro estilo. (¿Alguna vez ha tratado de escribir un servicio web asíncrono (lado del servidor) con JAX-WS? Eso es un montón de plomería). Así que diría cualquier sistema que no quiere colgar en uno de sus componentes, porque todo se llama implícitamente utilizando métodos síncronos, y que un componente es el bloqueo en algo. Es muy estable y la solución let-que-crash + supervisor para el fracaso realmente funciona bien. Todo es fácil de configurar mediante programación y no es difícil de probar la unidad.

Luego están los excelentes módulos adicionales. El módulo de camello realmente se conecta bien en Akka y permite el desarrollo fácil de tales servicios asíncronos con puntos finales configurables.

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

Otros consejos

exención de responsabilidad: yo soy el PO de Akka

Además de ofrecer una mezcla heterogénea concurrencia que es mucho más fácil de razonar sobre y para obtener correctos (actores, agentes, concurrencia de flujo de datos) y con el control de concurrencia en forma de STM.

Estos son algunos casos de uso que podría considerar:

  1. El procesamiento de transacciones (en línea juegos, finanzas, estadística, apuestas, medios de comunicación social, telecomunicaciones, ...)
    • escalar, escalar, tolerancia a fallos / HA
  2. Servicio de back-end (cualquier industria, cualquier aplicación)
    • Resto de servicios, SOAP, etc. cometd
    • actuar como concentrador mensaje / capa de integración
    • escalar, escalar, tolerancia a fallos / HA
  3. Snap-en concurrencia / paralelismo (cualquier aplicación)
    • correcta
    • fácil de trabajar y entender
    • Sólo tiene que añadir los frascos para su proyecto JVM existente (uso Scala, Java, Groovy o JRuby)
  4. El procesamiento por lotes (cualquier industria)
    • integración Camel para la conexión de fuentes de datos por lotes
    • Actores dividir y conquistar a las cargas de trabajo por lotes
  5. centro de comunicaciones (telecomunicaciones, medios web, medios de comunicación móviles)
    • escalar, escalar, tolerancia a fallos / HA
  6. Servidor de juego (juegos en línea, apuestas)
    • escalar, escalar, tolerancia a fallos / HA
  7. BI / extracción de datos / crujido de propósito general
    • escalar, escalar, tolerancia a fallos / HA
  8. Insertar otros casos de uso agradable aquí

Un ejemplo de cómo usamos lo que sería en una cola de prioridad de las 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 COMPROBAR tenemos muy poco procesamiento, pero si se trata de un punto de venta entonces no hay mucho que hacer, como fusión con los metadatos (categoría, etiquetas, etiquetas, etc.) y la prestación de servicios (alertas de correo electrónico / SMS, detección de fraudes, bajo el equilibrio de fondos, etc.). Con base en el tipo de entrada componemos clases de diversas características (llamadas mixins) necesarios para manejar el trabajo y luego realizar el trabajo. Todos estos trabajos entran en la misma cola en modo de tiempo real de diferentes instituciones financieras. Una vez que se limpia los datos que se envía a los diferentes almacenes de datos para la persistencia, análisis, o se empuja a una conexión de socket, o para levantar el actor cometa. actores que trabajan están en constante equilibrio de carga auto del trabajo para que podamos procesar los datos lo más rápido posible. También podemos encajar en los servicios adicionales, la persistencia modelos, y los puntos de decisión críticos.

El mensaje del estilo que pasa Erlang OTP en la JVM hace un gran sistema para el desarrollo de sistemas de tiempo real sobre los hombros de las bibliotecas existentes y servidores de aplicaciones.

Akka le permite hacer el paso de mensajes como lo haría en un pero con la velocidad! También le da herramientas en el marco de manejar la gran cantidad de piscinas actor, nodos remotos, y la tolerancia que necesita para su solución de fallos.

Utilizamos Akka a las llamadas proceso de REST de forma asíncrona - junto con el servidor web asíncrono (basado en Netty) podemos alcanzar 10 mejora veces en el número de usuarios servidos por nodo / servidor, en comparación con el hilo tradicional por solicitud de usuario del modelo

Dile a tu jefe que sus AWS alojamiento factura va a caer por el factor de 10 y es una obviedad! Shh ... no le digas a Amazon, aunque ...:)

Estamos utilizando Akka en un proyecto de telecomunicaciones a gran escala (por desgracia no puedo revelar muchos detalles). Akka actores se implementan y acceder a distancia a una aplicación web. De esta manera, tenemos un modelo simplificado basado en RPC Google protobuffer y conseguir el paralelismo usando Akka Futuros. Hasta el momento, este modelo ha trabajado de manera brillante. Una nota:. Estamos utilizando la API de Java

Si abstracta del servidor de chat a un nivel superior, se obtiene la respuesta.

Akka proporciona un sistema de mensajería que es similar a la de Erlang "deja que choque" mentalidad.

Así ejemplos son cosas que hay diferentes niveles de durabilidad y fiabilidad de los mensajes:

  • servidor de chat
  • capa de red para un MMO
  • bombeo de datos financieros
  • Sistema de notificación de un iPhone / / móvil sea cual sea la aplicación
  • Resto del servidor
  • Tal vez algo parecido a WebMachine (conjetura)

Las buenas cosas sobre Akka son las opciones que ofrece para la persistencia, es de aplicación STM, servidor REST y de tolerancia a fallos.

No se molesta por el ejemplo de un servidor de chat, piensa en él como un ejemplo de una cierta clase de solución.

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

(escrito con la única experiencia de ver vídeos y jugar con la fuente, he implementado nada usando akka.)

Utilizamos Akka en varios proyectos en el trabajo, el más interesante de los cuales está relacionado con la reparación de choque de vehículos. Principalmente en el Reino Unido pero ahora la expansión de los EE.UU., Asia, Australia y Europa. Utilizamos actores para asegurar que la información de reparación de choque se proporciona en tiempo real para permitir la reparación segura y rentable de los vehículos.

La pregunta con Akka es realmente más 'lo que no se puede hacer con Akka'. Su capacidad de integrarse con los marcos de gran alcance, su potente abstracción y todos los aspectos de la falta de tolerancia lo convierten en un conjunto de herramientas muy completa.

Se puede utilizar Akka para diferentes tipos de cosas.

Yo estaba trabajando en un sitio web, donde emigré la tecnología de pila de Scala y Akka. Lo usamos para casi todo lo que ocurrió en el sitio web. A pesar de que se podría pensar un ejemplo Chat es malo, todos son básicamente los mismos:

  • Actualizaciones en vivo en el sitio web (por ejemplo, puntos de vista, gustos, ...)
  • Mostrando los comentarios de los usuarios en vivo
  • Servicios de notificación
  • Búsqueda y todos los otros tipos de servicios

Especialmente las actualizaciones en tiempo real son fáciles, ya que se reducen a lo que es un ejemplo ist de Chat. La parte de servicios es otro tema interesante, ya que simplemente puede optar por utilizar actores remotos e incluso si su aplicación no está agrupado, puede desplegarlo en diferentes máquinas con facilidad.

También estoy usando Akka para una aplicación trazador automático PCB con la idea de ser capaz de escalar desde un ordenador portátil a un centro de datos. Cuanto más poder se le dé, mejor será el resultado será. Esto es extremadamente difícil de implementar si se intenta utilizar la concurrencia habitual debido a Akka le da también lugar la transparencia.

En la actualidad como un proyecto de tiempo libre, estoy construyendo un marco web utilizando sólo actores. Una vez más los beneficios son escalabilidad desde una sola máquina a toda una agrupación de máquinas. Además, utilizando un enfoque controlado por mensajes hace que su servicio de software orientado desde el principio. Usted tiene todos esos componentes agradables, hablando entre sí, pero no necesariamente saber uno del otro, viviendo en la misma máquina, ni siquiera en el mismo centro de datos.

Y como Google Reader cerró Empecé con un lector de RSS, usando Akka por supuesto. Es acerca de todos los servicios encapsulados para mí. A modo de conclusión: El mismo modelo de actor es lo que debe adoptar primero y Akka es un marco muy fiable que le ayuda a ponerlo en práctica con una gran cantidad de beneficios que recibirá en el camino

.

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

Yo estaba tratando a cabo las manos en Akka (API Java). Lo que intenté fue comparar modelo de concurrencia basado en el actor de Akka con la de modelo de concurrencia de Java normal (clases java.util.concurrent).

El caso de uso era un simple canónica MapReduce implementación de recuento de caracteres. El conjunto de datos fue una colección de cadenas generados aleatoriamente (400 caracteres de longitud), y calcular el número de vocales en ellos.

Para Akka he usado un BalancedDispatcher (para el equilibrio entre los hilos de carga) y RoundRobinRouter (para mantener un límite en mis actores de función). Para Java, solía tenedor combinación sencilla técnica (implementado sin ningún trabajo algoritmo de robar) que desembolsar map / reduce las ejecuciones y unirse a los resultados. Los resultados intermedios se llevaron a cabo en el bloqueo de colas para hacer que incluso la unión lo más paralelo posible. Probablemente, si no estoy equivocado, que imitaría de alguna manera el concepto de "buzón" de actores Akka, donde reciben mensajes.

Observación: Hasta cargas medias (~ 50.000 entrada de cadena) los resultados fueron comparables, variando ligeramente en diferentes iteraciones. Sin embargo, como he aumentado mi carga a ~ 100.000 colgaría la solución de Java. He configurado la solución Java con 20-30 hilos bajo esta condición y falló en todas las iteraciones.

El aumento de la carga a 1000000, fue fatal para Akka también. Puedo compartir el código con cualquier persona interesada a tener un control cruzado.

Así que para mí, parece Akka escalas mejor de lo tradicional de Java solución multiproceso. Y probablemente la razón es el bajo el capó de magia Scala.

Si puedo modelar un dominio del problema como un mensaje de evento impulsado pasando uno, creo Akka es una opción buena para la JVM.

Las verificaciones realizadas en: versión de Java: 1.6 IDE: Eclipse 3.7 Windows Vista de 32 bits. RAM 3GB. procesador Intel Core i5, 2.5 GHz velocidad de reloj

Por favor nota, el dominio del problema utilizada para la prueba puede ser debatido y yo trataba de ser lo más justo como mis conocimientos de Java permitió: -)

Utilizamos Akka en sistemas de diálogo hablado ( primetalk ). Tanto interna como externamente. Con el fin de ejecutar de forma simultánea una gran cantidad de canales de telefonía en un solo nodo de clúster está claro que es necesario tener algún marco multihilo. Akka funciona perfecto. Tenemos pesadilla anterior con el java-concurrencia. Y con Akka es como un columpio - simplemente funciona. Robusto y fiable. 24 * 7, sin parar.

Dentro de un canal tenemos flujo en tiempo real de los eventos que se procesan en paralelo. En particular: - reconocimiento automático del habla largo - se realiza con un actor; - productor de salida de audio que mezcla unas pocas fuentes de audio (incluyendo el habla sintetizada); - conversión de texto a voz es un conjunto separado de actores compartidos entre los canales; -. Procesamiento semántico y el conocimiento

Para hacer interconexiones de procesamiento de señal compleja que utilizamos SynapseGrid . Tiene la ventaja de comprobación en tiempo de compilación de la DataFlow en los sistemas de actor compleja.

Recientemente he implementado el mapa-canónica reducir ejemplo, en Akka: Recuento de palabras. Por lo tanto, de un caso de uso de Akka: un mejor rendimiento. Era más de un experimento de JRuby y de Akka actores que cualquier otra cosa, sino que también muestra que no es Akka Scala o únicamente Java: funciona en todos los idiomas en la parte superior de la JVM

.
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top