Microsoft Orleans

Orleans:

• Est un framework multiplateforme permettant de créer des applications distribuées robustes et évolutives. Les applications distribuées sont définies comme étant des applications qui couvrent plusieurs processus, en allant souvent au-delà des limites matérielles via une communication d’égal à égal.
• Peut être mis à l’échelle depuis un seul serveur local jusqu’à des milliers d’applications à haute disponibilité dans le cloud.
• Étend des concepts familiers et des idiomes de C# aux environnements multiserveurs.
• Est conçu pour une mise à l’échelle élastique. Quand un hôte rejoint un cluster, il peut accepter de nouvelles activations. Quand un hôte quitte le cluster, les activations précédentes sur cet hôte sont réactivées si nécessaire sur les hôtes restants. Un hôte peut quitter un cluster en raison d’un scale-down ou de la défaillance d’une machine. Un cluster Orleans peut être réduit à un seul hôte. Les mêmes propriétés qui permettent la scalabilité élastique permettent la tolérance de panne. Le cluster détecte automatiquement les défaillances et récupère rapidement.
• Simplifie la complexité du développement d’applications distribuées en fournissant un ensemble commun de modèles et d’API.
• Permet aux développeurs familiarisés avec le développement d’applications à un seul serveur de passer à la création d’applications distribuées et de services natifs Cloud résilients et évolutifs.
• Est parfois appelé « .NET distribué ».
• Est le framework de choix lors de la création d’applications natives Cloud.
• S’exécute partout où .NET est pris en charge. Cela inclut l’hébergement sur Linux, Windows et macOS.
• Les applications peuvent être déployées sur Kubernetes, sur des machines virtuelles et sur des services PaaS comme Azure App Service et Azure Container Apps.

Le « modèle d’acteur »

Orleans s’appuie sur le « modèle d’acteur ». Le modèle d’acteur est né au début des années 70 et représente maintenant un composant central d’Orleans. Le modèle d’acteur est un modèle de programmation dans lequel chaque acteur est un objet léger, simultané et immuable qui encapsule un état individuel et un comportement correspondant. Les acteurs communiquent exclusivement entre eux via des messages asynchrones. Orleans a notamment inventé l’abstraction d’acteur virtuel, où les acteurs existent de manière perpétuelle.

Notes

Les acteurs sont des entités purement logiques qui existent toujours, de manière virtuelle. Un acteur ne peut pas être explicitement créé ni détruit, et son existence virtuelle n’est pas affectée par la défaillance d’un serveur qui l’exécute. Comme les acteurs existent toujours, ils sont toujours adressables.

Il s’agit d’une approche inédite permettant de créer une nouvelle génération d’applications distribuées pour l’ère du cloud. Le modèle de programmation d’Orleans permet de maîtriser la complexité inhérente aux applications distribuées hautement parallèles sans restreindre les possibilités ou imposer des contraintes au développeur.

Pour plus d’informations, consultez Orleans : Acteurs virtuels via Microsoft Research. Un acteur virtuel est représenté sous la forme d’un grain Orleans.

Que sont les grains ?

Le grain est l’une des primitives d’Orleans. En termes de modèle d’acteur, un grain est un acteur virtuel. L’élément fondamental à la création de toute application Orleans est un grain. Les grains sont des entités comprenant une identité, un comportement et un état définis par l’utilisateur. Considérez la représentation visuelle suivante d’un grain :

Les identités de grain sont des clés définies par l’utilisateur qui rendent les grains toujours disponibles pour être appelés. Les grains peuvent être appelés par d’autres grains ou par un nombre quelconque de clients externes. Chaque grain est une instance d’une classe qui implémente une ou plusieurs des interfaces suivantes :

• IGrainWithGuidKey : interface de marqueur pour les grains avec des clés Guid.
• IGrainWithIntegerKey : interface de marqueur pour les grains avec des clés Int64.
• IGrainWithStringKey : interface de marqueur pour les grains avec des clés string.
• IGrainWithGuidCompoundKey : interface de marqueur pour les grains avec des clés composées.
• IGrainWithIntegerCompoundKey : interface de marqueur pour les grains avec des clés composées.

Les grains peuvent avoir des données dans un état volatile ou persistant qui peuvent être stockées dans n’importe quel système de stockage. Par conséquent, les grains partitionnent de façon implicite les états des applications, ce qui favorise la scalabilité automatique et simplifie la récupération après échec. L’état du grain est conservé en mémoire pendant que le grain est actif, ce qui entraîne une diminution de la latence et de la charge sur les magasins de données.

L’instanciation des grains est effectuée automatiquement à la demande par le runtime Orleans. Les grains qui ne sont pas utilisés pendant un certain temps sont automatiquement supprimés de la mémoire pour libérer des ressources. Cela est possible en raison de leur identité stable, qui permet d’appeler les grains, qu’ils soient déjà chargés en mémoire ou non. Cela permet également une récupération transparente après échec, car l’appelant n’a pas besoin de savoir sur quel serveur un grain est instancié à un quelconque moment donné. Les grains ont un cycle de vie géré et le runtime Orleans est responsable de l’activation/la désactivation et du positionnement/de la localisation des grains selon les besoins. Cela permet au développeur d’écrire du code comme si tous les grains sont toujours en mémoire.

Que sont les silos ?

Le silo est un autre exemple de primitive Orleans. Un silo héberge un ou plusieurs grains. C’est le runtime Orleans qui implémente le modèle de programmation pour les applications.

En règle générale, un groupe de silos s’exécute sous la forme d’un cluster par souci de scalabilité et de tolérance de panne. Lorsqu’ils sont exécutés sous la forme d’un cluster, les silos se coordonnent entre eux pour distribuer le travail, détecter les défaillances et récupérer après échec. Le runtime permet aux grains hébergés dans le cluster de communiquer entre eux comme s’ils figuraient dans un processus unique. Pour vous aider à visualiser la relation entre les clusters, les silos et les grains, examinez le diagramme suivant :

Le diagramme précédent illustre la relation entre les clusters, les silos et les grains. Vous pouvez avoir un nombre quelconque de clusters, chaque cluster comprenant un ou plusieurs silos, et chaque silo comprenant un ou plusieurs grains.

En plus du modèle de programmation principal, les silos fournissent aux grains un ensemble de services d’exécution tels que des minuteurs, des rappels (minuteurs persistants), la persistance, des transactions, des flux, etc. Pour plus d’informations, consultez Que puis-je faire avec Orleans ?

Les applications web et d’autres clients externes appellent les grains dans le cluster à l’aide de la bibliothèque de client, qui gère automatiquement la communication réseau. Les clients peuvent également être co-hébergés dans le même processus avec des silos, par souci de simplicité.

Comment puis-je utiliser Orleans ?

Orleans est une infrastructure permettant de créer des applications natives Cloud. Elle doit être envisagée chaque fois que vous créez des applications .NET qui devront éventuellement être mises à l’échelle. Il semble exister une infinité de façons d’utiliser Orleans, mais les plus courantes incluent les suivantes : le gaming, les services bancaires, les applications de conversation, le suivi GPS, les transactions boursières, les paniers d’achats, les applications de vote en ligne, etc. Orleans est utilisé par Microsoft sur Azure, Xbox, Skype, Halo, PlayFab, Gears of War et de nombreux autres services internes. Orleans possède de nombreuses fonctionnalités qui facilitent son utilisation pour diverses applications.

Persistance

Orleans fournit un modèle de persistance simple qui garantit la disponibilité de l’état avant de traiter une demande, ainsi que le maintien de sa cohérence. Les grains peuvent avoir plusieurs objets de données persistants nommés. Par exemple, il peut y avoir un objet appelé « profil » pour le profil d’un utilisateur et un objet appelé « inventaire » pour son inventaire. Cet état peut être stocké dans n’importe quel système de stockage.

Pendant l’exécution d’un grain, l’état est conservé en mémoire afin que les demandes de lecture puissent être traitées sans accéder au stockage. Quand le grain met à jour son état, l’appel de IStorage.WriteStateAsync garantit la mise à jour du magasin de stockage par souci de durabilité et de cohérence.

Pour plus d’informations, consultez Persistance des grains.

Minuteries et rappels

Les rappels sont un mécanisme de planification durable pour les grains. Ils peuvent être utilisés pour garantir qu’une action sera terminée à un stade ultérieur, même si le grain n’est pas activé à ce moment-là. Les minuteurs sont l’équivalent non durable des rappels et peuvent être utilisés pour les événements à fréquence élevée, qui ne nécessitent pas de fiabilité.

Pour plus d’informations, consultez Minuteurs et rappels.

Positionnement flexible des grains

Lorsqu’un grain est activé dans Orleans, le runtime détermine le serveur (silo) sur lequel activer ce grain. Cela s’appelle le positionnement de grain.

Le processus de positionnement dans Orleans est entièrement configurable. Les développeurs peuvent effectuer un choix parmi différentes stratégies de positionnement prêtes à l’emploi (aléatoire, local, en fonction de la charge), ou une logique personnalisée peut être configurée. Cela offre une flexibilité totale quant au choix de l’emplacement où sont créés les grains. Par exemple, les grains peuvent être placés sur un serveur proche des ressources avec lesquelles ils doivent interagir ou à proximité d’autres grains avec lesquels ils communiquent.

Pour plus d’informations, consultez Positionnement des grains.

Contrôle de version des grains et clusters hétérogènes

La mise à niveau des systèmes de production d’une manière rendant compte des changements en toute sécurité peut s’avérer difficile, notamment dans les systèmes avec état. Pour rendre compte de cela, il est possible de contrôler la version des interfaces de grain dans Orleans.

Le cluster conserve un mappage des implémentations de grain disponibles sur les silos du cluster et sur les versions de ces implémentations. Cette version des informations est utilisée par le runtime conjointement aux stratégies de positionnement pour prendre des décisions de positionnement lors du routage des appels vers les grains. En outre, pour mettre à jour en toute sécurité un grain versionné, cela favorise également des clusters hétérogènes, où différents silos disposent de différents ensembles d’implémentations de grain.

Pour plus d’informations, consultez Contrôle de version des grains.

Workers sans état

Les workers sans état sont des grains marqués spécialement qui n’ont aucun état associé et peuvent être activés sur plusieurs silos simultanément. Cela permet d’augmenter le parallélisme pour les fonctions sans état.

Pour plus d’informations, consultez Grains de Worker sans état.

Filtres d’appels de grain

Un filtre d’appels de grain est une logique commune à de nombreux grains. Orleans prend en charge les filtres pour les appels entrants et sortants. Les filtres pour l’autorisation, la journalisation, la télémétrie et la gestion des erreurs sont tous considérés comme courants.

Contexte de demandes

Des métadonnées et d’autres informations peuvent être transmises avec une série de demandes à l’aide du contexte de demandes. Le contexte de demandes peut être utilisé pour conserver des informations de suivi distribuées ou d’autres valeurs définies par l’utilisateur.

Transactions ACID distribuées

Outre le modèle de persistance simple décrit ci-dessus, les grains peuvent avoir un état transactionnel. Plusieurs grains peuvent participer ensemble à des transactions ACID, où que leur état soit finalement stocké. Les transactions dans Orleans sont distribuées et décentralisées (aucun gestionnaire de transactions central ou coordinateur de transactions impliqué) et disposent d’un isolement sérialisable.

Pour plus d’informations sur les transactions, consultez Transactions.

Flux

Les flux aident les développeurs à traiter une série d’éléments de données en quasi-temps réel. Les flux Orleans sont gérés. Les flux n’ont pas besoin d’être créés ou enregistrés avant qu’un grain ou un client ne publie un flux ou ne s’abonne à un flux. Cela permet un découplage plus important des producteurs et des consommateurs de flux les uns des autres et de l’infrastructure.

Le traitement de flux est fiable : les grains peuvent stocker des points de contrôle (curseurs) et effectuer une réinitialisation à un point de contrôle stocké durant l’activation ou à tout moment ultérieur. Les flux prennent en charge la remise par lots des messages aux consommateurs pour améliorer l’efficacité et les performances de récupération.

Les flux sont soutenus par des services de mise en file d’attente tels qu’Azure Event Hubs, Amazon Kinesis et autres.

Un nombre arbitraire de flux peuvent être multiplexés sur un plus petit nombre de files d’attente et la responsabilité de traiter ces files d’attente est équilibrée uniformément dans l’ensemble du cluster.

Présentation de la vidéo Orleans

Si vous êtes intéressé par une présentation vidéo d’Orleans, visionnez la vidéo suivante :

Étapes suivantes

Tutoriel : Créer une application Orleans minimale