Reliable Web App-mönster för Java

Den här artikeln innehåller vägledning om hur du implementerar reliable web app-mönstret. Det här mönstret beskriver hur du ändrar (omplatforma) webbappar för molnmigrering. Den erbjuder normativ arkitektur, kod och konfigurationsvägledning i linje med principerna i det välarkitekterade ramverket.

Varför är mönstret Reliable Web App för Java?

Mönstret Reliable Web App är en uppsättning principer och implementeringstekniker som definierar hur du ska formatera om webbappar när du migrerar till molnet. Den fokuserar på de minimala koduppdateringar som du behöver göra för att lyckas i molnet. Följande vägledning använder referensimplementeringen som ett exempel i hela och följer omplatformresan för det fiktiva företaget Contoso Fiber för att tillhandahålla affärskontext för din resa. Innan contoso Fiber implementerade mönstret Reliable Web App för Java hade det ett monolitiskt, lokalt kundkontohanteringssystem (CAMS) som använde Spring Boot-ramverket.

Så här implementerar du mönstret Reliable Web App

Den här artikeln innehåller vägledning för arkitektur, kod och konfiguration för att implementera mönstret Reliable Web App. Använd följande länkar för att navigera till den specifika vägledning du behöver:

• Affärskontext: Anpassa den här vägledningen till din affärskontext och lär dig hur du definierar omedelbara och långsiktiga mål som driver på omplatformningsbeslut.
• Arkitekturvägledning: Lär dig hur du väljer rätt molntjänster och utformar en arkitektur som uppfyller dina affärskrav.
• Kodvägledning: Implementera tre designmönster för att förbättra webbappens tillförlitlighet och prestandaeffektivitet i molnet: Försök igen, Kretsbrytare och Cache-Aside-mönster
• Konfigurationsvägledning: Konfigurera autentisering och auktorisering, hanterade identiteter, rättighetsbaserade miljöer, infrastruktur som kod och övervakning.

Affärskontext

Det första steget i att omplatforma en webbapp är att definiera dina affärsmål. Du bör ange omedelbara mål, till exempel servicenivåmål och kostnadsoptimeringsmål, samt framtida mål för ditt webbprogram. Dessa mål påverkar ditt val av molntjänster och arkitekturen för ditt webbprogram i molnet. Definiera ett mål-SLO för din webbapp, till exempel 99,9 % drifttid. Beräkna det sammansatta serviceavtalet för alla tjänster som påverkar webbappens tillgänglighet.

Contoso Fiber ville till exempel utöka sin lokala CAMS-webbapp (Customer Account Management System) för att nå andra regioner. För att möta den ökade efterfrågan på webbappen fastställde de följande mål:

• Tillämpa kodändringar med låga kostnader och höga värden
• Nå ett servicenivåmål (SLO) på 99,9 %
• Anta DevOps-metoder
• Skapa kostnadsoptimerade miljöer
• Förbättra tillförlitligheten och säkerheten

Contoso Fiber fastställde att deras lokala infrastruktur inte var en kostnadseffektiv lösning för att skala programmet. Därför bestämde de sig för att migrera sin CAMS-webbapp till Azure var det mest kostnadseffektiva sättet att uppnå sina omedelbara och framtida mål.

Vägledning för arkitektur

Reliable Web App-mönstret har några viktiga arkitektoniska element. Du behöver DNS för att hantera slutpunktsmatchning, en brandvägg för webbprogram för att blockera skadlig HTTP-trafik och en lastbalanserare för att skydda och dirigera inkommande användarbegäranden. Programplattformen är värd för din webbappskod och anropar alla serverdelstjänster via privata slutpunkter i ett virtuellt nätverk. Ett programprestandaövervakningsverktyg samlar in mått och loggar för att förstå din webbapp.

Figur 1. Viktiga arkitektoniska element i Reliable Web App-mönstret.

Utforma arkitekturen

Utforma infrastrukturen för att stödja dina återställningsmått, till exempel mål för återställningstid (RTO) och mål för återställningspunkter (RPO). RTO påverkar tillgängligheten och måste ha stöd för ditt serviceavtal. Fastställ ett mål för återställningspunkt (RPO) och konfigurera dataredundans för att uppfylla RPO.

• Välj infrastrukturtillförlitlighet. Avgör hur många tillgänglighetszoner och regioner du behöver för att uppfylla dina tillgänglighetsbehov. Lägg till tillgänglighetszoner och regioner tills det sammansatta serviceavtalet uppfyller ditt serviceavtal. Mönstret Reliable Web App stöder flera regioner för en aktiv-aktiv eller aktiv-passiv konfiguration. Referensimplementeringen använder till exempel en aktiv-passiv konfiguration för att uppfylla ett servicemål på 99,9 %.

  För en webbapp för flera regioner konfigurerar du lastbalanseraren så att den dirigerar trafik till den andra regionen för att stödja antingen en aktiv-aktiv eller aktiv-passiv konfiguration beroende på ditt affärsbehov. De två regionerna kräver samma tjänster förutom att en region har ett virtuellt navnätverk som ansluter regionerna. Anta en nätverkstopologi för nav och eker för att centralisera och dela resurser, till exempel en nätverksbrandvägg. Om du har virtuella datorer lägger du till en skyddsvärd i det virtuella hubbnätverket för att hantera dem på ett säkert sätt (se bild 2).

  

  Figur 2. Mönstret Reliable Web App med en andra region och en topologi med nav och eker.

• Välj en nätverkstopologi. Välj rätt nätverkstopologi för dina webb- och nätverkskrav. Om du planerar att ha flera virtuella nätverk använder du en nätverkstopologi för nav och ekrar. Det ger kostnads-, hanterings- och säkerhetsfördelar med hybridanslutningsalternativ till lokala och virtuella nätverk.

Välj rätt Azure-tjänster

När du flyttar en webbapp till molnet bör du välja Azure-tjänster som uppfyller dina affärskrav och som överensstämmer med de aktuella funktionerna i den lokala webbappen. Justeringen hjälper till att minimera omplatformningsarbetet. Använd till exempel tjänster som gör att du kan behålla samma databasmotor och stödja befintliga mellanprogram och ramverk. Följande avsnitt innehåller vägledning för att välja rätt Azure-tjänster för din webbapp.

Innan du till exempel flyttar till molnet var Contoso Fibers CAMS-webbapp en lokal, monolitisk Java-webbapp. Det är en Spring Boot-app med en PostgreSQL-databas. Webbappen är en verksamhetsspecifik supportapp. Det är medarbetarläge. Contoso Fiber-anställda använder programmet för att hantera supportärenden från sina kunder. Webbappen har drabbats av vanliga utmaningar när det gäller skalbarhet och funktionsdistribution. Den här utgångspunkten, deras affärsmål och SLO drev deras tjänstval.

• Programplattform: Använd Azure App Service som programplattform. Contoso Fiber valde Azure App Service som programplattform av följande skäl:

  • Naturlig utveckling: Contoso Fiber distribuerade en Spring Boot-fil jar på sin lokala server och ville minimera mängden omdirigering för den distributionsmodellen. App Service ger robust stöd för att köra Spring Boot-appar, och det var en naturlig utveckling för Contoso Fiber att använda App Service. Azure Container Apps är också ett attraktivt alternativ för den här appen. Mer information finns i Vad är Azure Spring Apps? och Java i Översikt över Azure Container Apps.
  • Högt serviceavtal: Det har ett högt serviceavtal som uppfyller kraven för produktionsmiljön.
  • Minskade hanteringskostnader: Det är en fullständigt hanterad värdlösning.
  • Containeriseringsfunktion: App Service fungerar med privata containeravbildningsregister som Azure Container Registry. Contoso Fiber kan använda dessa register för att containerisera webbappen i framtiden.
  • Autoskalning: Webbappen kan snabbt skalas upp, ned, in och ut baserat på användartrafik.

• Identitetshantering: Använd Microsoft Entra-ID som identitets- och åtkomsthanteringslösning. Contoso Fiber valde Microsoft Entra-ID av följande skäl:

  • Autentisering och auktorisering: Programmet måste autentisera och auktorisera callcenter-anställda.
  • Skalbar: Den skalas för att stödja större scenarier.
  • Användaridentitetskontroll: Callcenter-anställda kan använda sina befintliga företagsidentiteter.
  • Stöd för auktoriseringsprotokoll: Det stöder OAuth 2.0 för hanterade identiteter.

• Databas: Använd en tjänst som gör att du kan behålla samma databasmotor. Använd beslutsträdet för datalagret. Contoso Fiber valde Azure Database for PostgreSQL och alternativet flexibel server av följande skäl:

  • Tillförlitlighet: Distributionsmodellen för flexibel server stöder zonredundant hög tillgänglighet i flera tillgänglighetszoner. Den här konfigurationen har en varm väntelägesserver i en annan tillgänglighetszon inom samma Azure-region. Konfigurationen replikerar data synkront till väntelägesservern.
  • Replikering mellan regioner: Den har en skrivskyddad replikfunktion som gör att du asynkront kan replikera data till en skrivskyddad replikdatabas i en annan region.
  • Prestanda: Den ger förutsägbara prestanda och intelligent justering för att förbättra databasens prestanda med hjälp av verkliga användningsdata.
  • Minskade hanteringskostnader: Det är en fullständigt hanterad Azure-tjänst som minskar hanteringsskyldigheten.
  • Stöd för migrering: Den stöder databasmigrering från lokala PostgreSQL-databaser med en enda server. De kan använda migreringsverktyget för att förenkla migreringsprocessen.
  • Konsekvens med lokala konfigurationer: Den stöder olika community-versioner av PostgreSQL, inklusive den version som Contoso Fiber använder för närvarande.
  • Återhämtning. Den flexibla serverdistributionen skapar automatiskt serversäkerhetskopior och lagrar dem med zonredundant lagring (ZRS) inom samma region. De kan återställa sin databas till valfri tidpunkt inom kvarhållningsperioden för säkerhetskopior. Säkerhetskopierings- och återställningsfunktionen skapar ett bättre RPO (acceptabel mängd dataförlust) än vad Contoso Fiber kan skapa lokalt.

• Övervakning av programprestanda: Använd Application Insights för att analysera telemetri i ditt program. Contoso Fiber valde att använda Application Insights av följande skäl:

  • Integrering med Azure Monitor: Det ger den bästa integreringen med Azure Monitor.
  • Avvikelseidentifiering: Den identifierar automatiskt prestandaavvikelser.
  • Felsökning: Det hjälper dig att diagnostisera problem i appen som körs.
  • Övervakning: Den samlar in information om hur användare använder appen och gör att du enkelt kan spåra anpassade händelser.
  • Synlighetsgap: Den lokala lösningen hade ingen lösning för övervakning av programprestanda. Application Insights ger enkel integrering med programplattformen och koden.

• Cache: Välj om du vill lägga till cache i webbappens arkitektur. Azure Cache for Redis är Azures primära cachelösning. Det är ett hanterat minnesinternt datalager baserat på Redis-programvaran. Contoso Fiber har lagt till Azure Cache for Redis av följande skäl:

  • Hastighet och volym: Den har dataflöde med hög dataflöde och låg latensläsning för data som används ofta och ändras långsamt.
  • Mångsidig support: Det är en enhetlig cacheplats som alla instanser av webbappen kan använda.
  • Externt datalager. De lokala programservrarna utförde vm-lokal cachelagring. Den här konfigurationen avlastade inte mycket frekventa data och det gick inte att ogiltigförklara data.
  • Nonsticky-sessioner: Cachen gör att webbappen kan externalisera sessionstillståndet och använda icke-sticka sessioner. De flesta Java-webbappar som körs lokalt använder minnesintern cachelagring på klientsidan. Minnesintern cachelagring på klientsidan skalas inte bra och ökar minnets fotavtryck på värden. Med hjälp av Azure Cache for Redis har Contoso Fiber en fullständigt hanterad, skalbar cachetjänst för att förbättra skalbarheten och prestandan för sina program. Contoso Fiber använde ett cacheabstraktionsramverk (Spring Cache) och behövde bara minimala konfigurationsändringar för att växla ut cacheprovidern. Det gjorde det möjligt för dem att växla från en Ehcache-provider till Redis-providern.

• Lastbalanserare: Webbprogram som använder PaaS-lösningar bör använda Azure Front Door, Azure Application Gateway eller båda baserat på webbappens arkitektur och krav. Använd beslutsträdet för lastbalanseraren för att välja rätt lastbalanserare. Contoso Fiber behövde en layer-7-lastbalanserare som kunde dirigera trafik över flera regioner. Contoso Fiber behövde en webbapp för flera regioner för att uppfylla SLO:et på 99,9 %. Contoso Fiber valde Azure Front Door av följande skäl:

  • Global belastningsutjämning: Det är en layer-7-lastbalanserare som kan dirigera trafik över flera regioner.
  • Brandvägg för webbprogram: Den integreras internt med Azure Web Application Firewall.
  • Flexibilitet för routning: Det gör att programteamet kan konfigurera inkommande behov för att stödja framtida ändringar i programmet.
  • Trafikacceleration: Den använder anycast för att nå närmaste Azure-närvaropunkt och hitta den snabbaste vägen till webbappen.
  • Anpassade domäner: Den stöder anpassade domännamn med flexibel domänverifiering.
  • Hälsoavsökningar: Programmet behöver intelligent hälsoavsökningsövervakning. Azure Front Door använder svar från avsökningen för att fastställa det bästa ursprunget för routning av klientbegäranden.
  • Stöd för övervakning: Den stöder inbyggda rapporter med en allt-i-ett-instrumentpanel för både Front Door och säkerhetsmönster. Du kan konfigurera aviseringar som integreras med Azure Monitor. Programmet kan logga varje begäran och misslyckade hälsoavsökningar.
  • DDoS-skydd: Det har inbyggt layer 3-4 DDoS-skydd.
  • Nätverk för innehållsleverans: Det placerar Contoso Fiber i ett nätverk för innehållsleverans. Nätverket för innehållsleverans ger platsacceleration.

• Brandvägg för webbprogram: Använd Azure Web Application Firewall för att ge centraliserat skydd mot vanliga webbexploateringar och sårbarheter. Contoso Fiber använde Azure Web Application Firewall av följande skäl:

  • Globalt skydd: Det ger förbättrat globalt webbappskydd utan att offra prestanda.
  • Botnet-skydd: Teamet kan övervaka och konfigurera inställningar för att hantera säkerhetsproblem som rör botnät.
  • Paritet med lokal: Den lokala lösningen kördes bakom en brandvägg för webbprogram som hanteras av IT.
  • Användarvänlighet: Brandväggen för webbaserade program integreras med Azure Front Door.

• Secrets Manager: Använd Azure Key Vault om du har hemligheter att hantera i Azure. Contoso Fiber använde Key Vault av följande skäl:

  • Kryptering: Den stöder kryptering i vila och under överföring.
  • Stöd för hanterad identitet: Programtjänsterna kan använda hanterade identiteter för att komma åt det hemliga arkivet.
  • Övervakning och loggning: Det underlättar granskningsåtkomst och genererar aviseringar när lagrade hemligheter ändras.
  • Integrering: Den tillhandahåller intern integrering med Azure-konfigurationsarkivet (App Configuration) och webbvärdplattformen (App Service).

• Slutpunktssäkerhet: Använd Azure Private Link för att få åtkomst till lösningar för plattform som en tjänst via en privat slutpunkt i ditt virtuella nätverk. Trafik mellan ditt virtuella nätverk och tjänsten färdas över Microsofts stamnätverk. Contoso Fiber valde Private Link av följande skäl:

  • Förbättrad säkerhetskommunikation: Det ger programmet privat åtkomst till tjänster på Azure-plattformen och minskar nätverksavtrycket för datalager för att skydda mot dataläckage.
  • Minimalt arbete: De privata slutpunkterna stöder webbappplattformen och databasplattformen som webbappen använder. Båda plattformarna speglar befintliga lokala konfigurationer för minimal ändring.

• Nätverkssäkerhet: Använd Azure Firewall för att styra inkommande och utgående trafik på nätverksnivå. Använd Azure Bastion för att ansluta till virtuella datorer på ett säkert sätt utan att exponera RDP/SSH-portar. Contoso Fiber antog en topologi för nav- och ekernätverk och ville placera delade nätverkssäkerhetstjänster i hubben. Azure Firewall förbättrar säkerheten genom att inspektera all utgående trafik från ekrarna för att öka nätverkssäkerheten. Contoso Fiber behövde Azure Bastion för säkra distributioner från en jump-värd i DevOps-undernätet.

Kodvägledning

Om du vill flytta en webbapp till molnet måste du uppdatera webbappskoden med mönster för återförsök, mönster för kretsbrytarmönster och cache-aside-designmönster.

Figur 3. Designmönstrens roll.

Varje designmönster ger arbetsbelastningsdesignfördelar som överensstämmer med en av fler grundpelare i det väldefinierade ramverket. Här är en översikt över de mönster som du bör implementera:

1. Återförsöksmönster: Återförsöksmönstret hanterar tillfälliga fel genom att försöka utföra åtgärder som kan misslyckas tillfälligt. Implementera det här mönstret för alla utgående anrop till andra Azure-tjänster.

2. Kretsbrytarmönster: Kretsbrytarmönstret hindrar ett program från att försöka utföra åtgärder som inte är tillfälliga. Implementera det här mönstret i alla utgående anrop till andra Azure-tjänster.

3. Cache-Aside-mönster: Cache-Aside-mönstret lägger till och hämtar från en cache oftare än ett datalager. Implementera det här mönstret på begäranden till databasen.

Implementera återförsöksmönstret

Lägg till mönstret Försök igen i programkoden för att åtgärda tillfälliga tjänststörningar. Dessa störningar kallas för tillfälliga fel. Tillfälliga fel löser sig vanligtvis inom några sekunder. Med mönstret Försök igen kan du skicka misslyckade begäranden igen. Du kan också konfigurera fördröjningar i begäran och antalet försök innan felet släpps in.

Använd Resilience4j, ett enkelt bibliotek med feltolerans, för att implementera återförsöksmönstret i Java. Referensimplementeringen lägger till mönstret Försök igen genom att dekorera serviceplansstyrenhetens listServicePlans-metod med Återförsöksanteckningar. Koden försöker anropa igen till en lista över tjänstplaner från databasen om det första anropet misslyckas. Referensimplementeringen konfigurerar återförsöksprincipen, inklusive maximalt antal försök, väntetid och vilka undantag som ska göras på nytt. Återförsöksprincipen konfigureras i application.properties.

    @GetMapping("/list")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    @CircuitBreaker(name = SERVICE_PLAN)
    @Retry(name = SERVICE_PLAN)
    public String listServicePlans(Model model) {
        List<serviceplandto> servicePlans = planService.getServicePlans();
        model.addAttribute("servicePlans", servicePlans);
        return "pages/plans/list";
    }

Implementera kretsbrytarmönstret

Använd kretsbrytarmönstret för att hantera tjänststörningar som inte är tillfälliga fel. Kretsbrytarmönstret hindrar ett program från att kontinuerligt försöka komma åt en tjänst som inte svarar. Det släpper programmet och undviker att slösa cpu-cykler så att programmet behåller sin prestandaintegritet för slutanvändare.

Använd Dokumentation om Spring Circuit Breaker och Resilience4j för att implementera kretsbrytarmönstret. Referensimplementeringen implementerar till exempel kretsbrytarmönstret genom att dekorera metoder med attributet Kretsbrytare.

Implementera mönstret Cache-Aside

Lägg till mönstret Cache-Aside i webbappen för att förbättra minnesintern datahantering. Mönstret tilldelar programmet ansvaret för att hantera databegäranden och säkerställa konsekvens mellan cacheminnet och en beständig lagring, till exempel en databas. Det förkortar svarstiderna, förbättrar dataflödet och minskar behovet av mer skalning. Det minskar också belastningen på det primära dataarkivet, vilket förbättrar tillförlitligheten och kostnadsoptimeringen. Följ dessa rekommendationer för att implementera cache-Aside-mönstret:

• Konfigurera programmet så att det använder en cache. Om du vill aktivera cachelagring lägger du till spring-boot-starter-cache paketet som ett beroende i pom.xml filen. Det här paketet innehåller standardkonfigurationer för Redis Cache.

• Cachelagrade data med stort behov. Använd Cache-Aside-mönstret på data med stort behov för att förstärka dess effektivitet. Använd Azure Monitor för att spåra databasens processor, minne och lagring. De här måtten hjälper dig att avgöra om du kan använda en mindre databas-SKU efter att cache-aside-mönstret har tillämpats. Om du vill cachelagera specifika data i koden lägger du till anteckningen @Cacheable . Den här kommentaren anger för Spring vilka metoder som ska ha sina resultat cachelagrade.

• Håll cachedata fräscha. Schemalägg regelbundna cacheuppdateringar för att synkronisera med de senaste databasändringarna. Fastställa den optimala uppdateringshastigheten baserat på datavolatilitet och användarbehov. Den här metoden säkerställer att programmet använder mönstret Cache-Aside för att ge både snabb åtkomst och aktuell information. Standardinställningarna för cachen kanske inte passar ditt webbprogram. Du kan anpassa de här inställningarna i application.properties filen eller miljövariablerna. Du kan till exempel ändra spring.cache.redis.time-to-live värdet (uttryckt i millisekunder) för att styra hur länge data ska finnas kvar i cacheminnet innan de avlägsnas.

• Se till att data är konsekventa. Implementera mekanismer för att uppdatera cachen omedelbart efter en databasskrivningsåtgärd. Använd händelsedrivna uppdateringar eller dedikerade datahanteringsklasser för att säkerställa cachesammanhållning. Konsekvent synkronisering av cacheminnet med databasändringar är centralt för cache-Aside-mönstret.

Konfigurationsvägledning

Följande avsnitt innehåller vägledning om hur du implementerar konfigurationsuppdateringarna. Varje avsnitt överensstämmer med en eller flera pelare i det välarkitekterade ramverket.

Konfigurera användarautentisering och auktorisering

När du migrerar webbprogram till Azure konfigurerar du mekanismer för användarautentisering och auktorisering. Följ dessa rekommendationer:

• Använd en identitetsplattform. Använd Microsoft Identity-plattformen för att konfigurera autentisering av webbappar. Den här plattformen stöder program som använder en enda Microsoft Entra-katalog, flera Microsoft Entra-kataloger från olika organisationer samt Microsoft-identiteter eller sociala konton.

  Spring Boot Starter för Microsoft Entra ID effektiviserar den här processen och använder Spring Security och Spring Boot för enkel installation. Den erbjuder olika autentiseringsflöden, automatisk tokenhantering och anpassningsbara auktoriseringsprinciper, samt integreringsfunktioner med Spring Cloud-komponenter. Detta möjliggör enkel Microsoft Entra-ID och OAuth 2.0-integrering i Spring Boot-program utan manuell biblioteks- eller inställningskonfiguration.

  Referensimplementeringen använder till exempel Microsofts identitetsplattform (Microsoft Entra-ID) som identitetsprovider för webbappen. Den använder OAuth 2.0-auktoriseringskoden bevilja för att logga in en användare med ett Microsoft Entra-konto. Följande XML-kodfragment definierar de två nödvändiga beroendena för OAuth 2.0-auktoriseringskodens beviljandeflöde. Beroendet com.azure.spring: spring-cloud-azure-starter-active-directory möjliggör Microsoft Entra-autentisering och -auktorisering i ett Spring Boot-program. Beroendet org.springframework.boot: spring-boot-starter-oauth2-client stöder OAuth 2.0-autentisering och -auktorisering i ett Spring Boot-program.

  <dependency>
      <groupid>com.azure.spring</groupid>
      <artifactid>spring-cloud-azure-starter-active-directory</artifactid>
  </dependency>
  <dependency>
      <groupid>org.springframework.boot</groupid>
      <artifactid>spring-boot-starter-oauth2-client</artifactid>
  </dependency>
  

• Skapa en appregistrering. Microsoft Entra-ID kräver en programregistrering i den primära klientorganisationen. Programregistreringen säkerställer att de användare som får åtkomst till webbappen har identiteter i den primära klientorganisationen. Referensimplementeringen använder till exempel Terraform för att skapa en Microsoft Entra ID-appregistrering tillsammans med en appspecifik Account Manager-roll.

  resource "azuread_application" "app_registration" {
    display_name     = "${azurecaf_name.app_service.result}-app"
    owners           = [data.azuread_client_config.current.object_id]
    sign_in_audience = "AzureADMyOrg"  # single tenant
  
    app_role {
      allowed_member_types = ["User"]
      description          = "Account Managers"
      display_name         = "Account Manager"
      enabled              = true
      id                   = random_uuid.account_manager_role_id.result
      value                = "AccountManager"
    }
  }
  

• Framtvinga auktorisering i programmet. Använd rollbaserade åtkomstkontroller (RBAC) för att tilldela minst behörighet till programroller. Definiera specifika roller för olika användaråtgärder för att undvika överlappning och säkerställa tydlighet. Mappa användare till lämpliga roller och se till att de bara har åtkomst till nödvändiga resurser och åtgärder. Konfigurera Spring Security för att använda Spring Boot Starter för Microsoft Entra-ID. Det här biblioteket tillåter integrering med Microsoft Entra-ID och hjälper dig att säkerställa att användarna autentiseras på ett säkert sätt. Genom att konfigurera och aktivera Microsoft Authentication Library (MSAL) får du tillgång till fler säkerhetsfunktioner. Dessa funktioner omfattar cachelagring av token och automatisk tokenuppdatering.

  Referensimplementeringen skapar till exempel approller som återspeglar typerna av användarroller i Contoso Fibers kontohanteringssystem. Roller översätts till behörigheter under auktoriseringen. Exempel på appspecifika roller i CAMS är kontoansvarig, supportrepresentant på nivå ett (L1) och fälttjänstrepresentant. Rollen Account Manager har behörighet att lägga till nya appanvändare och kunder. En fälttjänstrepresentant kan skapa supportärenden. Attributet PreAuthorize begränsar åtkomsten till specifika roller.

      @GetMapping("/new")
      @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
      public String newAccount(Model model) {
          if (model.getAttribute("account") == null) {
              List<ServicePlan> servicePlans = accountService.findAllServicePlans();
              ServicePlan defaultServicePlan = servicePlans.stream().filter(sp -> sp.getIsDefault() == true).findFirst().orElse(null);
              NewAccountRequest accountFormData = new NewAccountRequest();
              accountFormData.setSelectedServicePlanId(defaultServicePlan.getId());
              model.addAttribute("account", accountFormData);
              model.addAttribute("servicePlans", servicePlans);
          }
          model.addAttribute("servicePlans", accountService.findAllServicePlans());
          return "pages/account/new";
      }
      ...
  

  För att integrera med Microsoft Entra-ID använder referensimplementeringen OAuth 2.0-auktoriseringskodens beviljandeflöde. Med det här flödet kan en användare logga in med ett Microsoft-konto. Följande kodfragment visar hur du konfigurerar SecurityFilterChain att använda Microsoft Entra-ID för autentisering och auktorisering.

  @Configuration(proxyBeanMethods = false)
  @EnableWebSecurity
  @EnableMethodSecurity
  public class AadOAuth2LoginSecurityConfig {
      @Bean
      SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
          http.apply(AadWebApplicationHttpSecurityConfigurer.aadWebApplication())
              .and()
                  .authorizeHttpRequests()
              .requestMatchers(EndpointRequest.to("health")).permitAll()
              .anyRequest().authenticated()
              .and()
                  .logout(logout -> logout
                              .deleteCookies("JSESSIONID", "XSRF-TOKEN")
                              .clearAuthentication(true)
                              .invalidateHttpSession(true));
          return http.build();
      }
  }
  ...
  

• Föredrar tillfällig åtkomst till lagring. Använd tillfälliga behörigheter för att skydda mot obehörig åtkomst och intrång, till exempel signaturer för delad åtkomst (SAS). Använd SAS för användardelegering för att maximera säkerheten när du beviljar tillfällig åtkomst. Det är den enda SAS som använder autentiseringsuppgifter för Microsoft Entra-ID och som inte kräver en permanent lagringskontonyckel.

• Framtvinga auktorisering i Azure. Använd Azure RBAC för att tilldela minsta möjliga behörighet till användaridentiteter. Azure RBAC avgör vilka Azure-resursidentiteter som kan kommas åt, vad de kan göra med dessa resurser och vilka områden de har åtkomst till.

• Undvik permanent utökade behörigheter. Använd Microsoft Entra Privileged Identity Management för att bevilja just-in-time-åtkomst för privilegierade åtgärder. Utvecklare behöver till exempel ofta åtkomst på administratörsnivå för att skapa/ta bort databaser, ändra tabellscheman och ändra användarbehörigheter. Med just-in-time-åtkomst får användaridentiteter tillfälliga behörigheter för att utföra privilegierade uppgifter.

Implementera hanterade identiteter

Använd hanterade identiteter för alla Azure-tjänster som stöder hanterade identiteter. Med en hanterad identitet kan Azure-resurser (arbetsbelastningsidentiteter) autentisera till och interagera med andra Azure-tjänster utan att hantera autentiseringsuppgifter. Hybridsystem och äldre system kan behålla lokala autentiseringslösningar för att förenkla migreringen men bör övergå till hanterade identiteter så snart som möjligt. Följ dessa rekommendationer för att implementera hanterade identiteter:

• Välj rätt typ av hanterad identitet. Föredrar användartilldelade hanterade identiteter när du har två eller flera Azure-resurser som behöver samma uppsättning behörigheter. Den här konfigurationen är effektivare än att skapa systemtilldelade hanterade identiteter för var och en av dessa resurser och tilldela samma behörigheter till dem alla. Annars använder du systemtilldelade hanterade identiteter.

• Konfigurera minsta behörighet. Använd Azure RBAC för att endast bevilja de behörigheter som är viktiga för åtgärderna, till exempel CRUD-åtgärder i databaser eller åtkomst till hemligheter. Identitetsbehörigheter för arbetsbelastningar är beständiga, så du kan inte ge just-in-time- eller kortsiktiga behörigheter till arbetsbelastningsidentiteter. Om Azure RBAC inte täcker ett specifikt scenario kompletterar du Azure RBAC med åtkomstprinciper på Azure-tjänstnivå.

• Skydda återstående hemligheter. Lagra eventuella återstående hemligheter i Azure Key Vault. Läs in hemligheter från Key Vault vid programstart i stället för under varje HTTP-begäran. Högfrekvent åtkomst i HTTP-begäranden kan överskrida key vault-transaktionsgränserna. Lagra programkonfigurationer i Azure App Configuration.

Rätt storleksmiljöer

Använd prestandanivåerna (SKU:er) för Azure-tjänster som uppfyller behoven i varje miljö utan överskott. Följ dessa rekommendationer om du vill ändra storlek på dina miljöer:

• Beräkna kostnader. Använd Priskalkylatorn för Azure för att beräkna kostnaden för varje miljö.

• Kostnadsoptimera produktionsmiljöer. Produktionsmiljöer behöver SKU:er som uppfyller serviceavtalen (SLA), funktioner och skalning som behövs för produktion. Övervaka resursanvändningen kontinuerligt och justera SKU:er så att de överensstämmer med de faktiska prestandabehoven.

• Kostnadsoptimera förproduktionsmiljöer. Förproduktionsmiljöer bör använda resurser med lägre kostnad, inaktivera onödiga tjänster och tillämpa rabatter som Priser för Azure Dev/Test. Se till att förproduktionsmiljöerna är tillräckligt lika produktionsmiljön för att undvika risker. Den här balansen säkerställer att testningen fortsätter att vara effektiv utan onödiga kostnader.

• Definiera SKU:er med hjälp av infrastruktur som kod (IaC). Implementera IaC för att dynamiskt välja och distribuera rätt SKU:er baserat på miljön. Den här metoden förbättrar konsekvensen och förenklar hanteringen.

Referensimplementeringen har till exempel en valfri parameter som distribuerar olika SKU:er. En miljöparameter instruerar Terraform-mallen att välja SKU:er för utveckling.

azd env set APP_ENVIRONMENT prod

Implementera autoskalning

Autoskalning säkerställer att en webbapp förblir elastisk, dynamisk och kan hantera dynamiska arbetsbelastningar effektivt. Följ dessa rekommendationer för att implementera automatisk skalning:

• Automatisera utskalning. Använd Automatisk skalning i Azure för att automatisera horisontell skalning i produktionsmiljöer. Konfigurera regler för automatisk skalning för att skala ut baserat på viktiga prestandamått, så att ditt program kan hantera varierande belastningar.

• Förfina skalningsutlösare. Börja med cpu-användning som den första skalningsutlösaren om du inte känner till programmets skalningskrav. Förfina dina skalningsutlösare så att de innehåller andra mått, till exempel RAM-minne, nätverksdataflöde och disk-I/O. Målet är att matcha webbappens beteende för bättre prestanda.

• Ange en utskalningsbuffert. Ange skalningströsklarna som utlösare innan du når maximal kapacitet. Konfigurera till exempel skalning till 85 % processoranvändning i stället för att vänta tills den når 100 %. Den här proaktiva metoden hjälper till att upprätthålla prestanda och undvika potentiella flaskhalsar.

Automatisera resursdistribution

Använd automatisering för att distribuera och uppdatera Azure-resurser och kod i alla miljöer. Följ dessa rekommendationer:

• Använd infrastruktur som kod. Distribuera infrastruktur som kod via CI/CD-pipelines (kontinuerlig integrering och kontinuerlig leverans). Azure har färdiga Bicep-, ARM- (JSON) och Terraform-mallar för varje Azure-resurs.

• Använd en CI/CD-pipeline (continuous integration/continuous deployment). Använd en CI/CD-pipeline för att distribuera kod från källkontroll till olika miljöer, till exempel test, mellanlagring och produktion. Använd Azure Pipelines om du arbetar med Azure DevOps eller GitHub Actions för GitHub-projekt.

• Integrera enhetstestning. Prioritera körning och överföring av alla enhetstester i pipelinen innan du distribuerar till App Services. Införliva kodkvalitets- och täckningsverktyg som SonarQube för att uppnå omfattande testtäckning.

• Anta modelleringsramverk. Om du vill testa externa slutpunkter använder du modelleringsramverk. Med dessa ramverk kan du skapa simulerade slutpunkter. De eliminerar behovet av att konfigurera verkliga externa slutpunkter och säkerställa enhetliga testvillkor i olika miljöer.

• Utföra säkerhetsgenomsökningar. Använd säkerhetstestning för statiska program (SAST) för att hitta säkerhetsfel och kodfel i källkoden. Utför dessutom analys av programvarusammansättning (SCA) för att undersöka bibliotek och komponenter från tredje part för säkerhetsrisker. Verktyg för dessa analyser är enkelt integrerade i både GitHub och Azure DevOps.

Konfigurera övervakning

Implementera program- och plattformsövervakning för att förbättra webbappens driftseffektivitet och prestandaeffektivitet. Följ dessa rekommendationer för att implementera övervakning:

• Samla in programtelemetri. Använd autoinstrumentation i Azure Application Insights för att samla in programtelemetri, till exempel dataflöde för begäranden, genomsnittlig varaktighet för begäran, fel och beroendeövervakning, utan kodändringar. Spring Boot registrerar flera kärnmått i Application Insights, till exempel virtuella Java-datorer (JVM), CPU, Tomcat och andra. Application Insights samlar automatiskt in från loggningsramverk som Log4j och Logback. Referensimplementeringen använder till exempel Application Insights aktiverat via Terraform som en del av App Service-konfigurationen app_settings . (se följande kod).

  app_settings = {
      APPLICATIONINSIGHTS_CONNECTION_STRING = var.app_insights_connection_string
      ApplicationInsightsAgent_EXTENSION_VERSION = "~3"
      ...
  }
  

  Mer information finns i:

  • Konfigurera Azure Monitor Application Insights för Spring Boot
  • Azure Monitor Application Insights för Java
  • Aktivera Azure Monitor OpenTelemetry för Java-program
  • Använda Azure Monitor Application Insights med Spring Boot

• Skapa anpassade programmått. Implementera kodbaserad instrumentation för att samla in anpassad programtelemetri genom att lägga till Application Insights SDK och använda dess API.

• Övervaka plattformen. Aktivera diagnostik för alla tjänster som stöds och skicka diagnostik till samma mål som programloggarna för korrelation. Azure-tjänster skapar plattformsloggar automatiskt men lagrar dem bara när du aktiverar diagnostik. Aktivera diagnostikinställningar för varje tjänst som stöder diagnostik. Referensimplementeringen använder Terraform för att aktivera Azure-diagnostik på alla tjänster som stöds. Följande Terraform-kod konfigurerar diagnostikinställningarna för App Service.

  # Configure Diagnostic Settings for App Service
  resource "azurerm_monitor_diagnostic_setting" "app_service_diagnostic" {
    name                           = "app-service-diagnostic-settings"
    target_resource_id             = azurerm_linux_web_app.application.id
    log_analytics_workspace_id     = var.log_analytics_workspace_id
    #log_analytics_destination_type = "AzureDiagnostics"
  
    enabled_log {
      category_group = "allLogs"
  
    }
  
    metric {
      category = "AllMetrics"
      enabled  = true
    }
  }
  

Distribuera referensimplementeringen

Referensimplementeringen vägleder utvecklare genom en simulerad migrering från ett lokalt Java-program till Azure och belyser nödvändiga ändringar under den inledande implementeringsfasen. I det här exemplet används ett CAMS-webbappprogram (Customer Account Management System) för det fiktiva företaget Contoso Fiber. Contoso Fiber anger följande mål för webbappen:

• Implementera kodändringar med låga kostnader och höga värden
• Uppnå ett servicenivåmål på 99,9 %
• Anta DevOps-metoder
• Skapa kostnadsoptimerade miljöer
• Förbättra tillförlitligheten och säkerheten

Contoso Fiber fastställde att deras lokala infrastruktur inte var en kostnadseffektiv lösning för att uppfylla dessa mål. De bestämde sig för att migrera sina CAMS-webbprogram till Azure var det mest kostnadseffektiva sättet att uppnå sina omedelbara och framtida mål. Följande arkitektur representerar sluttillståndet för Contoso Fibers reliable web app-mönsterimplementering.

Bild 4. Arkitektur för referensimplementeringen. Ladda ned en Visio-fil med den här arkitekturen.