App-service met meerdere lagen met service-eindpunt

App Service

Virtual Network

Elke webtoepassing die is ontwikkeld en gedistribueerd over meer dan één laag staat bekend als een webtoepassing met meerdere lagen. De lagen verdelen de toepassing in twee of meer onderdelen die afzonderlijk kunnen worden ontwikkeld en uitgevoerd. Eenvoudig gezegd is een webtoepassing met meerdere lagen een front-endwebtoepassing die een of meer API-toepassingen erachter aanroept. Deze referentiearchitectuur laat zien hoe u service-eindpunten gebruikt voor beveiligde communicatie tussen app-services in een omgeving met meerdere lagen.

Met behulp van service-eindpunten kunt u inkomende toegang tot uw API-app bepalen. U kunt opgeven dat alle accessoires zich moeten in de subnetten die u selecteert. De beperking kan worden ingesteld voor de API-app of op de front-endsite met regels voor toestaan en weigeren op het niveau van het virtuele netwerk en subnet.

Notitie

Hoewel dit artikel gericht is op het gebruik van service-eindpunten, zijn andere aspecten van de architectuur, zoals Azure App Service en integratie van virtuele netwerken, algemeen van toepassing.

Potentiële gebruikscases

Deze architectuur kan geschikt zijn voor deze gebruiksgevallen:

Oplossingen met twee services waarvoor toegangsbeperkingen zijn vereist
Toepassingen voor financiën en gezondheidszorg waarvoor privéverbindingen met een back-end-API-app zijn vereist

Architectuur

Een Visio-bestand van deze architectuur downloaden.

Dit is de verkeersstroom en de basisconfiguratie van de architectuur:

Aanvragen worden van internet gerouteerd naar een front-end-app.
De functie voor integratie van virtuele App Service alle uitgaande communicatie van de front-end-apps naar het integratiesubnet. Zie Uw app integreren met een virtueel Azure-netwerkvoor meer informatie over de integratie van virtuele netwerken.
De API-app heeft service-eindpunten die binnenkomende communicatie beperken. Ze staan alleen communicatie toe vanuit front-end-apps op het integratiesubnet. Zie service-eindpunten Virtual Network voor meer informatie over service-eindpunten.
De API-app is niet toegankelijk vanaf het openbare internet. Alleen interne onderdelen, of onderdelen die zijn verbonden met het virtuele netwerk, kunnen de API-app bereiken.
Een resourcegroep is een container met gerelateerde resources voor een Azure-oplossing. De resources kunnen virtuele machines, virtuele netwerken, opslagaccounts, web-apps, databases en databaseservers zijn. Het kan handig zijn om resources te groepen die dezelfde levenscyclus hebben, zodat u ze eenvoudig als groep kunt implementeren, bijwerken en verwijderen. Zie Wat is een resourcegroep voor meer informatie.

Onderdelen

Azure Virtual Network is een beveiligd particulier netwerk in de cloud. Het verbindt VM's met elkaar, met internet en met on-premises netwerken.
Azure App Service is een volledig beheerde service voor het bouwen, implementeren en schalen van web-apps. U kunt apps bouwen met behulp van .NET, .NET Core, Node.js, Java, Python of PHP. Apps kunnen worden uitgevoerd in containers of op Windows of Linux. De functie voor integratie van virtuele App Service kan uw app toegang geven tot resources in of via een virtueel netwerk. Zie Uw app integreren met een virtueel Azure-netwerk voor meer informatie.
Azure Private Link biedt persoonlijke toegang tot services die worden gehost op het Azure-platform, waarbij uw gegevens op het Microsoft-netwerk worden gehouden.

Alternatieven

U kunt zowel de front-end-app als de API-app in dezelfde Azure App Service Environment implementeren en de front-end-app rechtstreeks toegankelijk maken voor internet met behulp van een toepassingsgateway. Zie Introduction to the App Service Environments (Inleiding tot de omgevingen voor App Service) voor meer informatie App Service omgevingen.
Een andere techniek is het implementeren van de front-end-app in de multitenant-service en de API-app in een App Service Environment. U kunt ook zowel de front-end-app als de API-app hosten in de multitenant-service.
Er zijn andere manieren om uw web-apps te beveiligen, zoals:
- Door de app toegewezen adressen
- Toegangsbeperkingen
- Azure Private Link
Zie netwerkfuncties voor App Service meer informatie.

Voordelen

Deze architectuur biedt een manier om een webtoepassing met meerdere lagen te maken die een beveiligde API-back-end heeft. Verkeer naar uw API-app komt alleen uit het subnet van de front-end-web-app.
Service-eindpunten zijn betaalbaarder, sneller en gemakkelijker in te stellen in vergelijking met App Service omgevingen. Het is niet mogelijk dat een App Service-web-app lid wordt van een virtueel netwerk zonder de App Service Environment, wat duur is.
Service-eindpunten werken goed op kleinere schaal, omdat u eenvoudig service-eindpunten kunt inschakelen voor de API-app op het subnet voor front-endintegratie.
Het Private Link voegt complexiteit toe omdat er twee subnetten zijn. De privéverbinding is ook een resource op het hoogste niveau die beheeroverhead toevoegt.

Overwegingen

Service-eindpunten beschermen de API-apps tegen toegang door andere apps dan front-end-apps. Front-end-apps worden echter niet beveiligd tegen andere front-end-apps.

Beschikbaarheid

Een systeem kan niet zeer beschikbaar zijn, tenzij het betrouwbaar is. Zie Betrouwbaarheidspatronen voor technieken om de betrouwbaarheid te vergroten.

Schaalbaarheid

Efficiëntie van prestaties is het vermogen van uw workload om te schalen om op een efficiënte manier te voldoen aan de eisen die aan uw workload worden gevraagd. Let op prestatie-efficiëntiepatronen bij het ontwerpen en bouwen van uw cloudtoepassing. Zie Prestatie-efficiëntiepatronen voor meer informatie.
Meer informatie over het schalen van een eenvoudige web-app in De app App Service schalen. Lees de andere artikelen in dezelfde sectie voor ideeën over andere architecturen.
Zie controlelijst voor prestatie-efficiëntie voor meer ideeën over prestatie-efficiëntie.

Prijzen

Gebruik de Azure-prijscalculator om de kosten te schatten.

Enkele aspecten die van invloed zijn op de kosten van een implementatie zijn:

De schaalbaarheid van de oplossing: hoe goed deze wijzigingen in de vraag ondersteunt.
Of de oplossing continu of af en toe wordt uitgevoerd.
De gekozen servicelagen.