Comprendre quand utiliser les services avec état et quand s’appuyer sur la persistance externe dans Azure Service Fabric
Une option que vous avez est de conserver « une partie » de l’état dans l’acteur (disons ce qui pourrait être considéré comme des données chaudes qui doivent être rapidement disponibles) et de stocker tout le reste sur une infrastructure de stockage « traditionnelle » comme SQL Azure, DocDB, etc.
Il est difficile d’avoir une règle générale sur ce qui constitue trop d’état local, mais peut-être cela aide-t-il de réfléchir en termes de données chaudes vs données froides.
Les Reliable Actors offrent également la possibilité de personnaliser le StateProvider, vous pouvez donc aussi envisager d’implémenter un StateProvider personnalisé (en implémentant IActorStateProvider) avec les politiques spécifiques dont vous avez besoin pour être plus efficace avec vos exigences en termes de volume de données, de latence, de fiabilité, etc. (remarque : la documentation est encore très minimale sur l’interface StateProvider, mais nous pouvons publier du code exemple si c’est quelque chose que vous souhaitez explorer).
Concernant les anti-patterns : la remarque porte davantage sur l’implémentation de transactions entre plusieurs acteurs. Les Reliable Actors fournissent une garantie complète sur la fiabilité des données dans les limites d’un acteur. En raison de la nature distribuée et faiblement couplée du modèle Actor, l’implémentation de transactions impliquant plusieurs acteurs n’est pas une tâche triviale. Si les transactions « distribuées » sont une exigence forte, le modèle de programmation Reliable Services est probablement un meilleur choix.