Comment Akka est-il utilisé dans Play?
La page d'accueil de Play dit:
Construit sur Akka, Play fournit une consommation de ressources prévisible et minimale (CPU, mémoire, threads) pour des applications hautement évolutives.
J'aimerais savoir exactement comment et où Akka est utilisé dans Play et quelles sont les conséquences de la création de Play sur Akka.
Dans Play 2., Play a délégué toutes les demandes de passer par un acteur. Cela dépendait fortement de la future API d'Akka et d'autres parties.
Dans Play 2.1, avec le déplacement de la future API d'Akka dans Scala 2.10, Play a commencé à dépendre moins directement d'Akka. Il obtient tous ses contextes d'exécution d'Akka et fournit l'intégration avec Akka, mais c'est à peu près l'étendue de celui-ci.
Dans Play 2., nous ajoutons de nouvelles fonctionnalités pour faciliter l'intégration d'Akka, en particulier autour des WebSockets.
Dans Play 2.4, Play sera porté sur le nouveau akka-http (anciennement connu sous le nom de spray), auquel cas, Play sera aussi construit sur Akka que possible.
Quelles sont les conséquences? Akka fournit un paradigme pour la programmation qui rend la simultanéité simple à gérer. Il fournit également d'excellentes abstractions pour la programmation distribuée - la chose la plus difficile à propos de la programmation distribuée consiste à gérer les échecs (qui se produisent tout le temps) de manière appropriée. La plupart des outils essaient de résoudre ce problème en essayant de vous cacher les échecs, mais malheureusement, cacher quelque chose ne le fait pas disparaître, et rend vraiment les choses plus difficiles parce que lorsque vous essayez de résoudre des types spécifiques d'échecs, le fait qu'ils soient cachés de vous gêne. Akka vous fait face aux échecs, de sorte que lorsque vous codez, vous êtes obligé de réfléchir à la façon dont votre application réagira aux échecs. Par conséquent, vous êtes obligé de concevoir/coder votre application de manière à ce qu'elle tolère les échecs. Il vous donne également les outils pour y faire face de manière hiérarchique, vous permettant de spécifier à quel niveau vous souhaitez gérer quel type de défaillance, et comment y répondre (mourir, réessayer jusqu'à n fois, etc.) .
Alors, comment cela aide-t-il à jouer? La meilleure question est de savoir comment cela aide-t-il un utilisateur de Play? Akka m'aide à implémenter Play lui-même, mais il est possible de l'implémenter sans Akka (en fait, Netty fait la plupart des tâches lourdes maintenant, cela changera dans Play 2.4). L'important est que Play s'intègre de manière transparente à Akka, ce qui facilite la gestion des requêtes HTTP avec les acteurs, la gestion des échecs, etc., et cela aide les utilisateurs de Play car cela leur permet de concevoir leur application de manière à ce qu'elle soit évolutive et résiliente.
MISE À JOUR: Ce qui précède a été écrit il y a 3 ans, beaucoup de choses ont changé depuis lors. Play 2.4 a fourni un support expérimental pour akka-http, mais Play utilise toujours par défaut Netty.
Dans Play 2.5, nous avons déprécié l'API itérée et nous sommes passés aux flux Akka. Cela signifiait que maintenant tout asynchrone IO passait par les flux Akka. Bientôt (je ne sais pas si ce sera Play 2.6 ou version ultérieure), Play actionnera le commutateur pour faire de akka-http l'implémentation de support par défaut du serveur (mais pas encore le client WS).
MISE À JOUR 2: Play 2.6 fait maintenant akka-http l'implémentation backend par défaut de son serveur HTTP (Netty est toujours disponible en tant que option).