Compartir vía

Uso de Azure API Management en una solución multiinquilino

  • Artículo

Azure API Management es una puerta de enlace de API completa y un proxy inverso para las API. Proporciona muchas características, como el almacenamiento en caché, la simulación de respuesta y un portal para desarrolladores, que son útiles para las aplicaciones centradas en la API. En este artículo se resumen algunas de las características clave de API Management que son útiles para las soluciones multiinquilino.

Nota:

Este artículo se centra en cómo puede usar API Management cuando tiene sus propias aplicaciones multiinquilino que hospedan API para uso interno o externo.

Otra forma de multiinquilino es proporcionar la puerta de enlace de API Management como servicio a otros equipos. Por ejemplo, una organización podría tener una instancia compartida de API Management que varios equipos de aplicaciones implementan y usan. En este artículo no se describe esta forma de multiinquilino. Considere la posibilidad de usar áreas de trabajo, que le ayudan a compartir una instancia de API Management en varios equipos que podrían tener distintos niveles de acceso.

Modelos de aislamiento

API Management normalmente se implementa como un componente compartido con una sola instancia que atiende solicitudes para varios inquilinos. Sin embargo, en función del modelo de inquilino, hay muchas maneras de implementar API Management. En este artículo se supone que implementa la solución mediante stamps de implementación.

Normalmente, la forma en que se usa API Management es similar, independientemente del modelo de aislamiento. Esta sección se centra en las diferencias de coste y complejidad entre los modelos de aislamiento y cómo cada enfoque enruta las solicitudes a las aplicaciones de API de back-end.

Consideración Instancia compartida con back-ends de inquilino único Instancia compartida con back-end multiinquilino compartido Instancia de cada inquilino
Número de inquilinos admitidos Muchos Casi sin enlazar Una para cada instancia
Costos Inferior Inferior Superior
Complejidad de la implementación Baja: instancia única que se va a administrar para cada stamp Baja: instancia única que se va a administrar para cada stamp Alta: varias instancias para administrar
Complejidad de configuración de enrutamiento Mayor Menor Inferior
Susceptibilidad a los problemas de vecinos ruidosos Sí Sí No
Aislamiento de red de nivel de inquilino No No Sí
Escenario de ejemplo Nombres de dominio personalizados para cada inquilino Solución multiinquilino grande con un nivel de aplicación compartido Stamps de implementación específicos del inquilino

Modelos de aislamiento de instancias compartidas

Es habitual compartir una instancia de API Management entre varios inquilinos, lo que ayuda a reducir el coste y la complejidad de la implementación y la administración. Los detalles de cómo puede compartir una instancia de API Management dependen de cómo asignar inquilinos a aplicaciones de API back-end.

Aplicación back-end de un solo inquilino

Si implementa aplicaciones de back-end distintas para cada inquilino, puede implementar una sola instancia de API Management y enrutar el tráfico al back-end de inquilino correcto para cada solicitud. Este enfoque requiere que configure API Management con los nombres de host de back-end para cada inquilino o para tener otra manera de asignar una solicitud entrante al back-end del inquilino correcto.

Dado que requiere una búsqueda adicional, es posible que este enfoque no se escale a un gran número de inquilinos que comparten una sola instancia de API Management. También puede haber cierta sobrecarga de rendimiento al buscar el back-end del inquilino. Sin embargo, el tamaño de esta sobrecarga de rendimiento depende de cómo diseñe dicha búsqueda.

Aplicación de back-end multiinquilino compartida

En escenarios en los que los inquilinos comparten una aplicación de back-end común, el proceso de enrutamiento de API Management se simplifica porque puede enrutar todas las solicitudes a un único back-end. Si usa dominios comodín o dominios emitidos por el proveedor, es posible que pueda lograr una escala casi sin enlazar con este enfoque. Además, dado que las solicitudes no necesitan asignarse al back-end de un inquilino, no hay ningún impacto en el rendimiento de las decisiones de enrutamiento personalizadas.

Instancia de cada inquilino

En algunas situaciones, puede implementar una instancia de API Management para cada inquilino. Se recomienda este enfoque solo si tiene un pequeño número de inquilinos o si tiene requisitos de cumplimiento estrictos que le restrinjan el uso compartido de cualquier infraestructura entre inquilinos. Por ejemplo, si implementa una red virtual dedicada para cada inquilino, es probable que también tenga que implementar una instancia dedicada de API Management para cada inquilino.

Sugerencia

Si el único motivo para implementar varias instancias es admitir a los usuarios en diferentes regiones geográficas, es posible que quiera considerar si la característica de implementación de varias regiones de API Management cumple sus requisitos.

Al implementar una instancia de API Management, debe tener en cuenta los límites de servicio, incluidos los límites que se puedan aplicar al número de instancias de API Management dentro de una suscripción o región de Azure.

Las instancias de un solo inquilino suelen tener una configuración de enrutamiento mínima, ya que puede enrutar todas las solicitudes a un único back-end. Este escenario no requiere decisiones de enrutamiento personalizadas, por lo que no hay ningún impacto adicional en el rendimiento. Sin embargo, normalmente se incurre en un coste de recurso mayor que si implementa una instancia compartida. Si necesita implementar instancias de un solo inquilino, considere si las puertas de enlace autohospedadas le permiten reutilizar los recursos de proceso específicos del inquilino que ya implementó.

Características de API Management que admiten multiinquilino

API Management usa directivas para habilitar la flexibilidad. Puede personalizar cómo se validan, enrutan y procesan las solicitudes cuando se usan directivas. Y al diseñar una solución multiinquilino con API Management, se usan directivas para implementar muchas de sus funcionalidades.

Identificación de inquilinos en solicitudes entrantes

Tenga en cuenta cómo puede identificar el inquilino adecuado dentro de cada solicitud entrante. En una solución multiinquilino, es importante tener una comprensión clara de quién realiza cada solicitud para que devuelva los datos de ese inquilino específico y de nadie más.

API Management proporciona suscripciones que puede usar para autenticar solicitudes. Estas suscripciones usan una clave de suscripción única que ayuda a identificar al suscriptor que realiza la solicitud. Si decide usar suscripciones, considere cómo puede asignar las suscripciones de API Management a su propio inquilino o identificadores de cliente. Las suscripciones están estrechamente integradas en el portal para desarrolladores. Para la mayoría de las soluciones, se recomienda usar suscripciones para identificar inquilinos.

Como alternativa, puede identificar el inquilino mediante otros métodos. Estos son algunos ejemplos de enfoques que se ejecutan dentro de una directiva personalizada que defina:

  • Use un componente personalizado de la dirección URL, como un subdominio, una ruta de acceso o una cadena de consulta. Por ejemplo, en la dirección URL https://api.contoso.com/tenant1/products, puede extraer la primera parte de la ruta de acceso, tenant1, y tratarla como identificador de inquilino. Del mismo modo, dada la dirección URL https://tenant1.contoso.com/products entrante, puede extraer el subdominio, tenant1. Para usar este enfoque, considere la posibilidad de analizar la ruta de acceso o la cadena de consulta de la propiedad Context.Request.Url.

  • Use un encabezado de solicitud. Por ejemplo, las aplicaciones cliente pueden agregar un encabezado TenantID personalizado a las solicitudes. Para usar este enfoque, considere la posibilidad de leer desde la colección Context.Request.Headers.

  • Extraiga notificaciones de un token web JSON (JWT). Por ejemplo, puede tener una notificación tenantId personalizada en un JWT emitido por el proveedor de identidades. Para usar este enfoque, use la directiva validate-jwt y establezca la propiedad output-token-variable-name para que la definición de directiva pueda leer los valores del token.

  • Busque los identificadores de inquilino dinámicamente. Puede comunicarse con una base de datos o servicio externo mientras se procesa la solicitud. Al adoptar este enfoque, puede crear una lógica de asignación de inquilinos personalizada para asignar un identificador de inquilino lógico a una dirección URL específica o para obtener información adicional sobre un inquilino. Para usar este enfoque, use la directiva send-request.

    Es probable que este enfoque aumente la latencia de las solicitudes. Para mitigar este efecto, es recomendable usar el almacenamiento en caché para reducir el número de llamadas a la API externa. Puede usar las directivas cache-store-value y cache-lookup-value para implementar un enfoque de almacenamiento en caché. Asegúrese de invalidar la memoria caché con cada inquilino agregado, quitado o movido que afecte a la búsqueda de back-end.

Valores con nombre

API Management admite valores con nombre, que son valores de configuración personalizados que puede usar en todas las directivas. Por ejemplo, puede usar un valor con nombre para almacenar la dirección URL de back-end de un inquilino y, a continuación, reutilizar ese mismo valor en varios lugares dentro de las directivas. Si necesita actualizar la dirección URL, puede actualizarla en un solo lugar.

Advertencia

En una solución multiinquilino, es importante tener cuidado al establecer los nombres de los valores con nombre. Si la configuración varía entre inquilinos, asegúrese de incluir el identificador de inquilino en el nombre. Por ejemplo, puede usar un patrón como tenantId-key:value después de confirmar que tenantId es adecuado para la solicitud.

Incluya el identificador para reducir la posibilidad de hacer referencia accidentalmente a otro inquilino o manipularlo al hacer referencia al valor de otro inquilino al procesar una solicitud para otro inquilino.

Autenticación de solicitudes entrantes

Las solicitudes de API realizadas en la puerta de enlace de API Management normalmente deben autenticarse. API Management proporciona varios métodos para autenticar las solicitudes entrantes en la puerta de enlace, incluidos OAuth 2.0 y certificados de cliente. Tenga en cuenta los tipos de credenciales que debe admitir y dónde deben validarse. Por ejemplo, considere si la validación debe producirse en API Management, en las aplicaciones de back-end o en ambos lugares.

Para obtener más información, consulte Autenticación y autorización a las API en Azure API Management.

Nota:

Si usa una clave de suscripción o una clave de API, se recomienda usar también otro método de autenticación.

Una clave de suscripción por sí sola no es una forma segura de autenticación, pero es útil para otros escenarios, como el seguimiento del uso de la API de un inquilino individual.

Enrutamiento a back-ends específicos del inquilino

Al usar API Management como componente compartido, es posible que tenga que enrutar las solicitudes de API entrantes a distintos back-ends específicos del inquilino. Estos back-end pueden estar en diferentes stamps de implementación o pueden ser diferentes aplicaciones dentro de un único stamp. Para personalizar el enrutamiento en una definición de directiva, use la directiva set-backend-service. Debe especificar la nueva dirección URL base a la que se debe redirigir la solicitud.

Almacenamiento en caché de respuestas u otros datos

API Management tiene una eficaz característica de caché que puede usar para almacenar en caché respuestas HTTP completas o cualquier otro dato. Por ejemplo, puede usar la memoria caché para las asignaciones de inquilinos si usa lógica personalizada o si busca la asignación desde un servicio externo.

Use las directivas cache-store-value y cache-lookup-value para implementar un enfoque de almacenamiento en caché.

Advertencia

En una solución multiinquilino, es importante tener cuidado al establecer las claves de caché. Si los datos almacenados en caché pueden variar entre inquilinos, asegúrese de incluir el identificador de inquilino en la clave de caché.

Incluya el identificador para reducir la posibilidad de hacer referencia accidentalmente a otro inquilino o manipularlo al hacer referencia al valor de otro inquilino al procesar una solicitud para otro inquilino.

Dominios personalizados

Use API Management para configurar sus propios dominios personalizados para la puerta de enlace de API y el portal para desarrolladores. En algunos niveles, puede configurar dominios comodín o varios nombres de dominio completos (FQDN).

También puede usar API Management junto con un servicio como Azure Front Door. En este tipo de configuración, Azure Front Door controla con frecuencia los dominios personalizados y los certificados de seguridad de la capa de transporte (TLS) y se comunica con API Management mediante un único nombre de dominio. Si la dirección URL original del cliente incluye información de inquilino que necesita enviar a la instancia de API Management para su posterior procesamiento, considere la posibilidad de usar el encabezado de solicitud X-Forwarded-Host o use reglas de Azure Front Door para pasar la información como un encabezado HTTP.

Límites de frecuencia

Es habitual aplicar cuotas o límites de velocidad en una solución multiinquilino. Los límites de frecuencia pueden ayudarle a mitigar el problema de vecino ruidoso. También puede usar límites de velocidad para aplicar la calidad del servicio y para diferenciar entre diferentes planes de tarifa.

Use API Management para aplicar límites de velocidad específicos del inquilino. Si usa suscripciones específicas del inquilino, considere la posibilidad de usar la directiva de cuota para aplicar una cuota para cada suscripción. Como alternativa, considere la posibilidad de usar la directiva de cuota por clave para aplicar cuotas mediante cualquier otra clave de límite de velocidad, como un identificador de inquilino que obtuvo de la dirección URL de solicitud o un JWT.

Monetización

La documentación de API Management proporciona una amplia guía sobre la monetización de las API, incluida una implementación de ejemplo. Los enfoques de monetización combinan muchas de las características de API Management para que los desarrolladores puedan publicar una API, administrar suscripciones y cobrar en función de diferentes modelos de uso.

Administración de capacidades

Una instancia de API Management admite una determinada cantidad de capacidad, que representa los recursos disponibles para procesar las solicitudes. Cuando se usan directivas complejas o se implementan más API en la instancia, se consume más capacidad. Puede administrar la capacidad de una instancia de varias maneras, como comprar más unidades. También puede escalar dinámicamente la capacidad de la instancia.

Algunas instancias multiinquilino pueden consumir más capacidad que las instancias de un solo inquilino, como si usa muchas directivas para enrutar solicitudes a distintos back-end del inquilino. Considere cuidadosamente la planificación de la capacidad y prevea escalar la capacidad de su instancia si ve que su uso aumenta. También debe probar el rendimiento de la solución para comprender las necesidades de capacidad con antelación.

Para obtener más información sobre el escalado de API Management, consulte Actualización y escalado de una instancia de Azure API Management.

Implementaciones en varias regiones

API Management admite implementaciones de varias regiones, lo que significa que puede implementar un único recurso lógico de API Management en varias regiones de Azure sin necesidad de replicar su configuración en recursos independientes. Esta funcionalidad es especialmente útil al distribuir o replicar la solución globalmente. Puede implementar eficazmente una flota de instancias de API Management en varias regiones, lo que permite el procesamiento de solicitudes de baja latencia y administrarlas como una sola instancia lógica.

Sin embargo, si necesita instancias de API Management totalmente aisladas, también puede optar por implementar recursos independientes de API Management en diferentes regiones. Este enfoque separa el plano de administración de cada instancia de API Management.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

Otro colaborador:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Revise Enfoques de arquitectura para la integración en soluciones multiinquilino.