Ceci est un article invité de l'équipe d'Orléans. Orleans est un framework multiplateforme pour la construction d'applications distribuées avec .NET. Pour plus d'informations, voir https://github.com/dotnet/orleans .Nous sommes ravis d'annoncer la sortie d'Orléans 3.0. Un grand nombre d'améliorations et de correctifs ont été apportés, ainsi que plusieurs nouvelles fonctionnalités, depuis Orléans 2.0. Ces changements ont été motivés par l'expérience de nombreuses personnes exécutant des applications basées à Orléans en production dans un large éventail de scénarios et d'environnements, et par l'ingéniosité et la passion de la communauté mondiale d'Orléans qui s'efforce toujours d'améliorer la base de code, de la rendre plus rapide et plus encore. flexible. UN GRAND merci à tous ceux qui ont contribué à cette version de différentes manières!
Changements majeurs depuis Orléans 2.0
Orleans 2.0 est sorti il y a un peu plus de 18 mois et depuis, Orleans a fait des progrès importants. Certaines des principales modifications depuis la version 2.0 sont les suivantes:
- Transactions ACID distribuées - plusieurs grains peuvent rejoindre une transaction indépendamment de l'endroit où leur état est stocké
- Un nouveau planificateur, qui à lui seul a augmenté les performances de plus de 30% dans certains cas
- Un nouveau générateur de code basé sur l'analyse de code Roslyn
- Appartenance au cluster réécrite pour une vitesse de récupération améliorée
- Support de co-hébergement
Ainsi que de nombreuses autres améliorations et correctifs.
Depuis les jours de travail sur Orléans 2.0, l'équipe a établi un cycle vertueux de mise en œuvre ou d'intégration de certaines fonctionnalités, telles qu'un hôte générique, des options nommées, en étroite collaboration avec l'équipe .NET avant que ces fonctionnalités ne soient prêtes à faire partie du .NET Versions principales, contribuant aux commentaires et améliorations "en amont", et dans les versions ultérieures passant à leurs implémentations finales livrées avec les versions .NET. Pendant le développement d'Orléans 3.0, ce cycle s'est poursuivi, avec le code Bedrock utilisé par Orleans 3.0.0-beta1 avant qu'il ne soit finalement livré dans le cadre de .NET 3.0. De même, la prise en charge de TLS sur les connexions de socket TCP a été implémentée dans le cadre d'Orléans 3.0 et devrait faire partie d'une future version de .NET Core. Nous considérons cette collaboration en cours comme notre contribution à l'écosystème .NET plus large, dans le véritable esprit de l'Open Source.
Remplacement de la couche réseau avec ASP.NET Bedrock
Le soutien à la sécurisation de la communication avec
TLS est une demande majeure depuis un certain temps, tant de
la communauté que des partenaires internes. Avec la version 3.0, nous introduisons la prise en charge TLS, disponible via le package
Microsoft.Orleans.Connections.Security . Pour plus d'informations, consultez l'
exemple TransportLayerSecurity .
L'implémentation de la prise en charge TLS était une entreprise majeure en raison de la façon dont la couche réseau dans les versions précédentes d'Orléans était implémentée: elle ne pouvait pas être facilement adaptée pour utiliser
SslStream , qui est la méthode la plus courante pour implémenter TLS. Avec TLS comme moteur, nous nous sommes lancés dans un voyage pour réécrire la couche réseau d'Orléans.
Orléans 3.0 remplace l'intégralité de sa couche réseau par une couche intégrée au
projet Bedrock , une initiative de l'équipe ASP.NET. L'objectif de Bedrock est d'aider les développeurs à créer des clients et des serveurs réseau rapides et robustes.
L'équipe ASP.NET et l'équipe d'Orléans ont travaillé ensemble pour concevoir des abstractions qui prennent en charge à la fois les clients réseau et les serveurs, sont indépendantes du transport et peuvent être personnalisées à l'aide d'un middleware. Ces abstractions nous permettent de modifier le transport réseau via la configuration, sans modifier le code réseau interne propre à Orléans. Le support TLS d'Orléans est implémenté comme un middleware Bedrock et notre intention est de le rendre générique afin qu'il puisse être partagé avec d'autres dans l'écosystème .NET.
Bien que l'impulsion de cette entreprise ait été de permettre le support TLS, nous constatons une amélioration d'environ 30% du débit en moyenne dans nos tests de charge nocturne.
La réécriture de la couche réseau impliquait également le remplacement de notre pool de tampons personnalisé par la dépendance à
MemoryPool<byte> et en apportant cette modification, la sérialisation tire désormais davantage parti de
Span<T> . Certains chemins de code qui reposaient auparavant sur le blocage via des threads dédiés appelant
BlockingCollection<T> utilisent désormais
Channel<T> pour transmettre les messages de manière asynchrone. Cela entraîne moins de threads dédiés, déplaçant le travail vers le pool de threads .NET à la place.
Le protocole de fil central pour Orléans est resté fixe depuis sa sortie initiale. Avec Orleans 3.0, nous avons ajouté la prise en charge de la mise à niveau progressive du protocole réseau via la négociation de protocole. La prise en charge de la négociation de protocole ajoutée dans Orleans 3.0 permet de futures améliorations, telles que la personnalisation du sérialiseur principal, tout en conservant la compatibilité descendante. L'un des avantages du nouveau protocole de mise en réseau est la prise en charge des connexions silo à silo en duplex intégral plutôt que les paires de connexions simplex établies précédemment entre les silos. La version du protocole peut être configurée via
ConnectionOptions.ProtocolVersion .
Co-hébergement via l'hôte générique
Co-héberger Orléans avec d'autres frameworks, comme ASP.NET Core, dans le même processus est désormais plus facile qu'avant grâce à l'
hôte générique .NET .
Voici un exemple d'ajout d'Orléans aux côtés d'ASP.NET Core à un hôte utilisant
UseOrleans :
var host = new HostBuilder() .ConfigureWebHostDefaults(webBuilder => {
En utilisant le générateur d'hôte générique, Orléans partagera un fournisseur de services avec d'autres services hébergés. Cela permet à ces services d'accéder à Orléans. Par exemple, un développeur peut injecter
IClusterClient ou
IGrainFactory dans un contrôleur ASP.NET Core MVC et appeler des grains directement à partir de son application MVC.
Cette fonctionnalité peut être utilisée pour simplifier votre topologie de déploiement ou pour ajouter des fonctionnalités supplémentaires à une application existante. Certaines équipes utilisent en interne le co-hébergement pour ajouter des
sondes de réactivité et de réactivité Kubernetes à leurs silos d'Orléans à l'aide des
bilans de santé ASP.NET Core .
Améliorations de la fiabilité
Les clusters récupèrent désormais plus rapidement des échecs grâce à des potins étendus. Dans les versions précédentes d'Orléans, les silos envoyaient des potins d'adhésion à d'autres silos, leur demandant de mettre à jour les informations d'adhésion. Les messages de potins incluent désormais des instantanés versionnés et immuables de l'appartenance au cluster. Cela améliore le temps de convergence après qu'un silo rejoint ou quitte le cluster (par exemple pendant la mise à niveau, la mise à l'échelle ou après une défaillance) et atténue les conflits sur le magasin d'appartenance partagé, permettant des transitions de cluster plus rapides. La détection des pannes a également été améliorée, avec plus de messages de diagnostic et des améliorations pour assurer une détection plus rapide et plus précise. La détection des pannes implique des silos dans un cluster qui se surveillent en collaboration, chaque silo envoyant des sondes d'intégrité périodiques à un sous-ensemble d'autres silos. Les silos et les clients se déconnectent également de manière proactive des silos qui ont été déclarés disparus et ils refuseront les connexions à ces silos.
Les erreurs de messagerie sont désormais traitées de manière plus cohérente, ce qui entraîne la propagation des erreurs d'invite à l'appelant. Cela aide les développeurs à découvrir les erreurs plus rapidement. Par exemple, lorsqu'un message ne peut pas être entièrement sérialisé ou désérialisé, une exception détaillée sera renvoyée à l'appelant d'origine.
Extensibilité améliorée
Les flux peuvent désormais avoir des adaptateurs de données personnalisés, leur permettant d'ingérer des données dans n'importe quel format. Cela donne aux développeurs un meilleur contrôle sur la façon dont les éléments de flux sont représentés dans le stockage. Il permet également au fournisseur de flux de contrôler la façon dont les données sont écrites, ce qui permet aux steams de s'intégrer aux systèmes hérités et / ou aux services non-Orléans.
Les extensions de grain permettent d'ajouter un comportement supplémentaire à un grain lors de l'exécution en attachant un nouveau composant avec sa propre interface de communication. Par exemple, les transactions d'Orléans utilisent des extensions de grain pour ajouter des méthodes de cycle de vie de transaction, telles que
Préparer ,
Valider et
Abandonner , à un grain de manière transparente pour l'utilisateur. Les extensions Grain sont désormais également disponibles pour les services Grain et les cibles système.
L'état transactionnel personnalisé peut désormais déclarer les rôles qu'il peut remplir dans une transaction. Par exemple, une implémentation d'état transactionnel qui écrit des événements de cycle de vie de transaction dans une file d'attente Service Bus ne peut pas remplir les fonctions du gestionnaire de transactions car elle est en écriture seule.
Les stratégies de placement prédéfinies sont désormais accessibles au public, de sorte que tout directeur de placement peut être remplacé pendant le temps de configuration.
Rejoignez l'effort
Maintenant que Orleans 3.0 est sorti, nous tournons notre attention vers les prochaines versions - et nous avons des plans passionnants! Venez rejoindre notre communauté chaleureuse et accueillante sur
GitHub et
Gitter et aidez-nous à faire de ces plans une réalité.
Équipe d'Orléans