Microsoft Orleans

Orleans :

• Infrastructure multiplateforme permettant de créer des applications distribuées robustes et évolutives. Les applications distribuées sont définies en tant qu’applications qui s’étendent sur plus d’un processus unique, souvent au-delà des limites matérielles à l’aide de la communication peer-to-peer.
• Met à l’échelle un seul serveur local vers des milliers d’applications distribuées et hautement disponibles dans le cloud.
• Étend les concepts familiers et les idiomes C# aux environnements multi-serveurs.
• est conçu pour s'adapter de manière élastique. Lorsqu’un hôte rejoint un cluster, il peut accepter de nouvelles activations. Lorsqu’un hôte quitte le cluster, les activations précédentes sur cet hôte seront réactivées sur les hôtes restants en fonction des besoins. Un hôte peut quitter un cluster en raison d’un scale-down ou d’une défaillance de machine. Un cluster Orleans peut être réduit à un seul hôte. Les mêmes propriétés qui permettent la scalabilité élastique activent la tolérance de panne. Le cluster détecte automatiquement et se rétablit rapidement après des défaillances.
• 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 à serveur unique de passer à la création de services natifs cloud résilients et évolutifs et d’applications distribuées.
• Est parfois appelé « Distributed .NET ».
• 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, les machines virtuelles et les services PaaS tels que azure App Service et Azure Container Apps.

Le « modèle d’acteur »

Orleans est basé sur le « modèle d’acteur ». Le modèle d’acteur provient au début des années 1970 et est maintenant un composant principal de 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 élément d’état et un comportement correspondant. Les acteurs communiquent exclusivement entre eux à l’aide de messages asynchrones. Orleans a notamment inventé l’abstraction Virtual Actor, où les acteurs existent perpétuellement.

Remarque

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 l’échec d’un serveur qui l’exécute. Étant donné que les acteurs existent toujours, ils sont toujours adressables.

Il s’agit d’une nouvelle approche de la création d’une nouvelle génération d’applications distribuées pour l’ère cloud. Le modèle de programmation Orleans apprivoise la complexité inhérente aux applications hautement parallélisées et distribuées sans restreindre les capacités ni imposer de contraintes au développeur.

Pour plus d’informations, consultez Orleans: Virtual Actors via Microsoft Research. Un acteur virtuel est représenté par un grain Orleans.

Qu’est-ce que les grains ?

Le grain est l'une des nombreuses primitives Orleans. En termes de modèle d'acteur, un grain est un acteur virtuel. Le bloc de construction fondamental dans n’importe quelle 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 marquage pour les grains avec des clés Guid.
• IGrainWithIntegerKey : Interface de marquage pour les grains avec des clés Int64.
• IGrainWithStringKey : Interface de marquage pour les grains avec des clés string.
• IGrainWithGuidCompoundKey : Interface de marquage pour les grains avec des clés composées.
• IGrainWithIntegerCompoundKey : Interface de marquage pour les grains ayant des clés composées.

Les grains peuvent avoir des données d’état volatiles ou persistantes qui peuvent être stockées dans n’importe quel système de stockage. Par conséquent, les grains partitionnent implicitement les états d’application, ce qui permet l’extensibilité automatique et simplifie la récupération des défaillances. L’état du grain est conservé en mémoire pendant que le grain est actif, ce qui entraîne une latence inférieure et une charge moindre sur les magasins de données.

L'instanciation des grains est automatiquement réalisée à la demande par le moteur d'exécution 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, ce qui permet d’appeler des grains s’ils sont déjà chargés en mémoire ou non. Cela permet également une récupération transparente à partir d’une défaillance, car l’appelant n’a pas besoin de savoir sur quel serveur un grain est instancié à un moment donné. Les grains ont un cycle de vie managé, avec le runtime Orleans responsable de l’activation/de la désactivation et du placement/localisation des grains en fonction des besoins. Cela permet au développeur d’écrire du code comme si tous les grains sont toujours en mémoire.

Qu’est-ce que les silos ?

Un silo est un autre exemple de primitive Orleans. Un silo héberge un ou plusieurs grains. Le runtime Orleans est ce 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 en tant que cluster, les silos se coordonnent les uns avec les autres pour distribuer le travail et détecter et récupérer des défaillances. Le runtime permet aux grains hébergés dans le cluster de communiquer entre eux comme s’ils se trouvent dans un seul processus. Pour vous aider à visualiser la relation entre les clusters, les silos et les grains, tenez compte du diagramme suivant :

Le diagramme précédent montre la relation entre les clusters, les silos et les grains. Vous pouvez avoir n’importe quel nombre de clusters, chaque cluster a un ou plusieurs silos, et chaque silo a un ou plusieurs grains.

Outre le modèle de programmation principal, les silos fournissent aux grains une gamme de services d’exécution tels que des minuteurs, des rappels (minuteurs persistants), la persistance, les transactions, les flux de données, 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é.

Que puis-je faire avec Orleans?

Orleans est une infrastructure pour la création d’applications natives cloud et doit être prise en compte chaque fois que vous créez des applications .NET qui devront éventuellement être mises à l’échelle. Il existe des façons apparemment infinies d’utiliser Orleans, mais voici quelques-unes des façons les plus courantes ; Jeux, banques, applications chat, suivi GPS, trading boursier, paniers d’achat, applications de vote, etc. Orleans est utilisé par Microsoft dans Azure, Xbox, Skype, Halo, PlayFab, Gears of War et de nombreux autres services internes. Orleans dispose de nombreuses fonctionnalités qui facilitent l’utilisation pour diverses applications.

Persévérance

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

Pendant qu’un grain est actif, l’état est conservé en mémoire afin que les demandes de lecture puissent être traitées sans accéder à la mémoire de 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, voir Persistance des grains.

Minuteurs et rappels

Les rappels sont un mécanisme de planification durable pour les grains. Elles peuvent être utilisées pour s’assurer que certaines actions sont effectuées à un moment 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. C’est ce que l’on appelle le placement des grains.

Le processus de placement dans Orleans est entièrement configurable. Les développeurs peuvent choisir parmi un ensemble de stratégies de placement prêtes à l’emploi, telles que des stratégies aléatoires, locales et basées sur la charge, ou une logique personnalisée peut être configurée. Cela permet une flexibilité totale pour décider où les grains sont créés. Par exemple, les grains peuvent être placés sur un serveur proche des ressources qu'ils doivent utiliser ou 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 tenir compte de ce problème, les interfaces grain dans Orleans peuvent être versionnées.

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 permet également des clusters hétérogènes, où différents silos ont différents ensembles d’implémentations de grain disponibles.

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

Travailleurs 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 d’autorisation, de journalisation et de télémétrie et de gestion des erreurs sont tous considérés comme courants.

Contexte de requête

Les métadonnées et d’autres informations peuvent être transmises avec une série de requêtes à l’aide du contexte de requête . Le contexte de demande peut être utilisé pour contenir des informations de suivi distribuées ou toute autre valeur définie par l’utilisateur.

Transactions ACID distribuées

En plus du 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 (il n'y a pas de gestionnaire central de transactions ou de coordinateur de transactions) et ont une isolation 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. Orleans Les flux 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 ou ne s'abonne à un flux. Cela permet un découplage plus important des producteurs de flux et des consommateurs les uns des autres et l’infrastructure.

Le traitement de flux est fiable : les grains peuvent stocker des points de contrôle (curseurs) et rétablir un point de contrôle stocké pendant l’activation ou à tout moment ultérieur. Les flux prennent en charge la remise par lots de messages aux consommateurs afin d’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 d’autres.

Un nombre arbitraire de flux peut être multiplexé sur un plus petit nombre de files d’attente et la responsabilité de traitement de ces files d’attente est équilibrée uniformément sur le cluster.

Introduction à la vidéo Orleans

Si vous êtes intéressé par une présentation vidéo de Orleans, consultez la vidéo suivante :

Étapes suivantes

didacticiel : Créer une application Orleans minimale