azure-service-fabric - tutorial - service fabric sdk tools

Patrón de gateway/proxy API para microservicios implementados con Azure Service Fabric (7)

Después de ver los videos de la conferencia BUILD para Azure Service Fabric, me imagino cómo podría ser una buena opción para nuestra arquitectura actual basada en micro servicios. Sin embargo, hay una cosa que no estoy del todo seguro de cómo resolvería: el gateway / proxy API.

Considere una arquitectura de microservicio menos que trivial donde tiene N número de servicios ejecutándose dentro de Azure Service Fabric que expone los puntos finales REST. En muchas situaciones, desea empaquetar estos puntos finales API fragmentados en una API de entrada única para que los consumidores los utilicen, para evitar que se conecten directamente a las instancias de Fabric de servicio. La solución de Azure Service Fabric parece tan completa en todos los aspectos que me pregunto si me olvidé de algo obvio cuando no veo una manera de resolver trivialmente esto dentro de las capacidades mencionadas durante las conversaciones BUILD.

Los servicios como Vulcan tienen como objetivo resolver este problema haciendo que los servicios registren las rutas que quieren enrutar en ellos, etcd Supongo que una forma de resolver esto puede ser crear un servicio web independiente con el que otros servicios puedan registrarse, proporcionando el nombre del servicio y las rutas que necesitan enrutar a ellos. El servicio web con estado puede enrutar el tráfico a la instancia correcta en función de su estado. Sin embargo, esto no parece del todo ideal, con cosas como eliminar rutas cuando se eliminan aplicaciones y, en general, mantener el estado sincronizado con los servicios implementados dentro del clúster. ¿Alguien ha pensado en esto, o tiene alguna idea de cómo resolver esto dentro de Azure Service Fabric?

Azure Service Fabric hace que sea fácil implementar la arquitectura estándar para este escenario: un servicio de puerta de enlace como interfaz para que los clientes se conecten y todos los servicios de N backend que se comunican con la puerta de enlace frontal. Hay algunas pilas API de comunicación disponibles como parte de Service Fabric que facilitan la comunicación de los clientes a los servicios y dentro de los mismos servicios. Las pilas API de comunicación proporcionadas por Service Fabric ocultan los detalles de descubrir, conectar y reintentar conexiones para que pueda centrarse en el intercambio real de información. Al utilizar las API de comunicación de Service Fabric, los servicios no tienen que implementar el mecanismo de registrar sus nombres y puntos finales en un servicio de enrutamiento específico, excepto cuáles son los pasos habituales como parte de la creación del servicio. Las API de comunicación toman el URI del servicio y la clave de la partición y automáticamente resuelven y se conectan a la instancia de servicio correcta. Este artículo proporciona un buen punto de partida para tomar una decisión con respecto a qué API de comunicación serán las más adecuadas para su caso particular, dependiendo de si está utilizando Reliable Actors o Reliable Services, o protocolos como HTTP o WCF, o la elección de El lenguaje de programación en el que están escritos los servicios. Al final del artículo encontrará enlaces a artículos y tutoriales más detallados para diferentes API de comunicación. Para obtener un tutorial sobre comunicación en servicios de API web, vea this .

Cuando se inicia un servicio, registra su punto final con el servicio de nombres de tela. Al usar las API del cliente de Fabric, puede solicitar a fabric los puntos finales registrados, asociados con el nombre del servicio registrado.

Entonces sí, tal como describió su caso, tendría una puerta de enlace que aceptaría un URI entrante para la conexión, y luego usaría esa información de ruta como la búsqueda del nombre del servicio, para luego crear una conexión proxy entre la solicitud entrante y la interna real ubicación del punto final.

Parece que el equipo publicó una de las muestras que muestra cómo hacerlo: https://github.com/Azure/servicefabric-samples/tree/master/samples/Services/VS2015/WordCount

El registro / descubrimiento del servicio que necesita para hacer esto ya está allí. Hay un servicio de sistema con estado llamado Servicio de denominación, que básicamente es un registrador de instancias de servicio y los puntos finales que están escuchando. Por lo tanto, cuando inicia un servicio, ya sea sin estado o con estado, y abre algún oyente en él, la dirección se registra con el Servicio de nombres.

Ahora la parte que debe completar es la "puerta de enlace" con la que los usuarios interactúan. Esto no tiene que ser con estado porque el Servicio de nombres administra la parte con estado. Pero tendrías que idear un esquema de direcciones que funcione para ti, y luego solo reenviaría las solicitudes al lugar correcto. Básicamente algo como esto:

Recibir solicitud
Use NS para encontrar el servicio que puede tomar la solicitud.
Reenviar la solicitud y la respuesta al usuario.
Si el servicio ya no existe, 404.

En general, no nos gusta dictar nada sobre cómo sus servicios se comunican entre sí, pero estamos pensando en formas de solucionar este problema para HTTP como una solución integrada completa.

Esta característica está incorporada para los puntos finales http, comenzando con la versión 5.0 de la estructura del servicio. La documentación está disponible en https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reverseproxy/

Hemos utilizado un proyecto de código abierto llamado Traefik con un éxito increíble. Existe un envoltorio de Azure Service Fabri c en su interior; se trata esencialmente de un exe GoLang que se implementa en el clúster como Managed Executable.

Es compatible con los interruptores de circuito, el enrutamiento ponderado de LB robin, ruta y encabezado de la versión del encabezado (esto es increíble para alojar múltiples versiones de API), la lista continúa. Y tiene un portal útil para ver las estadísticas de configuración y estado.

El verdadero poder radica en cómo lo configuras. Se realiza a través del servicio en ServiceManifest.xml . Esto le permite implementar nuevos servicios y hacer que puedan enrutarse inmediatamente, sin necesidad de actualizar una tabla de enrutamiento, etc.

Ejemplo

<StatelessServiceType ServiceTypeName="WebServiceType"> <Extensions> <Extension Name="Traefik"> <Labels xmlns="http://schemas.microsoft.com/2015/03/fabact-no-schema"> <Label Key="traefik.frontend.rule.example">PathPrefixStrip: /a/path/to/strip</Label> <Label Key="traefik.enable">true</Label> <Label Key="traefik.frontend.passHostHeader">true</Label> </Labels> </Extension> </Extensions> </StatelessServiceType>

¡Muy recomendable!

Implementamos un servicio de puerta de enlace HTTP para este propósito también. Para garantizar que podamos tener una puerta de enlace HTTP para cualquier protocolo interno, implementamos la puerta de enlace para servicios internos basados en HTTP (como ASP.NET WebAPI) utilizando un middleware ASP.NET 5. Enruta las solicitudes desde, por ejemplo, / servicio a una dirección interna de Service Fabric como fabric: / myapp / myservice utilizando ServicePartitionClient y alguna lógica de reintento desde CommunicationClientFactoryBase .

Abrimos este middleware y lo puede encontrar aquí: https://github.com/c3-ls/ServiceFabric-HttpServiceGateway

También hay más documentación en la wiki del proyecto.

Me pregunto en lugar de exponer los servicios de Rest at N +, usar la pila de comunicación predeterminada en todas partes dentro del tejido del servicio (o tanto como sea posible para mantener la simplicidad interna). Exponga REST solo en los puntos de entrada del borde en la tela. Use una api web apátrida sin estado 2.x que envuelva a los representantes del tejido de sus servicios y actores, y / o use un servicio de tela exponiendo el descanso de la misma manera. Agregue su apis según sea necesario en los servicios de descanso orientados hacia adelante. No estoy seguro de haber visto aún la necesidad de una sobrecarga adicional de un agregador para nombrar la redirección (tal vez me esté perdiendo la idea). Entonces, parecería simplemente un ejercicio para organizar (y asegurar) los puntos finales de descanso con un espacio de nombre deseado (es decir, patrón de fachada).