Czym jest model sterowany zdarzeniami i jak szybki jest czas rzeczywisty?
Jeśli myślimy o tym, możemy zidentyfikować wiele scenariuszy opartych na zdarzeniach. Wiele z nich wymaga reakcji w czasie rzeczywistym.
Co mamy na myśli w czasie rzeczywistym?
Reakcja w czasie rzeczywistym może być postrzegana jako natychmiastowa odpowiedź. Weźmy przykład kasjera w kawiarni, który pyta, co chciałbyś/chciałabyś się napić.
Kasjer oczekuje natychmiastowej odpowiedzi lub przynajmniej odpowiedzi, która zostanie podana bardzo szybko. W przeciwnym razie kasjer może powtórzyć pytanie lub podejrzewać, że jesteś niegrzeczny. Żądana jest szybka odpowiedź, a także odpowiednia. Czas odpowiedzi może się nieco różnić, ale nadal jest postrzegany jako "natychmiastowy." Dlatego odpowiedź na powitanie powinna nastąpić szybko, ale można chwilę się zastanowić nad swoim zamówieniem, aby odpowiedzieć na pytanie kasjera.
Jeśli przetłumaczysz ten scenariusz na systemy oprogramowania, wszystko, o czym dbasz, to czas odpowiedzi, czas ukończenia, czas dostępu, czas rozpoczęcia itd. Użytkownik lub aplikacja, która uzyskuje dostęp, definiuje te terminy.
Notatka
W czasie rzeczywistym zadania systemów wykonują swoją funkcję w określonych terminach.
Zawsze należy pamiętać o tym, co dzieje się w systemie. Upewnij się, że nie zapomnisz o oczywistym, czyli rejestrowaniu, monitorowaniu i mierzeniu czasów.
Ważny
Upewnij się, że wcześniej określono terminy i ustal harmonogram oraz skonfiguruj rozwiązanie monitorujące, które nie blokuje, na potrzeby sprawdzania.
Podsumowując, zgadzamy się, że czas rzeczywisty oznacza super-szybko, natychmiast. Jak szybko dokładnie zależy od danego scenariusza.
Aplikacje sterowane zdarzeniami
Jeśli myślisz o zdarzeniu kliknięcia, myślisz o czymś innym. Aplikacje sterowane zdarzeniami używają zasady wystrzel i zapomnij. Zdarzenie jest wysyłane lub wyzwalane w kierunku następnego systemu, który może być inną usługą, hubem zdarzeń, strumieniem lub brokerem komunikatów, takich jak Kafka. Nie zawsze czekamy na odpowiedź od kolejnej osoby w systemie. Luźne sprzężenie jest osiągane kosztem spójności ostatecznej, która musi być zapewniona na innym poziomie.
Aby zidentyfikować charakter aplikacji opartych na zdarzeniach, przyjrzyjmy się głównym wzorom architektury, korzystając z przykładu klienta o nazwie Alex, zakupu kawy i cappuccino.
Powiadomienie o zdarzeniu
Powiadomienie o zdarzeniu to powiadomienie o konkretnym wystąpieniu lub zdarzeniu. Każde zdarzenie jest widoczne oddzielnie. Przykład klienta o nazwie Alex kupującego kawę i cappuccino może wyglądać następująco:
1. Wydarzenie: Alex kupuje kawę.
2. Wydarzenie: Alex kupuje cappuccino.
Jeden barista musiałby uważnie słuchać wszystkich elementów zamówienia, aby zrealizować całe zamówienie Alexa. Ale dwóch baristów może również przygotować i serwować napoje niezależnie.
Transfer stanu za pośrednictwem zdarzenia
W przypadku transferu stanu opartego na zdarzeniach wszystkie potrzebne informacje są przechowywane w jednym zdarzeniu. Jest to przydatne, jeśli zdarzenie zostanie utracone lub usługa nie nasłuchuje wszystkich zdarzeń. W naszym przykładzie zdarzenia będą wyglądać następująco:
1. Wydarzenie: Alex kupuje kawę.
2. Wydarzenie: Alex kupuje, oprócz kawy, cappuccino.
Z jednym barista, nasłuchiwanie tylko drugiego zdarzenia może wystarczyć. Gdyby było dwóch baristów, drugi musiałby spojrzeć na pierwszego. Zamówienie może być obsłużone razem, ale proces może trwać dłużej niż gdyby był całkowicie rozdzielony.
Określanie źródła zdarzeń
W przypadku modelowania na podstawie zdarzeń, magazynowanie zdarzeń staje się kluczowe. Jak widać, zdarzenia są takie same jak w pierwszym przykładzie. Ale barista jest ważny w tym kontekście, w momencie, gdy otrzymuje wydarzenie, a następnie myśli o wszystkich związanych z nimi wydarzeniach, aby uzyskać bieżący stan wszystkich zamówień złożonych przez Alexa.
Przy drugim zamówieniu barista wie, że zamówienie Alexa to kawa, dzięki zapamiętaniu pierwszego zamówienia, oraz cappuccino, bo ten napój zamówiono właśnie teraz. Praca równoległa z drugim baristą nie jest tak łatwo możliwa.
Po dodaniu kasjera do otrzymania zamówień i serwowania napojów barista może pracować niezależnie, aby przygotować napoje. Nie muszą nic wiedzieć o klientach. Kasjer jest tak zwanym magazynem zdarzeń, utrwalającym zdarzenia w tym scenariuszu. Sourcing zdarzeń dodaje kolejną warstwę złożoności, ale również rozluźnia zależności.
1. Wydarzenie: Alex kupuje kawę.
Kasjer: (Pierwsze) zamówienie (dla Alexa): Kawa
2. Wydarzenie: Alex kupuje cappuccino.
Cashier: (Drugie) zamówienie (dla Alex): Cappuccino
Dane telemetryczne to zdarzenia w czasie rzeczywistym
Istnieją również inne przykłady, o których możemy pomyśleć. Wyobraź sobie scenariusz uruchamiania systemu chłodniczego, na przykład dla producentów żywności lub leków. Potrzebujesz stałej kontroli temperatury i innych odpowiednich danych w systemie. Świadomość danych telemetrycznych i kontrolowanie ich automatycznie będzie krytyczna dla sukcesu. Pomiar telemetrii co dwie sekundy, a następnie wysyłanie ich do systemu sterowania, w którym dane są analizowane, przetwarzane i obsługiwane, to system sterowany zdarzeniami. Ponadto dane muszą być przetwarzane w czasie rzeczywistym, ponieważ niezwykle ważne jest szybkie reagowanie, aby uniknąć tragicznych konsekwencji dla firmy.