Partager via

Meilleures pratiques de conception d’application Azure Service Fabric

  • Article

Cet article fournit des conseils sur les bonnes pratiques de création d’applications et de services sur Azure Service Fabric.

Se familiariser avec Service Fabric

Guide de conception d’application

Familiarisez-vous avec l’architecture générale des applications Service Fabric et leurs considérations relatives à la conception.

Choisir une passerelle d’API

Utilisez un service de passerelle d’API qui communique avec les services principaux qui peuvent ensuite être montés en charge. Les services de passerelle d’API les plus couramment utilisés sont :

Service sans état

Nous vous recommandons de toujours commencer par créer des services sans état à l’aide de Reliable Services, et de stocker l’état dans une base de données Azure, Azure CosmosDB ou Stockage Azure. L’état externalisé est l’approche la plus familière pour la plupart des développeurs. Cette approche vous permet également de tirer parti des fonctionnalités de requête sur le magasin.

Quand utiliser des services avec état ?

Envisagez des services avec état lorsque votre scénario implique une faible latence et que vous devez conserver les données à proximité des ressources de calcul. Il peut s’agir de scénarios tels que des appareils jumeaux numériques IoT, l’état du jeu, l’état de la session, la mise en cache de données à partir d’une base de données et les flux de travail durables pour suivre les appels d’autres services.

Choisissez la période de conservation des données :

  • Données mises en cache. Utilisez la mise en cache quand la latence vers des magasins externes est un problème. Utilisez un service avec état comme cache de données ou envisagez d’utiliser le cache distribué SoCreate Service Fabric open source. Dans ce scénario, vous n’avez pas à vous inquiéter de perdre toutes les données dans le cache.
  • Données associées à un délai. Dans ce scénario, vous devez conserver les données à proximité des ressources de calcul pendant un certain délai pour des raisons de latence, mais vous pouvez vous permettre de perdre ces données en cas de sinistre. Par exemple, dans de nombreuses solutions IoT, les données doivent être proches des ressources de calcul (par exemple en cas de calcul de la température moyenne sur les derniers jours), mais si ces données sont perdues, les points de données spécifiques enregistrés ne sont pas si importants. En outre, dans ce scénario vous vous souciez généralement peu de la sauvegarde de points de données individuels. Vous sauvegardez uniquement les valeurs moyennes calculées qui sont régulièrement écrites vers le stockage externe.
  • Données à long terme. Des collections fiables peuvent stocker vos données de manière permanente. Dans ce cas, vous devez toutefois vous préparer à la reprise d’activité après sinistre, notamment à la configuration de stratégies de sauvegarde périodiques pour vos clusters. Dans les faits, vous configurez ce qu’il se passe si votre cluster est détruit lors d’un sinistre, auquel cas vous devez créer un nouveau cluster, et comment déployer de nouvelles instances d’application et récupérer à partir de la dernière sauvegarde.

Réduire les coûts et améliorer la disponibilité :

  • Vous pouvez réduire les coûts grâce à des services avec état, car vous n’engagez pas de coûts d’accès aux données et de transactions à partir du magasin distant, et car vous n’avez pas besoin d’utiliser un autre service, tel que le cache Azure pour Redis.
  • L’utilisation de services avec état principalement pour le stockage et non pour le calcul est coûteuse, et nous la déconseillons. Vous pouvez considérer les services avec état comme du calcul avec un stockage local économique.
  • En supprimant les dépendances à d’autres services, vous pouvez améliorer la disponibilité de votre service. La gestion de l’état avec haute disponibilité dans le cluster permet de vous isoler d’autres temps d’arrêt du service ou problèmes de latence.

Comment utiliser Reliable Services

Service Fabric Reliable Services vous permet de créer facilement des services sans et avec état. Pour plus d’informations, consultez l’introduction à Reliable Services.

  • Utilisez toujours le jeton d’annulation de la méthode RunAsync() pour les services sans et avec état et de la méthode ChangeRole() pour les services avec état. Sans cela, Service Fabric ne sait pas si votre service peut être fermé. Le fait de ne pas utiliser le jeton d’annulation peut, par exemple, entraîner des temps de mise à niveau d’applications beaucoup plus longs.
  • Ouvrez et fermez les écouteurs de communications aux moments opportuns et utilisez les jetons d’annulation.
  • Ne combinez jamais du code synchrone et du code asynchrone. Par exemple, n’utilisez pas .GetAwaiter().GetResult() dans vos appels asynchrones. Utiliser async à travers toute la pile des appels.

Comment utiliser Reliable Actors

Service Fabric Reliable Actors vous permet de créer facilement des acteurs virtuels avec état. Pour plus d’informations, consultez l’introduction à Reliable Actors.

  • L’utilisation de la messagerie de publication/d’abonnement entre vos acteurs pour la mise à l’échelle de l’application est vivement recommandée. Parmi les outils qui offrent ce service, citons l’open-source SoCreate Service Fabric Pub/Sub et Azure Service Bus.
  • Rendez l’état d’acteur aussi précis que possible.
  • Gérez le cycle de vie de l’acteur. Supprimez des acteurs si vous ne prévoyez pas de les réutiliser. La suppression des acteurs inutiles est particulièrement importante quand vous utilisez le fournisseur d’état volatile, car tout l’état est stocké en mémoire.
  • En raison de leur concurrence alternée, il est préférable d’utiliser les acteurs comme des objets indépendants. Ne créez pas de graphes d’appels de méthode synchrones à plusieurs acteurs (chacun d’entre eux constituera probablement un appel réseau distinct) ni de requêtes d’acteur circulaires. Celles-ci affectent considérablement les performances et la mise à l’échelle.
  • Ne combinez pas du code synchrone et du code asynchrone. Utilisez async de manière cohérente afin d’éviter les problèmes de performances.
  • N’effectuez pas d’appels longs dans des acteurs. Les appels longs bloquent les autres appels vers le même acteur à cause de la concurrence alternée.
  • Si vous communiquez avec d’autres services à l’aide de la communication à distance Service Fabric et que vous créez un ServiceProxyFactory, créez la fabrique au niveau du service d’acteur et non au niveau de l’acteur.

Diagnostic d'application

Veillez à ajouter la journalisation des applications dans les appels de service. Cela vous aidera à diagnostiquer les scénarios dans lesquels les services s’appellent mutuellement. Par exemple, quand A appelle B appelle C appelle D, l’appel peut échouer n’importe où. Si vous n’avez pas suffisamment de journalisation, les échecs sont difficiles à diagnostiquer. Si la journalisation des services est trop importante en raison des volumes d’appel, veillez à enregistrer au minimum les erreurs et avertissements.

Guide de conception sur Azure