I det här scenariot migrerar ett näthandelsföretag inom resebranschen ett äldre webbprogram med hjälp av Azure API Management. Det nya användargränssnittet kommer att finnas som ett PaaS-program (plattform som en tjänst) i Azure, och det beror på både befintliga och nya HTTP-API:er. Dessa API:er levereras med en bättre utformad uppsättning gränssnitt, vilket ger bättre prestanda, enklare integrering och framtida utökningsbarhet.
Arkitektur
Ladda ned en Visio-fil med den här arkitekturen.
Arbetsflöde
- Det befintliga lokala webbprogrammet fortsätter att använda de befintliga lokala webbtjänsterna direkt.
- Anrop från den befintliga webbappen till befintliga HTTP-tjänster förblir oförändrade. Dessa anrop är interna i företagsnätverket.
- Inkommande anrop görs från Azure till befintliga interna tjänster:
- Säkerhetsteamet tillåter trafik från API Management-instansen att passera genom företagets brandvägg till befintliga lokala tjänster med hjälp av säker transport (HTTPS eller SSL).
- Driftteamet tillåter endast inkommande anrop till tjänsterna från API Management-instansen. Det uppfyller detta krav genom att lägga till IP-adressen för API Management-instansen i listan över tillåtna i företagets nätverksperimeter.
- En ny modul konfigureras i den lokala pipelinen för begäran för HTTP-tjänster (för att endast agera på anslutningar som har sitt ursprung externt). Pipelinen verifierar ett certifikat som API Management tillhandahåller.
- Det nya API:et:
- Visas endast via API Management-instansen, som tillhandahåller API-fasaden. Det nya API:et nås inte direkt.
- Utvecklas och publiceras som en Azure PaaS-webb-API-app.
- Har konfigurerats (via inställningar för funktionen Web Apps i Azure App Service) för att endast acceptera den virtuella IP-adressen för API Management.
- Finns i Web Apps med säker transport (HTTPS eller SSL) aktiverad.
- Har auktorisering aktiverat, som tillhandahålls av Azure App Service via Microsoft Entra ID och OAuth 2.
- Det nya webbläsarbaserade webbprogrammet är beroende av Azure API Management-instansen för både det befintliga HTTP-API:et och det nya API:et.
API Management-instansen är konfigurerad för att mappa äldre HTTP-tjänster till ett nytt API-kontrakt. I den här konfigurationen känner det nya webbgränssnittet inte till integreringen med en uppsättning äldre tjänster/API:er och nya API:er.
I framtiden kommer projektteamet gradvis att portera funktioner till de nya API:erna och dra tillbaka de ursprungliga tjänsterna. Teamet hanterar dessa ändringar i API Management-konfigurationen, vilket gör att klientdelsgränssnittet inte påverkas och undviker ombyggnadsarbete.
Komponenter
Alternativ
Om organisationen planerar att flytta sin infrastruktur helt till Azure, inklusive de virtuella datorer som är värdar för de äldre programmen, är API Management fortfarande ett bra alternativ eftersom det kan fungera som en fasad för alla adresserbara HTTP-slutpunkter.
Om organisationen hade valt att hålla de befintliga slutpunkterna privata och inte exponera dem offentligt, kunde organisationens API Management-instans länkas till ett virtuellt Azure-nätverk:
- I ett Scenario med "lift and shift" i Azure som är länkat till ett distribuerat virtuellt Azure-nätverk kan organisationen direkt adressera serverdelstjänsten via privata IP-adresser.
- I det lokala scenariot kan API Management-instansen nå tillbaka till den interna tjänsten privat via en Azure VPN-gateway och IPSec VPN-anslutning från plats till plats eller Azure ExpressRoute. Det här scenariot skulle sedan bli en hybrid av Azure och lokalt.
Organisationen kan hålla API Management-instansen privat genom att distribuera den i internt läge. Organisationen kan sedan använda distribution med Azure Application Gateway för att aktivera offentlig åtkomst för vissa API:er medan andra förblir interna. Mer information finns i Integrera API Management i ett internt virtuellt nätverk med Application Gateway.
Organisationen kan välja att vara värd för sina API:er lokalt. En orsak till den här ändringen kan vara att organisationen inte kunde flytta underordnade databasberoenden som finns i omfånget för projektet till molnet. I så fall kan organisationen fortfarande dra nytta av API Management lokalt med hjälp av en gateway med egen värd.
Den lokalt installerade gatewayen är en containerbaserad distribution av API Management-gatewayen som ansluter tillbaka till Azure på en utgående socket. Den första förutsättningen är att lokala gatewayer inte kan distribueras utan en överordnad resurs i Azure, vilket medför en extra kostnad. För det andra krävs Premium-nivån för API Management.
Kommentar
Allmän information om hur du ansluter API Management till ett virtuellt nätverk finns i den här artikeln.
Information om scenario
Ett e-handelsföretag i resebranschen moderniserar sin äldre webbläsarbaserade programvarustack. Även om den befintliga stacken mestadels är monolitisk finns det vissa SOAP-baserade HTTP-tjänster från ett nytt projekt. Företaget överväger att skapa ytterligare intäktsströmmar för att tjäna pengar på en del av den interna immateriella egendom som det har utvecklat.
Målen för projektet är att åtgärda tekniska skulder, förbättra pågående underhåll och påskynda funktionsutvecklingen med färre regressionsbuggar. Projektet använder en iterativ process för att undvika risker, med vissa steg som utförs parallellt:
- Utvecklingsteamet moderniserar programmets serverdel, som består av relationsdatabaser som finns på virtuella datorer.
- Det interna utvecklingsteamet kommer att skriva nya affärsfunktioner som kommer att exponeras över nya HTTP-API:er.
- Ett kontraktsutvecklingsteam skapar ett nytt webbläsarbaserat användargränssnitt som kommer att finnas i Azure.
Nya programfunktioner levereras stegvis. Dessa funktioner ersätter gradvis de befintliga webbläsarbaserade klient-/servergränssnittsfunktionerna (lokalt värdbaserade) som nu driver företagets e-handelsverksamhet.
Medlemmar i ledningsgruppen vill inte modernisera i onödan. De vill också behålla kontrollen över omfång och kostnader. För att göra detta har de bestämt sig för att bevara sina befintliga SOAP HTTP-tjänster. De har också för avsikt att minimera ändringar i det befintliga användargränssnittet. De kan använda Azure API Management för att hantera många av projektets krav och begränsningar.
Potentiella användningsfall
Det här scenariot belyser modernisering av äldre webbläsarbaserade programvarustackar.
Du kan använda det här scenariot för att:
- Se hur ditt företag kan dra nytta av att använda Azure-ekosystemet.
- Planera för migrering av tjänster till Azure.
- Lär dig hur en övergång till Azure skulle påverka befintliga API:er.
Att tänka på
Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som bidrar till att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.
Tillgänglighet och skalbarhet
- Du kan skala ut Azure API Management genom att välja en prisnivå och sedan lägga till enheter.
- Skalning kan också ske automatiskt med automatisk skalning.
- Distribution över flera regioner möjliggör redundansalternativ och kan göras på Premium-nivån.
- Överväg att integrera med Azure Application Insights, som även visar mått via Azure Monitor för övervakning.
Kostnadsoptimering
Kostnadsoptimering handlar om att hitta sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.
API Management erbjuds på fyra nivåer: Developer, Basic, Standard och Premium. Detaljerad vägledning om skillnaderna på dessa nivåer finns i prisvägledningen för Azure API Management.
Du kan skala API Management genom att lägga till och ta bort enheter. Varje enhets kapacitet beror på dess nivå.
Kommentar
Du kan använda utvecklarnivån för utvärdering av API Management-funktionerna. Använd den inte för produktion.
Om du vill visa beräknade kostnader och anpassa efter dina distributionsbehov kan du ändra antalet skalningsenheter och App Service-instanser i Priskalkylatorn för Azure.
Distribuera det här scenariot
Kom igång genom att skapa en Azure API Management-instans i portalen.
Du kan också välja från en befintlig Azure Resource Manager-snabbstartsmall som överensstämmer med ditt specifika användningsfall.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudförfattare:
- Ben Gimblett | Senior kundtekniker
Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.
Nästa steg
Produktdokumentation:
Learn-moduler:
- Utforska Azure App Service
- Distribuera en webbplats till Azure med Azure App Service
- Skydda dina API:er i Azure API Management