Teraz omówimy architekturę mikrousług dla problemu, ze względu na potrzebną skalowalność aplikacji w produkcji. Jest to również kluczowe dla celów programistycznych, ponieważ Zadanie 1 i Zadanie 2 zostały niedawno dodane nowe funkcje/parametry i skalują się w różny sposób w rozwoju.
To jest dokładnie to, co dobrze robi platforma przetwarzania strumieni. Do rozwiązania tego problemu polecam system taki jak Apache Kafka lub Apache Pulsar.
Czy powinny istnieć co najmniej dwie różne usługi dla zadania 1 i zadania 2, a może nawet jedna do rzeczywistej kontroli stanu iteracji/symulacji?
Zadanie 1 i zadanie 2 to tak zwane procesory strumieniowe , czytają (subskrybują) jeden temat , wykonując pewne operacje/transformacje i pisząc (publikując) do innego tematu .
Główne pytanie brzmi, jakie są argumenty przemawiające za architekturą mikroserwisową ze względu na prawdopodobnie wąskie gardło komunikacyjne/sieciowe? Jedynym sposobem, aby to przyspieszyć, jest umieszczenie w pamięci wszystkich potrzebnych danych do zadania symulacji i przechowywanie ich tam przez cały czas, aby uniknąć wąskiego gardła w sieci?
Ponownie, to jest dokładnie ten problem, że system taki jak Apache Kafka czy Apache Pulsar dobrze sobie radzi. Do skalowania zapisuje i odczytuje w systemie przetwarzania strumieniowego, możesz partycjonować Twoje tematy .
