Dekompozycja większych aplikacji za pomocą Amazon EventBridge

14 czerwca 2022

Aktualizacja: 8 września 2021 Amazon Elasticsearch Service został przemianowany na Amazon OpenSearch Service. Zobacz szczegóły.

W miarę dojrzewania wiele aplikacji zaczyna rosnąć w złożoność, co utrudnia programistom utrzymywanie kodu lub dodawanie nowych funkcji. Może to prowadzić do aplikacji monolitycznych, w których programiści muszą wiedzieć więcej o całej architekturze, aby wprowadzić zmiany. Zazwyczaj powoduje to, że kod staje się mniej stabilny, a tempo rozwoju spada.

W tym wpisie pokazano, jak wykorzystać architekturę opartą na zdarzeniach do oddzielenia usług i obszarów funkcjonalnych aplikacji. Wykorzystuje rozwiązanie repozytorium dokumentów jako przykład, aby porównać architekturę po przejściu na podejście oparte na zdarzeniach. Nowa architektura oferuje zarówno większą rozszerzalność, jak i prostotę deweloperom, którzy w przyszłości będą dodawać nowe funkcje. Może pomóc złagodzić problemy związane z aplikacjami monolitycznymi.

Oryginalna wersja tej aplikacji wykorzystuje powiadomienia o zdarzeniach Amazon S3 do wywoływania funkcji AWS Lambda w celu indeksowania treści w usłudze Amazon Elasticsearch Service:

Dekompozycja większych aplikacji za pomocą Amazon EventBridge

Ten projekt ma pewne ograniczenia. Po pierwsze, istnieje jedno źródło dokumentów, które może nie odzwierciedlać wykorzystania produkcyjnego. Ponadto, chociaż można go zmodyfikować, aby umożliwić indeksowanie nowych typów plików, dodanie nowych funkcji, takich jak tłumaczenie dokumentów, wymagałoby refaktoryzacji. I pomimo posiadania wielu funkcji Lambda, jest spakowany jako pojedyncza aplikacja, co utrudnia wdrażanie zmian.

Nowy projekt wykorzystuje zdarzenia do oddzielenia każdej usługi używanej do przetwarzania przychodzących obiektów S3. Może również używać jednego lub więcej bucketów jako źródeł zdarzeń, które w razie potrzeby można zmieniać dynamicznie. Co najważniejsze, wprowadzanie zmian i nowych funkcjonalności może być łatwiejsze, ponieważ aplikacja nie jest już wdrażana jako mono-repo. Nowa architektura wykorzystuje ten projekt:

Dekompozycja większych aplikacji za pomocą Amazon EventBridge

  1. Konfiguracja i konfiguracja zasobów AWS.
  2. Funkcja Parser do filtrowania i ponownego formatowania zdarzeń S3 dla aplikacji.
  3. Funkcje Converter do pracy na różnych typach plików.
  4. Funkcje Analyzer do interpretacji zawartości plików.
  5. Funkcja Loader importuje metadane do usługi Amazon Elasticsearch.

Kod wykorzystuje AWS Serverless Application Model (SAM), umożliwiając łatwe wdrożenie aplikacji na własnym koncie AWS. Ta instrukcja tworzy zasoby objęte bezpłatną usługą AWS Free Tier, ale możesz ponieść koszty w przypadku znacznego wykorzystania danych. Dodatkowo wymaga domeny Amazon Elasticsearch Service, co może wiązać się z kosztami na rachunku AWS.

Powstałe rozwiązanie to pięć oddzielnych aplikacji, które wdrażasz etapami. Aby skonfigurować aplikację, odwiedź repozytorium GitHub i postępuj zgodnie z instrukcjami zawartymi w pliku README.md.

Ustawienie i konfiguracja

Szablon SAM w katalogu setup tworzy buckety S3 i konfiguruje AWS CloudTrail do przechwytywania zdarzeń put w tych bucketach. Jest to wymagane, ponieważ EventBridge przechwytuje zdarzenia S3 za pośrednictwem CloudTrail. Teraz, gdy dowolny obiekt jest zapisywany w jednym z tych bucketów S3, EventBridge odbiera zdarzenie.

Ten szablon tworzy również zarządzane przez klienta polityki uprawnień IAM, które tworzą dostęp tylko do odczytu do źródłowych bucketów S3:

MyManagedPolicy:

    Type: AWS::IAM::ManagedPolicy

    Properties:

      ManagedPolicyName: docrepo-s3-read-policy

      PolicyDocument:

        Version: 2012-10-17

        Statement:

          - Effect: Allow

            Action:

              - s3:GetObject

              - s3:ListBucket

              - s3:GetBucketLocation

              - s3:GetObjectVersion

              - s3:GetLifecycleConfiguration

            Resource:

              - !Sub 'arn:aws:s3:::${Dept1Bucket}/*'

              - !Sub 'arn:aws:s3:::${Dept2Bucket}/*'

              - !Sub 'arn:aws:s3:::${Dept3Bucket}/*'

Politykę tę można dołączyć do dowolnej funkcji Lambda, która musi odczytywać zawartość jednego z bucketów S3. Jeśli pula bucketów źródłowych zmieni się w przyszłości, wystarczy zmodyfikować tę politykę. Wszelkie dalsze funkcje Lambda korzystające z tej polityki automatycznie uzyskują dostęp do dodanych bucketów.

W drugiej aplikacji konfiguracyjnej usługa Parser odbiera te zdarzenia S3 i ponownie formatuje je dla usług podrzędnych. W szczególności tworzy nowy atrybut dla typu pliku obiektu S3. Po wdrożeniu tych dwóch szablonów utworzenie dowolnych obiektów w źródłowych bucketach S3 spowoduje wygenerowanie następującego zdarzenia w domyślnej magistrali zdarzeń:

Ustawienie i konfiguracja

Budowanie procesów konwertera

Ta aplikacja używa konwerterów do przetwarzania obiektów przychodzących w bucketach S3. Jeden konwerter obsługuje jeden typ pliku. Do odtworzenia oryginalnej funkcjonalności aplikacji wymagane są dwa konwertery, dla plików pdf i docx. Reguła EventBridge dopasowuje zdarzenia przychodzące i wyzwala odpowiednią funkcję Lambda w celu przekonwertowania obiektu. Ten diagram przedstawia skrócone zdarzenia wejściowe i wyjściowe dla tych funkcji:

Budowanie procesów konwertera

  1. Pasująca reguła EventBridge wywołuje odpowiednią funkcję converter. Funkcja konwertuje plik źródłowy na nieprzetworzony tekst.
  2. Tekst jest podzielony na paczki po 5000 znaków.
  3. Funkcje publikują partie tekstu z powrotem do EventBridge, używając atrybutów detail-type i source.

Szablon SAM określa reguły EventBridge, uprawnienia EventBridge do wywoływania funkcji Lambda oraz przetwarzania funkcji Lambda. Funkcje Lambda wykorzystują zarządzane przez klienta polityki uprawnień IAM utworzone podczas konfiguracji w celu uzyskania dostępu tylko do odczytu do źródłowego bucketu S3. Każdy konwerter ma własną logikę przetwarzania różnych typów plików i może w razie potrzeby generować różne typy zdarzeń.

Funkcje analyzer

W tym worflow każdy typ pliku zawierający tekst jest analizowany przez Amazon Comprehend w celu wykrycia jednostek. Funkcja AnalyzeText jest wywoływana przez regułę EventBridge. Reguła filtruje dla atrybutu NewTextBatch w zdarzeniu z docRepo.converters.

Inna reguła EventBridge wyzwala funkcję AnalyzeImage. Jest to filtrowanie dla typów plików jpg i jpeg, w których źródłem zdarzenia jest docRepo.s3. Ta funkcja wykorzystuje rozpoznawanie Amazon Rekognition do identyfikacji etykiet na obrazach.

Obie funkcje tworzą nowe zdarzenia zawierające jednostki i etykiety przy użyciu atrybutów detail-type i source. Te zdarzenia są publikowane z powrotem do domyślnej magistrali w EventBridge:

Funkcje analyzer

  1. Pasująca reguła EventBridge wywołuje odpowiednią funkcję analyzer. Funkcja wykorzystuje usługi Amazon ML do wykrywania etykiet na obrazach i jednostek w tekście.
  2. Funkcje publikują metadane z powrotem do EventBridge, używając atrybutów detail-type i source.

Funkcja Loader

Funkcja Loader jest wywoływana przez regułę EventBridge, która filtruje zdarzenia z funkcji Analyzers. Ta końcowa funkcja odbiera te zdarzenia i ładuje etykiety oraz metadane jednostki do usługi Amazon Elasticsearch Service:

Funkcja Loader

Wybór między AWS Step Functions a Amazon EventBridge

W tej aplikacji istnieje sekwencja kroków w worfklow, które mogą być również obsługiwane przez funkcje AWS Step Functions. Obie usługi mogą uprościć workflow w aplikacjach rozproszonych oraz ułatwić konserwację i modyfikację aplikacji bezserwerowych. W wielu przypadkach sensowne jest korzystanie z obu usług w przypadku większych aplikacji korporacyjnych o złożonej logice biznesowej.

Jednak EventBridge umożliwia rozdzielenie procesów na niezależne aplikacje. Umożliwia także innym konsumentom tworzenie niestandardowej logiki przy użyciu zdarzeń bez wpływu na projekt lub wydajność aplikacji. W aplikacjach korporacyjnych znacznie ułatwia to wprowadzanie innowacji i opracowywanie nowych funkcji aplikacji.

Zalety dla deweloperów/operatorów

Dzięki oryginalnej monolitycznej aplikacji podzielonej na pięć oddzielnych aplikacji, teraz różne zespoły mogą łatwiej pracować nad projektem. Łatwiejsze i bezpieczniejsze jest również wdrażanie zmian w jednym mikroserwisie bez konieczności wdrażania całej aplikacji. Deweloperzy muszą rozumieć tylko własną usługę, a nie całą architekturę aplikacji.

Na przykład, aby dodać więcej bucketów S3 do listy źródłowej, wystarczy zmodyfikować szablon SAM w części setup aplikacji. Funkcja Parser zużywa zdarzenia put z dowolnej liczby bucketów, a funkcje niższego rzędu wykorzystują zdarzenia za pośrednictwem EventBridge. Aby dodać nowy typ pliku, wystarczy dodać nową funkcję converter. Opcjonalnie, aby zmienić dostawcę indeksowania, tworzysz nową funkcję Loader, która kieruje metadane do innej usługi. Usługi tej aplikacji są niezależne, oddzielone przez EventBridge i w razie potrzeby możesz dodać więcej producentów i konsumentów.

Tradycyjnie jednym z wyzwań związanych z aplikacjami event-based jest śledzenie formatu zdarzeń. Zarządzanie schematami zdarzeń jest zazwyczaj trudne, ponieważ każda usługa może wygenerować zdarzenie. Schemat może się również zmieniać, gdy deweloperzy wypuszczają nowe wersje usługi. Aby pomóc rozwiązać te problemy, EventBridge ma funkcję o nazwie odnajdywanie schematów, która może zautomatyzować śledzenie i zarządzanie zdarzeniami w aplikacji.

Wszystkie mikrousługi w tej aplikacji są publikowane z atrybutem source z docRepo. Jeśli włączysz wykrywanie schematów, EventBridge szybko zidentyfikuje te niestandardowe schematy zdarzeń:

Zalety dla deweloperów/operatorów

Schematy są definiowane w formacie JSON przy użyciu specyfikacji OpenAPI. Podczas opracowywania nowych funkcji można pobierać powiązania kodu bezpośrednio z tych schematów. W przypadku tzw. języków type-safe umożliwia to używanie zdarzeń jako obiektów bezpośrednio w aplikacjach, co pomaga przyspieszyć programowanie. Aby dowiedzieć się więcej o tym, jak używać powiązań kodu i odnajdywania schematów, obejrzyj ten film:

Podsumowanie

Większe aplikacje mogą szybko stać się monolitami. Możesz użyć architektur event-based, aby oddzielić usługi w aplikacjach i zachować elastyczność wraz z rozwojem aplikacji. Amazon EventBridge to bezserwerowa magistrala zdarzeń, która może uprościć architekturę, pozwalając każdej usłudze działać niezależnie, bez zależności od odbiorców zdarzeń.

W tym poście pokazaliśmy, jak przebudować przykład bezserwerowego repozytorium dokumentów (Serverless Document Repository) na pięć mniejszych aplikacji zaaranżowanych przy użyciu zdarzeń. Zbadaliśmy korzyści płynące z tworzenia aplikacji przy użyciu tego podejścia, w tym możliwość łatwiejszego wprowadzania zmian. Pokazaliśmy również, w jaki sposób wykrywanie schematów EventBridge może pomóc zautomatyzować zarządzanie schematami zdarzeń.

Aby dowiedzieć się więcej o tym, jak używać Amazon EventBridge do oddzielania dużych aplikacji, odwiedź zobacz cykl instrukcji Amazon EventBridge.

źródło: AWS

Case Studies
Referencje

Bardzo profesjonalne podejście, niesamowicie szybki czas reakcji i bardzo miła obsługa sprawiły, że na pewno podejmiemy jeszcze współpracę. 

Marcin Krzaczkowski
Założyciel Automa.Net
W skrócie o nas
Specjalizujemy się w dostarczaniu rozwiązań IT w obszarach projektowania infrastruktury serwerowej, wdrażania chmury obliczeniowej, opieki administracyjnej i bezpieczeństwa danych.