Redigera

Dela via

Gridwichs rena monolitarkitektur

Azure Event Grid
Azure Functions

Koden i det här projektet är organiserad som en monolit med ren arkitektur med följande typiska konceptuella komponenter:

  • API-kort
  • Frikopplad affärslogik för program
  • Kärndomänobjekt
  • Infrastrukturgatewayer
  • Inversion av kontroll (IoC)

Diagram showing typical conceptual components of a clean monolith architecture.

Lösningen är tillståndslös, så den innehåller inga gatewayer till beständighetslager. Lösningen har inget användargränssnitt, så den har inga styrenheter eller presentatörer.

Programvarukomponentens sammansättning använder klassen GridwichConfigureServices för att definiera vilka betongklasser som är tillgängliga i IoC-containern för Azure Functions-appen.

Arkitektur

Diagram showing components of the Gridwich monolith architecture.

Gridwich-lösningen har ett Core.EventGrid-bibliotek som innehåller:

  • Domänens begärande- och svarsdataöverföringsobjekt (DTU: er).
  • Gränssnitt för alla programaffärslogik eller tjänstobjekt.
  • De basklasser som hjälper dig att uppnå vanlig domändriven logik eller aktiviteter.
  • Loggning, observerbarhet och undantagsdefinitioner för användning i hela programmet.

För att kapsla in Azure Event Grid som en begäran och svarskoordinator har biblioteket:

  • En händelseutskickare som använder IoC för att identifiera och skicka händelser till lyssnare.
  • En händelseutgivare för att placera svar på rätt Event Grid-ämne.

Event Grid-begärandekortet är en HTTP-slutpunkt i form av en AZURE-funktions-HTTP-slutpunkt. Ett kort för att konvertera webbbegäranden till Event Grid-matriser finns också i samma EventGridFunction.

Event Grid-svarsgatewayen består av:

  • EventGridHandlerBase, som konverterar ett svars-DTO till ett EventGridEvent objekt.
  • EventGridDispatcher, som placerar Event Grid-händelsen på rätt svar Event Grid-ämnesslutpunkts-URI med hjälp av ämnesnyckeln.

Lösningen frikopplar sagadeltagarna till följande bibliotek, som har ansvar för domänspecifik affärslogik för program. Biblioteken innehåller nödvändiga infrastrukturgatewayer och deras SDK:er, som utför de åtgärder som affärslogik kräver.

För återanvändning och centralisering av kod konsoliderar Gridwich affärslogik eller infrastrukturgatewayer som flera deltagare använder i följande delade bibliotek:

Alternativ för mikrotjänster

Ingenting i Gridwich-problemutrymmet eller arkitekturen pushar uttryckligen lösningen till antingen en monolitisk app eller flera mikrotjänster.

Du kan enkelt omstrukturera appen till mikrotjänster, var och en en funktionsapp som är värd för en enda saga-deltagare. Varje funktionsapp skulle länka kärn- och kärnbiblioteken för Event Grid. Apparna skulle ha varsin länkning eller använda ett gemensamt bibliotek för infrastrukturgatewayer.

Diagram showing an alternative Gridwich microservices architecture.

Fördelen med en sådan mikrotjänstmetod är möjligheten att skala olika för varje typ av begäran. Om det fanns tusentals begärandetyper per sekund, men bara hundratals andra typer av begäranden per dag, skulle den övergripande lösningen ha nytta av att ha mindre, lättinstansiera och snabb-till-köra-funktioner för begäranden med stora volymer.

Nackdelen med mikrotjänster är att alla delade modeller kräver synkroniserad distribution av mikrotjänsterna, eller att begärandepoolen töms och växlas om det sker en ändring av dataschemat. Det här kravet skulle komplicera framtida utveckling, kontinuerlig distribution och åtgärder. Eftersom affärsproblemet inte visade något behov av mikrotjänster använder Gridwich-arkitekturen en ren monolitmetod.

Nästa steg