Delen via


Betrouwbaar web-app-patroon voor Java

Azure App Service
Azure Front Door

Dit artikel bevat richtlijnen voor het implementeren van het patroon Reliable Web App. In dit patroon wordt beschreven hoe u web-apps voor cloudmigratie wijzigt (opnieuw platformen). Het biedt prescriptieve architectuur, code en configuratierichtlijnen die zijn afgestemd op de principes van de Azure 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 ze naar de cloud migreert. Het richt zich op de minimale code-updates die u nodig hebt om succesvol te zijn in de cloud. In de volgende richtlijnen wordt een referentie-implementatie als voorbeeld gebruikt. Het volgt het herplatformtraject van het fictieve bedrijf Contoso Fiber om bedrijfscontext te bieden voor uw reis. 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.

Aanbeveling

GitHub-logo. Er is een referentie-implementatie (voorbeeld) van het patroon Reliable Web App. Het vertegenwoordigt de eindstatus van de implementatie van betrouwbare web-apps. Het is een web-app op productieniveau die alle code, architectuur en configuratie-updates bevat die in dit artikel worden besproken. Implementeer en gebruik de referentie-implementatie om uw implementatie van het reliable web-app-patroon te begeleiden.

Het patroon Reliable Web App implementeren

Dit artikel bevat richtlijnen voor architectuur, code en configuratie voor het implementeren van het reliable web-app-patroon. Gebruik de volgende koppelingen om naar de specifieke richtlijnen te gaan die u nodig hebt:

  • Zakelijke context. 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. Meer informatie over het selecteren van de juiste cloudservices en het ontwerpen van een architectuur 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: de patronen voor opnieuw proberen, circuitonderbreker en Cache-Aside.
  • 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 (SLO) en kostenoptimalisatiedoelen, en ook 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 (bijvoorbeeld 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 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 SLO van 99,9%.
  • DevOps-procedures gebruiken.
  • Voor kosten geoptimaliseerde omgevingen maken.
  • Verbeter de betrouwbaarheid en beveiliging.

Contoso Fiber heeft vastgesteld dat hun on-premises infrastructuur geen rendabele oplossing was voor het schalen van de toepassing. 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.

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 routeren en te beveiligen. 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, zodat u inzicht krijgt in uw web-app.

diagram met de essentiële architecturale elementen van het patroon Reliable 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 uw beoogde hersteltijd (RTO) en RPO (Recovery Point Objective). De RTO beïnvloedt de beschikbaarheid en moet ondersteuning bieden voor uw SLO. Bepaal een 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 beschikbaarheidsvereisten. 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 heeft 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 te beheren met verbeterde beveiliging. (Zie afbeelding 2.)

    Diagram met het patroon Reliable Web App met een tweede regio en een hub-and-spoke-topologie.

    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 om meerdere virtuele netwerken te gebruiken, gebruikt u een hub-and-spoke-netwerktopologie. Het biedt voordelen van kosten, beheer en beveiliging en 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 kiezen die voldoen aan uw bedrijfsvereisten en die overeenkomen met de functies van de on-premises web-app. Deze 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 deze naar de cloud werd verplaatst, 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 progressie. 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 Container Apps? en Java in Het overzicht van Azure Container Apps voor meer informatie.
    • Hoge SLA. App Service biedt een hoge SLA die voldoet aan de vereisten voor de productieomgeving.
    • Minder beheeroverhead. App Service 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 uitschalen 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.
    • Schaalbaarheid. Microsoft Entra ID wordt geschaald om grotere scenario's te ondersteunen.
    • Gebruikersidentiteitsbeheer. Callcentermedewerkers kunnen hun bestaande bedrijfsidentiteiten gebruiken.
    • Ondersteuning voor autorisatieprotocol. Microsoft Entra ID ondersteunt OAuth 2.0 voor beheerde identiteiten.
  • Database: Gebruik een service waarmee u dezelfde database-engine kunt behouden. Gebruik de beslissingsstructuur voor gegevensarchief om uw selectie te begeleiden. Contoso Fiber koos om de volgende redenen voor Azure Database for PostgreSQL en het implementatiemodel voor flexibele servers:

    • Betrouwbaarheid. Het flexibele serverimplementatiemodel 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. Azure Database for PostgreSQL biedt een leesreplicafunctie waarmee u gegevens asynchroon kunt repliceren naar een alleen-lezen replicadatabase in een andere regio.
    • Voorstelling. Azure Database for PostgreSQL biedt voorspelbare prestaties en intelligente afstemming die de prestaties van uw database verbetert met behulp van echte gebruiksgegevens.
    • Minder beheeroverhead. Het is een volledig beheerde Azure-service die beheerverplichtingen vermindert.
    • Migratieondersteuning. Het ondersteunt databasemigratie van on-premises PostgreSQL-databases met één server. Contoso kan 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 in zone-redundante opslag (ZRS) binnen dezelfde regio. Contoso kan de database herstellen naar elk tijdstip dat zich binnen de bewaarperiode van de back-up bevindt. 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. Er worden automatisch prestatieafwijkingen gedetecteerd.
    • Probleemoplossing. Het helpt u bij het diagnosticeren van problemen in de actieve app.
    • Toezicht. 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 het bewaken van de prestaties van toepassingen. Application Insights biedt eenvoudige integratie met het toepassingsplatform en code.
  • Cache: Kiezen of u een cache wilt toevoegen aan de architectuur van uw web-app. Azure Cache voor Redis is de primaire Azure Cache-oplossing. Het is een beheerd gegevensarchief in het geheugen dat is gebaseerd op de Redis-software. Contoso Fiber heeft Om de volgende redenen Azure Cache voor Redis toegevoegd:

    • Snelheid en volume. Het biedt leesbewerkingen met een 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-plaksessies. Met de cache kan de web-app de sessiestatus externaliseren en niet-plaksessies gebruiken. De meeste Java-web-apps die on-premises worden uitgevoerd, maken gebruik van cacheopslag aan de clientzijde van het geheugen. Caching aan de clientzijde in het geheugen schaalt niet goed en verhoogt de geheugenvoetafdruk op de host. Met Azure Cache voor Redis heeft Contoso Fiber een volledig beheerde, schaalbare cacheservice om de schaalbaarheid en prestaties van hun toepassingen te verbeteren. Contoso gebruikte een cacheabstractieframework (Spring Cache) en had alleen minimale configuratiewijzigingen nodig om de cacheprovider uit te wisselen. Hiermee konden ze overstappen van een Ehcache-provider naar de Redis-provider.
  • Load balancer: Webtoepassingen die paaS-oplossingen (Platform as a Service) gebruiken, moeten Gebruikmaken van Azure Front Door, Azure Application Gateway of beide, afhankelijk van de architectuur en vereisten van de web-app. 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 en een web-app voor meerdere regio's om te voldoen aan de SLO van 99,9%. Contoso 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 is systeemeigen geïntegreerd 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-punt van aanwezigheid te bereiken en de snelste route naar de web-app te vinden.
    • Aangepaste domeinen. Het ondersteunt aangepaste domeinnamen met flexibele domeinvalidatie.
    • Gezondheidstests 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.
    • Bewakingsondersteuning. Azure Front Door biedt ondersteuning voor ingebouwde rapporten met een alles-in-één dashboard voor zowel Azure Front Door als beveiligingspatronen. U kunt waarschuwingen configureren die worden geïntegreerd met Azure Monitor. Met Azure Front Door kan de toepassing elke aanvraag en mislukte statustests registreren.
    • DDoS-beveiliging. Het heeft ingebouwde DDoS-beveiliging op laag 3-4.
    • Netwerk voor contentlevering. Het positioneert Contoso Fiber om een netwerk voor contentlevering te gebruiken. 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 te verhelpen.
    • Pariteit met on-premises. De on-premises oplossing is uitgevoerd achter een webtoepassingsfirewall die door IT wordt beheerd.
    • 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:

    • Codering. Het ondersteunt versleuteling-at-rest en in transit.
    • Ondersteuning voor beheerde identiteiten. De toepassingsservices kunnen beheerde identiteiten gebruiken om toegang te krijgen tot het geheime archief.
    • Bewaking en logboekregistratie. Key Vault vereenvoudigt controletoegang en genereert waarschuwingen wanneer opgeslagen geheimen worden gewijzigd.
    • Integratie. Key Vault biedt systeemeigen integratie met het Azure-configuratiearchief (Azure App Configuration) en het webhostingplatform (App Service).
  • Eindpuntbeveiliging: Gebruik Azure Private Link om toegang te krijgen tot PaaS-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 door de web-app wordt gebruikt. Beide platforms spiegelen bestaande on-premises configuraties, dus minimale wijziging is vereist.
  • Netwerkbeveiliging: Gebruik Azure Firewall om inkomend en uitgaand verkeer op netwerkniveau te beheren. Gebruik Azure Bastion- om verbinding te maken met virtuele machines met verbeterde beveiliging, zonder RDP-/SSH-poorten weer te geven. Contoso Fiber heeft een hub-and-spoke-netwerktopologie 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 verbeterde beveiligingsimplementaties van 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 Opnieuw proberen, circuitonderbrekerpatroon en Cache-Aside patroon.

diagram met de rollen van ontwerppatronen in het patroon Reliable Web App.

Figuur 3. Rollen van de ontwerppatronen.

Elk ontwerppatroon biedt voordelen voor workloadontwerp die zijn afgestemd op een of meer pijlers van het Well-Architected Framework. Hier volgt een overzicht van de patronen die u moet implementeren:

  1. Patroon voor opnieuw proberen. Met het patroon Opnieuw proberen worden tijdelijke fouten verwerkt door bewerkingen opnieuw uit te voeren die af en toe 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 laadt gegevens op aanvraag in een cache vanuit een gegevensarchief. Implementeer dit patroon voor aanvragen naar de database.

Ontwerppatroon Betrouwbaarheid (RE) Beveiliging (SE) Kostenoptimalisatie (CO) Operationele uitmuntendheid (OE) Prestatie-efficiëntie (PE) Ondersteuning van WAF-principes
Patroon Opnieuw proberen RE:07
Circuit Breaker-patroon RE:03
RE:07
PE:07
PE:11
Cache-Aside-patroon RE:05
PE:08
PE:12

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 vertraging tussen nieuwe pogingen en het aantal pogingen configureren dat moet worden uitgevoerd voordat een fout wordt opgegeven.

Gebruik Resilience4j, een lichtgewicht bibliotheek voor fouttolerantie, om het patroon Opnieuw proberen in Java te implementeren. Met de referentie-implementatie wordt het patroon Voor opnieuw proberen toegevoegd door de listServicePlans-methode van de serviceplancontroller 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. Het beleid voor opnieuw proberen voor de referentie-implementatie omvat 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 helpt cpu-cycli te voorkomen, zodat de toepassing de prestatie-integriteit voor eindgebruikers behoudt.

Gebruik Spring Cloud Circuit Breaker en Resilience4j om het circuitonderbrekerpatroon te implementeren. De referentie-implementatie implementeert 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 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, wat de betrouwbaarheid en kostenoptimalisatie verbetert. 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 met hoge behoeften om de effectiviteit ervan te verbeteren. 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 geeft aan Spring op welke methoden de resultaten in de cache moeten worden opgeslagen.

  • Houd cachegegevens actueel. Plan regelmatige cache-updates om te synchroniseren met de meest recente databasewijzigingen. Gebruik de gegevensvolatiliteit en de gebruiker moet de optimale vernieuwingsfrequentie bepalen. 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 deze 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.

Configuratie Betrouwbaarheid (RE) Beveiliging (SE) Kostenoptimalisatie (CO) Operationele uitmuntendheid (OE) Prestatie-efficiëntie (PE) Ondersteuning van WAF-principes
Gebruikersverificatie en -autorisatie configureren SE:05
OE:10
Beheerde identiteiten implementeren SE:05
OE:10
Omgevingen rechten verlenen CO:05
CO:06
Automatisch schalen implementeren RE:06
CO:12
PE:05
Resource-implementatie automatiseren OE:05
Bewaking implementeren OE:07
PE:04

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. Het maakt gebruik van Spring Security en Spring Boot om een eenvoudige configuratie te garanderen. Het biedt verschillende verificatiestromen, automatisch tokenbeheer, aanpasbaar autorisatiebeleid en integratiemogelijkheden met Spring Cloud-onderdelen. Deze service 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 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 maakt OAuth 2.0-verificatie en -autorisatie mogelijk 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 toepassingsregistratie. Microsoft Entra ID vereist een toepassingsregistratie in de primaire tenant. De toepassingsregistratie helpt ervoor te zorgen dat gebruikers die toegang krijgen tot de web-app identiteiten hebben in de primaire tenant. De referentie-implementatie maakt 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 maakt integratie met Microsoft Entra ID mogelijk 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 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 Account Manager, Level One (L1) Support Representative en Field Service Representative. 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. U kunt bijvoorbeeld SAS- (Shared Access Signatures) gebruiken om de toegang tot een bepaalde periode te beperken. Gebruik SAS voor gebruikersdelegering om de beveiliging te maximaliseren wanneer u tijdelijke toegang verleent. 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 definieert de Azure-resources waartoe identiteiten toegang hebben, wat ze kunnen doen met deze resources en de gebieden waartoe 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. Wanneer u Just-In-Time-toegang gebruikt, ontvangen gebruikersidentiteiten tijdelijke machtigingen om bevoorrechte taken uit te voeren.

Beheerde identiteiten implementeren

Gebruik beheerde identiteiten voor alle Azure-services die deze ondersteunen. Met een beheerde identiteit kunnen Azure-resources (workloadidentiteiten) worden geverifieerd bij en communiceren met andere Azure-services zonder dat u referenties hoeft te beheren. Ter vereenvoudiging van de migratie kunt u on-premises verificatieoplossingen blijven gebruiken voor hybride en verouderde systemen, maar u moet ze zo snel mogelijk overschakelen naar 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 aanpak 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 machtigingen te verlenen die essentieel zijn voor 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.

  • Beveiliging bieden voor 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 rechten verlenen

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

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

  • Productieomgevingen optimaliseren met kosten. 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.

  • preproductieomgevingen optimaliseren.preproductieomgevingen goedkopere resources moeten gebruiken en profiteren van kortingen zoals Prijzen voor Azure Dev/Test. In deze omgevingen moet u services uitschakelen die niet nodig zijn. Zorg er tegelijkertijd voor dat preproductieomgevingen voldoende vergelijkbaar zijn met productieomgevingen omgevingen om risico's te voorkomen. Het handhaven van dit evenwicht zorgt ervoor dat testen effectief blijft zonder onnodige kosten te maken.

  • Gebruik infrastructuur als code (IaC) om SKU's te definiëren. 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 de SKU wordt opgegeven die moet worden geïmplementeerd. Een omgevingsparameter geeft aan dat de Terraform-sjabloon ontwikkelings-SKU's moet implementeren:

azd env set APP_ENVIRONMENT prod

Automatisch schalen implementeren

Automatisch schalen helpt ervoor te zorgen dat een web-app flexibel, responsief blijft en dynamische workloads efficiënt kan verwerken. 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. Gebruik 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 de maximale capaciteit wordt 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 met behulp van CI/CD-pijplijnen (continuous integration and continuous delivery). Azure biedt vooraf gemaakte Bicep-, ARM-sjablonen (JSON) en Terraform-sjablonen 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 met Azure DevOps werkt. Gebruik 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.

  • Gesimuleerde frameworks gebruiken. Voor het testen van 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 SAST (Static 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 eenvoudig te integreren 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 Application Insights om de toepassing te verzamelen telemetrie, zoals aanvraagdoorvoer, gemiddelde duur van de aanvraag, fouten en afhankelijkheidsbewaking. U hoeft geen code te wijzigen om deze telemetrie te gebruiken. Spring Boot registreert verschillende kerngegevens in Application Insights, zoals een virtuele Java-machine (JVM), CPU, Tomcat en andere. Application Insights verzamelt automatisch van frameworks voor logboekregistratie, zoals Log4j en Logback.

    De referentie-implementatie maakt gebruik van Application Insights, die is ingeschakeld via Terraform in de configuratie van app_settings de app-service:

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

    Zie voor meer informatie:

  • 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. 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 wijzigingen worden gemarkeerd die nodig zijn tijdens de initiële acceptatiefase. In dit voorbeeld wordt een CAMS-web-app gebruikt voor het fictieve bedrijf Contoso Fiber. Contoso Fiber stelt de volgende doelen voor de webtoepassing in:

  • Goedkope, hoogwaardige codewijzigingen implementeren.
  • Een SLO bereiken van 99,9%.
  • DevOps-procedures gebruiken.
  • Voor kosten geoptimaliseerde omgevingen maken.
  • Verbeter de betrouwbaarheid en beveiliging.

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 betrouwbare web-app-patroon-implementatie van Contoso Fiber.

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