Po przeprowadzeniu nieco więcej badań natknąłem się na ten artykuł, z którego wyciągnąłem cytaty, które moim zdaniem są pomocne w tym, co chcę osiągnąć (i dla przyszłych czytelników). Umożliwia to przyjęcie modelu programowania reaktywnego zamiast modelu programowania imperatywnego.
Pozyskiwanie zdarzeń
Chodzi o to, aby przedstawić przejście stanu każdej aplikacji w formie niezmiennego zdarzenia. Zdarzenia są następnie zapisywane w formie dziennika lub dziennika w momencie ich wystąpienia (zwane również „magazynem zdarzeń”). Można je również przeszukiwać i przechowywać w nieskończoność, aby przedstawić, w jaki sposób stan aplikacji jako całości ewoluował w czasie.
Pomaga to w osiągnięciu tego, że jeśli mikrousługa ulegnie awarii, a inne związane z nią zdarzenia zostaną opublikowane, a zdarzenia zostaną zużyte przez, powiedzmy, inne przypadki tej mikrousługi, gdy ta mikrousługa powróci, może odnosić się do tego, event storeaby pobrać wszystkie wydarzenia, które przeoczył w okresie upadku.
Apache Kafka jako Broker wydarzeń
Rozważ zastosowanie Apache Kafka, który może przechowywać i wywoływać tysiące zdarzeń na sekundę oraz ma wbudowane mechanizmy replikacji i odporności na uszkodzenia. Ma trwały magazyn zdarzeń, które mogą być przechowywane na dysku w nieskończoność i zużyte w dowolnym momencie (ale nie usunięte) z Tematu (fantazyjna kolejka Kafki), do którego zostały dostarczone.
Zdarzeniom przypisuje się następnie przesunięcia, które jednoznacznie identyfikują je w Temacie - Kafka może samodzielnie zarządzać przesunięciami, łatwo zapewniając semantykę dostarczania „co najmniej raz” lub „co najmniej raz”, ale można je również negocjować, gdy konsument zdarzenia dołącza do Tematu , umożliwiając mikrousługom rozpoczęcie konsumpcji zdarzeń z dowolnego dowolnego miejsca w czasie - zwykle od miejsca, w którym konsument przerwał. Jeśli przesunięcie ostatniego zużytego zdarzenia jest transakcyjnie utrwalane w lokalnej pamięci usług, gdy przypadki użycia „zakończono pomyślnie”, to przesunięcie można łatwo wykorzystać do osiągnięcia semantyki dostarczania zdarzeń „dokładnie raz”.
W rzeczywistości, kiedy konsumenci identyfikują się z Kafką, Kafka rejestruje, które wiadomości zostały dostarczone do którego konsumenta, aby nie mogła go ponownie podać.
Sagi
W przypadku bardziej skomplikowanych przypadków użycia, w których komunikacja między różnymi usługami jest rzeczywiście konieczna, odpowiedzialność za ukończenie skrzynki użycia musi być dobrze rozpoznana - skrzynka użycia jest zdecentralizowana i kończy się dopiero, gdy wszystkie zaangażowane usługi uznają swoje zadanie za pomyślnie ukończone, w przeciwnym razie cała skrzynka użytkowników musi zawieść należy zastosować środki naprawcze w celu przywrócenia dowolnego nieprawidłowego stanu lokalnego.
Właśnie wtedy pojawia się saga. Saga to sekwencja lokalnych transakcji. Każda transakcja lokalna aktualizuje bazę danych i publikuje komunikat lub zdarzenie w celu uruchomienia następnej transakcji lokalnej w sadze. Jeśli lokalna transakcja nie powiedzie się, ponieważ narusza regułę biznesową, saga wykonuje serię transakcji kompensacyjnych, które cofają zmiany wprowadzone w poprzednich transakcjach lokalnych. Przeczytaj to, aby uzyskać więcej informacji.