management - panel azure login

Equilibrador de carga para Azure Service Fabric Cluster en las instalaciones

Question

Como desarrolladores, escribimos microservicios en Azure Service Fabric y podemos ejecutarlos en Azure en algún tipo de concepto PaaS para muchos clientes. Pero algunos de nuestros clientes no quieren correr en la nube, ya que las bases de datos son locales y no estarán disponibles desde el exterior, ni siquiera a través de una DMZ. Está bien, prometimos apoyarlo ya que Azure Service Fabric se puede instalar como un clúster local.

Tenemos un microservicio API-gateway ejecutándose dentro del clúster en cada máquina virtual, que usa el nombre de resolución, y las solicitudes se enrutan y distribuyen en consecuencia, pero la API que proporciona el microservicio API gateway es la entrada para otro software cliente que nuestro los clientes usan, ese software se ejecuta fuera del clúster y debe enviar solicitudes a la API.

Sugerí usar un Load Balancer como HA-Proxy o Nginx en una máquina separada (o máquinas) donde el software del cliente envía sus solicitudes y luego el proxy inverso lo reenvía a una máquina disponible dentro del clúster.

Parece que no es lo que quiere nuestro cliente, otra máquina como balanceador de carga no es una opción. Sugieren: hacer que el software del cliente sea más inteligente para descubrir a qué host ir, en otras palabras: debemos escribir nuestro propio balanceador de fallas / carga dentro del software del cliente.

¿Qué otras opciones tenemos?

• Instale la función del equilibrador de carga de red en cada una de las máquinas virtuales para darle al clúster una sola dirección IP, ¿esto es posible? Algo como https://www.poweradmin.com/blog/configuring-network-load-balancing-in-windows-server/

• Sugerir una puerta de enlace API fuera del clúster, como KONG https://getkong.org/

• Algo más ?

PD: las aplicaciones del cliente no envían muchas solicitudes por segundo, tal vez algunas por minuto.

Answer 1

Problema muy similar, tenemos muchos servicios y Service Fabric Cluster que se ejecuta en las instalaciones. Cuando llega el momento de utilizar el equilibrador de carga, instalamos IIS en la misma máquina donde se ejecuta el clúster Service Fabric. Como IIS es un buen equilibrador de carga, utilizamos IIS como proxy inverso solo para API Gateway. El alojamiento de Kestrel se usa para otros servicios que se comunican por HTTP. El microservicio gateway API es el único punto de entrada para todos los clientes y siempre tiene URI estático dentro de SF, usamos ese URI para configurar IIS

Si no tiene posibilidad de usar IIS, mire Usar nginx como equilibrador de carga HTTP

Answer 2

No necesita otra máquina solo para el reenvío HTTP. Solo use / ejecútelo como un servicio en el clúster.

¿Consideró usar el Proxy invertido de Service Fabric incorporado? Esto se ejecuta en todos los nodos y reenviará llamadas http a servicios dentro del clúster.

También puede ejecutar nginx como un ejecutable invitado o dentro de un contenedor en el clúster.

Answer 3

También hemos enfrentado la misma situación cuando comenzamos a trabajar con clúster de tejido de servicio. Configuramos Application Gateway como Proxy pero no proporcionaba la función como HTTP to HTTPS redirection.

Para eso, configuramos Nginx en lugar de Azure Application Gateway como Proxy to Service Fabric Application.