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 (VIP).
- 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 Open Authorization (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.
- Rese-e-handelsföretaget kan nu dirigera vissa användare till det nya användargränssnittet (för förhandsversion eller testning) samtidigt som det gamla användargränssnittet och befintliga funktioner bevaras sida vid sida.
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
- Azure API Management abstraherar serverdels-API:er samt lägger till övergripande funktioner och identifiering för utvecklare och program. I det här scenariot kan du återskapa befintliga äldre serverdels-API:er och lägga till nya API-funktioner genom att använda API Management som en fasad för att det nya klientprogrammet ska kunna använda konsekvent och med moderna standarder. Eftersom API Management fasader både befintliga och nya API:er är det möjligt för utvecklarna att modernisera de äldre serverdelarna bakom API Management-fasaden på ett iterativt sätt och med minimal till noll inverkan på den nya frontend-utvecklingen.
- Azure App Service är en nyckelfärdig PaaS-tjänst (Platform as a Service) för webbvärdtjänster som tillhandahåller färdiga funktioner som säkerhet, belastningsutjämning, automatisk skalning och automatiserad hantering. Azure App Service är ett bra val för de nya API:er som utvecklas för den här lösningen eftersom det ger flexibel nyckelfärdig värd, vilket gör det möjligt för DevOps-teamet att fokusera på att leverera funktioner.
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:
- När API Management är länkat till ett 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 EN IPSec-ANSLUTNING (Internet Protocol Security) 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.
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 (Simple Object Access Protocol) från ett projekt som nyligen har skapats. 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.
Tillförlitlighet
Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Checklista för designgranskning för tillförlitlighet.
- Överväg att distribuera din Azure API Management-instans med tillgänglighetszoner aktiverade. Alternativet att distribuera API Management till tillgänglighetszoner är endast tillgängligt på Premium-tjänstnivån.
- Tillgänglighetszoner kan användas tillsammans med ytterligare gatewayinstanser som distribueras till olika regioner. Detta förbättrar tjänstens tillgänglighet om en region kopplas från. Distribution i flera regioner är också endast tillgängligt på Premium-tjänstnivån.
- Överväg att integrera med Azure Application Insights, som även visar mått via Azure Monitor för övervakning. Kapacitetsmåttet kan till exempel användas för att fastställa den totala belastningen på API Management-resursen och om ytterligare utskalningsenheter krävs. Att spåra resurskapaciteten och hälsan förbättrar tillförlitligheten.
- Se till att underordnade beroenden, till exempel serverdelstjänster som är värdar för API:er som API Management-fasader, också är motståndskraftiga.
Kostnadsoptimering
Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Checklista för designgranskning för kostnadsoptimering.
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.
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