Orkiestracja serwisów w architekturze event driven

Witajcie,

pracujemy nad nową architekturą mikroserwisową do przetwarzania dokumentów i zastanawiam się, jak najlepiej rozwiązać komunikację oraz orkiestrację serwisów.

Mamy kilka serwisów domenowych, a cały proces przebiega sekwencyjnie: A → B → C → D. Każdy z serwisów może działać jako long-running proces.
Kluczowe wymagania to:

• pełna skalowalność i odporność każdego serwisu,
• transakcyjna baza danych przechowująca stan procesu,
• brak konieczności silnej spójności — wystarczy spójność ostateczna.

Chciałbym zastosować tutaj event-driven, aby w pełni uniezależnić serwisy i wzorzec Process Manager jako orkiestrator, który nasłuchuje na eventy z wszystkich serwisów, waliduje diagram stanów i wysyła odpowiednie komendy do kolejnego serwisu w procesie. 

Nie każdy event musi przechodzić przez Process Managera — część z nich może być przetwarzana bezpośrednio przez inny serwis, jeśli nie ma potrzeby zmiany stanu albo chodzi o wewnętrzny flow czy sub-stan(model hybrydowy, orkiestracja z częsścią choreografi).

Jak to widzicie, ma sens ?
I jak rozwiązać ten message bus ? Kafka cluster ? Jeden topic dla wszystkich eventów wchodzących do Proces managera i topic per serwis dla komend wychodzących do konkretnych serwisów ?

IMHO dobrze kombinujesz.

Moje standardowe podejście to byłby jakiś typowy message bus w postaci RabbitMQ lub czegoś chmurowego zamiast Kafki - niektóre dają z automatu redelivery, deadlettering. Jak masz bibliotekę która obsługuje process managera i przykrywa detale message busa to ten argument może nie mieć zastosowania, ale w przeciwnym wypadku na Kafce będziesz musiał implementować ręcznie coś co typowy message bus daje out of the box.

Na RabbitMQ przy odpowiednim wyskalowaniu osiągniesz luźno po 100k msg/sec. Jak z góry planujesz w tych granicach lub więcej to Kafka może mieć sens.

Kafka jest ciężka. Coś lżejszego jak RabbitMQ bardzo fajnie może zagrać. Od siebie mogę polecić MassTransita bo wystawia przyjemniejsze API, tylko uważaj, żeby się wrypac w tą nową, płatna wersję.

Przemyśl dobrze schemat eventów, żeby się dało cokolwiek wyśledzić - jest cała specka bardzo dobrych praktyk jak CloudEvents ale nie wiem czy dla takiej skali potrzebujesz tyle overheadu.

No i dobrze zadbać o observability, żeby się nie zakapućkać i być w stanie odtworzyć issuesy.

Tak, nie napisałem, że wydajność nie jest głównym triggerem tu. Max. wydajność to 10-20msg/sec. Czy w takim wypadku warto pakować się w Kafkę? Nigdy nie używałem a nie chcę wpakować się na minę. Zastanawiam się też nad jakiś rozwiązaniem cloudowym jak np. EventHub

@p_maciek: Kafka będzie overkillem przy takiej przepustowości. Każda cloudowa kolejeczka spokojnie to obsłuży więc szedlbym w jak najlżejszy klocek, np. Rabbit. Cloud providerzy też będą mieć swoje kolejki więc jeśli możesz skorzystać z którejś implementacji chmurowej to imo jeszcze lepiej bo Ci odpada zarządzanie kolejką

p_maciek napisał(a):

Zastanawiam się też nad jakiś rozwiązaniem cloudowym jak np. EventHub

A dlaczego tak cię ciągnie do event streamingu zamiast message brokera, którego tak na prawdę potrzebujesz?
Na Azure jest Service Bus.

Dawno temu Netflix stworzył po to Conductora (obecnie Orkes): https://www.orkes.io/what-is-conductor

Na pewno fajny pomysł z tym “process managerem” - musi być jakieś centralne miejsce, gdzie można podejrzeć aktualny status danego dokumentu. W przeciwnym przypadku, tj. jeśli każdy serwis komunikuje się z innymi niezależnie, będzie chaos w trackowaniu eventów.

W przypadku Kafki może dałoby się to ograć za pomocą projekcji Kafka Streams - wtedy można pisać zapytania na strumieniach zdarzeń. Można też zapisywać wszystkie zdarzenia do jakiejś nierelacyjnej bazy i odpytywać ja offline.

Oczywiście, jeśli wchodzisz w jakąkolwiek nową technologię, czy to Rabbit, Kafka, czy Conductor, potrzebujesz kogoś, kto to bardzo dobrze ogarnia. Zastanów się nad edge case’ami: niedostępność odbiorcy, retransmisje eventów, zaburzona kolejność, awaria brokera, rosnący lag na kolejce.

Charles_Ray napisał(a):

Dawno temu Netflix stworzył po to Conductora (obecnie Orkes): https://www.orkes.io/what-is-conductor

A co da ten Conductor w przypadku w miarę prostego procesu, którego nie ma potrzeby konfigurować z zewnątrz?

Na pewno fajny pomysł z tym “process managerem” - musi być jakieś centralne miejsce, gdzie można podejrzeć aktualny status danego dokumentu. W przeciwnym przypadku, tj. jeśli każdy serwis komunikuje się z innymi niezależnie, będzie chaos w trackowaniu eventów.

Myślę że podstawowym miejscem do trzymania statusu danego dokumentu będzie rekord dokumentu w bazie w której on się znajduje.
Process manager tutaj byłby orkiestratorem, który publikuje i nasłuchuje na eventy, może trzymać swój stan związany z danym procesem, ale ja bym traktował jego stan jako stan tymczasowy. Zakończy się dany proces w okół obiektu domenowego to można taki stan orkiestratora czyścić, a biznesowy rekord z ustalonym statusem zostaje w głównej bazie.