Ejemplo de integración de Akka con un proyecto java existente

Solución:

Respondiendo a mi pregunta. Solo para compartir mis pensamientos, lo que se me ocurrió.

Si ya tenemos una aplicación web en funcionamiento basada en Servlets / Spring MVC, parece que a menudo no hay una buena razón para cambiar a Actors/AKKA (o introducir actores al sistema existente solo para piratearlo) si en nuestra aplicación:

• No tienes: Trabajadores del hilo lógica cuando las tareas se dividen en segundo plano. (por lo general, la aplicación web típica no tiene esto), como cálculos largos. (paralelismo).
• Tengo: Si tenemos llamadas secuenciales, cuando un componente llama a otro, ese llama a otro, donde las llamadas dependen unas de otras: como los controladores llaman al componente, el componente guarda algunos datos en alguna lista (que es mutable, pero sincronizada como sincronizada) lista ).
• No tener tiempo libre para reemplazar todos los Spring Controllers por actores de Akka o usar diferentes servidores (no Tomcat) (no hay tantos gerentes / propietarios de productos que le permitan hacer eso)

¿Qué hay de malo en tener actores en este sencillo sistema?

• Teniendo toneladas de mensajes (clases que envuelven comandos a / desde actores) que vienen a través de los componentes en lugar de llamar a métodos generales (usando las ventajas de OPP, implementando interfaces, teniendo varias implementaciones, pero los Actores generalmente final class).

• Tener mensajes como string, tampoco es una buena solución, ya que es difícil de depurar.

• En un sistema de este tipo (como el sitio MVC), por lo general, no hay tantas cosas para sincronizar (ya es bastante stateless). Hay 0..2 mutable shared data en cada controlador / componente. Lo cual no es tan difícil de sincronizar (solo conviértase en un hábito de poner sincronizar todo lo común y compartido en la parte superior de sus clases (para que los estados sean reconocibles / localizados). A veces solo necesita synchronized collection o usa java Atomic tipo de envoltorio.

Sin embargo, cuándo se pueden usar los actores para una aplicación existente. Los casos de uso pueden ser así:

• cuando tenemos una búsqueda de larga duración, pasa por varias fuentes (tipo de trabajador de subprocesos). Tener varios / tirar de MasterActor -> SiteSearchActor (como se describió para el cálculo PI aquí). El MasterActor tiene el resultado final. Donde SiteSearchActor calcula (busque en varios sitios) para varios clientes.
• o cuando tenemos bifurcaciones de hilo, fuera de los servlets actuales
• cuando sepamos con certeza / descubrimos que nuestro sistema será utilizado por millones de clientes (incluso con una lógica simple), deberíamos pensar de antemano en scalability y performance (
  • los actores escalan bien: podemos delegar un trabajo de un actor a N-one.
  • Los actores protegen el tipo de procesador cuando trabajan con subprocesos (no es necesario 10000 hilos por 10000 clientes, en la mayoría de los casos se han 4 hilos (la misma cantidad que el núcleo de los procesadores, digamos))

Pero en general, estoy de acuerdo con este artículo sobre concurrency y parallelism. Si tengo la oportunidad de hacer una aplicación desde cero, usaría Akka sin contenedor Servlets y preocuparse de alguna manera por los mensajes (clases de mando) y OOP cuando necesita ser utilizado (no hay tantos OOP en aplicaciones web en general. Debo decir de todos modos. Pero nadie impide mantener cierta lógica empresarial en OOP manera, los actores solo un pegamento de comunicación). Eso es mucho mejor / más simple que usar JMS, por ejemplo.

Pero como dije:

Actors / Akka es bueno para:

1. Servicios / Controladores (en lugar de Servlet / SpringMVC)
2. A los trabajadores de hilos les gusta la lógica
3. Especialmente para un proyecto desde cero (cuando la infraestructura actual no te pone barreras aplicando el actor uno).

---

La única pregunta que tengo ahora es performance comparison. Suponiendo que sepamos que:

Tener 10000 subprocesos en una JVM sincronizados y bloqueados para datos mutables compartidos en nuestros Controladores / Servicios MVC puede ser muy malo desde la perspectiva del rendimiento. Dado que hay muchos bloqueos posibles, subprocesos que son concurrentes (un rival o competidor por un recurso compartido) entre sí.

Si tenemos el mismo escenario para AKKA / Servlets con N (actores, donde N mucho más menos que 1000), lo más probable es que tengamos un rendimiento mucho mejor (ya que nadie bloquea a nadie, excepto la cola misma, no es necesario cambiar de un hilo a otro).

Pero incluso si tiene un sistema con 10000 clientes para la aplicación basada en Servlet (modelo de hilo), con 100 clientes podría funcionar muy bien. Y si tenemos un grupo de conexión (ciertamente lo tenemos), hace el mismo trabajo que la cola de Actor (bandeja de entrada), programando a los clientes para que tengan acceso a algún servicio. Podría mejorar nuestro rendimiento en K veces (donde K es mucho más que si no tuviéramos un grupo, dejando que los hilos se bloqueen entre sí desesperadamente).

La pregunta es:

¿Es una buena razón para no aplicar AKKA para aplicaciones basadas en servlets existentes?

Tomar esto es un argumento: incluso teniendo un sistema antiguo en los servidores, con
connection pool puede mejorar el rendimiento a un buen nivel. Y este nivel, muy probablemente, podría ser lo suficientemente bueno para NO aplicar AKKA a la aplicación de Servlet existente, como intentar cambiar el modelo de servlet (que se supone que es malo en comparación con los controladores en la parte superior de AKKA).

¿Tiene sentido pensar así?

Considere que la extracción de conexión es una especie de INBOX (como en AKKA) que programa los comandos (conexión).

Incluso si El modelo de servlets es malo (teniendo un trato con bloqueos en el resto (activo) subproceso que se está creando por conexión proveniente del grupo de conexiones).

Podría ser lo suficientemente bueno con el grupo de conexiones, que se olvida al comparar Akka con cosas basadas en servlets. Todavía podemos ajustar nuestra aplicación, cambiando MAX-CONNECTION en el grupo de conexiones. Y, por lo general, hacemos todo lo posible para que la aplicación no tenga estado, por lo que, en la mayoría de los casos, no sincronizamos nada.

Pero claro, es malo tener solo Uno grupo de conexiones para Entero solicitud. Si se compara con Actores, cada actor tiene su propio grupo de conexiones (buzón de correo), y cada actor puede ser responsable de aceptar solicitudes HTTP. Ese modelo ciertamente mejor.

PD: En la mayoría de los casos, Futuros son lo suficientemente buenos. Los actores son buenos si quieres “seguridad” para almacenar el estado en ellos (que básicamente lo difiere del Futuro).

ACTUALIZAR:
Algunas personas creen que es una mala idea utilizar Actors. Lo bueno es: un enfoque funcional puro o algo que Scalaz ya proporciona (así como Haskell Supongo), pero todavía no para llamadas remotas.

Me he encontrado con un problema similar.

Estoy de acuerdo en que hay pocos beneficios de agregar AKKA a una aplicación web simple con una pequeña cantidad de usuarios.

Pero no creo que sea difícil adjuntar AKKA a la aplicación Spring MVC existente. En caso de que su proyecto necesite escalar, puede envolver su @Servicio capa en actores. Por eso, @Controladores no es necesario ser actores internos.

Aquí hay una presentación sobre la fusión de la primavera con akka: https://www.youtube.com/watch?v=fALUf9BmqYE

Código fuente de la presentación: https://github.com/jsuereth/spring-akka-sample/tree/master/src/main/java/org/springframework/samples/travel

---

---

Utiliza Nuestro Buscador