Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
In dit scenario migreert een e-commercebedrijf in de reisindustrie een verouderde web-app met behulp van Azure API Management. Het bedrijf host de nieuwe gebruikersinterface als een PaaS-app (Platform as a Service) in Azure. De nieuwe gebruikersinterface is afhankelijk van zowel bestaande als nieuwe HTTP-API's. Deze API's worden geïmplementeerd met effectiever ontworpen interfaces die de prestaties verbeteren, de integratie vereenvoudigen en toekomstige uitbreidbaarheid mogelijk maken.
Architecture
Download een Visio-bestand van deze architectuur.
Workflow
De volgende werkstroom komt overeen met het vorige diagram:
De bestaande on-premises web-app blijft de bestaande on-premises webservices rechtstreeks gebruiken.
Aanroepen van de bestaande web-app naar de bestaande HTTP-services blijven ongewijzigd. Deze aanroepen zijn intern voor het bedrijfsnetwerk.
API Management maakt oproepen vanuit Azure naar de bestaande interne services.
Het beveiligingsteam staat toe dat verkeer van het API Management-exemplaar door de bedrijfsfirewall naar de bestaande on-premises services passeert door gebruik te maken van beveiligde transportprotocollen, zoals Hypertext Transfer Protocol Secure (HTTPS) via Transport Layer Security (TLS).
Het operations-team staat binnenkomende aanroepen naar de services alleen toe vanuit het API Management-exemplaar. Het voldoet aan deze vereiste door het IP-adres van het API Management-exemplaar toe te voegen aan de acceptatielijst binnen de perimeter van het bedrijfsnetwerk.
Een nieuwe module in de on-premises aanvraagpijplijn voor HTTP-services (Hypertext Transfer Protocol) werkt alleen op verbindingen die extern afkomstig zijn. De pijplijn valideert een certificaat dat API Management biedt.
De nieuwe API heeft de volgende kenmerken:
Alleen het API Management-exemplaar, dat de API-gevel levert, geeft de nieuwe API weer. U hebt geen rechtstreeks toegang tot de nieuwe API.
U ontwikkelt en publiceert de nieuwe API als een Azure PaaS-web-API-app.
U stelt de nieuwe API in met behulp van de instellingen voor de functie Web Apps van Azure App Service om alleen het virtuele IP-adres (VIP) van API Management te accepteren.
Web Apps host de nieuwe API met beveiligde transportprotocollen, zoals HTTPS of TLS ingeschakeld.
Azure App Service biedt autorisatiemogelijkheden via Microsoft Entra ID en Open Authorization (OAuth) 2.
De nieuwe browsergebaseerde web-app is afhankelijk van het API Management-exemplaar voor zowel de bestaande HTTP-API als de nieuwe API.
Het e-commercebedrijf voor reizen kan sommige gebruikers doorsturen naar de nieuwe gebruikersinterface voor preview of testen, terwijl de oude gebruikersinterface en bestaande functionaliteit naast elkaar behouden blijven.
Stel het API Management-exemplaar in om de verouderde HTTP-services toe te wijzen aan een nieuw API-contract. In deze configuratie is de nieuwe webgebruikersinterface niet op de hoogte van de integratie met een set verouderde services of API's en nieuwe API's.
In de toekomst kan het projectteam geleidelijk functionaliteit verplaatsen naar de nieuwe API's en de oorspronkelijke services buiten gebruik stellen. Het team verwerkt deze wijzigingen in de API Management-configuratie, waardoor de front-endgebruikersinterface niet wordt beïnvloed en herontwikkeling wordt voorkomen.
Components
API Management is een beheerplatform en gateway voor API's in alle omgevingen. In deze architectuur fungeert het als een gevel voor de bestaande verouderde API's en de nieuwe API's. De nieuwe client-app verbruikt één consistente interface en het team kan verouderde back-ends incrementeel achter die gevel moderniseren met minimale impact op front-endontwikkeling.
App Service is een kant-en-klare PaaS-oplossing voor webhosting die kant-en-klare functies biedt, zoals beveiliging, taakverdeling, automatisch schalen en geautomatiseerd beheer. In deze architectuur biedt App Service flexibele kant-en-klare hosting, zodat het DevOps-team zich kan richten op functielevering.
Alternatives
Als de organisatie van plan is de infrastructuur te verplaatsen, inclusief de virtuele machines (VM's) die de verouderde apps hosten, volledig naar Azure, kan API Management fungeren als een gevel voor elk adresseerbaar HTTP-eindpunt.
Als de organisatie de bestaande eindpunten privé houdt en deze niet openbaar maakt, kan het API Management-exemplaar van de organisatie een koppeling maken naar een virtueel Azure-netwerk.
Wanneer API Management is gekoppeld aan een virtueel Azure-netwerk, kan de organisatie de back-endservice rechtstreeks adresseren via privé-IP-adressen.
In het on-premises scenario kan het API Management-exemplaar privé verbinding maken met de interne service via Azure VPN Gateway en een site-naar-site IPsec-VPN-verbinding (Internet Protocol Security) of Azure ExpressRoute. Dit scenario wordt vervolgens een hybride van Azure en on-premises.
De organisatie kan het API Management-exemplaar privé houden door het in de interne modus te implementeren. De organisatie kan vervolgens implementatie gebruiken met Azure Application Gateway om openbare toegang toe te staan voor sommige API's, terwijl andere intern blijven. Zie API Management integreren in een intern virtueel netwerk met behulp van Application Gateway voor meer informatie.
De organisatie kan besluiten om de API's on-premises te hosten. Een van de redenen voor deze wijziging kan zijn dat de organisatie geen downstreamdatabaseafhankelijkheden kan verplaatsen die binnen het bereik van dit project naar de cloud vallen. In dit scenario kan de organisatie lokaal gebruikmaken van API Management met behulp van een zelf-hostende gateway.
De zelf-hostende gateway is een containerimplementatie van de API Management-gateway die verbinding maakt met Azure op een uitgaande socket. Als u zelf-hostende gateways wilt gebruiken, moet u voldoen aan de volgende vereisten:
U moet zelf-hostende gateways implementeren met behulp van een bovenliggende resource in Azure, waardoor extra kosten worden toegevoegd.
U moet de Premium-laag van API Management gebruiken.
Scenario-details
Een e-commercebedrijf in de reisindustrie wil zijn verouderde, browsergebaseerde softwarestack moderniseren. De bestaande stack is voornamelijk monolithisch, maar sommige HTTP-services op basis van SOAP (Simple Object Access Protocol) bestaan uit een recent project. Het bedrijf beschouwt het creëren van extra inkomstenstromen om geld te verdienen met een deel van zijn interne intellectuele eigendom.
Doelen voor het project zijn onder andere het aanpakken van technische schulden, doorlopende onderhoudsverbeteringen en functieontwikkelingsversnelling met minder regressiefouten. Het project maakt gebruik van een iteratief proces om risico's te voorkomen en voert de volgende stappen parallel uit:
Het ontwikkelteam moderniseert de back-end van de app, die bestaat uit relationele databases die worden gehost op VM's.
Het interne ontwikkelteam schrijft nieuwe bedrijfsfunctionaliteit en maakt deze beschikbaar via nieuwe HTTP-API's.
Een contractontwikkelingsteam bouwt een nieuwe gebruikersinterface op basis van een browser, die door Azure wordt gehost.
Het bedrijf levert in fasen nieuwe app-functies. Deze functies vervangen geleidelijk de bestaande browsergebaseerde client- en servergebruikersinterfacefunctionaliteit die on-premises wordt gehost die de e-commerce-business van het bedrijf mogelijk maakt.
Leden van het managementteam willen niet onnodig moderniseren. Ze willen ook de controle over het bereik en de kosten behouden. Om deze doelen te bereiken, besluiten ze hun bestaande SOAP HTTP-services te behouden. Ze zijn ook van plan wijzigingen in de bestaande gebruikersinterface te minimaliseren. Ze kunnen API Management gebruiken om te voldoen aan veel van de vereisten en beperkingen van het project.
Potentiële gebruikscases
In dit scenario wordt uitgelegd hoe u verouderde, browsergebaseerde softwarestacks kunt moderniseren.
U kunt dit scenario gebruiken voor de volgende taken:
- Bekijk hoe uw bedrijf kan profiteren van het gebruik van het Azure-ecosysteem.
- Plan een servicemigratie naar Azure.
- Meer informatie over hoe een overstap naar Azure van invloed kan zijn op bestaande API's.
Considerations
Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die u kunt gebruiken om de kwaliteit van een workload te verbeteren. Zie Well-Architected Framework voor meer informatie.
Reliability
Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie de controlelijst ontwerpbeoordeling voor betrouwbaarheid voor meer informatie.
Activeer beschikbaarheidszones wanneer u uw API Management-exemplaar implementeert. De optie voor het implementeren van API Management in beschikbaarheidszones is alleen beschikbaar in de Premium-servicelagen.
Gebruik beschikbaarheidszones waarop extra gateway-exemplaren zijn geïmplementeerd in verschillende regio's. Deze combinatie verbetert de beschikbaarheid van de service als één regio offline gaat. Implementatie met meerdere regio's is alleen beschikbaar in de Premium-servicelaag.
Integreer met Application Insights, waarmee metrische gegevens worden weergegeven via Azure Monitor voor bewaking. U kunt bijvoorbeeld de metrische capaciteitsgegevens gebruiken om de totale belasting van de API Management-resource te bepalen en of u meer uitschaaleenheden nodig hebt. Resourcecapaciteit en -status bijhouden om de betrouwbaarheid te verbeteren.
Zorg ervoor dat downstreamafhankelijkheden, zoals de back-endservices die als host fungeren voor de API's die door API Management worden behandeld, ook tolerant zijn.
Kostenoptimalisatie
Kostenoptimalisatie richt zich op manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie de controlelijst ontwerpbeoordeling voor Kostenoptimalisatie voor meer informatie.
API Management heeft acht lagen:
- Verbruik
- Ontwikkelaar
- Basic en Basic v2
- Standard en Standard v2
- Premium en Premium v2
Zie prijzen voor API Management voor meer informatie over de verschillen in deze lagen.
U kunt API Management schalen door eenheden toe te voegen en te verwijderen. De capaciteit van elke eenheid is afhankelijk van de bijbehorende laag.
Note
U kunt de developer-laag gebruiken om API Management-functies te evalueren. Gebruik het niet voor productie.
Als u de verwachte kosten voor uw implementatiebehoeften wilt bekijken, kunt u het aantal schaaleenheden en App Service-exemplaren wijzigen in de Azure-prijscalculator.
Contributors
Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.
Hoofdauteur:
- Ben Gimblett | Senior klanttechnicus
Andere bijdrager:
- Andrew Cardy | Senior Software Engineer
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.
Volgende stappen
- Overzicht van App Service
- Overzicht van API Management
- Stagingomgevingen instellen in App Service
- Uw API transformeren en beveiligen
- App Service verkennen