Wir implementieren einen Auktions-Cloud-Service, der Bestellungen von einem externen API-Service auf Anfrage erhält. Jeder erhaltene Auftrag ist ein 1: 1 zu einer Auktion .
Wir können mehr als 2000 Bestellungen (Auktionen) pro Tag haben. Wir haben uns entschieden, Microservices + Redux zu verwenden, um Probleme zwischen Aufträgen und Auktionen zu trennen.
Nachstehend finden Sie die Erklärung zu jedem Service.
Externe API
Enternal API ist nur eine Website, die Bestellungen an unseren Bestellservice weiterleitet und Updates von unserem Bestellservice erhält, auf die wir keinen Einfluss haben.
Bestellservice
Bestellungen enthalten eine Reihe von Informationen (Eigenschaften), die der Kunde (mobile App) verwendet, um Informationen zu erhalten, um über den Beitritt zu einer Auktion zu entscheiden. So kann beispielsweise eine Bestellung aussehen:
%Vor%Im Bestellservice können die Aufträge jederzeit vom Server vor Beginn der Auktion aktualisiert werden (Adresse, Name, OpenPrice, MinPrice, Status, etc) die Aktionen unten .
%Vor%Auktionsservice
Ein Auktionsobjekt in diesem Service kann wie folgt aussehen:
%Vor%Auktionen können durch diese Aktionen aktualisiert werden:
%Vor%API-Dienst
Es funktioniert nur als Gateway zwischen der Front-End-App und den Microservices. Empfangen und senden Sie Anfragen von Kunden (Handys) an Bestellservice oder Auktionsservice in Form von Aktionen.
Workflow:
1 - Externe API sendet Aufträge des Tages über LOAD_ORDERS an Bestellservice . Außerdem wird eine CREATE_AUCTIONS-Aktion an den Aktionsservice zum Erstellen gesendet eine Auktion für jede Bestellung.
2 - Nutzer öffnen die mobile App und erhalten die Liste der Bestellungen des Tages mit Details einschließlich der offenen Preise von Bestellservice .
3 - Benutzer treten einer bestimmten Bestellung bei - API-Service erstellt einen Bieter -Agent, der Gebote abgibt. - API-Service sendet eine Join-Aktion über JOIN_AUCTION, um einer Auktion im Auktionsservice
beizutreten4 - Ein Auktionator -Agent startet die Auktion und die Gebote beginnen.
5 - Gebuchte Bieter agents beginnen, Gebote über die Aktion PLACE_BID auf Auktionsservice zu platzieren.
6 - Wenn die Auktion beendet ist, beendet der Auktionator die Auktion, indem er END_AUCTION abschickt.
7 - Wenn die Auktion endet, werden die Verkaufspreis- und Auktionsdetails (über das Objekt) über die SET_ORDER_AUCTION an den Bestellservice gesendet.
8 - Der Bestellservice bearbeitet die SET_ORDER_AUCTION und aktualisiert den Bestellstatus mit dem endgültigen Objekt salePrice und der Auktion und wartet dann auf die Zahlung .
9 - Sobald die Zahlungsinformationen vom Kunden empfangen wurden, werden sie vom externen Service über den Bestellservice
übermitteltMeine Fragen sind:
Ist der Workflow über einen vernünftigen Ansatz für die Verwendung von Microservices + Redux und die Aktualisierung jedes Dienststatus?
Es ist in Ordnung, Aktionen von einem Microservice zu einem anderen zu senden, wenn Sie redux microservices verwenden? Meine Frage ist, weil bei der Verwendung von Microservices + Event Sourcing + CQRS, Dienstleistungen Interkommunikation nicht empfohlen werden, sondern mit einer Sagas, die als Zwischen-Service, die Ereignisse in Befehle konvertieren arbeiten.
Meine andere Frage ist, wo die Geschäftslogik (Validierung) platziert werden soll, zum Beispiel kann ein Bieter kein Gebot senden, wenn die Auktion nicht gestartet oder bereits beendet ist. Ein Bieter kann kein Gebot senden, wenn er nicht beigetreten ist Auktion noch. Würden Sie diese Logik setzen? in Aktion, Middleware oder Reducer? und wie man Fehler zurück zu Clients behandelt?
Welche Best Practices gibt es im Allgemeinen für Microservices + Redux?
Was sind die Vor- und Nachteile der Verwendung von Microservices + Redux vs Microservices + Event Sourcing + CQRS ?
Entschuldigung für den langen Post, ich brauche nur ein wenig Orientierung, weil ich keine Dokumentation zu diesem Thema finden kann und ich bin mir nicht sicher, ob ich mich diesem Recht nähere.
Jeder Rat würde geschätzt werden !!!
Tags und Links redux redux-thunk