Presentamos la arquitectura de referencia de microservicios de NGINX

Chris Stetson

Nota del autor – Esta entrada de blog es la primera de una serie:

1. Presentación de la arquitectura de referencia de microservicios de NGINX (esta publicación)
2. MRA, parte 2: el modelo de proxy
3. MRA, parte 3: el modelo de malla de routers
4. MRA, parte 4: El modelo de tejido
5. MRA, parte 5: Adaptación de la aplicación de doce factores a los microservicios
6. MRA, parte 6: Implementación del patrón Circuit Breaker con NGINX Plus

Los seis artículos, junto con otro sobre frontends web para aplicaciones de microservicios<.htmla>, se han recopilado en un ebook gratuito.

Consulta también estos otros recursos de NGINX sobre microservicios:

• Una serie muy útil y popular de Chris Richardson sobre el diseño de aplicaciones de microservicios
• Los artículos de Chris Richardson recopilados en un ebook gratuito, con consejos adicionales sobre cómo implementar microservicios con NGINX y NGINX Plus
• Otras publicaciones del blog sobre microservicios
• Webinarios sobre microservicios
• Página de soluciones de microservicios
• Tema: Microservicios

Introducción

NGINX ha estado involucrado en el movimiento de los microservicios desde sus inicios. Su ligereza, alto rendimiento y flexibilidad hacen que NGINX sea una solución ideal para los microservicios.

La imagen de Docker de NGINX es la imagen de aplicación más descargada en Docker Hub, y la mayoría de las plataformas de microservicios disponibles actualmente en la Web incluyen una demostración que implementa NGINX de alguna forma y se conecta a la página de bienvenida.

Como creemos que la transición a los microservicios es crucial para el éxito de nuestros clientes, en NGINX hemos puesto en marcha un programa específico para desarrollar funcionalidades y prácticas que respalden este cambio radical en el desarrollo y la entrega de aplicaciones web. También reconocemos que existen muchos enfoques diferentes para implementar microservicios, muchos de ellos novedosos y adaptados a las necesidades específicas de cada equipo de desarrollo. Creemos que se necesitan modelos que faciliten a las empresas el desarrollo y la entrega de sus propias aplicaciones basadas en microservicios.

Teniendo todo esto en cuenta, en NGINX Professional Services estamos desarrollando la Arquitectura de Referencia de Microservicios de NGINX (MRA), un conjunto de modelos que puede utilizar para crear sus propias aplicaciones de microservicios.

La MRA consta de dos componentes: una descripción detallada de cada uno de los tres modelos y código descargable que implementa Ingenious, nuestro programa de ejemplo para compartir fotos. La única diferencia entre los tres modelos es el código de configuración utilizado para configurar NGINX Plus en cada uno de ellos. Esta serie de entradas de blog ofrecerá una descripción general de cada modelo; las descripciones detalladas, el código de configuración y el código del programa de ejemplo Ingenious estarán disponibles más adelante este año.

Nuestro objetivo al crear esta arquitectura de referencia es triple:

• Proporcionar a los clientes y al sector modelos listos para usar con los que crear sistemas basados en microservicios, agilizando y mejorando el desarrollo
• Crear una plataforma para probar nuevas funcionalidades de NGINX y NGINX Plus, tanto si se desarrollan interna como externamente y se distribuyen en el núcleo del producto o como módulos dinámicos
• Ayudarnos a comprender los sistemas y componentes de nuestros socios para obtener una visión integral del ecosistema de microservicios

La arquitectura de referencia de microservicios también es una parte importante de las ofertas de servicios profesionales para los clientes de NGINX. En la MRA, utilizamos funcionalidades comunes tanto a NGINX Open Source como a NGINX Plus siempre que es posible, y funcionalidades específicas de NGINX Plus cuando es necesario. Las dependencias de NGINX Plus son mayores en los modelos más complejos, como se describe a continuación. Prevemos que muchos usuarios de la MRA se beneficiarán del acceso a los servicios profesionales de NGINX y al soporte técnico incluido con una suscripción a NGINX Plus.

Descripción general de la arquitectura de referencia de microservicios

Estamos desarrollando la arquitectura de referencia de acuerdo con los principios de la aplicación de doce factores. Los servicios están diseñados para ser ligeros, efímeros y sin estado.

La MRA utiliza componentes estándar del sector, como contenedores Docker, una amplia variedad de lenguajes —Java, PHP, Python, NodeJS/JavaScript y Ruby— y redes basadas en NGINX.

Uno de los mayores cambios en el diseño y la arquitectura de aplicaciones al adoptar microservicios es el uso de la red para la comunicación entre los componentes funcionales de la aplicación. En las aplicaciones monolíticas, los componentes se comunican en memoria. En una aplicación de microservicios, esa comunicación se realiza a través de la red, por lo que el diseño y la implementación de la red adquieren una importancia crítica.

Para reflejarlo, la MRA se ha implementado utilizando tres modelos de red diferentes, todos ellos basados en NGINX o NGINX Plus. Estos modelos van desde uno relativamente sencillo hasta otros más complejos y con más funcionalidades:

• Modelo de proxy – Un modelo de red sencillo adecuado para implementar NGINX Plus como controlador o puerta de enlace de API para una aplicación de microservicios. Este modelo se basa en Docker Cloud.
• Modelo de malla de enrutadores – Un enfoque de red más robusto, con un equilibrador de carga en cada host y gestión de las conexiones entre sistemas. Este modelo es similar a la arquitectura de Deis 1.0.
• Modelo Fabric – La joya de la corona de la MRA, el modelo Fabric incorpora NGINX Plus en cada contenedor para gestionar todo el tráfico entrante y saliente. Funciona bien en sistemas con mucha carga y admite SSL/TLS en todos los niveles, mientras que NGINX Plus ofrece una latencia reducida, conexiones SSL/TLS persistentes, descubrimiento de servicios y el patrón de disyuntor en todos los microservicios.

Nuestra intención es que utilice estos modelos como punto de partida para sus propias implementaciones de microservicios. Agradecemos sus comentarios sobre cómo mejorar la MRA. (Puede empezar escribiendo en la sección de comentarios que aparece a continuación).

A continuación se ofrece una breve descripción de cada modelo. Le recomendamos que lea todas las descripciones para empezar a hacerse una idea de cómo podría sacar el máximo partido a uno o varios de los modelos. En futuras entradas del blog se describirá cada modelo en detalle, uno por entrada.

Resumen del modelo proxy

El modelo de proxy es un modelo de red relativamente sencillo. Es un excelente punto de partida para una primera aplicación de microservicios o un buen modelo objetivo al convertir una aplicación monolítica heredada de complejidad moderada.

En el modelo de proxy, NGINX o NGINX Plus actúa como controlador de entrada y dirige las solicitudes a los microservicios. NGINX Plus puede utilizar DNS dinámico para la detección de servicios a medida que se crean nuevos servicios. El modelo de proxy también puede utilizarse como plantilla cuando se usa NGINX como puerta de enlace de API.

Si se necesita comunicación entre servicios —como ocurre en la mayoría de las aplicaciones con cierto nivel de complejidad—, el registro de servicios proporciona el mecanismo necesario dentro del clúster. (Consulte esta entrada del blog para ver una lista detallada de los mecanismos de comunicación entre servicios.) Docker Cloud utiliza este enfoque de forma predeterminada; para conectarse a otro servicio, un servicio consulta el DNS y obtiene una dirección IP a la que enviar una solicitud.

En general, el modelo de proxy resulta adecuado para aplicaciones sencillas o de complejidad moderada. No es el enfoque ni el modelo más eficiente para el equilibrio de carga, especialmente a gran escala; si sus requisitos de equilibrio de carga son elevados, utilice uno de los modelos que se describen a continuación. («Escala» puede referirse tanto a un gran número de microservicios como a volúmenes de tráfico elevados).

Editor: Para un análisis exhaustivo de este modelo, consulte «MRA, parte 2: El modelo proxy».

El salto al modelo de malla de routers

El modelo de malla de enrutadores presenta una complejidad moderada y resulta idóneo para diseñar aplicaciones nuevas y robustas, así como para transformar aplicaciones monolíticas heredadas más complejas que no necesitan las capacidades del modelo de tejido.

El modelo Router Mesh adopta un enfoque de red más sólido que el modelo Proxy, ya que ejecuta un equilibrador de carga en cada host y gestiona activamente las conexiones entre microservicios. La principal ventaja del modelo Router Mesh es un equilibrio de carga entre servicios más eficiente y sólido. Si utiliza NGINX Plus, puede implementar comprobaciones de estado activas para supervisar las instancias individuales de los servicios y reducir gradualmente el tráfico cuando se retiran.

Deis Workflow utiliza un enfoque similar al modelo de malla de enrutadores para dirigir el tráfico entre servicios, con instancias de NGINX ejecutándose en un contenedor en cada host. A medida que se ponen en marcha nuevas instancias de aplicaciones, un proceso extrae la información de los servicios del registro de servicios etcd y la carga en NGINX. NGINX Plus también puede funcionar en este modo, utilizando varias ubicaciones y sus correspondientes grupos de servidores upstream.

Nota del editor: Para obtener un análisis exhaustivo de este modelo, consulte «MRA, parte 3: El modelo de malla de enrutadores».

Y, por último, el modelo Fabric, con SSL/TLS opcional

En NGINX, el modelo Fabric es el que más nos entusiasma. Hace realidad algunas de las promesas más interesantes de los microservicios, como un alto rendimiento, flexibilidad en el balanceo de carga y SSL/TLS omnipresente hasta el nivel de cada microservicio. El modelo Fabric es adecuado para aplicaciones seguras y puede escalar para admitir aplicaciones de gran tamaño.

En el modelo Fabric, NGINX Plus se implementa dentro de cada contenedor y actúa como proxy para todo el tráfico HTTP que entra y sale de los contenedores. Las aplicaciones se conectan a una dirección localhost para todas las conexiones de servicio y confían en NGINX Plus para realizar la detección de servicios, el balanceo de carga y las comprobaciones de estado.

En nuestra configuración, NGINX Plus consulta ZooKeeper para obtener todas las instancias de los servicios a los que la aplicación necesita conectarse. Por ejemplo, si el intervalo de consulta de DNS, valid, se establece en 1 segundo, NGINX Plus comprueba cada segundo si hay cambios en las instancias de ZooKeeper y enruta el tráfico según corresponda.

Gracias a la potente capacidad de procesamiento HTTP de NGINX Plus, podemos usar conexiones persistentes para mantener conexiones con estado a los microservicios, lo que reduce la latencia y mejora el rendimiento. Esta función resulta especialmente útil cuando se utiliza SSL/TLS para proteger el tráfico entre los microservicios.

Por último, utilizamos las comprobaciones de estado activas de NGINX Plus para dirigir el tráfico a las instancias en buen estado e incorporar, en esencia, el patrón de disyuntor sin coste adicional.

Editor: Para un análisis en profundidad de este modelo, consulte «MRA, parte 4: El modelo de tejido».

Una ingeniosa aplicación de demostración para la MRA

La MRA incluye una aplicación de ejemplo a modo de demostración: Ingenious, una aplicación para compartir fotos. Ingenious está implementada en cada uno de los tres modelos: Proxy, Router Mesh y Fabric. La aplicación de demostración Ingenious se pondrá a disposición del público a finales de este año.

Ingenious es una versión simplificada de una aplicación para almacenar y compartir fotos, al estilo de Flickr o Shutterfly. Elegimos una aplicación para compartir fotos por varios motivos:

• Tanto los usuarios como los desarrolladores pueden entender fácilmente lo que hace.
• Hay múltiples dimensiones de datos que gestionar.
• Es fácil incorporar un diseño atractivo en la aplicación.
• Proporciona requisitos de computación asimétricos —una combinación de procesamiento de alta y baja intensidad—, lo que permite realizar pruebas realistas de las funciones de conmutación por error, escalado y supervisión en distintos tipos de funcionalidades.

Conclusión

La arquitectura de referencia de microservicios de NGINX supone un avance apasionante tanto para nosotros como para los clientes y socios con los que la hemos compartido hasta la fecha. Durante los próximos meses publicaremos una serie de artículos en el blog en los que la describiremos en detalle, y estará disponible a finales de este año. También hablaremos de ella en profundidad en nginx.conf 2016, del 7 al 9 de septiembre en Austin, Texas. Envíenos sus comentarios; esperamos verle allí.

Mientras tanto, pruebe usted mismo la MRA con NGINX Plus: inicie hoy mismo su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso.

Sobre el autor

Chris Stetson

Más artículos de Chris Stetson