Nous discutons maintenant d'une architecture de microservice pour le problème, en raison de l'évolutivité nécessaire de l'application en production. Cela est également crucial à des fins de développement, car Task1 et Task2 ont récemment été ajoutées à de nouvelles fonctionnalités/paramètres et évoluent différemment dans le développement.
C'est exactement ce que fait une plate-forme de traitement de flux. Je recommande d'utiliser un système comme Apache Kafka ou Apache Pulsar pour ce problème.
Devrait-il y avoir au moins deux services différents pour Task1 et Task2 et peut-être même un pour le contrôle d'état d'itération/simulation réel ?
Task1 et Task2 sont ce qu'on appelle des processeurs de flux , ils lisent (s'abonnent à) un sujet , effectuer des opérations/transformations et écrire (publier) dans un autre sujet .
La principale question ici est de savoir quels sont les arguments en faveur d'une architecture de microservice en raison probablement d'un goulot d'étranglement de communication/réseau ? La seule façon d'accélérer cela est de générer toutes les données nécessaires à la tâche de simulation en mémoire et de les y conserver tout le temps, pour éviter le goulot d'étranglement du réseau ?
Encore une fois, c'est exactement le problème qu'un système comme Apache Kafka ou Apache Pulsar fait bien. Pour redimensionner écrit et lit dans un système de traitement de flux, vous pouvez partitionner vos sujets .
