Deze referentiearchitectuur maakt gebruik van Azure Integration Services voor het organiseren van aanroepen naar back-endsystemen voor ondernemingen. De back-endsystemen kunnen SaaS-systemen (Software as a Service), Azure-services en bestaande webservices in uw onderneming bevatten.
Architectuur
Een Visio-bestand van deze architectuur downloaden.
Workflow
Back-endsystemen. Aan de rechterkant van het diagram ziet u de verschillende back-endsystemen die door de onderneming zijn geïmplementeerd of waarvan de onderneming afhankelijk is. Deze systemen kunnen SaaS-systemen, andere Azure-services of webservices zijn die REST- of SOAP-eindpunten beschikbaar maken.
Azure Logic Apps. In deze architectuur worden logische apps geactiveerd door HTTP-aanvragen. U kunt ook werkstromen nesten voor complexere indeling. Logic Apps maakt gebruik van connectors om te integreren met veelgebruikte services. Logic Apps biedt honderden connectors en u kunt aangepaste connectors maken.
Azure API Management. API Management bestaat uit twee gerelateerde onderdelen:
API-gateway. De API-gateway accepteert HTTP-aanroepen en stuurt deze door naar de back-end.
Ontwikkelaarsportal. Elk exemplaar van Azure API Management biedt toegang tot een ontwikkelaarsportal. Deze portal biedt uw ontwikkelaars toegang tot documentatie en codevoorbeelden voor het aanroepen van de API's. U kunt ook API's testen in de ontwikkelaarsportal.
Azure DNS. Azure DNS biedt naamomzetting door gebruik te maken van de Azure-infrastructuur. Door uw domeinen in Azure te hosten, kunt u uw DNS-records beheren met dezelfde referenties, API's, hulpprogramma's en facturering die u gebruikt voor uw andere Azure-services. Als u een aangepaste domeinnaam wilt gebruiken, zoals contoso.com, maakt u DNS-records die de aangepaste domeinnaam toewijzen aan het IP-adres. Zie Een aangepaste domeinnaam configureren in API Management voor meer informatie.
Microsoft Entra-id. Gebruik Microsoft Entra ID om clients te verifiëren die de API-gateway aanroepen. Microsoft Entra ID ondersteunt het OpenID Connect-protocol (OIDC). Clients verkrijgen een toegangstoken van Microsoft Entra ID en API Gateway valideert het token om de aanvraag te autoriseren. Als u de Standard- of Premium-laag van API Management gebruikt, kan Microsoft Entra ID ook helpen bij het beveiligen van de toegang tot de ontwikkelaarsportal.
Onderdelen
- Integration Services is een verzameling services die u kunt gebruiken om toepassingen, gegevens en processen te integreren.
- Logic Apps is een serverloos platform voor het bouwen van bedrijfswerkstromen die toepassingen, gegevens en services integreren.
- API Management is een beheerde service voor het publiceren van catalogi van HTTP-API's. U kunt deze gebruiken om het hergebruik en de detectie van uw API's te bevorderen en een API-gateway te implementeren voor proxy-API-aanvragen.
- Azure DNS is een hostingservice voor DNS-domeinen.
- Microsoft Entra ID is een cloudservice voor identiteits- en toegangsbeheer. Ondernemingsmedewerkers kunnen Microsoft Entra-id gebruiken voor toegang tot externe en interne resources.
Scenariodetails
Integration Services is een verzameling services die u kunt gebruiken om toepassingen, gegevens en processen voor uw bedrijf te integreren. Deze architectuur maakt gebruik van twee van deze services: Logic Apps voor het organiseren van werkstromen en API Management voor het maken van catalogi van API's.
In deze architectuur worden samengestelde API's gebouwd door logische apps als API's te importeren. U kunt ook bestaande webservices importeren door OpenAPI-specificaties (Swagger) te importeren of SOAP-API's te importeren uit WSDL-specificaties.
De API-gateway helpt bij het loskoppelen van front-endclients van de back-end. Het kan bijvoorbeeld URL's herschrijven of aanvragen transformeren voordat ze de back-end bereiken. Het verwerkt ook veel geavanceerde problemen, zoals verificatie, CORS-ondersteuning (Cross-Origin Resource Sharing) en caching van reacties.
Potentiële gebruikscases
Deze architectuur is voldoende voor basisintegratiescenario's waarin de werkstroom wordt geactiveerd door synchrone aanroepen naar back-endservices. Een geavanceerdere architectuur met behulp van wachtrijen en gebeurtenissen bouwt voort op deze basisarchitectuur.
Aanbevelingen
Uw specifieke vereisten kunnen afwijken van de algemene architectuur die hier wordt weergegeven. Gebruik de aanbevelingen in deze sectie als uitgangspunt.
API Management
Gebruik de API Management Basic-, Standard- of Premium-lagen. Deze lagen bieden een SLA (Production Service Level Agreement) en bieden ondersteuning voor uitschalen binnen de Azure-regio. Doorvoercapaciteit voor API Management wordt gemeten in eenheden. Elke prijscategorie heeft een maximale uitschaling. De Premium-laag biedt ook ondersteuning voor uitschalen in meerdere Azure-regio's. Kies uw laag op basis van uw functieset en het niveau van de vereiste doorvoer. Zie prijzen voor API Management en capaciteit van een Azure API Management-exemplaar voor meer informatie.
Elk Azure API Management-exemplaar heeft een standaarddomeinnaam, een subdomein van azure-api.netbijvoorbeeld contoso.azure-api.net. Overweeg om een aangepast domein voor uw organisatie te configureren.
Logic Apps
Logic Apps werkt het beste in scenario's waarvoor geen lage latentie is vereist voor een reactie, zoals asynchrone of semi langlopende API-aanroepen. Als lage latentie vereist is, bijvoorbeeld in een aanroep die een gebruikersinterface blokkeert, gebruikt u een andere technologie. Gebruik bijvoorbeeld Azure Functions of een web-API die is geïmplementeerd in Azure-app Service. Gebruik API Management om de API aan uw API-gebruikers te koppelen.
Regio
Als u de netwerklatentie wilt minimaliseren, plaatst u API Management en Logic Apps in dezelfde regio. Kies in het algemeen de regio die zich het dichtst bij uw gebruikers bevindt (of het dichtst bij uw back-endservices).
Overwegingen
Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die u kunt gebruiken om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.
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.
Controleer de SLA voor elke service:
Als u API Management implementeert in twee of meer regio's met een Premium-laag, komt deze in aanmerking voor een hogere SLA. Zie prijzen voor API Management.
Back-ups
Maak regelmatig een back-up van uw API Management-configuratie. Sla uw back-upbestanden op in een locatie of Azure-regio die verschilt van de regio waarin de service wordt geïmplementeerd. Kies op basis van uw RTO een strategie voor herstel na noodgevallen:
Richt in een noodherstel gebeurtenis een nieuw API Management-exemplaar in, herstel de back-up naar het nieuwe exemplaar en wijs de DNS-records opnieuw aan.
Behoud een passief exemplaar van de API Management-service in een andere Azure-regio. Herstel regelmatig back-ups naar dat exemplaar om deze gesynchroniseerd te houden met de actieve service. Als u de service wilt herstellen tijdens een gebeurtenis voor herstel na noodgevallen, hoeft u alleen de DNS-records opnieuw te laten aanwijzen. Bij deze aanpak worden extra kosten in rekening gebracht omdat u betaalt voor de passieve instantie, maar het vermindert de hersteltijd.
Voor logische apps raden we een configuratie-as-code-benadering aan voor het maken van back-ups en het herstellen van back-ups. Omdat logische apps serverloos zijn, kunt u deze snel opnieuw maken vanuit Azure Resource Manager-sjablonen. Sla de sjablonen op in broncodebeheer, integreer de sjablonen met uw CI/CD-proces (continue integratie/continue implementatie). Implementeer de sjabloon in een gebeurtenis voor herstel na noodgevallen in een nieuwe regio.
Als u een logische app in een andere regio implementeert, werkt u de configuratie bij in API Management. U kunt de back-endeigenschap van de API bijwerken met behulp van een eenvoudig PowerShell-script.
Beveiliging
Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.
Hoewel in deze lijst niet alle aanbevolen procedures voor beveiliging volledig worden beschreven, zijn hier enkele beveiligingsoverwegingen die specifiek van toepassing zijn op deze architectuur:
De Azure API Management-service heeft een vast openbaar IP-adres. Beperk de toegang voor het aanroepen van Logic Apps-eindpunten tot alleen het IP-adres van API Management. Zie Binnenkomende IP-adressen beperken voor meer informatie.
Als u ervoor wilt zorgen dat gebruikers over de juiste toegangsniveaus beschikken, gebruikt u op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC).
Beveilig openbare API-eindpunten in API Management met behulp van OAuth of OpenID Connect. Als u openbare API-eindpunten wilt beveiligen, configureert u een id-provider en voegt u een JSON-validatiebeleid (Web Token) toe. Zie Een API beveiligen met OAuth 2.0 met Microsoft Entra ID en API Management voor meer informatie.
Maak verbinding met back-endservices vanuit API Management met behulp van wederzijdse certificaten.
HTTPS afdwingen op de API Management-API's.
Geheimen opslaan
Schakel wachtwoorden, toegangstoetsen of verbindingsreeksen nooit in broncodebeheer in. Als deze waarden vereist zijn, moet u deze waarden beveiligen en implementeren met behulp van de juiste technieken.
Als voor een logische app gevoelige waarden zijn vereist die u niet binnen een connector kunt maken, slaat u deze waarden op in Azure Key Vault en verwijst u ernaar vanuit een Resource Manager-sjabloon. Gebruik parameters en parameterbestanden voor implementatiesjablonen voor elke omgeving. Zie Beveiligde parameters en invoer in een werkstroom voor meer informatie.
API Management beheert geheimen met behulp van objecten die benoemde waarden of eigenschappen worden genoemd. Deze objecten slaan veilig waarden op waartoe u toegang hebt via API Management-beleid. Zie Benoemde waarden gebruiken in Azure API Management-beleid voor meer informatie.
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.
DevOps
Maak afzonderlijke resourcegroepen voor productie-, ontwikkelings- en testomgevingen. Met afzonderlijke resourcegroepen kunt u eenvoudiger implementaties beheren, testimplementaties verwijderen en toegangsrechten verlenen.
Houd rekening met de volgende factoren wanneer u resources toewijst aan resourcegroepen:
Levenscyclus. In het algemeen kunt u resources die dezelfde levenscyclus hebben het beste in dezelfde resourcegroep onderbrengen.
Toegang. Als u toegangsbeleid wilt toepassen op de resources in een groep, kunt u op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruiken.
Facturering. U kunt samengetelde kosten voor de resourcegroep weergeven.
Prijscategorie voor API Management. Gebruik de Developer-laag voor ontwikkel- en test omgevingen. Als u de kosten tijdens de preproductie wilt minimaliseren, implementeert u een replica van uw productie-omgeving, voert u uw tests uit en sluit u deze af.
Implementatie
Gebruik Azure Resource Manager-sjablonen om de Azure-resources te implementeren. Volg het proces infrastructuur als code (IaC). Met sjablonen kunt u eenvoudiger implementaties automatiseren met behulp van Azure DevOps Services of andere CI/CD-oplossingen.
Staging
Overweeg de fasering van uw workloads, wat betekent dat u in verschillende fasen implementeert en validaties uitvoert in elke fase voordat u verdergaat met de volgende fase. Als u deze aanpak gebruikt, kunt u updates naar uw productieomgevingen pushen op een zeer gecontroleerde manier en onverwachte implementatieproblemen minimaliseren. Blauwgroene implementatie en Canary-releases worden aanbevolen implementatiestrategieën voor het bijwerken van live productieomgevingen. Overweeg ook een goede terugdraaistrategie te hebben voor wanneer een implementatie mislukt. U kunt bijvoorbeeld automatisch een eerdere, geslaagde implementatie opnieuw implementeren vanuit uw implementatiegeschiedenis. De --rollback-on-error vlagparameter in Azure CLI is een goed voorbeeld.
Isolatie van workloads
Plaats API Management en eventuele afzonderlijke logische apps in hun eigen afzonderlijke Resource Manager-sjablonen. Met behulp van afzonderlijke sjablonen kunt u de resources opslaan in broncodebeheersystemen. U kunt de sjablonen samen of afzonderlijk implementeren als onderdeel van een CI/CD-proces.
Versies
Telkens wanneer u de configuratie van een logische app wijzigt of een update implementeert via een Resource Manager-sjabloon, bewaart Azure een kopie van die versie en bewaart alle versies met een uitvoeringsgeschiedenis. U kunt deze versies gebruiken om historische wijzigingen bij te houden of een versie te promoveren als de huidige configuratie van de logische app. U kunt bijvoorbeeld een logische app terugdraaien naar een eerdere versie.
API Management biedt ondersteuning voor twee afzonderlijke, maar aanvullende versiebeheerconcepten:
Met versies kunnen API-gebruikers een API-versie kiezen op basis van hun behoeften, bijvoorbeeld v1, v2, bèta of productie.
Met revisies kunnen API-beheerders vaste wijzigingen aanbrengen in een API en deze wijzigingen implementeren, samen met een wijzigingslogboek om API-gebruikers te informeren over de wijzigingen.
U kunt een revisie aanbrengen in een ontwikkelomgeving en deze wijziging implementeren in andere omgevingen met behulp van Resource Manager-sjablonen. Zie Meerdere versies van uw API publiceren voor meer informatie
U kunt ook revisies gebruiken om een API te testen voordat u de wijzigingen actueel en toegankelijk maakt voor gebruikers. Deze methode wordt echter niet aanbevolen voor belastingtests of integratietests. Gebruik in plaats daarvan afzonderlijke test- of preproductieomgevingen.
Diagnose en controle
Gebruik Azure Monitor voor operationele bewaking in API Management en Logic Apps. Azure Monitor biedt informatie op basis van de metrische gegevens die voor elke service zijn geconfigureerd en is standaard ingeschakeld. Zie voor meer informatie:
- Gepubliceerde API's bewaken
- Status controleren, diagnostische logboekregistratie instellen, en waarschuwingen inschakelen voor Azure Logic Apps
Elke service heeft ook de volgende opties:
Voor uitgebreidere analyse en dashboarding verzendt u Logic Apps-logboeken naar Azure Log Analytics.
Configureer voor DevOps-bewaking Azure-toepassing Insights voor API Management.
API Management ondersteunt de Power BI-oplossingssjabloon voor aangepaste API-analyses. U kunt deze oplossingssjabloon gebruiken voor het maken van uw eigen analyseoplossing. Voor zakelijke gebruikers maakt Power BI rapporten beschikbaar.
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.
Als u de schaalbaarheid van API Management wilt vergroten, voegt u waar nodig cachebeleid toe. Caching helpt ook om de belasting van back-endservices te verminderen.
Als u meer capaciteit wilt bieden, kunt u Azure API Management Basic-, Standard- en Premium-lagen uitschalen in een Azure-regio. Als u het gebruik van uw service wilt analyseren, selecteert u Capaciteitsmetrie in het menu Metrische gegevens en schaalt u vervolgens naar wens omhoog of omlaag. Het kan 15 tot 45 minuten duren voordat het upgrade- of schaalproces is toegepast.
Aanbevelingen voor het schalen van een API Management-service:
Houd rekening met verkeerspatronen bij het schalen. Klanten met meer vluchtige verkeerspatronen hebben meer capaciteit nodig.
Consistente capaciteit die groter is dan 66% kan duiden op een noodzaak om omhoog te schalen.
Consistente capaciteit die minder dan 20% is, kan duiden op een mogelijkheid om omlaag te schalen.
Voordat u de belasting in productie inschakelt, moet u uw API Management-service altijd laden met een representatieve belasting.
Met de Premium-laag kunt u een API Management-exemplaar schalen in meerdere Azure-regio's. Hierdoor komt API Management in aanmerking voor een hogere SLA en kunt u services in de buurt van gebruikers in meerdere regio's inrichten.
Het serverloze Logic Apps-model betekent dat beheerders geen schaalbaarheid van de service hoeven te plannen. De service wordt automatisch geschaald om aan de vraag te voldoen.
Kostenoptimalisatie
Gebruik in ieder geval de prijscalculator om een schatting van de kosten te maken. Hier volgen enkele andere overwegingen.
API Management
Er worden kosten in rekening gebracht voor alle API Management-exemplaren wanneer ze worden uitgevoerd. Als u omhoog hebt geschaald en dit prestatieniveau niet altijd nodig hebt, schaalt u handmatig omlaag of configureert u automatisch schalen.
Logic Apps
Logic Apps maakt gebruik van een serverloos model. Facturering wordt berekend op basis van actie en connectoruitvoering. Zie Prijzen voor Logic Apps voor meer informatie.
Raadpleeg de kostensectie in Microsoft Azure Well-Architected Framework voor meer informatie.
Volgende stappen
Verwante resources
Voor een grotere betrouwbaarheid en schaalbaarheid gebruikt u berichtenwachtrijen en gebeurtenissen om de back-endsystemen los te koppelen. Deze architectuur wordt weergegeven in het volgende artikel in deze reeks:
Mogelijk bent u ook geïnteresseerd in deze artikelen van het Azure Architecture Center: