EShopOnContainers toewijzen aan Azure Services

Tip

Deze inhoud is een fragment uit het eBook, Cloud Native .NET Applications for Azure ontwerpen, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.

PDF downloaden

Hoewel dit niet vereist is, is Azure geschikt voor het ondersteunen van de eShopOnContainers omdat het project is gebouwd als een cloudeigen toepassing. De toepassing is gebouwd met .NET, zodat deze kan worden uitgevoerd op Linux- of Windows-containers, afhankelijk van de Docker-host. De toepassing bestaat uit meerdere autonome microservices, elk met eigen gegevens. De verschillende microservices tonen verschillende benaderingen, variërend van eenvoudige CRUD-bewerkingen tot complexere DDD- en CQRS-patronen. Microservices communiceren met clients via HTTP en met elkaar via communicatie op basis van berichten. De toepassing ondersteunt ook meerdere platforms voor clients, omdat deze HTTP als standaardcommunicatieprotocol gebruikt en ASP.NET Core- en Xamarin-mobiele apps bevat die worden uitgevoerd op Android-, iOS- en Windows-platforms.

De architectuur van de toepassing wordt weergegeven in afbeelding 2-5. Aan de linkerkant bevinden zich de client-apps, onderverdeeld in mobiele, traditionele web- en spa-varianten (Web Single Page Application). Aan de rechterkant bevinden zich de onderdelen aan de serverzijde waaruit het systeem bestaat, die elk kunnen worden gehost in Docker-containers en Kubernetes-clusters. De traditionele web-app wordt mogelijk gemaakt door de ASP.NET Core MVC-toepassing die geel wordt weergegeven. Deze app en de mobiele en web-BEVEILIGD-WACHTWOORDVERIFICATIE-toepassingen communiceren met de afzonderlijke microservices via een of meer API-gateways. De API-gateways volgen het patroon 'back-ends voor front-ends' (BFF), wat betekent dat elke gateway is ontworpen ter ondersteuning van een bepaalde front-endclient. De afzonderlijke microservices worden rechts van de API-gateways vermeld en bevatten zowel bedrijfslogica als een soort persistentiearchief. De verschillende services maken gebruik van SQL Server-databases, Redis-cache-exemplaren en MongoDB-/CosmosDB-archieven. Helemaal rechts is de Event Bus van het systeem, die wordt gebruikt voor communicatie tussen de microservices.

Afbeelding 2-5. De architectuur van eShopOnContainers.

De onderdelen aan de serverzijde van deze architectuur zijn allemaal eenvoudig toegewezen aan Azure-services.

Containerindeling en clustering

De containerservices van de toepassing, van ASP.NET Core MVC-apps naar afzonderlijke microservices voor catalogus en bestellen, kunnen worden gehost en beheerd in Azure Kubernetes Service (AKS). De toepassing kan lokaal worden uitgevoerd op Docker en Kubernetes, en dezelfde containers kunnen vervolgens worden geïmplementeerd in faserings- en productieomgevingen die worden gehost in AKS. Dit proces kan worden geautomatiseerd, zoals we in de volgende sectie zullen zien.

AKS biedt beheerservices voor afzonderlijke clusters van containers. De toepassing implementeert afzonderlijke containers voor elke microservice in het AKS-cluster, zoals wordt weergegeven in het bovenstaande architectuurdiagram. Met deze benadering kan elke afzonderlijke service onafhankelijk worden geschaald op basis van de resourcevereisten. Elke microservice kan ook onafhankelijk worden geïmplementeerd en in het ideale geval moeten dergelijke implementaties geen downtime van het systeem veroorzaken.

API-gateway

De eShopOnContainers-toepassing heeft meerdere front-endclients en meerdere verschillende back-endservices. Er is geen een-op-een-correspondentie tussen de clienttoepassingen en de microservices die deze ondersteunen. In een dergelijk scenario kan er veel complexiteit zijn bij het schrijven van clientsoftware om op een veilige manier te communiceren met de verschillende back-endservices. Elke client moet deze complexiteit zelfstandig aanpakken, wat resulteert in duplicatie en veel plaatsen waar updates moeten worden aangebracht wanneer services worden gewijzigd of nieuwe beleidsregels worden geïmplementeerd.

Met Azure API Management (APIM) kunnen organisaties API's op een consistente, beheerbare manier publiceren. APIM bestaat uit drie onderdelen: de API-gateway en de beheerportal (de Azure-portal) en een ontwikkelaarsportal.

De API-gateway accepteert API-aanroepen en stuurt deze door naar de juiste back-end-API. Het kan ook extra services bieden, zoals verificatie van API-sleutels of JWT-tokens en API-transformaties, zonder codewijzigingen (bijvoorbeeld om clients te voorzien van een oudere interface).

In Azure Portal definieert u het API-schema en verpakt u verschillende API's in producten. U configureert ook gebruikerstoegang, bekijkt rapporten en configureert beleidsregels voor quota of transformaties.

De ontwikkelaarsportal fungeert als de hoofdresource voor ontwikkelaars. Het biedt ontwikkelaars API-documentatie, een interactieve testconsole en rapporten over hun eigen gebruik. Ontwikkelaars gebruiken de portal ook om hun eigen accounts te maken en te beheren, inclusief ondersteuning voor abonnementen en API-sleutels.

Met APIM kunnen toepassingen verschillende groepen services beschikbaar maken, die elk een back-end bieden voor een bepaalde front-endclient. APIM wordt aanbevolen voor complexe scenario's. Voor eenvoudigere behoeften kan de lichtgewicht API Gateway Ocelot worden gebruikt. De eShopOnContainers-app maakt gebruik van Ocelot vanwege de eenvoud en omdat deze kan worden geïmplementeerd in dezelfde toepassingsomgeving als de toepassing zelf. Meer informatie over eShopOnContainers, APIM en Ocelot.

Een andere optie als uw toepassing AKS gebruikt, is het implementeren van de Controller voor inkomend verkeer van Azure Gateway als een pod in uw AKS-cluster. Met deze benadering kan uw cluster worden geïntegreerd met een Azure-toepassing Gateway, zodat de gateway verkeer kan verdelen over de AKS-pods. Meer informatie over de Controller voor inkomend verkeer van Azure Gateway voor AKS.

Gegevens

De verschillende back-endservices die door eShopOnContainers worden gebruikt, hebben verschillende opslagvereisten. Verschillende microservices maken gebruik van SQL Server-databases. De Basket-microservice maakt gebruik van een Redis-cache voor de persistentie. De microservice Locations verwacht een MongoDB-API voor de gegevens. ondersteuning voor Azure elk van deze gegevensindelingen.

Voor ondersteuning van SQL Server-databases heeft Azure producten voor alles, van individuele databases tot zeer schaalbare elastische SQL Database-pools. Afzonderlijke microservices kunnen snel en eenvoudig worden geconfigureerd om te communiceren met hun eigen individuele SQL Server-databases. Deze databases kunnen naar behoefte worden geschaald om elke afzonderlijke microservice te ondersteunen op basis van de behoeften.

In de eShopOnContainers-toepassing wordt het huidige winkelwagentje van de gebruiker tussen aanvragen opgeslagen. Dit aspect wordt beheerd door de Basket-microservice waarin de gegevens in een Redis-cache worden opgeslagen. In ontwikkeling kan deze cache worden geïmplementeerd in een container, terwijl deze in productie gebruik kan maken van Azure Cache voor Redis. Azure Cache voor Redis is een volledig beheerde service die hoge prestaties en betrouwbaarheid biedt zonder dat u Zelf Redis-exemplaren of -containers hoeft te implementeren en beheren.

De microservice Locations maakt gebruik van een MongoDB NoSQL-database voor persistentie. Tijdens de ontwikkeling kan de database worden geïmplementeerd in een eigen container, terwijl de service in productie gebruikmaakt van de API van Azure Cosmos DB voor MongoDB. Een van de voordelen van Azure Cosmos DB is de mogelijkheid om gebruik te maken van meerdere verschillende communicatieprotocollen, waaronder een SQL-API en algemene NoSQL-API's, waaronder MongoDB, Cassandra, Gremlin en Azure Table Storage. Azure Cosmos DB biedt een volledig beheerde en wereldwijd gedistribueerde database als een service die kan worden geschaald om te voldoen aan de behoeften van de services die deze gebruiken.

Gedistribueerde gegevens in cloudtoepassingen worden uitgebreider behandeld in hoofdstuk 5.

Event Bus

De toepassing gebruikt gebeurtenissen om wijzigingen tussen verschillende services te communiceren. Deze functionaliteit kan worden geïmplementeerd met verschillende implementaties en lokaal de eShopOnContainers-toepassing maakt gebruik van RabbitMQ. Wanneer deze wordt gehost in Azure, maakt de toepassing gebruik van Azure Service Bus voor de berichten. Azure Service Bus is een volledig beheerde integratieberichtbroker waarmee toepassingen en services op een ontkoppelde, betrouwbare, asynchrone manier met elkaar kunnen communiceren. Azure Service Bus ondersteunt afzonderlijke wachtrijen en afzonderlijke onderwerpen ter ondersteuning van scenario's voor uitgeversabonnee. De eShopOnContainers-toepassing maakt gebruik van onderwerpen met Azure Service Bus ter ondersteuning van het distribueren van berichten van de ene microservice naar elke andere microservice die nodig is om op een bepaald bericht te reageren.

Tolerantie

Zodra de toepassing eShopOnContainers in productie is geïmplementeerd, kan de toepassing profiteren van verschillende Azure-services die beschikbaar zijn om de tolerantie te verbeteren. De toepassing publiceert statuscontroles, die kunnen worden geïntegreerd met Application Insights om rapportage en waarschuwingen te bieden op basis van de beschikbaarheid van de app. Azure-resources bieden ook diagnostische logboeken die kunnen worden gebruikt om fouten en prestatieproblemen te identificeren en op te lossen. Resourcelogboeken bieden gedetailleerde informatie over wanneer en hoe verschillende Azure-resources worden gebruikt door de toepassing. Meer informatie over cloudeigen tolerantiefuncties vindt u in hoofdstuk 6.

VorigeVolgende