Serveurs principaux dans Gestion des API

  • Article

S’APPLIQUE À : Tous les niveaux de Gestion des API

Un service principal (ou API back-end) dans Gestion des API est un service HTTP qui implémente votre API frontale et ses opérations.

Lors de l’importation de certaines API, Gestion des API configure automatiquement l’API back-end. Par exemple, le service Gestion des API configure le service web back-end lors de l’importation :

La Gestion des API prend également en charge l’utilisation d’autres ressources Azure, comme un back-end d’API, par exemple :

Avantages des serveurs principaux

La Gestion des API prend en charge les entités de back-end personnalisés afin que vous puissiez gérer les services back-end de votre API. Une entité back-end encapsule des informations sur le service back-end, favorisant la réutilisation entre les API et améliorant la gouvernance.

Utilisez des back-ends pour une ou plusieurs des actions suivantes :

  • Autoriser les informations d’identification des requêtes au service back-end
  • Utilisez la fonctionnalité de Gestion des API pour gérer les secrets dans Azure Key Vault si des valeurs nommées sont configurées pour l’authentification de paramètre de requête ou d’en-tête.
  • Définir des règles de disjoncteur pour protéger votre back-end contre un trop grand nombre de requêtes
  • Acheminer ou équilibrer la charge des requêtes vers plusieurs back-ends

Configurez et gérez les entités back-end personnalisés dans le Portail Azure, ou bien à l’aide d’API ou d’outils Azure.

Référencer le back-end à l’aide de la stratégie set-backend-service

Une fois le back-end créé, vous pouvez le référencer dans vos API. Utilisez la stratégie set-backend-service pour diriger une requête d’API entrante vers le back-end. Si vous avez déjà configuré un service web principal pour une API, vous pouvez utiliser la stratégie set-backend-service pour rediriger la requête vers une entité back-end à la place. Par exemple :

<policies>
    <inbound>
        <base />
        <set-backend-service backend-id="myBackend" />
    </inbound>
    [...]
<policies/>

Vous pouvez utiliser la logique conditionnelle avec la stratégie set-backend-service pour modifier le back-end effectif en fonction de l’emplacement, de la passerelle appelée ou d’autres expressions.

Par exemple, voici une stratégie permettant d’acheminer le trafic vers un autre back-end en fonction de la passerelle appelée :

<policies>
    <inbound>
        <base />
        <choose>
            <when condition="@(context.Deployment.Gateway.Id == "factory-gateway")">
                <set-backend-service backend-id="backend-on-prem" />
            </when>
            <when condition="@(context.Deployment.Gateway.IsManaged == false)">
                <set-backend-service backend-id="self-hosted-backend" />
            </when>
            <otherwise />
        </choose>
    </inbound>
    [...]
<policies/>

Disjoncteur (préversion)

À compter de la version de l’API2023-03-01, la gestion des API expose une propriété de disjoncteur dans la ressource back-end pour protéger un service back-end d’être submergé par trop de demandes.

  • La propriété disjoncteur définit des règles pour effectuer le déclenchement du disjoncteur, telles que le nombre ou le pourcentage de conditions d’échec pendant un intervalle de temps défini et une plage d’état des codes qui indiquent des défaillances.
  • Lorsque le disjoncteur se déclenche, la gestion des API arrête d’envoyer des requêtes au service back-end pendant une durée définie et retourne une réponse 503 Service Indisponible au client.
  • Après la durée du trajet configurée, le circuit se réinitialise et le trafic reprend vers le back-end.

Le disjoncteur du back-end est une implémentation du modèle de disjoncteur pour permettre au back-end de se rétablir après des situations de surcharge. Il augmente les stratégies générales de limitation de débit et de limitation de concurrence que vous pouvez implémenter pour protéger la passerelle de la gestion des API et de vos services back-end.

Remarque

  • Actuellement, le disjoncteur de back-end n’est pas pris en charge au niveau Consommation de la Gestion des API.
  • En raison de la nature distribuée de l’architecture de la Gestion des API, les règles de déclenchement du disjoncteur sont approximatives. Différentes instances de la passerelle ne se synchronisent pas et appliquent des règles de disjoncteur en fonction des informations sur la même instance.

Exemple

Utilisez la Gestion des API API REST ou un modèle Bicep ou ARM pour configurer un disjoncteur dans un back-end. Dans l’exemple suivant, le disjoncteur dans myBackend dans l’instance de Gestion des API myAPIM se déclenche lorsqu’il existe trois codes d’état 5xx ou plus indiquant les erreurs de serveur dans une journée. Le disjoncteur se réinitialise après une heure.

Incluez un extrait de code similaire à ce qui suit dans votre modèle Bicep pour une ressource back-end avec un disjoncteur :

resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-03-01-preview' = {
  name: 'myAPIM/myBackend'
  properties: {
    url: 'https://mybackend.com'
    protocol: 'https'
    circuitBreaker: {
      rules: [
        {
          failureCondition: {
            count: 3
            errorReasons: [
              'Server errors'
            ]
            interval: 'P1D'
            statusCodeRanges: [
              {
                min: 500
                max: 599
              }
            ]
          }
          name: 'myBreakerRule'
          tripDuration: 'PT1H'
        }
      ]
    }
   }
 }

Pool à charge équilibrée (préversion)

À compter de la préversion de l’API version 2023-05-01, la Gestion des API prend en charge les pools de back-ends, lorsque vous souhaitez implémenter plusieurs back-ends pour une API et équilibrer la charge des requêtes entre ces back-ends. Actuellement, le pool de back-ends prend en charge l’équilibrage de charge round-robin.

Utilisez un pool de back-ends pour des scénarios tels que les suivants :

  • Répartir la charge sur plusieurs back-ends, ce qui peut avoir des disjoncteurs de back-end individuels.
  • Déplacer la charge d’un ensemble de back-ends vers un autre pour la mise à niveau (déploiement bleu-vert).

Pour créer un pool de back-ends, définissez la propriété type du back-end sur pool et spécifiez une liste de back-ends qui composent le pool.

Remarque

  • Actuellement, vous ne pouvez inclure que des back-ends uniques dans un pool de back-ends. Vous ne pouvez pas ajouter un back-end de type pool à un autre pool de back-ends.
  • En raison de la nature distribuée de l’architecture de Gestion des API, l’équilibrage de charge de back-end est approximatif. Différentes instances de la passerelle ne se synchronisent pas et équilibrent la charge en fonction des informations sur la même instance.

Exemple

Utilisez l’API REST de Gestion des API ou un modèle Bicep ou ARM pour configurer un pool de back-ends. Dans l’exemple suivant, le serveur principal myBackendPool dans l’instance de Gestion des API myAPIM est configuré avec un pool principal. Les exemples de back-end du pool sont nommés backend-1 et backend-2.

Incluez un extrait de code similaire à ce qui suit dans votre modèle Bicep pour une ressource back-end avec un pool à charge équilibrée :

resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-05-01-preview' = {
  name: 'myAPIM/myBackendPool'
  properties: {
    description: 'Load balancer for multiple backends'
    type: 'Pool'
    protocol: 'http'
    url: 'https://example.com'
    pool: {
      services: [
        {
          id: '/backends/backend-1'
        }
        {
          id: '/backends/backend-2'
        }
      ]
    }
  }
}

Limitation

Pour les niveaux Développeur et Premium, une instance Gestion des API déployée dans un réseau virtuel interne peut générer des erreurs HTTP 500 BackendConnectionFailure quand l’URL du point de terminaison de passerelle et l’URL du back-end sont identiques. Si vous rencontrez cette limitation, suivez les instructions fournies dans l’article Limitation des demandes de la Gestion des API autochaînées en mode réseau virtuel interne du blog de la communauté technique.

Contenu connexe