Bewerken

Delen via

Gridwich schone monolith-architectuur

Azure Event Grid
Azure Functions

De code in dit project is geordend als een monolithische architectuur met de volgende typische conceptuele onderdelen:

  • API-adapters
  • Losgekoppelde bedrijfslogica voor toepassingen
  • Kerndomeinobjecten
  • Infrastructuurgateways
  • Inversion of Control (IoC)

Diagram showing typical conceptual components of a clean monolith architecture.

De oplossing is staatloos, dus deze bevat geen gateways naar persistentielagen. De oplossing heeft geen gebruikersinterface, dus er zijn geen controllers of presentatoren.

De samenstelling van softwareonderdelen maakt gebruik van de klasse GridwichConfigureServices om te definiëren welke concrete klassen beschikbaar zijn in de IoC-container voor de Azure Functions-app.

Architectuur

Diagram showing components of the Gridwich monolith architecture.

De Gridwich-oplossing heeft een Core.EventGrid-bibliotheek , die het volgende bevat:

  • De domeinaanvraag- en antwoordgegevensoverdrachtobjecten (DTU's).
  • Interfaces voor alle bedrijfslogica van toepassingen of serviceobjecten.
  • De basisklassen waarmee algemene logica of activiteiten op basis van een domein kunnen worden bereikt.
  • Logboekregistratie, waarneembaarheid en uitzonderingsdefinities voor gebruik in de hele toepassing.

Als u Azure Event Grid wilt inkapselen als aanvraag- en antwoordbroker, heeft de bibliotheek het volgende:

  • Een gebeurtenis-dispatcher die gebruikmaakt van ioC om gebeurtenissen te identificeren en te verzenden naar listeners.
  • Een gebeurtenisuitgever om reacties op het juiste Event Grid-onderwerp te plaatsen.

De Event Grid-aanvraagadapter is een HTTP-eindpunt in de vorm van een AZURE Function HTTP-eindpunt. Een adapter voor het converteren van webaanvragen naar Event Grid-matrices bevindt zich ook in dezelfde EventGridFunction.

De Event Grid-antwoordgateway bestaat uit:

  • EventGridHandlerBase, waarmee een antwoord-DTO wordt geconverteerd naar een EventGridEvent object.
  • De EventGridDispatcher, die de Event Grid-gebeurtenis op de juiste eindpunt-URI van het Event Grid-onderwerp plaatst met behulp van de onderwerpsleutel.

De oplossing koppelt de saga-deelnemers los in de volgende bibliotheken, die verantwoordelijk zijn voor domeinspecifieke bedrijfslogica van toepassingen. De bibliotheken bevatten vereiste infrastructuurgateways en hun SDK's, waarmee de acties worden uitgevoerd die nodig zijn voor de bedrijfslogica.

Gridwich consolideert voor hergebruik en centralisatie van code bedrijfslogica of infrastructuurgateways die meerdere deelnemers gebruiken in de volgende gedeelde bibliotheken:

Alternatief voor microservices

Niets in de gridwich-probleemruimte of -architectuur pusht de oplossing expliciet naar een monolithische app of verschillende microservices.

U kunt de app eenvoudig herstructureren in microservices, elke functie-app die als host fungeert voor één saga-deelnemer. Elke functie-app koppelt de kern- en kernbibliotheken van Event Grid. De apps zouden elk een koppeling hebben of een gemeenschappelijke bibliotheek gebruiken voor infrastructuurgateways.

Diagram showing an alternative Gridwich microservices architecture.

Het voordeel van een dergelijke microservicesbenadering is de mogelijkheid om voor elk type aanvraag anders te schalen. Als er duizenden aanvraagtypen per seconde waren, maar slechts honderden andere aanvraagtypen per dag, zou de algehele oplossing profiteren van kleinere, eenvoudig te instantiëren en snel uit te voeren functies voor de aanvragen met een hoog volume.

Het nadeel van microservices is dat voor gedeelde modellen gesynchroniseerde implementatie van de microservices is vereist, of dat poolafvoer en -overschakeling moeten worden aangevraagd als er een gegevensschemawijziging is. Deze vereiste zou toekomstige ontwikkeling, continue implementatie en bewerkingen bemoeilijken. Omdat het zakelijke probleem geen behoefte aan microservices heeft aangetoond, maakt Gridwich-architectuur gebruik van een schone monolithische benadering.

Volgende stappen