Jetzt diskutieren wir eine Microservice-Architektur für das Problem, aufgrund der erforderlichen Skalierbarkeit der Anwendung in der Produktion. Auch für Entwicklungszwecke ist dies von entscheidender Bedeutung, da Task1 und Task2 kürzlich neue Funktionen/Parameter hinzugefügt wurden und in der Entwicklung unterschiedlich skaliert werden.
Genau das leistet eine Stream-Processing-Plattform. Ich empfehle, für dieses Problem ein System wie Apache Kafka oder Apache Pulsar zu verwenden.
Soll es mindestens zwei unterschiedliche Dienste für Task1 und Task2 geben und vielleicht sogar einen für die eigentliche Zustandssteuerung der Iteration/Simulation?
Task1 und Task2 sind sogenannte Stream-Prozessoren , sie lesen (abonnieren) ein Thema , einige Operationen/Transformationen durchführen und zu einem anderen Thema schreiben (veröffentlichen). .
Die Hauptfrage hier ist, was die Argumente für eine Microservice-Architektur aufgrund eines wahrscheinlichen Kommunikations-/Netzwerkengpasses sind. Die einzige Möglichkeit, dies zu beschleunigen, besteht darin, alle erforderlichen Daten für die Simulationsaufgabe im Speicher zu erzeugen und dort die ganze Zeit zu halten, um den Netzwerkengpass zu vermeiden?
Auch hier ist genau das Problem, das einem System wie Apache Kafka oder Apache Pulsar gut tut. Zum Skalieren schreibt und liest in einem Stream-Verarbeitungssystem, können Sie partitionieren Ihre Themen .
