Partage via

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

Gestion des API expose une propriété de disjoncteur dans la ressource back-end pour protéger un service back-end d’une submersion par trop de requêtes.

  • 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 Gestion des API myAPIM, se déclenche lorsqu’il existe trois codes d’état 5xx (ou plus) indiquant des erreurs de serveur en une heure.

Le disjoncteur se réinitialise après une heure. Si un en-tête Retry-After est présent dans la réponse, le disjoncteur accepte la valeur et attend l’heure spécifiée avant l’envoi de nouvelles requêtes au back-end.

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-09-01-preview' = {
  name: 'myAPIM/myBackend'
  properties: {
    url: 'https://mybackend.com'
    protocol: 'https'
    circuitBreaker: {
      rules: [
        {
          failureCondition: {
            count: 3
            errorReasons: [
              'Server errors'
            ]
            interval: 'PT1H' 
            statusCodeRanges: [
              {
                min: 500
                max: 599
              }
            ]
          }
          name: 'myBreakerRule'
          tripDuration: 'PT1H'  
          acceptRetryAfter: true
        }
      ]
    }
   }
 }

Pool à équilibrage de charge

Gestion des API prend en charge les pools back-ends, lorsque vous souhaitez implémenter plusieurs back-ends pour une API et équilibrer la charge des requêtes entre ces back-ends.

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. Vous pouvez inclure jusqu’à 30 back-ends par pool.
  • 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.

Options d’équilibrage de charge

Gestion des API prend en charge les options d’équilibrage de charge suivantes pour les pools back-end :

  • Tourniquet : par défaut, les requêtes sont distribuées uniformément entre les back-ends du pool.
  • Pondéré : les pondérations sont affectées aux back-ends du pool et les requêtes sont réparties sur les back-ends en fonction du poids relatif attribué à chaque back-end. Utilisez cette option pour des scénarios comme l’exécution d’un déploiement bleu-vert.
  • Basé sur la priorité : les back-ends sont organisés en groupes de priorité et les requêtes sont envoyées aux back-ends dans l’ordre des groupes de priorité. Au sein d’un groupe de priorité, les requêtes sont distribuées uniformément entre les back-ends, ou (si elles sont affectées) en fonction du poids relatif de chaque back-end.

Remarque

Les back-ends dans les groupes de priorité inférieure ne sont utilisés que lorsque tous les back-ends des groupes de priorité supérieure ne sont pas disponibles, car les règles de disjoncteur sont triplées.

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. Les deux back-ends se trouvent dans le groupe de priorité le plus élevé. Au sein du groupe, backend-1 a un poids supérieur à 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-09-01-preview' = {
  name: 'myAPIM/myBackendPool'
  properties: {
    description: 'Load balancer for multiple backends'
    type: 'Pool'
    pool: {
      services: [
        {
          id: '/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ApiManagement/service/<APIManagementName>/backends/backend-1'
          priority: 1
          weight: 3
        }
        {
          id: '/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ApiManagement/service/<APIManagementName>/backends/backend-2'
          priority: 1
          weight: 1
        }
      ]
    }
  }
}

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