Architektura. Asynchro, niespójność danych. Trochę Legacy.

0

Mamy 3 systemy.
Bank.
Firma od której Bank kupił oprogramowanie dajmy jej nazwę „MięsoLux” XD
Integrator - brzmi jak seryjny morderca (jestem w tym zespole i nikogo nie zabiliśmy).

Bank jak wiadomo ma pierdyliat swoich uslug, które w tym przypadku są niskopoziomowe.
Miesolux ma opcje dość wysokopoziomowe.

Przykład: Chcemy przez miesolux dokonać zakupu mięsa - jest to jedna operacja.
Zakup miesa od strony banku składa się z 3 etapów.

  1. Zablokowania środków klienta banku, który chce kupić mieso.
  2. Wysłanie do drugiego banku informacji o tym, ze ten drugi bank dostanie pieniazki, ponieważ właściciel swini ze sklepu MiesoLux jest klientem drugiego banku.
  3. Usunięcie środków klienta z konta.

Najważniejsze w tych operacjach, ze jest sa one typu mutable dla innych systemów. Wiec wprowadzają chwilowa niespójność danych.

Gdy 2 operacja nie pyknie, mamy problem. Trzeba ustalić polityke i o tej polityce chciałbym pogadać.

Czytałem richardsona o mikroserwisach. On powiedział, żeby używać sag. Problem w tym, ze projekt mamy typu legacy a dopiero pod koniec teraz w projekcie zostało powiedziane, ze trzeba będzie zabezpieczyć się przed niespójnością danych.
Czyli operujemy na istniejącym systemie.

Cel jest taki by jak najmniejszymi środkami osiągnąć rezultat.

Transakcje rozproszone odpadają, bo to niemożliwe. Działamy NIE tylko na bazach a innych interfejsach, jak np wiadomosc do innego banku, gdzie Nie ma rollbacku.

Nigdy nie korzystałem z sag, frameworkow sagowych itd. Znam je tylko z poziomu koncepcyjnego, ale tu trzeba isc w ta stronę. Nie wiem tylko jak.

Myslalem, żeby zrobić zabezpieczenie w postaci składowania obecnego stanu operacji do oddzielnej bazy danych.
Czyli zaszła operacja -> event. Zapis do bazy. Mamy maszynę stanu w bazie, ale co z tym dalej to nie wiem...Robi się skomplikowanie.

Drugie pytanie, to jak taki event wysłać i wygenerować najlepiej do tego przypadku?

Czyli 2 dość mocno otwarte pytania.
Jak generować eventy i co dalej z nimi robić w tym przypadku.

3

Idziesz w dobrą stronę z sagami i eventami.
Możesz też pójść w stronę równocześnie Event Sourcingu. To że wiesz o tych wymaganiach dopiero teraz, i zmieniają CI całą architekturę systemu... to trudno. Trzeba było żeby ktoś Ci wcześniej powiedział, nie Twoja wina. Tak potrzebujesz czegoś typu saga, co wie, czy operacja się udała i jeśli nie to możliwości jej odwrócenia. JAK to zrobić to zależy. Można na eventach typu "Zablokowano Środki" {Powód = "Na kotlety" } i np "Odblokowano środki" {Powód = "Kotlety był za stare" }, albo zmieniając stan w bazie o właściwe wartości.
Dodam, że przy typowych operacjach księgowych, eventy są jedną z najlepszych implementacji bo widać co i kiedy się stało, a także DLACZEGO. Środki zablokowano, odblokowano, wyszły z konta, wróciły... zamiast mieć tylko stan obecny. Zwykle stan obecny to nie wystarczy przy wszelakich audytach i kontroli.

Co do technologii i frameworków i pytania o jak:
No tak jak jest najlepiej w technologii w której piszesz. Znajdujesz coś co obsługuje Sagi, np słyszałem że Java ma Axon, ale nie piszę w Javie i nie mogę polecić. Co do baz danych - EventStore to chyba najciekawsze wyjście jeśli byś szedł w Event Sourcing.

2

Tak jak pisze AreQrm, z tym że EventStore radzę dobrze przetestować, uruchomić nie-produkcyjny system i upewnić się że nam odpowiada. A i wtedy wziąć dobrą poprawkę na naszą opinię.

W poprzedniej pracy stosowaliśmy właśnie event sourcing w oparciu o Event Store, i wszyscy opinie mieli... mieszane. Do tego stopnia że następnym razem sam bym chyba wolał napisać własną bibliotekę ES w oparciu o jakąś bazę danych.

0

Integrator:

  • dostaje dane, że środki zostały zablokowane w celu zakupu świni
  • zapisuje sobie lokalnie tę informację ze statusem pending
  • wywołuje świniarnię w celu nabycia świni
  • jak dostanie OK, to przestawia status na "świnia kupiona" i informuje o tym system bankowy (zmiana blokady na obciążenie konta)
  • jak dostanie ERROR, to przestawia na status "świnia zdechła" i informuje system bankowy, że można zwolnić blokadę.

Realnie, polecam rozrysować sobie diagram maszyny stanów i zastanowić się co się czy system bankowy zawsze odpowie prawidłowo.

1 użytkowników online, w tym zalogowanych: 0, gości: 1