Utforma en geografiskt distribuerad nätverksarkitektur
I en distribuerad app är det viktigt att se till att komponenterna kan kommunicera på ett tillförlitligt sätt och att förfrågningar kan dirigeras till en annan komponent eller region om ett fel uppstår.
Vi har beslutat att återskapa vår leveransportal i Azure för att minska dess sårbarhet för regionala haverier. Vi vill se till att programmet redundansväxlar till komponenter i en sekundär region när den primära regionen inte är tillgänglig. Redundansväxlingen bör orsaka minimala avbrott i tjänstleveransen till användarna.
Här lär vi oss hur Azure DNS, Traffic Manager, Front Door och Azure CDN stöder vårt leveransföretags apparkitektur.
Azure DNS
Vi såg tidigare att vi inte behövde utföra några ändringar i vår Azure DNS-implementering. Vi använder Azure DNS som värd för de domännamnsposter som identifierar vår app.
Azure DNS tillhandahåller all namnmatchning via Azure-infrastrukturen. Den här tjänsten finns i flera regioner. Det innebär att du inte behöver ändra den befintliga Azure DNS-konfigurationen för att stödja funktionen i vår nya arkitekturdesign.
Serviceavtalet för Azure DNS har också en 100-procentig garanti för att giltiga DNS-begäranden får ett svar från minst en Azure DNS-namnserver hela tiden.
Välja en trafikrouter
Vi behöver en tjänst som kan lastbalansera och omdirigera trafik över flera regioner med distribuerade webbappar.
Azure erbjuder flera olika tjänster som kan dirigera trafik mellan komponenter på klientsidan. Vi behöver bara ersätta vår Azure Application Gateway, eftersom det bara är den som kopplad till en region. Om ett fel uppstår i den regionen, går det inte att utföra routningen.
Det finns två trafikroutrar i Azure som kan utföra global routning mellan flera regioner och som inte är sårbara för ett avbrott i en enda region:
- Azure Traffic Manager
- Azure Front Door
Vi ska gå igenom dessa tjänster mer detaljerat så att vi kan välja rätt router för vårt program.
Vad är Azure Traffic Manager?
Azure Traffic Manager är en global lastbalanserare som använder DNS-poster när trafik dirigeras till mål i flera Azure-regioner.
Vi kan konfigurera Traffic Manager för att dirigera alla begäranden till vår primära region och övervaka svarstiden för App Service i den regionen. Om det uppstår fel i App Service i den primära regionen, dirigerar Traffic Manager automatiskt om användarförfrågningarna till App Service i den sekundära regionen. Den här omdirigeringen kör redundansväxlingen för att säkerställa en kontinuerlig tjänst. Vi kallar det för prioritetsroutning.
Eftersom Traffic Manager använder DNS-systemet till att dirigera trafik dirigeras alla protokoll, inte bara HTTP-trafik. Traffic Manager kan dock inte dirigera eller filtrera trafik baserat på HTTP-egenskaper, t.ex. klientens landskoder eller användaragenthuvuden. Det går inte heller att avsluta TLS-protokollet (Transport Layer Security), där routern dekrypterar begäranden och krypterar svar för att inte belasta de virtuella App Service-servrarna. Om vi behöver någon av dessa funktioner måste vi använda Azure Front Door.
Traffic Manager använder konfigureringsbar slutpunktsövervakning. Vi kan till exempel definiera protokollet, porten, sökvägen, anpassade rubrikinställningar, förväntade statuskodintervall och tolererat antal fel. Med slutpunktsövervakningen får vi en kontinuerlig bild av den övergripande hälsan för alla delar i vårt program.
Vad är Azure Front Door?
Precis som Traffic Manager är Azure Front Door en global lastbalanserare. Till skillnad från Traffic Manager används den på nätverkets programnivå (lager 7) och den använder HTTP- och HTTPS-egenskaper till att filtrera och dirigera.
Med Front Door kan vi utföra många typer av routning som Traffic Manager inte stöder. Vi kan till exempel dirigera trafik baserat på webbläsarens landskod. Front Door har även stöd för avslutning av TLS-protokoll.
Det finns dock ett undantag. Om vi vill dirigera trafik för något annat protokoll än HTTP och HTTPS måste vi använda Traffic Manager.
Med Front Door kan vi tilldela prioriteter till de olika serverdelarna som utgör spårningsportalen. De här prioriteringarna gör det möjligt för Front Door att dirigera begäranden efter behov. Vi tilldelar våra primära regiontjänster med högsta prioritet och vår sekundära regiontjänst med lägre prioritet.
Front Door implementerar hälsoavsökningar som övervakar hälsostatus för tjänsterna och om det uppstår något fel kan trafiken dirigeras på rätt sätt. Läget för prioritetsroutning och slutpunktsövervakning i Front Door liknar dessa funktioner i Traffic Manager, förutom att hälsoavsökningar alltid körs via HTTP.
All trafik i leveransportalens webbgränssnitt och dess API:er görs via HTTPS, vilket innebär att vi kan byta ut Azure Traffic Manager mot Front Door. Vi kan också konfigurera Front Door med prioriterad serverdelstilldelning.
Azure CDN
I vår arkitektur för en region använde vi Azure CDN till att cachelagra statiskt innehåll från Azure Blob Storage. Azure CDN-tjänsten är ett globalt nätverk med servrar som cachelagrar statiskt innehåll nära användarna. Vi behöver inte ändra den här tjänsten för arkitekturen i flera regioner. Det finns dock saker att tänka på när det gäller vårt Azure Storage-konto som vi kommer att ta upp i nästa lektion.