Co to jest sterowane zdarzeniami i jak szybko jest w czasie rzeczywistym?
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 chcesz pić.
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 "w czasie rzeczywistym". Więc powrót powitania powinien się zdarzyć szybko, ale dobrze jest krótko myśleć o swoim zamówieniu, 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.
Uwaga
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 zapomnij o oczywistym, czyli rejestrowaniu, monitorowaniu i mierzeniu chronometrażu.
Ważne
Upewnij się, że wcześniej określono terminy i terminy oraz skonfigurować rozwiązanie do monitorowania nieblokujące na potrzeby sprawdzania.
Podsumowując, zgadzamy się, że czas rzeczywisty oznacza super-szybkie, w chwili. Jak szybko jest dokładnie określony w danym scenariuszu.
Aplikacje oparte na zdarzeniach
Jeśli myślisz o wydarzeniu click-event, myślisz o czymś innym. Aplikacje sterowane zdarzeniami korzystają z reguły pożaru i zapomnij . Zdarzenie zostanie wysłane lub wyzwolone w kierunku następnego systemu, który może być inną usługą, centrum zdarzeń, strumieniem lub brokerem komunikatów, takiego jak Kafka. Niekoniecznie czekamy na odpowiedź od następnego w systemie. Luźne sprzężenie jest osiągane w przypadku ceny spójności ostatecznej, która musi być zadbana o inny poziom.
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 wydarzeń, aby uzyskać cały porządek Alexa. Ale dwóch baristów może również przygotować i serwować napoje niezależnie.
Transfer stanu prowadzonego przez zdarzenie
W przypadku przeniesienia stanu zdarzeń wszystkie potrzebne informacje są przechowywane w jednym zdarzeń. 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ć. Z dwoma baristami, drugi musiałby spojrzeć na pierwszy. Zamówienie może być obsłużone razem, ale proces może trwać dłużej niż całkowite oddzielenie go.
Określanie źródła zdarzeń
W przypadku określania źródła zdarzeń magazyn zdarzeń jest skoncentrowany. Jak widać, zdarzenia są takie same jak w pierwszym przykładzie. Ale barista jest ważny dla tej koncepcji w momencie, gdy barista otrzymuje wydarzenie, a następnie myśli o wszystkich odpowiednich wydarzeniach, aby uzyskać bieżący stan dla wszystkich zamówień złożonych przez Alexa.
Z drugim zamówieniem barista wie, że zamówienie Alexa składa się z kawy, pamiętając o pierwszym zamówieniu, i cappuccino, ponieważ ten napój został właśnie zamówiony. Praca równolegle z drugą baristą nie jest tak 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. Określanie źródła zdarzeń dodaje kolejną warstwę złożoności, ale również dodaje oddzielenie.
1. Wydarzenie: Alex kupuje kawę.
Kasjer: (Pierwsze) zamówienie (dla Alex): Kawa
2. Wydarzenie: Alex kupuje cappuccino.
Kasjer: (drugi) zamówienie (dla Alexa): 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.