Reliable Web App-mönster för Java

Den här artikeln innehåller vägledning för att implementera reliable web app-mönstret. Det här mönstret beskriver hur du ändrar (omplatforma) webbappar för molnmigrering. Den innehåller vägledning om förebyggande arkitektur, kod och konfiguration som är anpassad efter principerna i Azure Well-Architected Framework.

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 dem till molnet. Den fokuserar på de minimala koduppdateringar som du behöver göra för att lyckas i molnet. I följande vägledning används en referensimplementering som ett exempel hela vägen. Den följer omplatformresan för det fiktiva företaget Contoso Fiber för att ge 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 arkitektur, kod och konfigurationsvägledning för implementering av mönstret Reliable Web App. Använd följande länkar för att gå 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 omplatformingsbeslut.
• 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: mönster för återförsök, kretsbrytare och Cache-Aside.
• 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 (SLO) och kostnadsoptimeringsmål, samt framtida mål för webbappen. 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 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 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. De beslutade att migrera sina CAMS-webbprogram 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 dirigera och skydda 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 som hjälper dig 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 ditt mål för återställningstid (RTO) och mål för återställningspunkt (RPO). RTO påverkar tillgängligheten och måste ha stöd för ditt serviceavtal. Fastställ ett RPO och konfigurera dataredundans för att uppfylla RPO.

• Välj infrastrukturtillförlitlighet. Ta reda på hur många tillgänglighetszoner och regioner du behöver för att uppfylla dina tillgänglighetskrav. 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å företagets behov. 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 med förbättrad säkerhet. (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 använda flera virtuella nätverk använder du en nätverkstopologi för nav och eker. Det ger kostnads-, hanterings- och säkerhetsfördelar samt 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 funktionerna i den lokala webbappen. Den här 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 den till exempel flyttades 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 progression. Contoso Fiber distribuerade en Spring Boot-fil jar på sin lokala server och ville minimera mängden omarbetning 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 Container Apps? och Java i Översikt över Azure Container Apps.
  • Högt serviceavtal. App Service tillhandahåller ett högt serviceavtal som uppfyller kraven för produktionsmiljön.
  • Minskade hanteringskostnader. App Service ä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.
  • Skalbarhet. Microsoft Entra ID skalar 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. Microsoft Entra ID 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 datalager för att vägleda ditt val. Contoso Fiber valde Azure Database for PostgreSQL och den flexibla serverdistributionsmodellen av följande skäl:

  • Tillförlitlighet. Den flexibla serverdistributionsmodellen 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. Azure Database for PostgreSQL innehåller en skrivskyddad replikfunktion som gör att du asynkront kan replikera data till en skrivskyddad replikdatabas i en annan region.
  • Prestanda Azure Database for PostgreSQL ger förutsägbar prestanda och intelligent justering som förbättrar databasens prestanda med hjälp av verkliga användningsdata.
  • Minskade hanteringskostnader. Det är en fullständigt hanterad Azure-tjänst som minskar hanteringsskyldigheten.
  • Migreringsstöd. Den stöder databasmigrering från lokala PostgreSQL-databaser med en enda server. Contoso kan använda migreringsverktyget för att förenkla migreringsprocessen.
  • Konsekvens med lokala konfigurationer. Det 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 i zonredundant lagring (ZRS) inom samma region. Contoso kan återställa databasen 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 en cache i webbappens arkitektur. Azure Cache for Redis är den primära Azure Cache-lösningen. Det är ett hanterat minnesinternt datalager som baseras på Redis-programvaran. Contoso Fiber har lagt till Azure Cache for Redis av följande skäl:

  • Hastighet och volym. Det ger dataflöde med hög dataflöde och läsningar med låg svarstid för data som används ofta och ändras långsamt.
  • Varierande 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. Med cacheminnet kan webbappen externalisera sessionstillståndet och använda icke-stickiga sessioner. De flesta Java-webbappar som körs lokalt använder minnesintern cachelagring på klientsidan. Minnesintern cachelagring på klientsidan skalas inte så bra och ökar minnets fotavtryck på värden. Med 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 använde ett cacheabstraktionsramverk (Spring Cache) och behövde bara minimala konfigurationsändringar för att utbyta 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 (plattform som en tjänst) bör använda Azure Front Door, Azure Application Gateway eller båda, beroende 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 och en webbapp för flera regioner för att uppfylla SLO på 99,9%. Contoso 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å den närmaste Azure-platsen och hitta den snabbaste vägen till webbappen.
  • Anpassade domäner. Den stöder anpassade domännamn med flexibel domänverifiering.
  • Hälsoundersö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. Azure Front Door stöder inbyggda rapporter med en allt-i-ett-instrumentpanel för både Azure Front Door och säkerhetsmönster. Du kan konfigurera aviseringar som integreras med Azure Monitor. Med Azure Front Door kan programmet logga varje begäran och misslyckade hälsoavsökningar.
  • DDoS-skydd. Den har inbyggt layer 3-4 DDoS-skydd.
  • Nätverk för innehållsleverans. Det positionerar Contoso Fiber för att använda 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 lokalt. Den lokala lösningen kördes bakom en brandvägg för webbprogram som IT-hanterade.
  • 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. Key Vault underlättar granskningsåtkomst och genererar aviseringar när lagrade hemligheter ändras.
  • Integration. Key Vault tillhandahåller intern integrering med Azure-konfigurationsarkivet (Azure App Configuration) och webbvärdplattformen (App Service).

• Slutpunktssäkerhet: Använd Azure Private Link för att komma åt PaaS-lösningar 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 gör att programmet kan komma åt tjänster privat på Azure-plattformen och minskar nätverksavtrycket för datalager för att skydda mot dataläckage.
  • Minimal ansträngning. De privata slutpunkterna stöder webbappplattformen och databasplattformen som webbappen använder. Båda plattformarna speglar befintliga lokala konfigurationer, så minimala ändringar krävs.

• 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 med förbättrad säkerhet, utan att exponera RDP/SSH-portar. Contoso Fiber antog en nätverkstopologi för nav och eker 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 utökade säkerhetsdistributioner från en jump-värd i DevOps-undernätet.

Kodvägledning

Om du vill flytta en webbapp till molnet måste du uppdatera webbappens kod med återförsöksmönstret, kretsbrytarmönstret och Cache-Aside mönstret.

Figur 3. Roller för designmönstren.

Varje designmönster ger arbetsbelastningsdesignfördelar som överensstämmer med en eller flera grundpelare i Well-Architected Framework. 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 förhindrar att ett program försöker utföra åtgärder som inte är tillfälliga igen. Implementera det här mönstret i alla utgående anrop till andra Azure-tjänster.

3. Cache-Aside mönster. Mönstret Cache-Aside läser in data på begäran till en cache frå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 återförsöksmönstret kan du skicka misslyckade begäranden igen. Det gör också att du kan konfigurera fördröjningen mellan återförsök och antalet försök att göra innan du medger fel.

Använd Resilience4j, ett lättviktigt bibliotek för feltolerans, för att implementera återförsöksmönstret i Java. Referensimplementeringen lägger till återförsöksmönstret 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. Återförsöksprincipen för referensimplementeringen innehåller maximala 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 hjälper till att förhindra att processorcykler slösas bort så att programmet behåller sin prestandaintegritet för slutanvändarna.

Använd Spring Cloud Circuit Breaker och Resilience4j för att implementera kretsbrytarmönstret. Referensimplementeringen implementerar 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 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örbättra dess effektivitet. Använd Azure Monitor för att spåra databasens processor, minne och lagring. Dessa mått hjälper dig att avgöra om du kan använda en mindre databas-SKU när du har tillämpat Cache-Aside-mönstret. 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. Använd datavolatilitet och användaren måste fastställa den optimala uppdateringsfrekvensen. Den här metoden säkerställer att programmet använder Cache-Aside-mönstret 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 tas bort.

• 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. Den använder Spring Security och Spring Boot för att säkerställa enkel konfiguration. Den innehåller olika autentiseringsflöden, automatisk tokenhantering, anpassningsbara auktoriseringsprinciper och integreringsfunktioner med Spring Cloud-komponenter. Den här tjänsten 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 Microsoft identity platform (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 möjliggör 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 programregistrering. Microsoft Entra-ID kräver en programregistrering i den primära klientorganisationen. Programregistreringen hjälper till att säkerställa att användare som får åtkomst till webbappen har identiteter i den primära klientorganisationen. Referensimplementeringen använder 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 rollbaserad åtkomstkontroll (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 möjliggör 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 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 account manager, supportrepresentant på nivå 1 (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. Du kan till exempel använda signaturer för delad åtkomst (SAS) för att begränsa åtkomsten till en viss tidsperiod. 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 definierar de Azure-resurser som identiteter kan komma åt, vad de kan göra med dessa resurser och de områden som 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. När du använder 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 dem. Med en hanterad identitet kan Azure-resurser (arbetsbelastningsidentiteter) autentisera till och interagera med andra Azure-tjänster utan att du behöver hantera autentiseringsuppgifter. För att förenkla migreringen kan du fortsätta att använda lokala autentiseringslösningar för hybridsystem och äldre system, men du bör överföra dem 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 metoden ä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 behörigheter som är viktiga för åtgärder, 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å.

• Ange säkerhet för å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.

Rightsize-miljöer

Använd prestandanivåer (SKU:er) för Azure-tjänster som uppfyller behoven i varje miljö utan att överskrida dem. Följ dessa rekommendationer för att ge dina miljöer rättigheter:

• 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 och dra nytta av rabatter som Prissättning för Azure Dev/Test. I dessa miljöer bör du inaktivera tjänster som inte behövs. Se samtidigt till att förproduktionsmiljöer är tillräckligt lika produktionsmiljöer miljöer för att undvika risker. Att upprätthålla den här balansen säkerställer att testningen förblir effektiv utan onödiga kostnader.

• Använd infrastruktur som kod (IaC) för att definiera SKU:er. 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 anger vilken SKU som ska distribueras. En miljöparameter anger att Terraform-mallen ska distribuera SKU:er för utveckling:

azd env set APP_ENVIRONMENT prod

Implementera autoskalning

Autoskalning hjälper till att säkerställa 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. Använd CPU-användning som din första skalningsutlösare om du inte känner till programmets skalningskrav. Förfina dina skalningsutlösare så att de innehåller andra mått som RAM, nätverksdataflöde och disk-I/O. Målet är att matcha webbappens beteende för bättre prestanda.

• Ange en utskalningsbuffert. Ställ in skalningströsklarna så att de utlöses innan maximal kapacitet uppnås. 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 med hjälp av CI/CD-pipelines (kontinuerlig integrering och kontinuerlig leverans). Azure tillhandahåller fördefinierade 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. Använd 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. För testning som omfattar 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 enkla att integrera 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 program telemetri, till exempel dataflöde för begäranden, genomsnittlig varaktighet för begäran, fel och beroendeövervakning. Du behöver inte ändra någon kod för att använda den här telemetrin. Spring Boot registrerar flera kärnmått i Application Insights, till exempel virtuell Java-dator (JVM), CPU, Tomcat och andra. Application Insights samlar automatiskt in från loggningsramverk som Log4j och Logback.

  Referensimplementeringen använder Application Insights, som är aktiverat via Terraform i apptjänstens app_settings konfiguration:

  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. 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 av ett lokalt Java-program till Azure och belyser de ändringar som krävs under den inledande implementeringsfasen. I det här exemplet används en CAMS-webbapp för det fiktiva företaget Contoso Fiber. Contoso Fiber anger följande mål för webbprogrammet:

• Implementera kodändringar med låga kostnader och höga värden.
• Uppnå ett servicemå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.