Utforma en geografiskt distribuerad programarkitektur
När våra nätverkskomponenter dirigerar begäranden till flera regioner för att minska effekterna av ett regionalt avbrott måste vi utforma programtjänster som kan svara på dessa begäranden i både primära och väntelägesregioner.
Kom ihåg att vi planerar att konfigurera Azure Front Door med prioriterad serverdelstilldelning. Vi tilldelar regionen USA, östra som primär region och regionen USA, västra som vår väntelägesregion. När ett regionalt fel inträffar dirigeras begäranden till App Service i den fungerande regionen. Vi måste konfigurera resurser i varje region för att stödja dessa redundansväxlingar för användaråtkomst, replikerad lagring och programkod.
Här undersöker vi programtjänsterna i vår lösning och avgör om de behöver ändras för att fungera i en arkitektur med flera regioner. Mer specifikt tittar vi på Active Directory, lagring av statiskt innehåll, webbappar, webb-API:er, köer, Azure-funktioner och datacacheminnen.
Microsoft Entra ID
I vår leveransspårningsportal kan användarna spåra leveransen av sina inköp genom att ange ett spårningsnummer. Vanliga användare kan dock registrera sig för medlemskap för att få åtkomst till avancerade funktioner, till exempel snabb leverans och annan statistik. Vi har utvecklat spårningsportalen för att lagra användarkonton i Microsoft Entra-ID.
Microsoft Entra-ID är utformat som ett globalt system som standard. Därför är den inte sårbar för regionala fel och vi behöver inte ändra den här komponenten i systemet.
Azure Blob Storage (lagringstjänst)
Statiskt innehåll, till exempel bilder och videor, lagras i Azure Storage-konton som binära stora objekt (blobar) och hanteras av användare via Azure CDN.
I vår ursprungliga design finns lagringskontot i en enda region eftersom vi valde att använda lokalt redundant lagring (LRS). Våra data replikeras endast inom ett enda datacenter med LRS. Lagringskontot är därför inte tillgängligt om det uppstår ett regionalt avbrott i den här konfigurationen. Allt statiskt innehåll som redan cachelagras av CDN är fortfarande tillgängligt för användare.
Detsamma gäller zonredundant lagring (ZRS). Även om data replikeras till olika datacenter i den här konfigurationen finns alla dessa datacenter fortfarande i samma region. Ett regionalt avbrott påverkar även lagringskontot i den här konfigurationen.
I vår design förlitar vi oss mycket på vår CDN-konfiguration för att cachelagra statiskt innehåll. Det finns en risk att en användare vid ett avbrott kan begära en statisk fil som ännu inte finns i CDN-cachen. Den här begäran skulle resultera i en bild eller video som inte kan visas.
Vi kan eliminera den här möjligheten genom att replikera lagringskontot till flera regioner när vi väljer ett geo-redundant lagringsalternativ. Ett skrivskyddat replikeringsalternativ är också tillgängligt för att förhindra att statiskt innehåll läggs till under ett regionalt avbrott.
Vi har två alternativ att välja mellan när vi behöver aktivera geo-redundans. De här alternativen är Read-Access Geo-Redundant Storage (RA-GRS) och Read-Access Geo-Zone-Redundant Storage (RA-GZRS). Valet vi gör beror på vår budget och den procentandel av driftstiden som vi behöver.
Azure App Service och Azure Function Apps
Vår spårningsportal för leveranser implementerar två Azure App Services. Den första App Service är värd för en webbapp som implementerar det användarriktade webbgränssnittet och den andra är värd för ett webb-API som används av mobilappar för att spåra leveransdata. Alla våra bakgrundsuppgifter körs som Azure-funktionsappar.
I vår ursprungliga design lokaliseras varje Azure App Service till en enda Azure-region. Vi skapar en andra App Service i den sekundära regionen (USA, västra) och distribuerar webbprojektet där för att stödja den nya arkitekturen för flera regioner. Vi konfigurerar Azure Front Door-prioritetsdirigeringsläget för att skicka begäranden till vår sekundära region när den primära regionen inte är tillgänglig.
Kontrollera att redundansväxlingen är så smidig som möjligt genom att se till att webbprogrammet inte lagrar någon information om sessionstillstånd i minnet. Vi ändrar vår webbplats för att se till att vi inte får dataförlust. Om koden till exempel lagrar en lista över användarnas sändningar i minnet går den här listan förlorad om en redundansväxling inträffar.
Varje webbbegäran hanteras utan att påverka den andra när inget sessionstillstånd lagras. Om en redundansväxling sker mitt i en användares session ska redundansväxlingen vara transparent för användaren.
Vi gör en liknande ändring för våra appar med Azure-funktioner. Vi skapar en separat instans av Azure-funktionen i den sekundära regionen och distribuerar samma anpassade kod till den som körs i den primära regionen.
Viktig
När du distribuerar en uppdatering av den anpassade koden i App Service eller Funktionsapptjänsten ska du komma ihåg att distribuera den till alla instanser av App Service. Om du vill automatisera den här processen har Azure DevOps verktyg som kan hjälpa dig.
Azure Storage-köer
I vår ursprungliga arkitektur med en enda region använde vi en kö i ett Azure Storage-konto för att hantera kommunikationen mellan App Service och funktionsappen. När webbappen eller webb-API:et behöver köra en bakgrundsaktivitet placerar den ett meddelande med all nödvändig information i kön. Funktionsappen övervakar kön efter nya meddelanden och kör bakgrundsaktiviteten genom att köra nödvändiga frågor mot datalager.
Vi kan hantera en hög efterfrågan i webbbegäranden på ett ordnat sätt när vi använder en kö på det här sättet. När det finns många bakgrundsaktiviteter att köra kan kön byggas upp, men aktiviteter tas inte bort. De stannar kvar i kön tills de bearbetas. Funktionsapparna arbetar genom kön och minskar dess storlek när efterfrågan minskar. Om efterfrågan kvarstår ökar vi antalet instanser av funktionsappen.
För multi-region-versionen av leveransspårningsportalen måste vi se till att köobjekt inte går förlorade när redundansväxling sker. Vår kö definieras i Azure Storage och vi kan använda ett redundansalternativ för geo-replikering.
Tänk på att vi inte kan använda ett redundansalternativ för läsåtkomst eftersom vår kö stöder läs- och skrivåtgärder. App Service måste lägga till objekt i kön och funktionsappen måste ta bort slutförda objekt från kön. Använd Geo-Redundant Storage (GRS) eller Geo-Zone-Redundant Storage (GZRS) i stället.
Azure Redis Cache
Vi använder Azure Redis Cache för att maximera datalagringens prestanda. Redis cachelagrar alla frågeresultat som genereras från våra appar när de begär data från vår databas. Ytterligare frågor för liknande data behöver ingen databasfråga och hämtas från Redis-cachen.
För arkitekturen för flera regioner skapar vi en Redis Cache-instans i både primära regioner och väntelägesregioner. Tänk på att Redis Cache i väntelägesregionen sannolikt kommer att vara tom när en redundansväxling inträffar. Den tomma cachen orsakar inga fel, men prestandan kan tillfälligt sjunka när data fyller den nya cachen.