Presentación de la arquitectura de referencia de microservicios de NGINX

Nota del autor : Esta publicación 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 proxy
3. MRA, Parte 3: El modelo de malla del enrutador
4. MRA, Parte 4: El modelo de tela
5. MRA, Parte 5: Adaptación de la aplicación de doce factores para microservicios
6. MRA, Parte 6: Implementación del patrón de disyuntor con NGINX Plus

Los seis blogs, además de un blog sobre interfaces web para aplicações de microservicios <.htmla>, se han recopilado en un libro electrónico gratuito .

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

• Una serie muy útil y popular de Chris Richardson sobre el diseño de aplicação de microservicios.
• Los artículos de Chris Richardson recopilados en un libro electrónico gratuito , con consejos adicionales sobre la implementación de microservicios con NGINX y NGINX Plus
• Otras publicaciones del blog sobre microservicios
• Seminarios web sobre microservicios
• Página de soluciones de microservicios
• Tema: Microservicios

INTRODUCCIÓN

NGINX ha estado involucrado en el movimiento de microservicios desde el principio. La naturaleza liviana, de alto rendimiento y flexible de NGINX es ideal para los microservicios.

La imagen Docker de NGINX es la imagen de aplicação número uno descargada en Docker Hub, y la mayoría de las plataformas de microservicios que encuentra en la Web hoy en día incluyen una demostración que implementa NGINX de alguna forma y se conecta a la página de bienvenida.

Porque creemos que migrar a microservicios es crucial para el éxito de nuestros clientes, en NGINX hemos lanzado un programa dedicado a desarrollar características y prácticas que respalden este cambio radical en el desarrollo y la entrega de aplicação web. También reconocemos que existen muchos enfoques diferentes para implementar microservicios, muchos de ellos novedosos y específicos para las necesidades de los equipos de desarrollo individuales. Creemos que existe una necesidad de modelos que faciliten a las empresas el desarrollo y la entrega de sus propias aplicações basadas en microservicios.

Con todo esto en mente, aquí en NGINX Professional Services estamos desarrollando la Arquitectura de Referencia de Microservicios (MRA) de NGINX: un conjunto de modelos que puede utilizar para crear sus propias aplicações de microservicios.

El MRA se compone de dos componentes: una descripción detallada de cada uno de los tres modelos, además de un código descargable que implementa nuestro programa de ejemplo para compartir fotografías, Ingenious. La única diferencia entre los tres modelos es el código de configuración que se utiliza para configurar NGINX Plus para cada uno de ellos. Esta serie de publicaciones de blog proporcionará descripciones generales de cada uno de los modelos; las descripciones detalladas, el código de configuración y el código para el programa de muestra Ingenious estarán disponibles más adelante este año.

Nuestro objetivo al construir esta Arquitectura de Referencia es triple:

• Proporcionar a los clientes y a la industria modelos listos para usar para construir sistemas basados en microservicios, acelerando y mejorando el desarrollo.
• Crear una plataforma para probar nuevas funciones en NGINX y NGINX Plus, ya sea desarrolladas interna o externamente y distribuidas en el núcleo del producto o como módulos dinámicos
• Para ayudarnos a comprender los sistemas y componentes de los socios para que podamos obtener una perspectiva holística 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 el MRA, utilizamos características comunes a NGINX Open Source y NGINX Plus cuando es posible, y características específicas de NGINX Plus cuando es necesario. Las dependencias de NGINX Plus son más fuertes en los modelos más complejos, como se describe a continuación. Anticipamos que muchos usuarios de MRA se beneficiarán del acceso a los servicios profesionales y al soporte técnico de NGINX, que viene con una suscripción a NGINX Plus.

Una descripción general de la arquitectura de referencia de microservicios

Estamos desarrollando la Arquitectura de Referencia para que cumpla con los principios de la Aplicación de Doce Factores . Los servicios están diseñados para ser ligeros, efímeros y sin estado.

MRA utiliza componentes estándar de la industria como contenedores Docker, una amplia gama 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 las aplicação al pasar a los microservicios es el uso de la red para comunicarse entre los componentes funcionales de la aplicação. En las aplicaciones monolíticas, los componentes de la aplicação se comunican en la 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 se vuelven de vital importancia.

Para reflejar esto, el MRA se ha implementado utilizando tres modelos de red diferentes, todos los cuales utilizan NGINX o NGINX Plus. Van desde los relativamente simples hasta los más complejos y con más funciones:

• Modelo de proxy : un modelo de red simple adecuado para implementar NGINX Plus como controlador o puerta de enlace API para una aplicação de microservicios. Este modelo está construido sobre Docker Cloud.
• Modelo de malla de enrutador : un enfoque más sólido para la red, con un equilibrador de carga en cada host y administración de las conexiones entre sistemas. Este modelo es similar a la arquitectura de Deis 1.0 .
• Modelo Fabric : la joya de la corona del MRA, el modelo Fabric presenta NGINX Plus en cada contenedor, manejando todo el tráfico de entrada y salida. Funciona bien para sistemas de alta carga y admite SSL/TLS en todos los niveles, y NGINX Plus proporciona latencia reducida, conexiones SSL/TLS persistentes, descubrimiento de servicios y 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 y agradecemos sus comentarios sobre cómo mejorar el MRA. (Puedes comenzar agregando en los comentarios a continuación).

A continuación se presenta una breve descripción de cada modelo; le sugerimos leer todas las descripciones para comenzar a tener una idea de cómo puede utilizar mejor uno o más de los modelos. En futuras publicaciones del blog se describirá cada uno de los modelos en detalle, uno por publicación.

El modelo proxy en breve

El modelo Proxy es un modelo de red relativamente simple. Es un excelente punto de partida para una aplicação de microservicios inicial, o como modelo objetivo para convertir una aplicación heredada monolítica moderadamente compleja.

En el modelo proxy, NGINX o NGINX Plus actúa como un controlador de ingreso, enrutando solicitudes a microservicios. NGINX Plus puede usar DNS dinámico para el descubrimiento de servicios a medida que se crean nuevos servicios. El modelo Proxy también es adecuado para usarse como plantilla cuando se utiliza NGINX como puerta de enlace API .

Si se necesita comunicación entre servicios (y es así en la mayoría de las aplicações de cualquier nivel de complejidad), el registro de servicios proporciona el mecanismo dentro del clúster. (Consulte esta entrada del blog para obtener 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 para enviar una solicitud.

En general, el modelo Proxy es viable para aplicações simples a moderadamente complejas. No es el enfoque/modelo más eficiente para el balanceo de carga, especialmente a escala; utilice uno de los modelos descritos a continuación si tiene requisitos de balanceo de carga elevados. (El término "escala" puede referirse a una gran cantidad de microservicios, así como a un alto volumen de tráfico).

Editor – Para una exploración en profundidad de este modelo, véase MRA, Parte 2 – El modelo Proxy .

Avanzando hacia el modelo de malla de enrutador

El modelo de malla de enrutador es moderadamente complejo y es una buena opción para nuevos diseños de aplicação robustas y también para convertir aplicaciones heredadas más complejas y monolíticas que no necesitan las capacidades del modelo de estructura.

El modelo de malla de enrutador adopta un enfoque de red más sólido que el modelo de proxy, al ejecutar un balanceador de carga en cada host y administrar activamente las conexiones entre microservicios. El beneficio clave del modelo Router Mesh es un equilibrio de carga más eficiente y sólido entre servicios. Si usa NGINX Plus, puede implementar controles de estado activos para monitorear las instancias de servicio individuales y regular el tráfico de manera elegante cuando se desactivan.

Deis Workflow utiliza un enfoque similar al modelo de malla de enrutador para enrutar el tráfico entre servicios, con instancias de NGINX ejecutándose en un contenedor en cada host. A medida que se crean nuevas instancias de la aplicación, un proceso extrae información del registro de servicios etcd y la carga en NGINX. NGINX Plus también puede funcionar en este modo, utilizando diversas ubicaciones y sus correspondientes upstreams.

Editor: para una exploración en profundidad de este modelo, consulte MRA, Parte 3: El modelo de malla de enrutador .

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

Aquí en NGINX estamos muy entusiasmados con el modelo Fabric. Hace realidad algunas de las promesas más interesantes de los microservicios, entre las que se incluyen alto rendimiento, flexibilidad en el equilibrio de carga y SSL/TLS ubicuo hasta el nivel de microservicios individuales. El modelo Fabric es adecuado para aplicações seguras y escalable para aplicações muy grandes.

En el modelo Fabric, NGINX Plus se implementa dentro de cada contenedor y se convierte en el proxy para todo el tráfico HTTP que entra y sale de los contenedores. Las aplicações se comunican con una ubicación de host local para todas las conexiones de servicio y confían en NGINX Plus para realizar el descubrimiento de servicios, el equilibrio de carga y la verificación del estado.

En nuestra configuración, NGINX Plus consulta a ZooKeeper para todas las instancias de los servicios a los que la aplicación necesita conectarse. Con la configuración de frecuencia de DNS válida establecida en 1 segundo, por ejemplo, NGINX Plus escanea ZooKeeper en busca de cambios de instancia cada segundo y enruta el tráfico de manera adecuada.

Gracias al potente procesamiento HTTP en NGINX Plus, podemos usar keepalives para mantener conexiones con estado a microservicios, lo que reduce la latencia y mejora el rendimiento. Esta es una característica especialmente valiosa cuando se utiliza SSL/TLS para proteger el tráfico entre los microservicios.

Por último, utilizamos los controles de estado activo de NGINX Plus para administrar el tráfico hacia instancias en buen estado y, esencialmente, incorporamos el patrón de disyuntor de forma gratuita.

Editor: Para una exploración en profundidad de este modelo, consulte MRA, Parte 4 – El modelo de tejido .

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

El MRA incluye una aplicação de muestra como demostración: la aplicación para compartir fotos Ingenious. Ingenious se implementa en cada uno de los tres modelos: Proxy, Router Mesh y Fabric. La aplicación de demostración Ingenious se lanzará al público a finales de este año.

Ingenious es una versión simplificada de una aplicação para almacenar y compartir fotografías, como Flickr o Shutterfly. Elegimos una aplicação para compartir fotos por algunas razones:

• Es fácil tanto para los usuarios como para los desarrolladores comprender lo que hace.
• Hay múltiples dimensiones de datos que gestionar.
• Es fácil incorporar un hermoso diseño en la aplicación.
• Proporciona requisitos de computación asimétrica (una combinación de procesamiento de alta y baja intensidad) que permite realizar pruebas realistas de funciones de conmutación por error, escalamiento y monitoreo en diferentes tipos de funcionalidades.

CONCLUSIÓN

La arquitectura de referencia de microservicios NGINX es un desarrollo emocionante para nosotros y para los clientes y socios con quienes la hemos compartido hasta la fecha. En los próximos meses publicaremos una serie de entradas de blog que lo describirán en detalle y lo pondremos a disposición a finales de este año. También lo discutiremos en detalle en nginx.conf 2016 , del 7 al 9 de septiembre en Austin, Texas. Por favor, compartan sus comentarios y esperamos verlos.

Mientras tanto, pruebe usted mismo MRA con NGINX Plus: comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .