Deze referentiearchitectuur maakt gebruik van Azure Integration Services om aanroepen naar bedrijfsback-endsystemen te orkestreren. De back-endsystemen kunnen SaaS-systemen (Software as a Service), Azure-services en bestaande webservices in uw onderneming bevatten.
Azure Integration Services is een verzameling services voor het integreren van toepassingen en gegevens. Deze architectuur maakt gebruik van twee van deze services: Logic Apps om werkstromen te API Management catalogi van API's te maken. Deze architectuur is voldoende voor basisintegratiescenario's waarbij de werkstroom wordt geactiveerd door synchrone aanroepen naar back-upservices. Een meer geavanceerde architectuur met behulp van wachtrijen en gebeurtenissen is gebaseerd op deze basisarchitectuur.
Architectuur
De architectuur heeft de volgende onderdelen:
Back-endsystemen. Aan de rechterkant van het diagram ziet u de verschillende back-endsystemen die de onderneming heeft geïmplementeerd of gebruikt. Dit kunnen SaaS-systemen, andere Azure-services of webservices zijn die REST- of SOAP-eindpunten beschikbaar maken.
Azure Logic Apps. Logic Apps is een serverloos platform voor het bouwen van bedrijfswerkstromen die toepassingen, gegevens en services integreren. In deze architectuur worden de logische apps geactiveerd door HTTP-aanvragen. U kunt ook werkstromen nesten voor complexere orchestration. 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 is een beheerde service voor het publiceren van catalogi van HTTP-API's om hergebruik en vindbaarheid te bevorderen. API Management bestaat uit twee gerelateerde onderdelen:
API-gateway. De API-gateway accepteert HTTP-aanroepen en routeer deze 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.
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 vanuit WSDL-specificaties.
De API-gateway helpt bij het loskoppelen van front-end-clients van de back-end. Het kan bijvoorbeeld URL's herschrijven of aanvragen transformeren voordat ze de back-end bereiken. Er worden ook veel belangrijke zaken verwerkt, zoals verificatie, ONDERSTEUNING voor cross-origin resource sharing (CORS) en reactie in de caching.
Azure DNS. Azure DNS is een hostingservice voor DNS-domeinen. Azure DNS biedt naamresolutie met behulp van de Microsoft 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 voor uw andere Azure-services gebruikt. Als u een aangepaste domeinnaam wilt gebruiken, zoals contoso.com, maakt u DNS-records die de aangepaste domeinnaam aan het IP-adres toe te voegen. Zie Configure a custom domain name in API Management (Een aangepaste domeinnaam configureren in API Management).
Azure Active Directory (Azure AD). Gebruik Azure AD om clients te verifiëren die de API-gateway aanroepen. Azure AD ondersteunt het OpenID Verbinding maken (OIDC)-protocol. Clients verkrijgen een toegangs token van Azure AD en API Gateway valideert het token om de aanvraag te autoreren. Wanneer u de Standard- of Premium-laag van API Management, kan Azure AD ook de toegang tot de ontwikkelaarsportal beveiligen.
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-laag. Deze lagen bieden een SLA (Service Level Agreement) voor productie en bieden ondersteuning voor uitschalen binnen de Azure-regio. De doorvoercapaciteit voor API Management wordt gemeten in eenheden. Elke prijscategorie heeft een maximale scale-out. 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 en capaciteit van API Management Azure-API Management voor meer informatie.
Elke Azure API Management-instantie heeft een standaarddomeinnaam. Dit is een subdomein van azure-api.net , bijvoorbeeld contoso.azure-api.net . Overweeg 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 antwoord, zoals asynchrone of semi-langlopende API-aanroepen. Als lage latentie is vereist, bijvoorbeeld in een aanroep die een gebruikersinterface blokkeert, gebruikt u een andere technologie. Gebruik bijvoorbeeld een Azure Functions of een web-API die is geïmplementeerd voor Azure App Service. Gebruik API Management om de API te fronten voor uw API-consumenten.
Region
Als u de netwerklatentie wilt minimaliseren, API Management en Logic Apps in dezelfde regio. In het algemeen kiest u de regio die zich het dichtst bij uw gebruikers (of het dichtst bij uw back-endservices) ligt.
De resourcegroep heeft ook een regio. Deze regio geeft aan waar de metagegevens van de implementatie moeten worden opgeslagen en waar de implementatiesjabloon moet worden uitgevoerd. Plaats de resourcegroep en resources in dezelfde regio om de beschikbaarheid tijdens de implementatie te verbeteren.
Schaalbaarheidsoverwegingen
Als u de schaalbaarheid van de API Management, voegt u waar nodig cachingbeleid toe. Caching helpt ook de belasting van back-endservices te verminderen.
Als u meer capaciteit wilt bieden, kunt u Azure API Management Basic-, Standard- en Premium-lagen in een Azure-regio. Als u het gebruik voor uw service wilt analyseren, selecteert u in het menu Metrische gegevens de optie Metrische capaciteit en schaalt u vervolgens naar eigen goed vermogen 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 vluchtige verkeerspatronen hebben meer capaciteit nodig.
Een consistente capaciteit van meer dan 66% kan duiden op een behoefte om omhoog te schalen.
Een consistente capaciteit van minder dan 20% kan duiden op een mogelijkheid om omlaag te schalen.
Voordat u de belasting in productie inschakelen, laadt u altijd uw API Management service met een representatieve belasting.
Met de Premium laag kunt u een API Management in meerdere Azure-regio's schalen. Hierdoor komt API Management in aanmerking voor een hogere SLA en kunt u services inrichten in de buurt van gebruikers in meerdere regio's.
Het Logic Apps serverloos model betekent dat beheerders niet hoeven te plannen voor schaalbaarheid van de service. De service wordt automatisch geschaald om aan de vraag te voldoen.
Beschikbaarheidsoverwegingen
Controleer de SLA voor elke service:
Als u een API Management in twee of meer regio's met Premium-laag implementeert, komt deze in aanmerking voor een hogere SLA. Zie API Management prijzen.
Back-ups
Regelmatig een back-up maken van API Management configuratie. Sla uw back-upbestanden op een locatie of Azure-regio op die verschilt van de regio waarin de service is geïmplementeerd. Kies op basis van uw RTO een strategie voor herstel na noodherstel:
In een noodherstelgebeurtenis moet u een nieuw API Management inrichten, de back-up herstellen naar het nieuwe exemplaar en de DNS-records opnieuw richten.
Bewaar een passief exemplaar van de API Management service in een andere Azure-regio. Herstel regelmatig back-ups naar dat exemplaar om deze synchroon te houden met de actieve service. Als u de service wilt herstellen tijdens een noodherstelgebeurtenis, hoeft u alleen de DNS-records te herstellen. Deze aanpak kost extra kosten omdat u betaalt voor de passieve instantie, maar de hersteltijd wordt beperkt.
Voor logische apps raden we een configuration-as-code-benadering aan voor het maken van back-up en herstellen. Omdat logische apps serverloos zijn, kunt u ze snel opnieuw maken op basis van Azure Resource Manager sjablonen. Sla de sjablonen op in broncodebeheer en integreer de sjablonen met uw CI/CD-proces (continue integratie/continue implementatie). In een noodherstelgebeurtenis implementeert u de sjabloon in een nieuwe regio.
Als u een logische app implementeert in een andere regio, moet u de configuratie in API Management. U kunt de eigenschap Back-end van de API bijwerken met behulp van een powershell-basisscript.
DevOps overwegingen
Maak afzonderlijke resourcegroepen voor productie-, ontwikkelings- en testomgevingen. Met afzonderlijke resourcegroepen kunt u eenvoudiger implementaties beheren, testimplementaties verwijderen en toegangsrechten verlenen.
Wanneer u resources toewijst aan resourcegroepen, moet u rekening houden met de volgende factoren:
Levenscyclus. In het algemeen kunt u resources die dezelfde levenscyclus hebben het beste in dezelfde resourcegroep onderbrengen.
Toegang tot. 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 de rollupkosten voor de resourcegroep bekijken.
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 om de Azure-resources te implementeren en volg de infrastructuur als codeproces (IaC). Met sjablonen kunt u implementaties gemakkelijker automatiseren met behulp van Azure DevOps Servicesof andere CI/CD-oplossingen.
Faseren
Overweeg fasering van uw workloads, wat betekent dat u in verschillende fasen kunt implementeren en validaties in elke fase moet uitvoeren voordat u verder gaat met de volgende; Op die manier kunt u updates naar uw productieomgevingen pushen op een zeer gecontroleerde manier en onverwachte implementatieproblemen minimaliseren. Blue-green implementatie en Canary-releases zijn aanbevolen implementatiestrategieën voor het bijwerken van live productieomgevingen. Overweeg ook om een goede strategie voor terugdraaien te gebruiken wanneer een implementatie mislukt; U kunt bijvoorbeeld automatisch een eerdere, geslaagde implementatie uit uw implementatiegeschiedenis opnieuw implementeren. De vlagparameter --rollback-on-error in Azure CLI is een goed voorbeeld.
Isolatie van workloads
Plaats API Management en 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 ondersteunt twee verschillende, maar aanvullende versieconcepten:
Met versies kunnen API-consumenten een API-versie kiezen op basis van hun behoeften, bijvoorbeeld v1, v2, bèta of productie.
Met revisies kunnen API-beheerders niet-belangrijke wijzigingen aanbrengen in een API en deze wijzigingen implementeren, samen met een wijzigingslogboek om API-consumenten te informeren over de wijzigingen.
U kunt een revisie maken in een ontwikkelomgeving en die wijziging implementeren in andere omgevingen met behulp van Resource Manager sjablonen. Zie Publish multiple versions of your API (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 belastingstests of integratietests. Gebruik in plaats daarvan afzonderlijke test- of preproductieomgevingen.
Diagnose en controle
Gebruik Azure Monitor voor operationele bewaking in zowel API Management als 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 dashboards verzendt u Logic Apps logboeken naar Azure Log Analytics.
Voor DevOps-bewaking configureert u Azure-toepassing Insights voor API Management.
API Management ondersteunt de Power BI oplossingssjabloon voor aangepaste API-analyse. U kunt deze oplossingssjabloon gebruiken om uw eigen analyseoplossing te maken. Voor zakelijke gebruikers maakt Power BI rapporten beschikbaar.
Beveiligingsoverwegingen
Hoewel in deze lijst niet alle best practices 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 Logic Apps eindpunten tot alleen het IP-adres van API Management. Zie Inkomende IP-adressen beperken voor meer informatie.
Gebruik op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) om ervoor te zorgen dat gebruikers de juiste toegangsniveaus hebben.
Beveilig openbare API-eindpunten in API Management met behulp van OAuth- of OpenID-Verbinding maken. Als u openbare API-eindpunten wilt beveiligen, configureert u een id-provider en voegt u een JSON Web Token validatiebeleid (JWT) toe. Zie Een API beveiligen met OAuth 2.0met Azure Active Directory en API Management voor meer informatie.
Verbinding maken back-endservices van API Management met behulp van wederzijdse certificaten.
HTTPS afdwingen op 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 een logische app gevoelige waarden vereist die u niet binnen een connector kunt maken, kunt u deze waarden opslaan in Azure Key Vault en er vanuit een sjabloon naar Resource Manager verwijzen. Gebruik implementatiesjabloonparameters en parameterbestanden voor elke omgeving. Zie Beveiligde parameters en invoer binnen een werkstroom voor meer informatie.
API Management beheert geheimen met behulp van objecten die benoemde waarden of eigenschappen worden genoemd. Deze objecten worden veilig opgeslagen waarden die u kunt openen via API Management beleid. Zie How to use Named Values in Azure API Management policies (Benoemde waarden gebruiken in Azure-beleid) voor API Management informatie.
Kostenoverwegingen
Over het algemeen gebruikt u de Azure-prijscalculator om de kosten te schatten. Hier zijn enkele andere overwegingen.
API Management
Er worden kosten in rekening gebracht voor API Management exemplaren wanneer deze 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. De facturering wordt berekend op basis van de actie en de uitvoering van de connector. Zie prijzen voor Logic Apps meer informatie.
Raadpleeg de kostensectie in Microsoft Azure Well-Architected Framework voor meer informatie.
Volgende stappen
Voor een grotere betrouwbaarheid en schaalbaarheid gebruikt u berichtenwachtrijen en gebeurtenissen om de back-endsystemen los tekoppelen. Dit patroon wordt weergegeven in de volgende referentiearchitectuur in deze reeks: Enterprise-integratie met behulp van berichtenwachtrijen en gebeurtenissen.