Partager via


Microsoft Orleans

Orleans est une infrastructure multiplateforme conçue pour simplifier la création d’applications distribuées. Qu’il s’agisse d’une mise à l’échelle d’un serveur unique vers des milliers d’applications basées sur le cloud, Orleans fournit des outils permettant de gérer les complexités des systèmes distribués. Il étend les concepts C# familiers aux environnements multi-serveurs, ce qui permet aux développeurs de se concentrer sur la logique de l’application.

Voici les offres suivantes Orleans :

  • Il est conçu pour être échelonné d'une manière flexible. Ajoutez ou supprimez des serveurs, et Orleans s'ajuste en conséquence pour maintenir la tolérance aux pannes et l’extensibilité.
  • Il simplifie le développement d’applications distribuées avec un ensemble commun de modèles et d’API, ce qui le rend accessible même pour les nouveaux systèmes distribués.
  • Il est natif dans le cloud et s’exécute sur des plateformes où .NET est pris en charge ( Linux, Windows, macOS, etc.).
  • Il prend en charge les options de déploiement modernes telles que Kubernetes, Azure App Service et Azure Container Apps.

Orleans est souvent appelé « Distributed .NET » en raison de son focus sur la création de services natifs cloud résilients et évolutifs. Examinons ensuite le modèle d’acteur.

Modèle d’acteur

Orleans est basé sur le modèle d’acteur. Apparu au début des années 1970, le modèle d’acteur est désormais un élément central de Orleans. Dans le modèle d’acteur , chaque acteur est un objet léger, simultané et immuable encapsulant un élément d’état et un comportement correspondant. Les acteurs communiquent exclusivement à l’aide de messages asynchrones. Orleans a notamment inventé l’abstraction d’acteur virtuel , 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.

Cette nouvelle approche permet de créer 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 distribuées hautement parallèles sans limiter les fonctionnalités ni imposer de contraintes.

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 :

Un grain est composé d’une identité stable, d’un comportement et d’un état.

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

Les grains peuvent avoir des données d’état volatiles ou persistantes 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. Orleans conserve l’état du grain en mémoire pendant que le grain est actif, ce qui entraîne une latence plus faible et une charge moindre sur les magasins de données.

Cycle de vie géré d’un grain Orleans.

Le Orleans runtime instancie automatiquement les grains à la demande. Les grains non utilisés pendant un certain temps sont automatiquement supprimés de la mémoire pour libérer des ressources. Cette suppression est possible en raison de leur identité stable, ce qui permet l'invocation des grains, qu'ils soient chargés en mémoire ou non. Cela permet également une récupération transparente en cas d’échec, car l’appelant n’a pas besoin de savoir sur quel serveur un grain est instancié à tout moment. Les grains possèdent un cycle de vie géré, où le runtime est responsable de leur activation, désactivation, placement et localisation selon les besoins. Cela permet 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 Orleans runtime 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 coordonnent 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 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 :

Un cluster a un ou plusieurs silos et un silo a un ou plusieurs grains.

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

En plus du modèle de programmation principal, les silos fournissent des grains avec des services d’exécution tels que les minuteurs, les rappels (minuteurs persistants), la persistance, les transactions, les flux, etc. Pour plus d’informations, consultez Ce qui peut être fait 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é.

Qu’est-ce qui peut être fait avec Orleans?

Orleans est une infrastructure pour la création d’applications natives cloud et doit être prise en compte lors de la création d’applications .NET qui peuvent éventuellement avoir besoin d’être mises à l’échelle. Il existe apparemment des façons infinies d’utiliser Orleans, mais voici quelques-unes des plus courantes : jeux, banques, applications de conversation, suivi GPS, bourse de trading, paniers d’achat, applications de vote, etc. Microsoft utilise Orleans 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 différentes applications.

Persévérance

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

Pendant qu’un grain s’exécute, Orleans conserve l’état en mémoire pour traiter les demandes de lecture sans accéder au stockage. Lorsque le grain met à jour son état, l'appel de IStorage.WriteStateAsync garantit que le magasin de stockage est mis à jour pour assurer la durabilité et la 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. Utilisez-les pour garantir qu’une action se termine à un moment ultérieur, même si le grain n’est pas activé. 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 s’active dans Orleans, le runtime décide du serveur (silo) sur lequel l’activer. Ce processus est appelé placement des grains.

Le processus de placement dans Orleans est entièrement configurable. Choisissez parmi les stratégies de placement prêtes à l’emploi, telles que aléatoires, plutôt locales et basées sur la charge, ou configurez une logique personnalisée. Cela permet une flexibilité totale pour décider où les grains sont créés. Par exemple, placez des grains sur un serveur proche des ressources dont ils ont besoin pour fonctionner, ou proche 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 en toute sécurité en tenant compte des changements peut être difficile, en particulier dans les systèmes avec état. Pour tenir compte de ce problème, les interfaces de grain peuvent être versionnées dans Orleans.

Le cluster conserve une cartographie des implémentations de grains disponibles sur les silos ainsi que leurs versions. Le runtime utilise ces informations de version avec des stratégies de positionnement pour prendre des décisions de placement lors du routage des appels vers les grains. Outre la mise à jour sécurisée d’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 travailleurs sans état sont des grains spécialement marqués sans état associé qui peuvent s’activer simultanément sur plusieurs silos. 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’appel de grain est une logique commune à de nombreux grains. Orleans prend en charge les filtres pour les appels entrants et sortants. Les utilisations courantes incluent l’autorisation, la journalisation et la télémétrie et la gestion des erreurs.

Contexte de requête

Transmettez des métadonnées et d’autres informations avec une série de requêtes à l’aide du contexte de requête. Utilisez le contexte de demande pour contenir des informations de suivi distribuées ou d’autres valeurs définies.

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 à des transactions ACID ensemble, quel que soit l’emplacement où leur état est finalement stocké. Les transactions dans Orleans ce domaine sont distribuées et décentralisées (ce qui signifie qu’il n’y a pas de gestionnaire de transactions central ou coordinateur) et ont une isolation sérialisable.

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

Flux

Les flux aident à 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 de créer ou d’inscrire avant qu’un grain ou un client publie ou s’abonne. 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 restaurer un point de contrôle stocké lors de l'activation ou à tout autre 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 traiter ces files d’attente est équilibrée uniformément sur le cluster.

Introduction à la vidéo Orleans

Pour une présentation vidéo de Orleans, consultez la vidéo suivante :

Étapes suivantes