Edytuj

Udostępnij za pośrednictwem

Czysta architektura monolityczna usługi Gridwich

Azure Event Grid
Azure Functions

Kod w tym projekcie jest zorganizowany jako monolit z czystą architekturą, z następującymi typowymi składnikami koncepcyjnymi:

  • Karty interfejsu API
  • Odłączona logika biznesowa aplikacji
  • Podstawowe obiekty domeny
  • Bramy infrastruktury
  • Inversion of Control (IoC)

Diagram showing typical conceptual components of a clean monolith architecture.

Rozwiązanie jest bezstanowe, więc nie zawiera żadnych bram do warstw trwałości. Rozwiązanie nie ma interfejsu użytkownika, więc nie ma kontrolerów ani prezenterów.

Kompozycja składników oprogramowania używa klasy GridwichConfigureServices do zdefiniowania, które klasy konkretne są dostępne w kontenerze IoC dla aplikacji usługi Azure Functions.

Architektura

Diagram showing components of the Gridwich monolith architecture.

Rozwiązanie Gridwich ma bibliotekę Core.EventGrid , która zawiera:

  • Obiekty transferu danych żądania domeny i odpowiedzi (DTO).
  • Interfejsy dla wszystkich obiektów usługi lub logiki biznesowej aplikacji.
  • Klasy podstawowe, które pomagają osiągnąć typową logikę lub działania oparte na domenie.
  • Rejestrowanie, obserwowanie i definicje wyjątków do użycia w całej aplikacji.

Aby hermetyzować usługę Azure Event Grid jako broker żądań i odpowiedzi, biblioteka ma następujące elementy:

  • Dyspozytor zdarzeń, który używa IoC do identyfikowania i wysyłania zdarzeń do odbiorników.
  • Wydawca zdarzeń do umieszczania odpowiedzi w poprawnym temacie usługi Event Grid.

Karta żądania usługi Event Grid jest punktem końcowym HTTP w postaci punktu końcowego HTTP funkcji platformy Azure. Adapter do konwertowania żądań internetowych na tablice usługi Event Grid również znajduje się w tej samej funkcji EventGridFunction.

Brama odpowiedzi usługi Event Grid składa się z następujących elementów:

  • EventGridHandlerBase, która konwertuje obiekt DTO odpowiedzi na EventGridEvent obiekt.
  • EventGridDispatcher, który umieszcza zdarzenie usługi Event Grid na prawidłowym identyfikatorze URI punktu końcowego tematu usługi Event Grid przy użyciu klucza tematu.

Rozwiązanie rozdziela uczestników sagi na następujące biblioteki, które mają obowiązki związane z logiką biznesową aplikacji specyficznych dla domeny. Biblioteki zawierają wymagane bramy infrastruktury i ich zestawy SDK, które wykonują działania wymagane przez logikę biznesową.

W przypadku ponownego użycia kodu i centralizacji usługa Gridwich konsoliduje logikę biznesową lub bramy infrastruktury używane przez kilku uczestników do następujących bibliotek udostępnionych:

Alternatywa mikrousług

Nic w przestrzeni problemowej gridwich lub architekturze jawnie wypycha rozwiązanie do aplikacji monolitycznej lub kilku mikrousług.

Możesz łatwo refaktoryzować aplikację do mikrousług, z których każda aplikacja funkcji hostuje jednego uczestnika sagi. Każda aplikacja funkcji łączy podstawowe i podstawowe biblioteki usługi Event Grid. Każda aplikacja będzie mieć połączenie lub używać wspólnej biblioteki dla bram infrastruktury.

Diagram showing an alternative Gridwich microservices architecture.

Zaletą takiego podejścia mikrousług jest możliwość skalowania w inny sposób dla każdego typu żądania. Jeśli na sekundę było tysiące jednego typu żądania, ale tylko setki innych typów żądań dziennie, ogólne rozwiązanie skorzystałoby z mniejszych, łatwych w utworzeniu wystąpień i szybkich do wykonania funkcji dla żądań o dużej ilości.

Wadą mikrousług jest to, że wszystkie modele udostępnione wymagają zsynchronizowanego wdrożenia mikrousług lub opróżniania puli żądań i przełączania w przypadku zmiany schematu danych. To wymaganie komplikuje przyszłe programowanie, ciągłe wdrażanie i operacje. Ponieważ problem biznesowy nie wykazał potrzeby mikrousług, architektura Gridwich używa czystego podejścia monolitycznego.

Następne kroki