Bewerken

Delen via

Basislijnarchitectuur voor Azure Spring Apps

Azure Application Gateway
Azure Key Vault
Azure Spring Apps
Azure Database for MySQL

In deze referentiearchitectuur wordt beschreven hoe u Java Spring Boot-workloads uitvoert in Azure Spring Apps. Het ontwerp maakt gebruik van zoneredundantie om hoge beschikbaarheid te bereiken. Implementeer dit ontwerp om te voorkomen dat een toepassing mislukt als er een storing optreedt in alle datacenters in een zone.

Deze architectuur helpt u bij het volgende:

  • Verhoog de beschikbaarheid van uw toepassing via een implementatie met één zone.
  • Verhoog de algehele tolerantie en serviceniveaudoelstelling (SLO) van uw toepassing.

Deze oplossing biedt een basislijnstrategie voor de implementatie van Azure Spring Apps. Zie Azure Spring Apps implementeren in meerdere regio's en Azure Spring Apps geïntegreerd met landingszones voor andere oplossingen die zijn gebaseerd op deze architectuur.

Tip

GitHub-logo Bekijk een voorbeeld van een implementatie die enkele ontwerpkeuzen van deze architectuur illustreert. Houd rekening met deze implementatie als uw eerste stap in de richting van productie.

Architectuur

In het volgende diagram ziet u de architectuur voor deze benadering:

Diagram met een referentiearchitectuur voor Azure Spring Apps met meerdere regio's.Een Visio-bestand van deze architectuur downloaden.

Workflow

Deze werkstroom komt overeen met het vorige diagram:

  1. De gebruiker opent de toepassing met behulp van de HTTP-hostnaam van de toepassing, zoals www.contoso.com. Azure DNS wordt gebruikt om de aanvraag voor deze hostnaam om te lossen naar het openbare eindpunt van de Azure-toepassing Gateway.

  2. Application Gateway wordt gebruikt om de aanvraag te inspecteren. Het wordt ook gebruikt om het toegestane verkeer door te sturen naar het IP-adres van de load balancer die zich in het ingerichte Azure Spring Apps-exemplaar bevindt. Application Gateway is geïntegreerd met Azure Web Application Firewall.

  3. De interne load balancer wordt gebruikt om het verkeer naar de back-endservices te routeren.

  4. Terwijl de aanvraag wordt verwerkt, communiceert de toepassing met andere Azure-services in het virtuele netwerk. De toepassing kan bijvoorbeeld geheimen ontvangen van Azure Key Vault of de opslagstatus van de database.

Onderdelen

De volgende Azure-services zijn de onderdelen in deze architectuur:

  • De standaardversie van Azure Spring Apps wordt gebruikt voor het hosten van een Java Spring Boot-voorbeeldtoepassing die wordt geïmplementeerd als microservices.

  • De standaard v2-versie van Application Gateway wordt gebruikt om verkeer naar de toepassingen te beheren. Het fungeert als een lokale omgekeerde proxy in de regio die uw toepassing uitvoert.

    Deze SKU heeft Web Application Firewall geïntegreerd om uw webtoepassingen te beschermen tegen aanvallen en beveiligingsproblemen. Web Application Firewall op Application Gateway houdt aanvallen van Open Web Application Security Project (OWASP) bij.

  • Azure DNS wordt gebruikt om aanvragen op te lossen die worden verzonden naar de hostnaam van de toepassing. Deze aanvragen worden omgezet naar het openbare eindpunt van Application Gateway. Privézones van Azure DNS worden gebruikt voor het oplossen van aanvragen voor de privé-eindpunten die toegang hebben tot de benoemde Azure Private Link-resources .

  • Azure Database for MySQL wordt gebruikt om de status op te slaan in een relationele back-enddatabase.

  • Key Vault wordt gebruikt voor het opslaan van toepassingsgeheimen en -certificaten. De microservices die worden uitgevoerd in Azure Spring Apps gebruiken de toepassingsgeheimen. Azure Spring Apps en Application Gateway gebruiken de certificaten voor het behouden van hostnamen.

Alternatieven

Azure Database for MySQL is niet de enige optie voor een database. U kunt ook gebruikmaken van:

Redundantie

Bouw redundantie in uw workload om single points of failure te minimaliseren. In deze architectuur repliceert u onderdelen tussen zones binnen een regio. Zorg ervoor dat u in uw architectuur beschikbaarheidszones gebruikt voor alle onderdelen in uw installatie.

Azure-services worden niet ondersteund in alle regio's en niet in alle regio's ondersteunen zones. Voordat u een regio selecteert, moet u de regionale en zone-ondersteuning controleren.

Zone-redundante services repliceren of distribueren resources automatisch tussen zones. Altijd beschikbare services zijn altijd beschikbaar in alle Azure-geografische gebieden en zijn bestand tegen zonebrede en regiobrede storingen.

In de volgende tabel ziet u de tolerantietypen voor de services in deze architectuur:

Service Tolerantie
Azure DNS Altijd beschikbaar
Application Gateway Zone-redundant
Azure Spring Apps Zone-redundant
Azure Database for MySQL Zone-redundant
Key Vault Zone-redundant
Azure Virtual Network Zone-redundant
Privé-eindpunten van Azure Zone-redundant

Azure Spring Apps ondersteunt zoneredundantie. Met zoneredundantie wordt alle onderliggende infrastructuur van de service verspreid over meerdere beschikbaarheidszones, die een hogere beschikbaarheid voor de toepassing bieden. Toepassingen worden horizontaal geschaald zonder codewijzigingen. Een netwerk met hoge prestaties verbindt Azure-beschikbaarheidszones. De verbinding heeft een retourlatentie van minder dan 2 milliseconden (ms). U hoeft niet te vertrouwen op asynchrone replicatie voor gegevensworkloads, wat vaak ontwerpuitdagingen aangeeft.

Er zijn meerdere beschikbaarheidszones ingesteld voor Application Gateway, inclusief het openbare IP-adres dat Application Gateway gebruikt. Openbare IP-adressen met een standaard-SKU ondersteunen beschikbaarheidszones.

Deze architectuur maakt gebruik van Azure Database for MySQL met de flexibele serverimplementatieoptie ter ondersteuning van hoge beschikbaarheid met automatische failover. Afhankelijk van uw latentievereisten kiest u zone-redundante hoge beschikbaarheid of hoge beschikbaarheid in dezelfde zone. Met een configuratie met hoge beschikbaarheid wordt met de optie Flexibele server automatisch een stand-byreplica ingericht en beheerd. Als er een storing optreedt, gaan vastgelegde gegevens niet verloren.

Key Vault is automatisch zone-redundant in elke regio waarin beschikbaarheidszones beschikbaar zijn. Het Key Vault-exemplaar dat in deze architectuur wordt gebruikt, wordt geïmplementeerd voor het opslaan van geheimen voor back-endservices.

Schaalbaarheid

Schaalbaarheid geeft de mogelijkheid aan van de workload om efficiënt te voldoen aan de vereisten die gebruikers erop plaatsen. De benadering met meerdere zones is beter voor schaalbaarheid dan een implementatie met één zone, omdat deze de belasting over beschikbaarheidszones verspreidt.

Deze architectuur heeft verschillende onderdelen die automatisch kunnen worden geschaald op basis van metrische gegevens:

Afhankelijk van de configuratie van uw database kan er extra latentie optreden wanneer u gegevens tussen zones moet synchroniseren.

Netwerkbeveiliging

Beveilig uw toepassing tegen onbevoegde toegang via internet, systemen in privénetwerken, andere Azure-services en nauw gekoppelde afhankelijkheden.

Virtual Network is de fundamentele bouwsteen voor een privénetwerk in Azure. Deze architectuur maakt gebruik van een virtueel netwerk voor de regio van de implementatie. Plaats onderdelen in subnetten om verdere isolatie te maken. Azure Spring Apps vereist een toegewezen subnet voor de serviceruntime en een afzonderlijk subnet voor Java Spring Boot-toepassingen.

Beveilig uw virtuele netwerken met Azure DDoS Protection. Combineer DDoS-beveiliging (Distributed Denial of Service) met best practices voor toepassingsontwerp om verbeterde oplossingen te bieden voor bescherming tegen DDoS-aanvallen.

Het architectuurontwerp bevat verschillende PaaS-oplossingen (Platform as a Service) waarmee een gebruikersaanvraag kan worden verwerkt. Plaats strikte netwerkcontroles op deze services om ervoor te zorgen dat de toepassing niet wordt beïnvloed.

Privéconnectiviteit

Gebruik privé-eindpunten of netwerkintegratie om communicatie van Azure Spring Apps te bieden voor ondersteunende services, zoals Key Vault en Azure Database for MySQL.

Gebruik privé-eindpunten om de toegang te beheren. De netwerkinterfaces gebruiken privé-IP-adressen om de services over te dragen naar het virtuele netwerk. Deze architectuur maakt gebruik van Azure-services die automatisch de privé-eindpunten instellen.

Implementeer Azure Spring Apps in het netwerk via het injectieproces van het virtuele netwerk. De toepassing wordt geopend door het privé-IP-adres te bereiken.

De database volgt een vergelijkbaar model. De flexibele-serverimplementatiemodus van Azure Database for MySQL ondersteunt integratie van virtuele netwerken via een toegewezen subnet.

Andere services, zoals Key Vault, zijn via Private Link verbonden met het virtuele netwerk. Voor Private Link moet u een privé-eindpunt inschakelen om openbare netwerktoegang uit te schakelen. Zie Key Vault integreren met Private Link voor meer informatie.

Voor privé-eindpunten is geen toegewezen subnet vereist, maar het is raadzaam om ze in een afzonderlijk subnet te plaatsen. Privé-IP-adressen aan de privé-eindpunten worden toegewezen vanuit dat subnet.

De privé-eindpunten en netwerk-geïntegreerde verbindingen maken gebruik van een Azure DNS-privézone.

Besturingselementen voor de verkeersstroom

Met deze architectuur zijn binnenkomende aanvragen alleen toegestaan via het openbare eindpunt dat wordt weergegeven door Application Gateway. Het verkeer moet nog steeds worden geïnspecteerd om aanvallen en beveiligingsproblemen te blokkeren. Web Application Firewall op de Application Gateway houdt OWASP-beveiligingsproblemen bij. Binnenkomend verkeer wordt gecontroleerd op basis van de geconfigureerde regels met een actie die moet worden gevolgd.

Het Azure Spring Apps-exemplaar heeft een interne load balancer waarmee verkeer naar de back-endservices wordt gerouteerd en gedistribueerd. De load balancer is geconfigureerd om alleen verkeer van Application Gateway te accepteren.

De toepassing moet mogelijk verbinding maken met andere eindpunten via het openbare internet. U kunt deze stroom beperken door Azure Firewall op het pad naar uitgaand verkeer te plaatsen.

Omgekeerde proxy instellen

Deze oplossing maakt gebruik van Application Gateway als een omgekeerde proxy. U kunt echter verschillende omgekeerde proxy's voor Azure Spring Apps gebruiken. U kunt Application Gateway combineren met Azure Front Door of u kunt Azure Front Door gebruiken in plaats van Application Gateway.

Zie Azure Spring Apps beschikbaar maken via een omgekeerde proxy voor informatie over scenario's met omgekeerde proxy's, het instellen ervan en de bijbehorende beveiligingsoverwegingen.

Identiteits- en toegangsbeheer

Naast het gebruik van netwerkcontroles, versterkt u de beveiligingspostuur door identiteit als perimeter te gebruiken.

De toepassing moet zichzelf verifiëren wanneer deze verbinding maakt met de back-endservices, bijvoorbeeld als de toepassing geheimen ophaalt uit Key Vault. In de toepassing is de aanbevolen methode om door Microsoft Entra beheerde identiteiten in te schakelen voor Azure-resources. Met deze configuratiemethode wordt een identiteit toegewezen aan de toepassing, zodat deze Microsoft Entra ID-tokens kan verkrijgen, waardoor de overhead van het beheren van referenties wordt verminderd.

Deze architectuur maakt gebruik van door het systeem toegewezen beheerde identiteiten voor verschillende interacties.

De back-endservices moeten toegang verlenen tot de service-principal die is toegewezen aan de beheerde identiteit. De service moet minimaal toegangsbeleid definiëren voor bepaalde acties. In deze architectuur wordt Key Vault gebruikt om de toepassing toegang te geven tot de geheimen, certificaten en sleutels.

Geheimenbeheer

In deze architectuur worden de toepassingsgeheimen en -certificaten opgeslagen in één sleutelkluis. Toepassingsgeheimen en de certificaten voor het behouden van hostnamen zijn verschillende problemen, dus u kunt deze items mogelijk opslaan in afzonderlijke sleutelkluizen. Met deze alternatieve benadering wordt een andere sleutelkluis aan uw architectuur toegevoegd.

Controleren

Azure Monitor is een bewakingsoplossing voor het verzamelen, analyseren en reageren op bewakingsgegevens uit uw cloud- en on-premises omgevingen.

Voeg instrumentatie toe aan uw toepassing om logboeken en metrische gegevens op codeniveau te verzenden. Overweeg gedistribueerde tracering in te schakelen voor waarneembaarheid tussen services in het Azure Spring Apps-exemplaar. Gebruik een APM-hulpprogramma (Application Performance Management) om logboeken en metrische gegevens te verzamelen. De Application Insights Java-agent voor Azure Monitor is een goede keuze voor het APM-hulpprogramma.

Gebruik platformdiagnose om logboeken en metrische gegevens op te halen uit alle Azure-services, zoals Azure Database for MySQL. Integreer alle gegevens met Azure Monitor-logboeken om end-to-end inzicht te bieden in uw toepassing en de platformservices.

Azure Log Analytics-werkruimte is de sink voor bewakingsgegevens waarmee logboeken en metrische gegevens van de Azure-resources en Application Insights worden verzameld. Deze logboekregistratieoplossing biedt zichtbaarheid, waardoor automatiseringsprocessen in realtime kunnen worden geschaald. Het analyseren van logboekgegevens kan ook inefficiëntie in toepassingscode onthullen die u kunt aanpakken om de kosten en prestaties te verbeteren.

Zie Toepassingen end-to-end bewaken met Dynatrace Java OneAgent voor specifieke spring-apps.

Geautomatiseerde implementatie

Automatiseer uw infrastructuurimplementatie en toepassingscode-implementaties zoveel mogelijk.

Het automatiseren van infrastructuurimplementaties garandeert dat de infrastructuurconfiguratie identiek is, wat helpt om configuratiedrift te voorkomen, mogelijk tussen omgevingen. U kunt infrastructuurautomatisering ook gebruiken om failoverbewerkingen te testen.

U kunt een blauwgroene of canary-implementatiestrategie gebruiken voor uw toepassingen.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

De volgende overwegingen bieden richtlijnen voor het implementeren van de pijlers van het Azure Well-Architected Framework in de context van deze architectuur.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Overzicht van de betrouwbaarheidspijler voor meer informatie.

Implementeer de volgende suggesties om een betrouwbaardere toepassing te maken:

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.

Implementeer de volgende suggesties om een veiligere toepassing te maken:

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

Voor deze architectuur verwacht u hogere kosten omdat u onderdelen in meerdere zones implementeert. In plaats van één exemplaar van Azure Spring Apps voert u twee of zelfs drie exemplaren uit. Er zijn echter geen extra kosten verbonden aan het inschakelen van zoneredundantie voor de service. Zie prijzen voor Azure Spring Apps voor meer informatie.

Houd rekening met de volgende implementatieopties om de kosten aan te pakken:

  • U kunt verschillende toepassingen en toepassingstypen implementeren in één exemplaar van Azure Spring Apps. Wanneer u meerdere toepassingen implementeert, worden de kosten van de onderliggende infrastructuur gedeeld tussen toepassingen.

  • Azure Spring Apps biedt ondersteuning voor automatisch schalen van toepassingen die worden geactiveerd door metrische gegevens of planningen, waardoor het gebruik en de kostenefficiëntie kunnen worden verbeterd.

  • U kunt Application Insights in Azure Monitor gebruiken om de operationele kosten te verlagen. Continue bewaking kan helpen om problemen sneller op te lossen en de kosten en prestaties te verbeteren.

  • Kies de beste prijscategorie op basis van uw vereisten:

  • Gebruik automatische schaalaanpassing voor toepassingen om omhoog en omlaag te schalen op basis van de vraag.

Zie de Azure-prijscalculator voor een geschatte kosten van services voor deze architectuur. Deze schatting maakt gebruik van redelijke standaardwaarden voor een kleinschalige toepassing. U kunt de schatting bijwerken op basis van de verwachte doorvoerwaarden voor uw toepassing.

Operationele uitmuntendheid

Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Zie Overzicht van de operationele uitmuntendheidpijler voor meer informatie.

Naast de eerder behandelde bewakingsrichtlijnen implementeert u de volgende suggesties om u te helpen uw toepassing te implementeren en te bewaken.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid om op efficiënte wijze uw werkbelasting te schalen om te voldoen aan de vereisten die gebruikers eraan stellen. Zie Overzicht van de pijler prestatie-efficiëntie voor meer informatie.

Implementeer de volgende suggesties om een efficiëntere toepassing te maken:

Dit scenario implementeren

Volg de stapsgewijze instructies in de referentiearchitectuur voor meerdere zones van Azure Spring Apps om deze architectuur te implementeren. De implementatie maakt gebruik van Terraform-sjablonen.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen