Dela via

Pålitligt webbappmö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 omplatformar webbappar för molnmigrering. Det ger vägledning om normativ arkitektur, kod och konfiguration som överensstämmer med principerna i Azure Well-Architected Framework.

Varför ska du använda mönstret Reliable Web App för Java?

Reliable Web App-mönstret är en uppsättning principer och implementeringstekniker som definierar hur du formaterar om webbappar när du migrerar dem till molnet. Den betonar minimala koduppdateringar för att säkerställa framgång i molnet. Den här vägledningen använder en referensimplementering som ett konsekvent exempel hela tiden. Den följer resan med plattformbyte för det fiktiva företaget Contoso Fiber, för att ge affärskontext för din egen migrering. Innan Contoso Fiber implementerar Reliable Web App-mönstret för Java driver det ett monolitiskt, lokalt CAMS-system (Customer Account Management System) som skapats med Spring Boot-ramverket.

Tips/Råd

GitHub-logotyp. Referensimplementeringen (exempel) för reliable web app-mönstret representerar det slutliga tillståndet för en slutförd implementering. Den här webbappen i produktionsklass innehåller alla kod-, arkitektur- och konfigurationsuppdateringar som beskrivs i den här artikeln. Distribuera och använd referensimplementeringen för att vägleda din egen implementering av reliable web app-mönstret.

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

Hitta den specifika vägledning som du behöver i följande avsnitt i den här artikeln:

  • Affärskontext: Anpassa den här vägledningen till din affärskontext och lär dig att definiera omedelbara och långsiktiga mål som driver på omplatformeringsbeslut.

  • Arkitekturvägledning: Välj rätt molntjänster och utforma en arkitektur som uppfyller dina affärskrav.

  • Kodvägledning: Implementera designmönster för återförsök, kretsbrytare och Cache-Aside för att förbättra tillförlitligheten och prestandaeffektiviteten för webbappen i molnet.

  • Konfigurationsvägledning: Konfigurera autentisering och auktorisering, hanterade identiteter, rättighetsbaserade miljöer, infrastruktur som kod (IaC) och övervakning.

Affärskontext

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

Contoso Fiber vill utöka sin lokala CAMS-webbapp för att nå andra regioner. För att möta den ökade efterfrågan på webbappen fastställer företaget 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 avgör att den lokala infrastrukturen inte är en kostnadseffektiv lösning för att skala programmet. Företaget beslutar att migrera CAMS-webbappen till Azure är 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 (Domain Name System) 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 serverdelstjänsterna 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.

Diagram som visar de viktigaste arkitektoniska elementen i reliable web app-mönstret.

Utforma arkitekturen

Utforma din infrastruktur 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ällningspunkter (RPO). RTO påverkar tillgängligheten och måste stödja ditt SLO. Fastställ ett RPO och konfigurera dataredundans för att uppfylla RPO: et.

Välj rätt Azure-tjänster

När du flyttar en webbapp till molnet väljer du Azure-tjänster som uppfyller dina affärskrav och ö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öre migreringen är Contoso Fibers CAMS-webbapp ett lokalt, monolitiskt Java-program. Det är en Spring Boot-app med en PostgreSQL-databas. Webbappen är en verksamhetsspecifik supportapp (LOB) för anställda. De använder den för att hantera kundsupportärenden. Appen upplever vanliga utmaningar med skalbarhet och funktionsdistribution. Den här utgångspunkten, tillsammans med affärsmål och serviceavtal, påverkar deras tjänstval.

Följande lista innehåller vägledning för att välja rätt Azure-tjänster för din webbapp och beskriver varför Contoso Fiber väljer specifika tjänster:

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

    • Naturlig utveckling: Contoso Fiber distribuerar en Spring Boot JAR-fil på sin lokala server och vill minimera mängden omarbetning för distributionsmodellen. App Service ger robust stöd för att köra Spring Boot-appar, vilket gör det till ett lämpligt alternativ. Azure Container Apps är också ett lämpligt alternativ för det här programmet. Mer information finns i Översikt över Container Apps och Java i Container Apps.

    • Högt serviceavtal: App Service tillhandahåller ett högt serviceavtal som uppfyller produktionskraven.

    • Minskade hanteringskostnader: App Service är en hanterad värdlösning.

    • Containeriseringsfunktion: App Service integreras med privata containeravbildningsregister som Azure Container Registry. Contoso Fiber kan använda dessa register för att containerisera webbappen i framtiden.

    • Automatisk skalning: Webbappen kan snabbt skala upp, skala ned, skala in och skala ut baserat på användartrafik.

  • Identitetshantering: Använd Microsoft Entra ID som din identitets- och åtkomsthanteringslösning. Contoso Fiber använder 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 låter dig behålla samma databasmotor. Använd beslutsträdet för datalager för att vägleda ditt val. Contoso Fiber använder Azure Database for PostgreSQL– flexibel serverdistributionsmodell 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 tillhandahåller en skrivskyddad replikfunktion för att asynkront replikera data till en skrivskyddad replikdatabas i en annan region.

    • Föreställning: Azure Database for PostgreSQL ger förutsägbar prestanda och intelligent justering som förbättrar databasprestanda med hjälp av verkliga användningsdata.

    • Minskade hanteringskostnader: Den här hanterade Azure-tjänsten minskar hanteringsskyldigheten.

    • Migreringsstöd: Den stöder databasmigrering från lokala PostgreSQL-databaser med en enda server. Contoso Fiber 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.

    • Resiliency: Den flexibla serverdistributionen skapar automatiskt serversäkerhetskopior och lagrar dem i zonredundant lagring (ZRS) inom samma region. Contoso Fiber kan återställa databasen till valfri tidpunkt inom kvarhållningsperioden för säkerhetskopior. Säkerhetskopierings- och återställningsfunktionen skapar ett bättre RPO jämfört med lokala miljöer.

  • Övervakning av programprestanda: Använd Application Insights för att analysera telemetri i ditt program. Contoso Fiber använder 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 användningsdata för appen och spårar anpassade händelser.

    • Synlighetsgap: Den lokala lösningen har 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 Managed Redis är den primära Azure-cachelösningen. Det är ett hanterat minnesinternt datalager baserat på Redis-programvaran. Contoso Fiber lägger till Azure Managed Redis av följande skäl:

    • Hastighet och volym: Det ger högt dataflöde och snabb åtkomst för ofta åtkommen och långsamt förändrande data.

    • Mångsidig supportbarhet: Det är en enhetlig cacheplats som alla instanser av webbappen kan använda.

    • Externt datalager: De lokala programservrarna använder vm-lokal cachelagring. Den här konfigurationen avlastar inte data som används ofta och kan inte ogiltigförklara inaktuella data.

    • Icke-ihärdiga sessioner: Med hjälp av cacheminnet kan webbappen hantera sessionstillståndet externt och använda icke-ihärdiga sessioner. De flesta Java-webbappar som körs lokalt är beroende av minnesintern cachelagring på klientsidan. Denna metod skalas inte bra och ökar minnesförbrukningen på värden. Azure Managed Redis tillhandahåller en hanterad, skalbar cachetjänst för att förbättra skalbarheten och prestandan för program. Contoso Fiber använde Spring Cache som cacheabstraktionsramverk och behövde bara minimala konfigurationsändringar för 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över en layer-7-lastbalanserare som kan dirigera trafik över flera regioner och en webbapp för flera regioner för att uppfylla SLO för 99,9%. Företaget använder Azure Front Door av följande skäl:

    • Global belastningsutjämning: Den här layer-7-lastbalanseraren 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-routning 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: Applikationen behöver intelligent övervakning av hälsoavsökningar. 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. Den innehåller aviseringar som integreras med Azure Monitor. Med Azure Front Door kan programmet logga varje begäran och misslyckade hälsoavsökningar.

    • DDoS-skydd (Distributed Denial-of-Service): Den har inbyggt DDoS-skydd på lager 3 och lager 4.

    • 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 accelererar webbplatsen.

  • 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änder Azure Web Application Firewall av följande skäl:

    • Globalt skydd: Det ger förbättrat globalt webbappskydd samtidigt som prestandan bibehålls.

    • Botnet-skydd: Teamet kan övervaka och konfigurera inställningar för att hantera säkerhetsproblem som rör botnät.

    • Paritet med lokala lösningar: Den lokala lösningen körs bakom en brandvägg för webbapplikationer som IT hanterar.

    • Användarvänlighet: Azure Web Application Firewall integreras med Azure Front Door.

  • Secrets Manager: Använd Azure Key Vault om du har hemligheter att hantera i Azure. Contoso Fiber använder 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 sekretesslagret.

    • Ö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 använder 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.

    • Minimalt arbete: 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 (Remote Desktop Protocol/Secure Shell). Contoso Fiber använder en nätverkstopologi för nav och ekrar och placerar delade nätverkssäkerhetstjänster i hubben. Azure Firewall inspekterar utgående trafik från ekrarna för att förbättra nätverkssäkerheten. Företaget använder 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 hjälp av mönster för återförsök, kretsbrytare och Cache-Aside.

Diagram som visar rollerna för designmönster i mönstret Reliable Web App.

Följande designmönster ger arbetsbelastningsfördelar som mappas till en eller flera av Well-Architected Framework-pelarna:

  1. Å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ö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. Mönstret Cache-Aside läser in data på begäran i en cache från ett datalager. Implementera det här mönstret på begäranden till databasen.

Designmönster Tillförlitlighet (RE) Säkerhet (SE) Kostnadsoptimering (CO) Operational Excellence (OE) Prestandaeffektivitet (PE) Stöd för WAF-principer
Mönster för återförsök ✔ RE:07
"Circuit Breaker"-mönster ✔ ✔ RE:03
RE:07
PE:07
PE:11
Cache-Aside-mönstret ✔ ✔ RE:05
PE:08
PE:12

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. Du kan använda mönstret Försök igen för att skicka misslyckade begäranden igen. Det gör också att du kan konfigurera fördröjningen mellan omförsök och antal försök innan du accepterar misslyckande.

Använd Resilience4j, ett lättviktigt bibliotek för feltolerans, för att implementera återförsöksmönstret i Java. Om du vill lägga till återförsöksmönstret dekorerar referensimplementeringen serviceplanens kontrollmetod listServicePlans med återförsökskommentarer. Koden försöker anropa listan över tjänsteplaner från databasen igen om det första anropet misslyckas. Återförsöksprincipen för referensimplementeringen innehåller maximala försök, väntetid och undantag för återförsök. Konfigurera återförsöksprincipen i application.properties filen.

    @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. Programmet frigörs och hjälper till att förhindra slöseri med processorcykler (central bearbetningsenhet) så att programmet behåller sin prestandaintegritet för användarna.

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

Implementera Cache-Aside-mönstret

Lägg till Cache-Aside-mönstret 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.

  • Cachea data med högt 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 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 databasskrivningsåtgärder. Använd händelsedrivna uppdateringar eller dedikerade datahanteringsklasser för att säkerställa cachesammanhållning. Att synkronisera cacheminnet konsekvent 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 Well-Architected Framework.

Konfiguration Tillförlitlighet (RE) Säkerhet (SE) Kostnadsoptimering (CO) Operational Excellence (OE) Prestandaeffektivitet (PE) Stöd för WAF-principer
Konfigurera användarautentisering och auktorisering ✔ ✔ SE:05
OE:10
Implementera hanterade identiteter ✔ ✔ SE:05
OE:10
Rightsize-miljöer ✔ CO:05
CO:06
Implementera autoskalning ✔ ✔ ✔ RE:06
CO:12
PE:05
Automatisera resursdistribution ✔ OE:05
Implementera övervakning ✔ ✔ ✔ OE:07
PE:04

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 Microsofts identitetsplattform för utvecklare för att konfigurera webbappautentisering. 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](/azure/developer/java/spring-framework/spring-boot-starter-for-entra-developer-guide använder Spring Security och Spring Boot för att säkerställa enkel konfiguration och integrering. Den innehåller olika autentiseringsflöden, automatisk tokenhantering, anpassningsbara auktoriseringsprinciper och integreringsfunktioner med Spring Cloud-komponenter. Det här verktyget 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 som har 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 till att säkerställa att användarna autentiseras på ett säkert sätt. Konfigurera och aktivera Microsoft Authentication Library (MSAL) för att få åtkomst 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 hjälp av 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 (PIM) för att bevilja JIT-åtkomst för privilegierade åtgärder. Utvecklare behöver till exempel ofta åtkomst på administratörsnivå för att skapa och ta bort databaser, ändra tabellscheman och ändra användarbehörigheter. När du använder JIT-å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, särskilt 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 som att skapa, läsa, uppdatera och ta bort (CRUD) i databaser eller komma åt hemligheter. Identitetsbehörigheter för arbetsbelastningar är beständiga, så du kan inte ge JIT- 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 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 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. Utför följande åtgärder för att anpassa storleken på dina miljöer:

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

  • Optimera produktionsmiljöer. Produktionsmiljöer behöver SKU:er som uppfyller serviceavtalet, 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.

  • Optimera förproduktionsmiljöer.Förproduktionsmiljöer bör använda lågkostnadsresurser och dra nytta av rabatter som Azure-plan för dev/test-priser. I dessa miljöer inaktiverar du tjänster som inte behövs. Se också till att förproduktionsmiljöerna är tillräckligt lika produktionsmiljöer för att undvika risker. Bevara den här balansen för att säkerställa att testningen förblir effektiv utan onödiga kostnader.

  • Använd 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 inkluderar andra mått som RAM, nätverksdataflöde och diskindata/utdata (I/O). Målet är att matcha webbappens beteende för bättre prestanda.

  • Ange en utskalningsbuffert. Ange dina skalningströsklar för att initiera skalning innan maximal kapacitet uppnås. Konfigurera till exempel skalning så att den sker vid 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 IaC. Distribuera IaC med hjälp av CI/CD-pipelines (kontinuerlig integrering och kontinuerlig leverans). Azure tillhandahåller fördefinierade Bicep-mallar, Azure Resource Manager-mallar (ARM-mallar) JSON och Terraform-mallar för varje Azure-resurs.

  • Använd en CI/CD-pipeline. 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 validering av alla enhetstester i pipelinen innan du distribuerar till App Service. Införliva kodkvalitets- och täckningsverktyg som SonarQube för att uppnå omfattande testtäckning.

  • Adoptera mockningramverk. För testning som omfattar externa slutpunkter bör du använda mockningsramverk. 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 analys av programvarusammansättning (SCA) för att undersöka bibliotek och komponenter som inte kommer från Microsoft för säkerhetsrisker. Integrera verktyg för dessa analyser 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 automatisk instrumentering i 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. 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 och Tomcat. Application Insights samlar automatiskt in från loggningsramverk som Log4j och Logback.

    Referensimplementeringen möjliggör Application Insights 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 följande artiklar:

  • 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å 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 dig genom Contoso Fibers simulerade migrering av ett lokalt Java-program till Azure. Den belyser också nödvändiga ändringar under den inledande implementeringsfasen.

Följande arkitektur representerar det slutliga tillståndet för Contoso Fibers reliable web app-mönsterimplementering baserat på deras mål.

Diagram som visar referensimplementeringens arkitektur.

Ladda ned en Visio-fil med den här arkitekturen.

Nästa steg

  • Last updated on