J'essaie de migrer vers la solution existante de matrice de service. Une partie de cela est le nombre de travailleurs qui écoutent les files d'attente. Par exemple, j'ai quelques files d'attente:Travailleurs évolutifs dans Azure Service Fabric
Task1_Queue, Task2_Queue ... TaskN_Queue
Pour chaque file d'attente, il y a une certaine logique de traitement des messages d'entre eux, disons travailleurs. Ils font des tâches différentes comme générer d'énormes fichiers de rapport et télécharger vers Azure Storage ou faire de petites mises à jour dans la base de données.
La question est de savoir comment concevoir des services afin d'avoir une bonne évolutivité des travailleurs. Mes pensées étaient:
Option 1 - Chaque file d'attente aura un service sans état séparé. Pas de moyen facile d'autoscaler un seul service.
Option 2 - Implémenter les opérateurs en tant qu'acteurs distincts et disposer d'un service unique sans état pour écouter les files d'attente et les acteurs d'appel. Avantages - mise à l'échelle automatique hors de la boîte, comme pour chaque message de la file nouvel acteur sera créé. Inconvénients - les acteurs seront jetables.
Les données doivent-elles être conservées entre les exécutions de tâches? Si c'est le cas, les acteurs deviennent beaucoup moins réalisables. –
Non, fondamentalement, le worker reçoit un message de requête le traite d'une manière ou d'une autre et renvoie l'exécution –
Comme pour l'option 1: vous pouvez créer plusieurs instances d'un service à l'échelle. –