Przejście do architektur sterowanych zdarzeniami z bezserwerowymi agregatorami zdarzeń

Architektury sterowane zdarzeniami zyskują na popularności, ponieważ pomagają osiągnąć korzyści poprzez oddzielenie usług, zwiększenie skalowalności, dodanie elastyczności i zwiększenie zwinności organizacji programistów. Wraz z upływem czasu firmy muszą znaleźć sposoby na integrację (połączenie) wielu procesów i aplikacji (które zwykle należą do różnych zespołów).

Połączone aplikacje działają w pewnych scenariuszach, w których wymagana jest komunikacja synchroniczna (np. wywołania API). Mogą one obsługiwać krytyczne funkcje biznesowe, ale z czasem mogą stać się uciążliwe, gdy zależności między aplikacjami wykraczają poza pierwotny kontekst. Na przykład, przy rosnącej złożoności, zmiany w jednej aplikacji mogą wymagać również zmian w ściśle powiązanych aplikacjach. To właśnie te ściśle powiązane aplikacje zwykle zaczynają wprowadzać „wąskie gardła” i zmniejszają elastyczność, gdy patrzy się na ogólne wysiłki modernizacyjne. Proste zmiany stają się skomplikowane, a w niektórych przypadkach całkowicie blokują działania modernizacyjne lub znacznie je opóźniają. W takich sytuacjach warto przyjrzeć się zaletom architektur sterowanych zdarzeniami.

W architekturach sterowanych zdarzeniami każda aplikacja wywołuje zdarzenie za każdym razem, gdy coś ulegnie zmianie. To wtedy zależne aplikacje odpowiadają za słuchanie i decydowanie, jakie działania podjąć. W tym podejściu możesz oddzielić źródła i cele zdarzeń. Zmniejszenie zależności między aplikacjami umożliwia również zespołom działanie w sposób bardziej niezależny i daje im elastyczność wymaganą do dalszych prac modernizacyjnych.

Dzisiaj możesz używać Amazon EventBridge do aranżowania swoich wydarzeń. W tej choreografii reguły Amazon EventBridge dopasowują zdarzenia przychodzące ze źródeł zdarzeń. Kieruje je ona do celów na podstawie zdefiniowanych wzorców wyzwalania. Jeśli jednak masz złożone procesy, w których przed wyzwoleniem zdarzenia analizowanych jest wiele warunków, będziesz potrzebować dodatkowej logiki do organizowania zdarzeń na dużą skalę. To właśnie określa się mianem agregatorów zdarzeń.

Przy pomocy tego artykułu autorzy omówią, w jaki sposób można przekształcić istniejące środowisko za pomocą architektur sterowanych zdarzeniami. Obejmuje to sposób budowania „bezserwerowych agregatorów zdarzeń” podczas tworzenia złożonych mechanizmów wyzwalających.

Omówienie scenariusza

Aby wyjaśnić wartość podejścia z wykorzystaniem bezserwerowych agregatorów zdarzeń, użyjesz uproszczonej wersji popularnego scenariusza e-commerce. Ten przykładowy scenariusz dotyczy firmy online, w której klienci korzystają z Twojej witryny, aby kupić Twoje produkty. W takim przypadku masz wiele zespołów (i systemów/aplikacji zaplecza) szukających różnych części procesu. Wszyscy muszą wykonać zadania na podstawie otrzymanych informacji.

Kiedy Twoi klienci tworzą zamówienie:

• sprawdzasz i zatwierdzasz ich konto pod kątem wystarczającej liczby kredytów na pokrycie kosztów produktu ORAZ
• sprawdzasz, czy zapasy dla żądanego produktu są wystarczające.

A jeśli OBA procesy zakończą się powodzeniem:

• wysyłasz wiadomość do swojego klienta o treści ​​„Zamówienie przesłane” lub
• w przypadku wystąpienia problemu w procesie (nieprawidłowe zamówienie) podejmujesz dalsze działania.

W przeszłości, w przypadku podobnych scenariuszy, można było zaobserwować dwa podstawowe wzorce:

• Polling mechanism: jest tworzony dla każdej kolejnej aplikacji w celu ciągłego sprawdzania, czy poprzednie procesy zostały zakończone.
• Fixed scheduling: dla każdego procesu ustalany jest stały harmonogram, co ułatwia przestrzeganie sekwencji.

Chociaż te podejścia integracyjne sprawdziły się w niektórych przypadkach użycia, nieumyślnie wprowadziły ścisłe powiązania między aplikacjami. Doprowadziło to do statycznych architektur, które stały się wąskimi gardłami w wysiłkach modernizacyjnych. Miało to również bezpośredni wpływ na klientów, gdzie kompleksowe architektury synchroniczne (takie jak operacje API) wymagały wykonania wszystkich kroków przed udostępnieniem odpowiedzi.

Tworzenie Serverless Event Aggregators

Aby rozwiązać problemy opisane w poprzednim scenariuszu, możesz zaimplementować kontrole asynchroniczne za pomocą agregatora zdarzeń. Ta decyzja oddziela również aplikacje, potencjalnie chroniąc środowisko klienta w trakcie przetwarzania wszystkich kroków.

To bezserwerowe rozwiązanie agregatora zdarzeń można zbudować za pomocą DynamoDB, AWS Lambda i Amazon EventBridge. W tym rozwiązaniu autorzy wykorzystują funkcjonalność strumieni DynamoDB i AWS Lambda do agregowania zdarzeń, a także routing oparty na zdarzeniach z Amazon EventBridge. To rozwiązanie składa się z czterech głównych kroków:

Krok 1: Zaktualizuj DynamoDB ze źródeł zdarzeń

Wszystko zaczyna się od źródeł zdarzeń (w omawianym przykładzie aplikacje „sprawdzanie konta” i „w magazynie”). Po uruchomieniu aplikacji źródłowych aktualizują one tabelę DynamoDB za pośrednictwem interfejsu API UpdateItem.

Poniższy zrzut ekranu przedstawia tabelę „Zdarzenia” utworzoną w DynamoDB i zaktualizowane zdarzenia z aplikacji źródłowych („sprawdzanie konta” i „w magazynie”) wraz z ich identyfikatorem zamówienia.

Używając DynamoDB jako magazynu zdarzeń, możesz dodawać więcej źródeł zdarzeń lub aktualizować je w miarę zmieniających się potrzeb biznesowych. Zapewni to większą elastyczność i skalowalność, umożliwiając włączenie większej liczby zespołów i procesów do architektury sterowanej zdarzeniami.

Krok 2: użycie strumienia DynamoDB do wywołania zdarzenia

Gdy Twoje aplikacje (źródła zdarzeń) zaktualizują tabelę DynamoDB, Twoja tabela DynamoDB uruchomi funkcję Lambda przy użyciu zintegrowanego mechanizmu wyzwalania Lambda i DynamoDB.

Możesz zaimplementować tę integrację za pomocą strumieni DynamoDB. Po włączeniu strumienia DynamoDB w tabeli DynamoDB będzie on postrzegany jako „wyzwalacz” w funkcji AWS Lambda. Możesz skorzystać z tego samouczka, aby utworzyć strumień DynamoDB i trigger AWS Lambda. Poniższy obraz przedstawia konsolę Lambda po zakończeniu instalacji.

Krok 3: Zsumuj swoje zdarzenia

Teraz zbudujesz swój agregator zdarzeń za pomocą funkcji Lambda, aby zsumować wszystkie swoje zdarzenia. Będzie to obejmować całą logikę biznesową agregacji. W omawianym scenariuszu ta funkcja otrzymuje identyfikator zamówienia, który został utworzony jako dane wejściowe. Następnie wykonuje skanowanie tabeli DynamoDB pod kątem wszystkich zdarzeń związanych z tym samym zamówieniem. Następnie generuje niestandardowe zdarzenie EventBridge z listą wszystkich zdarzeń dla zamówienia za pomocą interfejsu API PutEvents.

Poniżej znajduje się przykład agregatora zdarzeń tej funkcji Lambda napisanej w Pythonie:

import json

import boto3

from boto3.dynamodb.conditions import Attr

dynamodb = boto3.resource('dynamodb')

client = boto3.client('events')

def lambda_handler(event, context):

print(json.dumps(event))

order = int(event['Records'][0]['dynamodb']['NewImage']['OrderID']['N']) print(order)

table = dynamodb.Table('Events')

table_scan = table.scan(FilterExpression=Attr('OrderID').eq(order))

event_status = {} for item in table_scan['Items']:

event_status[item['EventName']] = order print (json.dumps(event_status))

response = client.put_events(

Entries=[

{

'Source': 'my-event',

'DetailType': 'events list from dynamodb',

'Detail': json.dumps(event_status), '

EventBusName': 'default',

},

])

Krok 4: Filtruj i kieruj swoje wydarzenia za pomocą Amazon EventBridge

Gdy funkcja agregatora zostanie uruchomiona, utworzy zdarzenie, które zawiera zagregowany widok stanu wielu zdarzeń. Na przykład w wygenerowanym zdarzeniu w poniższej tabeli widać, że zarówno zdarzenia „w magazynie”, jak i „sprawdzanie konta” zostały zaktualizowane o wartość OrderID: 7. Oznacza to, że obydwie kontrole dotyczące Rozkazu 7 zostały zakończone i możesz teraz przystąpić do dalszych wydarzeń.

{

"version":"0",

"id":"711ef30b-582a-cda5-c132-bceb46bc5c6a",

"detail-type":"events list from dynamodb",

"source":"my-event",

"account":"123456789098",

"time":"2022-10-13T13:03:02Z",

"region":"eu-west-1",

"resources":[

],

"detail":{

"In Stock":7,

"Account Check":7

}

}

Gdy EventBridge otrzyma to zdarzenie, zostanie ono przetworzone w regułach EventBridge w celu uchwycenia określonego stanu obu zdarzeń („sprawdzenie konta” i „w magazynie”). A jeśli oba przejdą testy, uruchomi się funkcja Lambda „Przetwarzanie faktury”.

Poniżej możesz zobaczyć konfigurację reguły EventBridge zdefiniowanej dla omawianego scenariusza.

{

"source": ["my-event"],

"detail-type": ["events list from dynamodb"],

"detail": {

"Account Check": [{

"exists": true

}],

"In Stock": [{

"exists": true

}]

}

}

Reguły EventBridge wykorzystują wzorce zdarzeń do wybierania i dopasowywania zdarzeń przychodzących oraz wyzwalania określonych celów do przetwarzania.

Amazon EventBridge obsługuje kilka operatorów porównania. Możesz zapoznać się z wzorcami zdarzeń Amazon EventBridge, aby uzyskać pełną listę obsługiwanych.

W przykładowym wzorcu autorzy użyli operatora „And”, aby wybrać zdarzenia „sprawdzanie konta” i „w magazynie” „istnieje: prawda”. Gdy warunki wzorca zostaną spełnione, EventBridge uruchomi cel „Przetwarzanie faktury”.

Poniższy zrzut ekranu pokazuje, jak funkcja Lambda „InvoiceProcessing” jest skonfigurowana do wyzwalania z dopasowanym zdarzeniem.

Tym krokiem autorzy zakończyli omawiany scenariusz. Zebrali zdarzenia z wielu źródeł zdarzeń i zagregowali je według uznania za pomocą „Agregatora zdarzeń”. Po spełnieniu wszystkich zdefiniowanych warunków zorganizowali je za pośrednictwem Amazon EventBridge, aby uruchomić zdefiniowaną aplikację docelową „Przetwarzanie faktur”. Ze względu na elastyczny charakter tego rozwiązania można dodawać/usuwać i zmieniać komponenty bez konieczności zmiany architektury.

Wnioski

Dzięki bezserwerowym agregatorom zdarzeń można osiągnąć skalowalność, elastyczność i kontrolę poprzez oddzielenie aplikacji wymagających złożonych mechanizmów wyzwalania. Jak w przypadku każdego projektu modernizacyjnego, Twoja podróż zaczyna się od zrozumienia Twoich potrzeb biznesowych i aktualnych możliwości. Połączenie zespołów i ustalenie sposobu interakcji aplikacji będzie cennym krokiem do przejścia na architekturę sterowaną zdarzeniami.

Na podstawie tego artykułu autorzy zbadali, w jaki sposób można podejść do przekształcania aplikacji za pomocą architektur opartych na zdarzeniach przy użyciu bezserwerowych agregatorów zdarzeń. Zastosowali uproszczony scenariusz dla aplikacji e-commerce, która w przeszłości była ściśle powiązana z systemami przetwarzania zaplecza. Transformacja rozerwała ścisłe sprzężenie zależnych procesów i umożliwiła zakończenie niezależnego i asynchronicznego przetwarzania zdarzeń. Pozwala to na usunięcie wąskich gardeł i skuteczniejsze skalowanie wysiłków modernizacyjnych.

Dzięki integracji DynamoDB możesz mieć tyle źródeł zdarzeń, ile potrzebujesz, wraz z rosnącym rozwiązaniem i pełną kontrolą nad funkcją Agregator Lambda. Te dwie integracje zapewnią elastyczność pozwalającą na reagowanie na zmieniające się wymagania biznesowe. Po zagregowaniu zdarzeń AWS EventBridge może pomóc w integracji rozwiązania z ponad 35 celami. Cele te obejmują wiele aplikacji SaaS, takich jak Datadog, Onelogin i PagerDuty. Dzięki gotowym integracjom nie musisz zarządzać żadną konfiguracją integracji. Zwiększy to elastyczność programistów, zmniejszając tym samym potrzebę koordynacji między różnymi zespołami i aplikacjami SaaS.

Aby dowiedzieć się więcej o architekturach opartych na zdarzeniach, wypróbuj „Building event-driven architectures on AWS workshop”, sprawdź także Serverless Land, aby znaleźć najnowsze blogi, filmy i materiały szkoleniowe, a także zapoznaj się z repozytorium AWS Serverless Application, aby odkryć gotowe aplikacje na potrzeby modernizacji.

Źródło: AWS