Información general de Service Fabric con Azure API Management

Las aplicaciones en la nube normalmente necesitan una puerta de enlace front-end para proporcionar un único punto de entrada para usuarios, dispositivos u otras aplicaciones. En Service Fabric, una puerta de enlace puede ser cualquier servicio sin estado como una aplicación ASP.NET Core u otro servicio designado para la entrada de tráfico, como Event Hubs, IoT Hub o Azure API Management.

Este artículo es una introducción al uso de Azure API Management como puerta de enlace para las aplicaciones de Service Fabric. API Management se integra directamente con Service Fabric, lo que le permite publicar API con un amplio conjunto de reglas de enrutamiento para los servicios back-end de Service Fabric.

Disponibilidad

Importante

Esta característica ya está disponible en los niveles Premium y Developer de API Management debido a la compatibilidad requerida con redes virtuales.

Architecture

Una arquitectura de Service Fabric común usa una aplicación web de una página que realiza llamadas HTTP a servicios back-end que exponen API HTTP. La aplicación de ejemplo de inicio de Service Fabric presenta una muestra de esta arquitectura.

En este escenario, un servicio web sin estado actúa como puerta de enlace en la aplicación de Service Fabric. Este enfoque precisa que escriba un servicio web que admita solicitudes HTTP proxy para servicios back-end, como se muestra en el siguiente diagrama:

A medida que aumenta la complejidad de las aplicaciones, también lo hacen las puertas de enlace que deben presentar una API delante de innumerables servicios back-end. Azure API Management se ha diseñado para controlar API complejas con reglas de enrutamiento, control de acceso, limitación de velocidad, supervisión, registro de eventos y almacenamiento en caché de respuestas con el mínimo esfuerzo por su parte. Azure API Management admite la selección de réplicas, la resolución de la partición y la detección de servicios de Service Fabric para enrutar de forma inteligente las solicitudes directamente a los servicios back-end en Service Fabric para que no tenga que escribir su propia puerta de enlace de API sin estado.

En este escenario, la interfaz de usuario web se sigue ofreciendo a través de un servicio web, mientras que las llamadas a la API HTTP se administran y se enrutan a través de Azure API Management, tal como se muestra en el siguiente diagrama:

Escenarios de aplicación

Los servicios de Service Fabric pueden ser con o sin estado, y pueden tener particiones con uno de los tres esquemas: singleton, intervalo de Int-64 y con nombre. La resolución del punto de conexión de servicio requiere identificar una partición específica de una instancia de servicio específica. Al resolver un punto de conexión de un servicio, deben especificarse el nombre de instancia de servicio (por ejemplo, fabric:/myapp/myservice) y la partición específica del servicio, salvo en el caso de la partición singleton.

Azure API Management puede usarse con cualquier combinación de servicios con o sin estado y cualquier esquema de partición.

Envío de tráfico a un servicio sin estado

En el caso más simple, el tráfico se reenvía a una instancia de servicio sin estado. Para lograr esto, una operación de API Management contiene una directiva de procesamiento de entrada con un back-end de Service Fabric que se asigna a una instancia de servicio sin estado específica en el back-end de Service Fabric. Las solicitudes destinadas a ese servicio se envían a una instancia aleatoria del servicio.

Ejemplo

En el siguiente escenario, una aplicación de Service Fabric contiene un servicio sin estado denominado fabric:/app/fooservice que expone una API HTTP interna. El nombre de instancia de servicio es conocido y puede estar codificado de forma rígida directamente en la directiva de procesamiento de entrada de API Management.

Envío de tráfico a un servicio con estado

De forma similar a lo que ocurría en el escenario del servicio sin estado, el tráfico se puede reenviar a una instancia de servicio con estado. En este caso, una operación de API Management contiene una directiva de procesamiento de entrada con un back-end de Service Fabric que asigna una solicitud a una partición específica de una instancia de servicio con estado específica. La partición para asignar cada solicitud se calcula a través de un método lambda con algunas entradas de la solicitud HTTP entrante, como un valor de la ruta de acceso de la dirección URL. La directiva puede configurarse para enviar solicitudes solo a la réplica principal o a una réplica aleatoria para operaciones de lectura.

Ejemplo

En el siguiente escenario, una aplicación de Service Fabric contiene un servicio con estado con partición denominado fabric:/app/userservice, que expone una API HTTP interna. El nombre de instancia de servicio es conocido y puede estar codificado de forma rígida directamente en la directiva de procesamiento de entrada de API Management.

Se realiza la partición del servicio mediante el esquema de partición Int-64 con dos particiones y un intervalo de claves que abarca de Int64.MinValue a Int64.MaxValue. La directiva de back-end calcula una clave de partición dentro de ese intervalo convirtiendo el valor id proporcionado en la ruta de acceso de solicitud de la dirección URL en un entero de 64 bits, aunque se puede utilizar aquí cualquier algoritmo para calcular la clave de partición.

Envío de tráfico a varios servicios sin estado

En escenarios más avanzados, puede definir una operación de API Management que asigne solicitudes a más de una instancia de servicio. En este caso, cada operación contiene una directiva que asigna solicitudes a una instancia de servicio determinada basándose en valores de la solicitud HTTP de entrada, como la cadena de consulta o la ruta de acceso de la dirección URL y, en el caso de servicios con estado, una partición dentro de la instancia de servicio.

Para lograr esto, una operación de API Management contiene una directiva de procesamiento de entrada con un back-end de Service Fabric que asigna una instancia de servicio sin estado en el back-end de Service Fabric basándose en los valores recuperados de la solicitud HTTP entrante. Las solicitudes a un servicio se envían a una instancia aleatoria del servicio.

Ejemplo

En este ejemplo, se crea una nueva instancia de servicio sin estado para cada usuario de una aplicación con un nombre generado de forma dinámica con la siguiente fórmula:

• fabric:/app/users/<username>

  Cada servicio tiene un nombre único, pero los nombres no se conocen por adelantado porque los servicios se crean en respuesta a la entrada del administrador o usuario y, por lo tanto, no se pueden codificar de forma rígida en las directivas APIM o las reglas de enrutamiento. En su lugar, se genera el nombre del servicio que se va a enviar una solicitud en la definición de la directiva de back-end del valor name proporcionado en la ruta de acceso de solicitud de la dirección URL. Por ejemplo:

  • Se enruta una solicitud para /api/users/foo a la instancia de servicio fabric:/app/users/foo
  • Se enruta una solicitud para /api/users/bar a la instancia de servicio fabric:/app/users/bar

Envío de tráfico a varios servicios con estado

De forma similar al ejemplo de servicio sin estado, una operación de API Management puede asignar solicitudes a más de una instancia de servicio con estado, en cuyo caso también podría tener que realizar una resolución de partición para cada instancia de servicio con estado.

Para lograr esto, una operación de API Management contiene una directiva de procesamiento de entrada con un back-end de Service Fabric que se asigna a una instancia de servicio con estado en el back-end de Service Fabric basándose en los valores recuperados de la solicitud HTTP entrante. Además de asignar una solicitud a la instancia de servicio específica, la solicitud también se puede asignar a una partición específica dentro de la instancia de servicio y, opcionalmente, a la réplica principal o a una réplica secundaria aleatoria dentro de la partición.

Ejemplo

En este ejemplo, se crea una nueva instancia de servicio con estado para cada usuario de la aplicación con un nombre generado de forma dinámica con la siguiente fórmula:

• fabric:/app/users/<username>

  Cada servicio tiene un nombre único, pero los nombres no se conocen por adelantado porque los servicios se crean en respuesta a la entrada del administrador o usuario y, por lo tanto, no se pueden codificar de forma rígida en las directivas APIM o las reglas de enrutamiento. En su lugar, se genera el nombre del servicio que se va a enviar una solicitud en la definición de la directiva de back-end del valor name proporcionado en la ruta de acceso de solicitud de la dirección URL. Por ejemplo:

  • Se enruta una solicitud para /api/users/foo a la instancia de servicio fabric:/app/users/foo
  • Se enruta una solicitud para /api/users/bar a la instancia de servicio fabric:/app/users/bar

Se realiza también la partición de cada instancia de servicio mediante el esquema de partición Int-64 con dos particiones y un intervalo de claves que abarca de Int64.MinValue a Int64.MaxValue. La directiva de back-end calcula una clave de partición dentro de ese intervalo convirtiendo el valor id proporcionado en la ruta de acceso de solicitud de la dirección URL en un entero de 64 bits, aunque se puede utilizar aquí cualquier algoritmo para calcular la clave de partición.

Pasos siguientes

Siga el tutorial para configurar el primer clúster de Service Fabric con API Management y enviar solicitudes mediante API Management a sus servicios.