Betrouwbaar web-app-patroon voor Java

Dit artikel bevat richtlijnen voor het implementeren van het patroon Reliable Web App. In dit patroon wordt beschreven hoe u web-apps wijzigt (opnieuw platformen) voor cloudmigratie. Het biedt prescriptieve architectuur, code en configuratierichtlijnen die zijn afgestemd op de principes van het Well-Architected Framework.

Waarom het reliable web-app-patroon voor Java?

Het patroon Reliable Web App is een set principes en implementatietechnieken waarmee wordt gedefinieerd hoe u web-apps opnieuw moet platformen wanneer u naar de cloud migreert. Het richt zich op de minimale code-updates die u moet uitvoeren om succesvol te zijn in de cloud. In de volgende richtlijnen wordt de referentie-implementatie als voorbeeld gebruikt en wordt het herplatformtraject van het fictieve bedrijf Contoso Fiber gevolgd om bedrijfscontext te bieden voor uw traject. Voordat het reliable web-app-patroon voor Java werd geïmplementeerd, had Contoso Fiber een monolithisch, on-premises CUSTOMER Account Management System (CAMS) dat het Spring Boot-framework gebruikte.

Het patroon Reliable Web App implementeren

Dit artikel bevat richtlijnen voor architectuur, code en configuratie voor het implementeren van het patroon Reliable Web App. Gebruik de volgende koppelingen om naar de specifieke richtlijnen te navigeren die u nodig hebt:

• Bedrijfscontext: stem deze richtlijnen af op uw bedrijfscontext en leer hoe u onmiddellijke en langetermijndoelen definieert die bepalend zijn voor het opnieuw platformeren van beslissingen.
• Richtlijnen voor architectuur: leer hoe u de juiste cloudservices selecteert en een architectuur ontwerpt die voldoet aan uw bedrijfsvereisten.
• Coderichtlijnen: Implementeer drie ontwerppatronen om de betrouwbaarheid en prestatie-efficiëntie van uw web-app in de cloud te verbeteren: Opnieuw proberen, Circuitonderbreker en Cache-Aside-patronen
• Configuratierichtlijnen: verificatie en autorisatie configureren, beheerde identiteiten, gerechtende omgevingen, infrastructuur als code en bewaking.

Zakelijke context

De eerste stap bij het opnieuw platformen van een web-app is het definiëren van uw bedrijfsdoelstellingen. U moet onmiddellijke doelen instellen, zoals serviceniveaudoelstellingen en kostenoptimalisatiedoelen, evenals toekomstige doelen voor uw webtoepassing. Deze doelstellingen zijn van invloed op uw keuze van cloudservices en de architectuur van uw webtoepassing in de cloud. Definieer een doel-SLO voor uw web-app, zoals 99,9% uptime. Bereken de samengestelde SLA voor alle services die van invloed zijn op de beschikbaarheid van uw web-app.

Contoso Fiber wilde bijvoorbeeld hun on-premises CAMS-web-app (Customer Account Management System) uitbreiden om andere regio's te bereiken. Om aan de toegenomen vraag op de web-app te voldoen, hebben ze de volgende doelstellingen vastgesteld:

• Wijzigingen in code met lage kosten en hoge waarden toepassen
• Bereik een serviceniveaudoelstelling (SLO) van 99,9%
• DevOps-procedures gebruiken
• Voor kosten geoptimaliseerde omgevingen maken
• Betrouwbaarheid en beveiliging verbeteren

Contoso Fiber heeft vastgesteld dat hun on-premises infrastructuur geen rendabele oplossing was voor het schalen van de toepassing. Daarom hebben ze besloten dat het migreren van hun CAMS-webtoepassing naar Azure de meest rendabele manier was om hun onmiddellijke en toekomstige doelstellingen te bereiken.

Uitleg bij architectuur

Het patroon Reliable Web App heeft enkele essentiële architecturale elementen. U hebt DNS nodig voor het beheren van eindpuntomzetting, een webtoepassingsfirewall om schadelijk HTTP-verkeer te blokkeren en een load balancer om binnenkomende gebruikersaanvragen te beveiligen en te routeren. Het toepassingsplatform fungeert als host voor uw web-app-code en roept alle back-endservices aan via privé-eindpunten in een virtueel netwerk. Een hulpprogramma voor bewaking van toepassingsprestaties legt metrische gegevens en logboeken vast om inzicht te hebben in uw web-app.

Figuur 1. Essentiële architecturale elementen van het patroon Reliable Web App.

De architectuur ontwerpen

Ontwerp uw infrastructuur ter ondersteuning van uw metrische herstelgegevens, zoals RTO (Recovery Time Objective) en RPO (Recovery Point Objective). De RTO beïnvloedt de beschikbaarheid en moet ondersteuning bieden voor uw SLO. Bepaal een beoogde herstelpunt (RPO) en configureer gegevensredundantie om te voldoen aan de RPO.

• Kies de betrouwbaarheid van de infrastructuur. Bepaal hoeveel beschikbaarheidszones en regio's u nodig hebt om te voldoen aan uw beschikbaarheidsbehoeften. Voeg beschikbaarheidszones en regio's toe totdat de samengestelde SLA voldoet aan uw SLO. Het patroon Reliable Web App ondersteunt meerdere regio's voor een actief-actief- of actief-passieve configuratie. De referentie-implementatie maakt bijvoorbeeld gebruik van een actief-passieve configuratie om te voldoen aan een SLO van 99,9%.

  Voor een web-app met meerdere regio's configureert u uw load balancer om verkeer naar de tweede regio te routeren ter ondersteuning van een actief-actief- of actief-passieve configuratie, afhankelijk van de behoeften van uw bedrijf. Voor de twee regio's zijn dezelfde services vereist, behalve één regio, een virtueel hubnetwerk waarmee de regio's worden verbonden. Gebruik een hub-and-spoke-netwerktopologie om resources, zoals een netwerkfirewall, te centraliseren en te delen. Als u virtuele machines hebt, voegt u een bastionhost toe aan het virtuele hubnetwerk om deze veilig te beheren (zie afbeelding 2).

  

  Figuur 2. Het patroon Reliable Web App met een tweede regio en een hub-and-spoke-topologie.

• Kies een netwerktopologie. Kies de juiste netwerktopologie voor uw web- en netwerkvereisten. Als u van plan bent meerdere virtuele netwerken te hebben, gebruikt u een hub- en spoke-netwerktopologie. Het biedt voordelen van kosten, beheer en beveiliging met hybride connectiviteitsopties voor on-premises en virtuele netwerken.

De juiste Azure-services kiezen

Wanneer u een web-app naar de cloud verplaatst, moet u Azure-services selecteren die voldoen aan uw zakelijke vereisten en overeenkomen met de huidige functies van de on-premises web-app. De uitlijning helpt bij het minimaliseren van de herplatformingsinspanning. Gebruik bijvoorbeeld services waarmee u dezelfde database-engine kunt behouden en bestaande middleware en frameworks kunt ondersteunen. De volgende secties bevatten richtlijnen voor het selecteren van de juiste Azure-services voor uw web-app.

Voordat de overstap naar de cloud werd uitgevoerd, was de CAMS-web-app van Contoso Fiber bijvoorbeeld een on-premises, monolithische Java-web-app. Het is een Spring Boot-app met een PostgreSQL-database. De web-app is een Line-Of-Business-ondersteunings-app. Het is werknemersgericht. Contoso Fiber-werknemers gebruiken de toepassing om ondersteuningsaanvragen van hun klanten te beheren. De web-app heeft last van veelvoorkomende uitdagingen bij schaalbaarheid en functie-implementatie. Dit uitgangspunt, hun bedrijfsdoelen en SLO hebben hun servicekeuzen aangereden.

• Toepassingsplatform: gebruik Azure-app Service als uw toepassingsplatform. Contoso Fiber koos Azure-app Service als het toepassingsplatform om de volgende redenen:

  • Natuurlijke voortgang: Contoso Fiber heeft een Spring Boot-bestand jar geïmplementeerd op hun on-premises server en wilde de hoeveelheid herarchitecteren voor dat implementatiemodel minimaliseren. App Service biedt robuuste ondersteuning voor het uitvoeren van Spring Boot-apps en het was een natuurlijke voortgang voor Contoso Fiber om App Service te gebruiken. Azure Container Apps is ook een aantrekkelijk alternatief voor deze app. Zie Wat is Azure Spring Apps? en Java in Het overzicht van Azure Container Apps voor meer informatie.
  • Hoge SLA: Het heeft een hoge SLA die voldoet aan de vereisten voor de productieomgeving.
  • Verminderde beheeroverhead: het is een volledig beheerde hostingoplossing.
  • Containerisatiemogelijkheid: App Service werkt met persoonlijke containerinstallatiekopieën, zoals Azure Container Registry. Contoso Fiber kan deze registers gebruiken om de web-app in de toekomst in een container te plaatsen.
  • Automatisch schalen: de web-app kan snel omhoog, omlaag, in en uit schalen op basis van gebruikersverkeer.

• Identiteitsbeheer: Gebruik Microsoft Entra-id als uw oplossing voor identiteits- en toegangsbeheer. Contoso Fiber heeft om de volgende redenen microsoft Entra-id gekozen:

  • Verificatie en autorisatie: de toepassing moet medewerkers van het callcenter verifiëren en autoriseren.
  • Schaalbaar: deze schaalt om grotere scenario's te ondersteunen.
  • Beheer van gebruikersidentiteiten: callcentermedewerkers kunnen hun bestaande bedrijfsidentiteiten gebruiken.
  • Autorisatieprotocolondersteuning: Het ondersteunt OAuth 2.0 voor beheerde identiteiten.

• Database: Gebruik een service waarmee u dezelfde database-engine kunt behouden. Gebruik de beslissingsstructuur van het gegevensarchief. Contoso Fiber koos om de volgende redenen voor Azure Database for PostgreSQL en de optie flexibele server:

  • Betrouwbaarheid: het implementatiemodel voor flexibele servers ondersteunt zone-redundante hoge beschikbaarheid in meerdere beschikbaarheidszones. Deze configuratie onderhoudt een warme stand-byserver in een andere beschikbaarheidszone binnen dezelfde Azure-regio. De configuratie repliceert gegevens synchroon naar de stand-byserver.
  • Replicatie tussen regio's: het heeft een functie voor leesreplica waarmee u gegevens asynchroon kunt repliceren naar een alleen-lezen replicadatabase in een andere regio.
  • Prestaties: Het biedt voorspelbare prestaties en intelligente afstemming om de prestaties van uw database te verbeteren met behulp van echte gebruiksgegevens.
  • Verminderde beheeroverhead: het is een volledig beheerde Azure-service die beheerverplichtingen vermindert.
  • Migratieondersteuning: Het ondersteunt databasemigratie van on-premises PostgreSQL-databases met één server. Ze kunnen het migratiehulpprogramma gebruiken om het migratieproces te vereenvoudigen.
  • Consistentie met on-premises configuraties: het ondersteunt verschillende communityversies van PostgreSQL, inclusief de versie die Contoso Fiber momenteel gebruikt.
  • Flexibiliteit. De flexibele serverimplementatie maakt automatisch serverback-ups en slaat deze op met behulp van zone-redundante opslag (ZRS) binnen dezelfde regio. Ze kunnen hun database herstellen naar een bepaald tijdstip binnen de bewaarperiode van de back-up. De mogelijkheid voor back-up en herstel maakt een betere RPO (acceptabele hoeveelheid gegevensverlies) dan Contoso Fiber on-premises kan maken.

• Bewaking van toepassingsprestaties: Gebruik Application Insights om telemetrie op uw toepassing te analyseren. Contoso Fiber heeft ervoor gekozen om Application Insights te gebruiken om de volgende redenen:

  • Integratie met Azure Monitor: Het biedt de beste integratie met Azure Monitor.
  • Anomaliedetectie: Hiermee worden prestatieafwijkingen automatisch gedetecteerd.
  • Probleemoplossing: Hiermee kunt u problemen vaststellen in de actieve app.
  • Bewaking: Het verzamelt informatie over hoe gebruikers de app gebruiken en stelt u in staat om eenvoudig aangepaste gebeurtenissen bij te houden.
  • Zichtbaarheidsverschil: de on-premises oplossing heeft geen oplossing voor bewaking van toepassingsprestaties. Application Insights biedt eenvoudige integratie met het toepassingsplatform en code.

• Cache: Kies of u cache wilt toevoegen aan uw web-app-architectuur. Azure Cache voor Redis is de primaire cacheoplossing van Azure. Het is een beheerd gegevensarchief in het geheugen op basis van de Redis-software. Contoso Fiber heeft om de volgende redenen Azure Cache voor Redis toegevoegd:

  • Snelheid en volume: er zijn leesbewerkingen met hoge gegevensdoorvoer en lage latentie voor veelgebruikte, langzaam veranderende gegevens.
  • Diverse ondersteuningsmogelijkheden: het is een uniforme cachelocatie die alle exemplaren van de web-app kunnen gebruiken.
  • Externe gegevensopslag. De on-premises toepassingsservers hebben vm-lokale caching uitgevoerd. Met deze installatie zijn niet zeer frequente gegevens overgeslagen en kunnen gegevens niet ongeldig worden.
  • Niet-plakige sessies: Met de cache kan de web-app de sessiestatus externaliseren en niet-stickerige sessies gebruiken. De meeste Java-web-apps die on-premises worden uitgevoerd, maken gebruik van cacheopslag aan de clientzijde. Caching aan de clientzijde in het geheugen schaalt niet goed en verhoogt de geheugenvoetafdruk op de host. Met behulp van Azure Cache voor Redis heeft Contoso Fiber een volledig beheerde, schaalbare cacheservice om de schaalbaarheid en prestaties van hun toepassingen te verbeteren. Contoso Fiber gebruikte een cacheabstractieframework (Spring Cache) en had alleen minimale configuratiewijzigingen nodig om de cacheprovider te verwisselen. Hiermee konden ze overstappen van een Ehcache-provider naar de Redis-provider.

• Load balancer: webtoepassingen die PaaS-oplossingen gebruiken, moeten Gebruikmaken van Azure Front Door, Azure-toepassing Gateway of beide op basis van de architectuur en vereisten van web-apps. Gebruik de beslissingsstructuur van de load balancer om de juiste load balancer te kiezen. Contoso Fiber had een load balancer van laag 7 nodig die verkeer kon routeren over meerdere regio's. Contoso Fiber heeft een web-app met meerdere regio's nodig om te voldoen aan de SLO van 99,9%. Contoso Fiber heeft Om de volgende redenen gekozen voor Azure Front Door :

  • Globale taakverdeling: het is een load balancer van laag 7 die verkeer kan routeren over meerdere regio's.
  • Web Application Firewall: Het integreert systeemeigen met Azure Web Application Firewall.
  • Flexibiliteit voor routering: hiermee kan het toepassingsteam inkomend verkeer configureren om toekomstige wijzigingen in de toepassing te ondersteunen.
  • Verkeersversnelling: Er wordt gebruikgemaakt van anycast om het dichtstbijzijnde Azure-aanwezigheidspunt te bereiken en de snelste route naar de web-app te vinden.
  • Aangepaste domeinen: het ondersteunt aangepaste domeinnamen met flexibele domeinvalidatie.
  • Statustests: De toepassing heeft intelligente statustestbewaking nodig. Azure Front Door gebruikt reacties van de test om de beste oorsprong te bepalen voor het routeren van clientaanvragen.
  • Ondersteuning voor bewaking: het ondersteunt ingebouwde rapporten met een alles-in-één dashboard voor zowel Front Door als beveiligingspatronen. U kunt waarschuwingen configureren die worden geïntegreerd met Azure Monitor. Hiermee kan de toepassing elke aanvraag en mislukte statustests registreren.
  • DDoS-beveiliging: het heeft ingebouwde DDoS-beveiliging op laag 3-4.
  • Netwerk voor contentlevering: Contoso Fiber posities voor het gebruik van een netwerk voor contentlevering. Het netwerk voor contentlevering biedt siteversnelling.

• Web Application Firewall: Gebruik Azure Web Application Firewall om gecentraliseerde beveiliging te bieden tegen veelvoorkomende aanvallen en beveiligingsproblemen op internet. Contoso Fiber heeft Azure Web Application Firewall gebruikt om de volgende redenen:

  • Wereldwijde beveiliging: Het biedt verbeterde wereldwijde web-app-beveiliging zonder dat dit ten koste gaat van de prestaties.
  • Botnet-beveiliging: het team kan instellingen bewaken en configureren om beveiligingsproblemen met betrekking tot botnets aan te pakken.
  • Pariteit met on-premises: de on-premises oplossing werd uitgevoerd achter een webtoepassingsfirewall die wordt beheerd door IT.
  • Gebruiksgemak: Web Application Firewall kan worden geïntegreerd met Azure Front Door.

• Geheimenbeheerder: Gebruik Azure Key Vault als u geheimen hebt om te beheren in Azure. Contoso Fiber heeft Key Vault gebruikt om de volgende redenen:

  • Versleuteling: het ondersteunt versleuteling at rest en in transit.
  • Ondersteuning voor beheerde identiteiten: de toepassingsservices kunnen beheerde identiteiten gebruiken voor toegang tot het geheime archief.
  • Bewaking en logboekregistratie: het vereenvoudigt de toegang tot audit en genereert waarschuwingen wanneer opgeslagen geheimen worden gewijzigd.
  • Integratie: Het biedt systeemeigen integratie met het Azure-configuratiearchief (App Configuration) en het webhostingplatform (App Service).

• Eindpuntbeveiliging: Gebruik Azure Private Link om toegang te krijgen tot platform-as-a-service-oplossingen via een privé-eindpunt in uw virtuele netwerk. Verkeer tussen uw virtuele netwerk en de service loopt over het Backbone-netwerk van Microsoft. Contoso Fiber koos voor Private Link om de volgende redenen:

  • Verbeterde beveiligingscommunicatie: Hiermee kan de toepassing privé toegang krijgen tot services op het Azure-platform en vermindert de netwerkvoetafdruk van gegevensarchieven om bescherming te bieden tegen gegevenslekken.
  • Minimale inspanning: de privé-eindpunten ondersteunen het web-app-platform en het databaseplatform dat de web-app gebruikt. Beide platforms spiegelen bestaande on-premises configuraties voor minimale wijzigingen.

• Netwerkbeveiliging: Gebruik Azure Firewall om inkomend en uitgaand verkeer op netwerkniveau te beheren. Gebruik Azure Bastion om veilig verbinding te maken met virtuele machines zonder RDP-/SSH-poorten weer te geven. Contoso Fiber heeft een sternetwerktopologie aangenomen en wilde gedeelde netwerkbeveiligingsservices in de hub plaatsen. Azure Firewall verbetert de beveiliging door al het uitgaande verkeer van de spokes te inspecteren om de netwerkbeveiliging te verbeteren. Contoso Fiber heeft Azure Bastion nodig voor veilige implementaties vanaf een jumphost in het DevOps-subnet.

Richtlijnen voor code

Als u een web-app naar de cloud wilt verplaatsen, moet u de code van uw web-app bijwerken met het patroon Voor opnieuw proberen, circuitonderbreker en ontwerppatroon Cache-Aside.

Figuur 3. Rol van de ontwerppatronen.

Elk ontwerppatroon biedt voordelen van workloadontwerp die zijn afgestemd op een van de meer pijlers van het goed ontworpen framework. Hier volgt een overzicht van de patronen die u moet implementeren:

1. Patroon voor opnieuw proberen: het patroon Opnieuw proberen verwerkt tijdelijke fouten door bewerkingen opnieuw uit te voeren die af en toe kunnen mislukken. Implementeer dit patroon voor alle uitgaande aanroepen naar andere Azure-services.

2. Circuitonderbrekerpatroon: Het circuitonderbrekerpatroon voorkomt dat een toepassing bewerkingen opnieuw probeert uit te voeren die niet tijdelijk zijn. Implementeer dit patroon in alle uitgaande aanroepen naar andere Azure-services.

3. Cache-Aside-patroon: het cache-aside-patroon wordt vaker toegevoegd aan en opgehaald uit een cache dan een gegevensarchief. Implementeer dit patroon voor aanvragen naar de database.

Het patroon Opnieuw proberen implementeren

Voeg het patroon Opnieuw proberen toe aan uw toepassingscode om tijdelijke serviceonderbrekingen aan te pakken. Deze onderbrekingen worden tijdelijke fouten genoemd. Tijdelijke fouten lossen zichzelf meestal binnen enkele seconden op. Met het patroon Opnieuw proberen kunt u mislukte aanvragen opnieuw verzenden. Hiermee kunt u ook de aanvraagvertragingen en het aantal pogingen configureren voordat een fout wordt toegestaan.

Gebruik Resilience4j, een lichtgewicht bibliotheek met fouttolerantie, om het patroon Opnieuw proberen in Java te implementeren. Met de referentie-implementatie wordt bijvoorbeeld het patroon Opnieuw proberen toegevoegd door de listServicePlans-methode van de Service Plan Controller te decoreren met aantekeningen voor opnieuw proberen. De code probeert de aanroep opnieuw uit te voeren naar een lijst met serviceplannen uit de database als de eerste aanroep mislukt. De referentie-implementatie configureert het beleid voor opnieuw proberen, inclusief maximale pogingen, wachttijd en welke uitzonderingen opnieuw moeten worden geprobeerd. Het beleid voor opnieuw proberen is geconfigureerd in 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";
    }

Het circuitonderbrekerpatroon implementeren

Gebruik het circuitonderbrekerpatroon om serviceonderbrekingen af te handelen die geen tijdelijke fouten zijn. Het circuitonderbrekerpatroon voorkomt dat een toepassing continu toegang probeert te krijgen tot een service die niet reageert. De toepassing wordt vrijgegeven en cpu-cycli worden vermeden, zodat de toepassing de prestatie-integriteit voor eindgebruikers behoudt.

Gebruik de documentatie voor Spring Circuit Breaker en Resilience4j om het circuitonderbrekerpatroon te implementeren. De referentie-implementatie implementeert bijvoorbeeld het circuitonderbrekerpatroon door methoden te decoreren met het kenmerk Circuitonderbreker.

Het cache-aside-patroon implementeren

Voeg het cache-aside-patroon toe aan uw web-app om het gegevensbeheer in het geheugen te verbeteren. Het patroon wijst de toepassing de verantwoordelijkheid toe voor het verwerken van gegevensaanvragen en zorgt voor consistentie tussen de cache en een permanente opslag, zoals een database. Het verkort de reactietijden, verbetert de doorvoer en vermindert de behoefte aan meer schaalaanpassing. Het vermindert ook de belasting van het primaire gegevensarchief, waardoor de betrouwbaarheid en kostenoptimalisatie worden verbeterd. Volg deze aanbevelingen om het cache-aside-patroon te implementeren:

• Configureer de toepassing voor het gebruik van een cache. Als u caching wilt inschakelen, voegt u het spring-boot-starter-cache pakket toe als een afhankelijkheid in uw pom.xml bestand. Dit pakket biedt standaardconfiguraties voor Redis-cache.

• Gegevens die veel nodig zijn in de cache opslaan. Pas het cache-aside-patroon toe op gegevens die veel nodig zijn om de effectiviteit ervan te vergroten. Gebruik Azure Monitor om de CPU, het geheugen en de opslag van de database bij te houden. Met deze metrische gegevens kunt u bepalen of u een kleinere database-SKU kunt gebruiken nadat u het cache-aside-patroon hebt toegepast. Als u specifieke gegevens in uw code in de cache wilt opslaan, voegt u de @Cacheable aantekening toe. Deze aantekening vertelt Spring welke methoden hun resultaten in de cache moeten opslaan.

• Houd cachegegevens actueel. Plan regelmatige cache-updates om te synchroniseren met de meest recente databasewijzigingen. Bepaal de optimale vernieuwingsfrequentie op basis van gegevensvolatiliteit en gebruikersbehoeften. Deze procedure zorgt ervoor dat de toepassing gebruikmaakt van het cache-aside-patroon om zowel snelle toegang als huidige informatie te bieden. De standaardcache-instellingen passen mogelijk niet bij uw webtoepassing. U kunt deze instellingen aanpassen in het application.properties bestand of de omgevingsvariabelen. U kunt bijvoorbeeld de spring.cache.redis.time-to-live waarde (uitgedrukt in milliseconden) wijzigen om te bepalen hoe lang gegevens in de cache moeten blijven voordat ze worden verwijderd.

• Zorg voor gegevensconsistentie. Implementeer mechanismen voor het bijwerken van de cache direct na een schrijfbewerking van de database. Gebruik gebeurtenisgestuurde updates of toegewezen gegevensbeheerklassen om cachecoherentie te garanderen. Het consistent synchroniseren van de cache met databasewijzigingen is centraal in het cache-aside-patroon.

Configuratierichtlijnen

De volgende secties bevatten richtlijnen voor het implementeren van de configuratie-updates. Elke sectie wordt uitgelijnd met een of meer pijlers van het Well-Architected Framework.

Gebruikersverificatie en -autorisatie configureren

Wanneer u webtoepassingen naar Azure migreert, configureert u gebruikersverificatie en autorisatiemechanismen. Volg deze aanbevelingen:

• Gebruik een identiteitsplatform. Gebruik het Microsoft Identity Platform om verificatie van web-apps in te stellen. Dit platform ondersteunt toepassingen die gebruikmaken van één Microsoft Entra-directory, meerdere Microsoft Entra-mappen van verschillende organisaties en Microsoft-identiteiten of sociale accounts.

  De Spring Boot Starter voor Microsoft Entra ID stroomlijnt dit proces, waarbij Spring Security en Spring Boot worden gebruikt voor eenvoudige installatie. Het biedt verschillende verificatiestromen, automatisch tokenbeheer en aanpasbaar autorisatiebeleid, samen met integratiemogelijkheden met Spring Cloud-onderdelen. Dit maakt eenvoudige Integratie van Microsoft Entra ID en OAuth 2.0 mogelijk in Spring Boot-toepassingen zonder handmatige bibliotheek- of instellingenconfiguratie.

  De referentie-implementatie maakt bijvoorbeeld gebruik van het Microsoft Identity Platform (Microsoft Entra ID) als id-provider voor de web-app. De OAuth 2.0-autorisatiecode wordt gebruikt om een gebruiker aan te melden met een Microsoft Entra-account. In het volgende XML-fragment worden de twee vereiste afhankelijkheden van de OAuth 2.0-autorisatiecodestroom gedefinieerd. De afhankelijkheid com.azure.spring: spring-cloud-azure-starter-active-directory maakt Verificatie en autorisatie van Microsoft Entra mogelijk in een Spring Boot-toepassing. De afhankelijkheid org.springframework.boot: spring-boot-starter-oauth2-client ondersteunt OAuth 2.0-verificatie en -autorisatie in een Spring Boot-toepassing.

  <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>
  

• Maak een app-registratie. Microsoft Entra ID vereist een toepassingsregistratie in de primaire tenant. De toepassingsregistratie zorgt ervoor dat de gebruikers die toegang krijgen tot de web-app identiteiten hebben in de primaire tenant. De referentie-implementatie maakt bijvoorbeeld gebruik van Terraform om een Microsoft Entra ID-app-registratie te maken, samen met een app-specifieke accountmanagerrol.

  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"
    }
  }
  

• Autorisatie in de toepassing afdwingen. Gebruik op rollen gebaseerd toegangsbeheer (RBAC) om minimale bevoegdheden toe te wijzen aan toepassingsrollen. Specifieke rollen definiëren voor verschillende gebruikersacties om overlapping te voorkomen en duidelijkheid te garanderen. Wijs gebruikers toe aan de juiste rollen en zorg ervoor dat ze alleen toegang hebben tot de benodigde resources en acties. Configureer Spring Security voor het gebruik van Spring Boot Starter voor Microsoft Entra ID. Deze bibliotheek staat integratie met Microsoft Entra-id toe en helpt u ervoor te zorgen dat gebruikers veilig worden geverifieerd. Het configureren en inschakelen van de Microsoft Authentication Library (MSAL) biedt toegang tot meer beveiligingsfuncties. Deze functies omvatten tokencaching en automatisch vernieuwen van tokens.

  Met de referentie-implementatie worden bijvoorbeeld app-rollen gemaakt die overeenkomen met de typen gebruikersrollen in het accountbeheersysteem van Contoso Fiber. Rollen worden tijdens autorisatie omgezet in machtigingen. Voorbeelden van app-specifieke rollen in CAMS zijn de accountmanager, niveau één (L1) ondersteuningsmedewerker en Field Service-vertegenwoordiger. De rol Accountmanager heeft machtigingen om nieuwe app-gebruikers en -klanten toe te voegen. Een Field Service-vertegenwoordiger kan ondersteuningstickets maken. Het PreAuthorize kenmerk beperkt de toegang tot specifieke rollen.

      @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";
      }
      ...
  

  Voor integratie met Microsoft Entra-id gebruikt de referentie-implementatie de stroom voor het verlenen van OAuth 2.0-autorisatiecode . Met deze stroom kan een gebruiker zich aanmelden met een Microsoft-account. In het volgende codefragment ziet u hoe u de SecurityFilterChain Microsoft Entra-id configureert voor verificatie en autorisatie.

  @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();
      }
  }
  ...
  

• Geef de voorkeur aan tijdelijke toegang tot opslag. Gebruik tijdelijke machtigingen om te beschermen tegen onbevoegde toegang en schendingen, zoals Shared Access Signatures (SASs). Gebruik SAS's voor gebruikersdelegatie om de beveiliging te maximaliseren bij het verlenen van tijdelijke toegang. Het is de enige SAS die gebruikmaakt van Microsoft Entra ID-referenties en waarvoor geen permanente opslagaccountsleutel is vereist.

• Autorisatie afdwingen in Azure. Gebruik Azure RBAC om minimale bevoegdheden toe te wijzen aan gebruikersidentiteiten. Azure RBAC bepaalt waartoe Identiteiten van Azure-resources toegang hebben, wat ze met deze resources kunnen doen en tot welke gebieden ze toegang hebben.

• Vermijd permanente verhoogde machtigingen. Gebruik Microsoft Entra Privileged Identity Management om Just-In-Time-toegang te verlenen voor bevoorrechte bewerkingen. Ontwikkelaars hebben bijvoorbeeld vaak toegang op beheerdersniveau nodig om databases te maken/verwijderen, tabelschema's te wijzigen en gebruikersmachtigingen te wijzigen. Met Just-In-Time-toegang ontvangen gebruikersidentiteiten tijdelijke machtigingen voor het uitvoeren van bevoorrechte taken.

Beheerde identiteiten implementeren

Beheerde identiteiten gebruiken voor alle Azure-services die beheerde identiteiten ondersteunen. Met een beheerde identiteit kunnen Azure-resources (workloadidentiteiten) worden geverifieerd bij en communiceren met andere Azure-services zonder referenties te beheren. Hybride en verouderde systemen kunnen on-premises verificatieoplossingen behouden om de migratie te vereenvoudigen, maar moeten zo snel mogelijk worden overgestapt op beheerde identiteiten. Volg deze aanbevelingen om beheerde identiteiten te implementeren:

• Kies het juiste type beheerde identiteit. Geef de voorkeur aan door de gebruiker toegewezen beheerde identiteiten wanneer u twee of meer Azure-resources hebt die dezelfde set machtigingen nodig hebben. Deze installatie is efficiënter dan het maken van door het systeem toegewezen beheerde identiteiten voor elk van deze resources en het toewijzen van dezelfde machtigingen aan al deze resources. Gebruik anders door het systeem toegewezen beheerde identiteiten.

• Minimale bevoegdheden configureren. Gebruik Azure RBAC om alleen de machtigingen te verlenen die essentieel zijn voor de bewerkingen, zoals CRUD-acties in databases of toegang tot geheimen. Machtigingen voor workloadidentiteit zijn permanent, zodat u geen Just-In-Time- of Korte-termijnmachtigingen kunt opgeven voor workloadidentiteiten. Als Azure RBAC geen specifiek scenario omvat, moet u Azure RBAC aanvullen met toegangsbeleid op Azure-serviceniveau.

• Beveilig resterende geheimen. Sla eventuele resterende geheimen op in Azure Key Vault. Laad geheimen uit Key Vault bij het opstarten van de toepassing in plaats van tijdens elke HTTP-aanvraag. Toegang met hoge frequentie binnen HTTP-aanvragen kan de transactielimieten van Key Vault overschrijden. Sla toepassingsconfiguraties op in Azure-app Configuratie.

Omgevingen met de juiste grootte

Gebruik de prestatielagen (SKU's) van Azure-services die voldoen aan de behoeften van elke omgeving zonder overtollige behoeften. Volg deze aanbevelingen om de grootte van uw omgevingen te wijzigen:

• Kosten schatten. Gebruik de Azure-prijscalculator om de kosten van elke omgeving te schatten.

• Kosten optimaliseren van productieomgevingen. Productieomgevingen hebben SKU's nodig die voldoen aan de SLA(Service Level Agreements), functies en schaal die nodig zijn voor productie. Bewaak continu het resourcegebruik en pas SKU's aan om te voldoen aan de werkelijke prestatiebehoeften.

• Kosten optimaliseren preproductieomgevingen. Preproductieomgevingen moeten gebruikmaken van goedkopere resources, overbodige services uitschakelen en kortingen toepassen, zoals Prijzen voor Azure Dev/Test. Zorg ervoor dat preproductieomgevingen voldoende vergelijkbaar zijn met productie om risico's te voorkomen. Dit evenwicht zorgt ervoor dat testen effectief blijft zonder onnodige kosten te maken.

• SKU's definiëren met infrastructuur als code (IaC). Implementeer IaC om dynamisch de juiste SKU's te selecteren en te implementeren op basis van de omgeving. Deze aanpak verbetert de consistentie en vereenvoudigt het beheer.

De referentie-implementatie heeft bijvoorbeeld een optionele parameter waarmee verschillende SKU's worden geïmplementeerd. Met een omgevingsparameter wordt de Terraform-sjabloon geïnstrueerd om ontwikkelings-SKU's te selecteren.

azd env set APP_ENVIRONMENT prod

Automatisch schalen implementeren

Automatische schaalaanpassing zorgt ervoor dat een web-app flexibel, responsief en geschikt blijft voor het efficiënt verwerken van dynamische workloads. Volg deze aanbevelingen om automatisch schalen te implementeren:

• Uitschalen automatiseren. Gebruik automatische schaalaanpassing van Azure om horizontaal schalen in productieomgevingen te automatiseren. Configureer regels voor automatisch schalen om uit te schalen op basis van belangrijke prestatiegegevens, zodat uw toepassing verschillende belastingen kan verwerken.

• Schaaltriggers verfijnen. Begin met CPU-gebruik als de eerste schaaltrigger als u niet bekend bent met de schaalvereisten van uw toepassing. Verfijn uw schaaltriggers met andere metrische gegevens, zoals RAM, netwerkdoorvoer en schijf-I/O. Het doel is om het gedrag van uw webtoepassing te vinden voor betere prestaties.

• Geef een uitschaalbuffer op. Stel de drempelwaarden voor schaalaanpassing in om te activeren voordat u de maximale capaciteit bereikt. Configureer bijvoorbeeld schalen voor 85% CPU-gebruik in plaats van te wachten totdat het 100% bereikt. Deze proactieve aanpak helpt de prestaties te behouden en potentiële knelpunten te voorkomen.

Resource-implementatie automatiseren

Automatisering gebruiken om Azure-resources en -code in alle omgevingen te implementeren en bij te werken. Volg deze aanbevelingen:

• Gebruik infrastructuur als code. Implementeer infrastructuur als code via CI/CD-pijplijnen (continue integratie en continue levering). Azure heeft vooraf bicep-, ARM-(JSON) en Terraform-sjablonen gemaakt voor elke Azure-resource.

• Gebruik een pijplijn voor continue integratie/continue implementatie (CI/CD). Gebruik een CI/CD-pijplijn om code van broncodebeheer te implementeren in uw verschillende omgevingen, zoals testen, faseren en productie. Gebruik Azure Pipelines als u werkt met Azure DevOps of GitHub Actions voor GitHub-projecten.

• Moduletests integreren. Prioriteit geven aan de uitvoering en het doorgeven van alle eenheidstests in uw pijplijn voordat u een implementatie naar App Services uitvoert. Neem codekwaliteit en dekkingshulpprogramma's zoals SonarQube op om uitgebreide testdekking te bereiken.

• Een mockingframework aannemen. Voor het testen met externe eindpunten gebruikt u mocking-frameworks. Met deze frameworks kunt u gesimuleerde eindpunten maken. Ze elimineren de noodzaak om echte externe eindpunten te configureren en uniforme testomstandigheden in omgevingen te garanderen.

• Beveiligingsscans uitvoeren. Gebruik statische SAST (Application Security Testing) om beveiligingsfouten en coderingsfouten in uw broncode te vinden. Voer bovendien softwaresamenstellingsanalyse (SCA) uit om bibliotheken en onderdelen van derden te onderzoeken op beveiligingsrisico's. Hulpprogramma's voor deze analyses zijn direct geïntegreerd in Zowel GitHub als Azure DevOps.

Bewaking configureren

Implementeer toepassings- en platformbewaking om de operationele uitmuntendheid en prestatie-efficiëntie van uw web-app te verbeteren. Volg deze aanbevelingen om bewaking te implementeren:

• Toepassingstelemetrie verzamelen. Gebruik automatische instrumentatie in Azure-toepassing Insights om toepassingstelemetrie te verzamelen, zoals aanvraagdoorvoer, gemiddelde aanvraagduur, fouten en afhankelijkheidsbewaking, zonder codewijzigingen. Spring Boot registreert verschillende kerngegevens in Application Insights, zoals JVM (Java Virtual Machine), CPU, Tomcat en andere. Application Insights verzamelt automatisch van frameworks voor logboekregistratie, zoals Log4j en Logback. De referentie-implementatie maakt bijvoorbeeld gebruik van Application Insights die is ingeschakeld via Terraform als onderdeel van de configuratie van app_settings De App Service. (zie de volgende code).

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

  Zie voor meer informatie:

  • Azure Monitor Application Insights configureren voor Spring Boot
  • Azure Monitor Application Insights voor Java
  • Azure Monitor OpenTelemetry inschakelen voor Java-toepassingen
  • Azure Monitor Application Insights gebruiken met Spring Boot

• Aangepaste metrische toepassingsgegevens maken. Implementeer instrumentatie op basis van code om aangepaste toepassingstelemetrie vast te leggen door de Application Insights SDK en de BIJBEHORENDE API toe te voegen.

• Bewaak het platform. Schakel diagnostische gegevens in voor alle ondersteunde services en verzend diagnostische gegevens naar dezelfde bestemming als de toepassingslogboeken voor correlatie. Azure-services maken automatisch platformlogboeken, maar slaan ze alleen op wanneer u diagnostische gegevens inschakelt. Schakel diagnostische instellingen in voor elke service die diagnostische gegevens ondersteunt. De referentie-implementatie maakt gebruik van Terraform om Diagnostische gegevens van Azure in te schakelen voor alle ondersteunde services. Met de volgende Terraform-code worden de diagnostische instellingen voor de App Service geconfigureerd.

  # 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
    }
  }
  

De referentie-implementatie implementeren

De referentie-implementatie begeleidt ontwikkelaars bij een gesimuleerde migratie van een on-premises Java-toepassing naar Azure, waarbij de benodigde wijzigingen tijdens de initiële acceptatiefase worden gemarkeerd. In dit voorbeeld wordt een CAMS-web-app-toepassing (Customer Account Management System) gebruikt voor het fictieve bedrijf Contoso Fiber. Contoso Fiber stelt de volgende doelen voor hun webtoepassing in:

• Goedkope, hoogwaardige codewijzigingen implementeren
• Een serviceniveaudoelstelling (SLO) van 99,9% bereiken
• DevOps-procedures gebruiken
• Voor kosten geoptimaliseerde omgevingen maken
• Betrouwbaarheid en beveiliging verbeteren

Contoso Fiber heeft vastgesteld dat hun on-premises infrastructuur geen rendabele oplossing was om aan deze doelstellingen te voldoen. Ze hebben besloten dat het migreren van hun CAMS-webtoepassing naar Azure de meest rendabele manier was om hun onmiddellijke en toekomstige doelstellingen te bereiken. De volgende architectuur vertegenwoordigt de eindstatus van de implementatie van het betrouwbare web-app-patroon van Contoso Fiber.

Afbeelding 4. Architectuur van de referentie-implementatie. Download een Visio-bestand van deze architectuur.