architecture vert.x microservices

architecture - Vert.x 3 y microservicios



microservices (3)

Creo que debe tener razones sólidas de escalabilidad para la partición de sus servicios, y no existe un enfoque único para tratar el ciclo de vida y abordar los problemas que enfrentará para lograr que esos servicios interactúen entre sí. . Si un ''verticle'' o alguna otra cosa está escuchando en un zócalo, hubiera pensado que limitar el número de puntos finales / direcciones causaría el menor número de dolores de cabeza en esa dirección. En cualquier caso, la entidad de código responsable de asociar un artículo determinado a su zócalo tendría que exponer los controles del ciclo de vida a algún marco de orquestación de alguna manera ... tal como lo haría si no fuera un artículo que escuchara allí.

Los microservicios están ganando terreno como un estilo de arquitectura de software que admitirá mejor la entrega continua, proporcionará un modelo para un rápido despliegue y separación de inquietudes.

Vert.x 3 y Vert.x-Apex proporcionan un modelo interesante para construir microservicios. Como muestra uno de los ejemplos, un artículo simple puede exponer un servicio HTTP, por lo que hay un servicio REST disponible. El verticle se une a su propio puerto TCP.

Al escalar a múltiples microservicios para admitir una aplicación completa, terminará con una serie de opciones. ¿Alguna idea sobre qué estilo podría eventualmente admitir la entrega continua y minimizar el tiempo de inactividad en las actualizaciones?

Opciones

  1. Ejecutar múltiples verticles podría ser una solución, ya que todos contienen su propio enrutamiento, por lo que el manejo de http está contenido en el verticle. Una solicitud / respuesta puede ser manejada completamente por el artículo. Esto podría significar que cada artículo se ejecuta en su propio puerto TCP.
  2. Usando un enrutador puede exponer todas las rutas en un solo puerto, y manejarlas en consecuencia. Los datos serán manejados por el artículo que contiene el enrutador, posiblemente pasándolo a otros verticles. Esto luego comienza a parecer un enfoque más monolítico.
  3. Ejecute instancias separadas de vert.x que contengan el servicio (posiblemente agruparlas). Esto podría facilitar el uso de la entrega continua, ya que todo es autónomo.
  4. Otras opciones posibles?

Despliegue

En el lado de la implementación, la implementación rápida de nuevos servicios sería deseable, sin desbaratar toda la aplicación.

  • La opción 3. podría proporcionar una manera para esto, pero también puede causar una sobrecarga, especialmente cuando hay un artículo de DB en ejecución en cada artículo.
  • La opción 1 podría ser más fácil, pero ¿qué hay de volver a cargar los nuevos y actualizados verticles?

Los microservicios separados ofrecen una forma interesante de desarrollo, pero ofrecen algunos desafíos en la orquestación y el despliegue.

¿Alguna idea?

Vamos a empezar con la terminología.

  • Un verticle es una clase Java que generalmente extiende AbstractVerticle e implementa un método de inicio (..). Un artículo puede exponer uno o más puntos finales HTTP y exportar uno o más eventbus finales de eventbus .
  • Un verticle se ejecuta dentro de una application Vert.x (anteriormente llamada "módulo"). Una aplicación puede contener uno o más verticles. Normalmente lo mantengo 1: 1 para mantener las cosas pequeñas y simples.
  • Una aplicación Vert.x se ejecuta dentro de una instance Vert.x. Puede ejecutar varias instancias de una aplicación para aumentar la paralelización.
  • Una instancia de Vert.x se ejecuta dentro de un container Vert.x. Un contenedor es un proceso en ejecución con una o más instancias de una aplicación.
  • Un contenedor Vert.x se ejecuta dentro de una JVM.

Al crear una aplicación de estilo microservicios con Vert.x, normalmente desea pequeñas unidades lógicas de trabajo independientes, llámelas servicios. Dicho servicio debería ejecutarse idealmente en su propio proceso, ser autónomo y actualizable de forma independiente. Asignándolo a la terminología anterior: cree el servicio como una aplicación Vert.x que contenga un único Verticle con la lógica del servicio.

Las aplicaciones Vert.x se comunican entre sí mediante el bus de eventos distribuido, construido con Hazelcast. Esto significa que varias JVM que se ejecutan en el mismo servidor, o incluso en múltiples servidores, pueden comunicarse entre sí a través del bus de eventos Vert.x.

Una aplicación web creada con Vert.x generalmente consiste en una o más aplicaciones Vert.x que exponen puntos finales REST que se comunican a través del bus de eventos con una o más aplicaciones Vert.x que exponen puntos finales del bus de eventos (interno).

Para responder a su pregunta: la opción 3 es la más común en las configuraciones de Vert.x, y es la más cercana a una arquitectura de microservicios. Puede elegir entre 2 opciones allí: puede ejecutar 1 aplicación con un punto final REST que maneja todas las llamadas HTTP y los delegados solicitan el procesamiento sobre el bus de eventos a otras aplicaciones, o brinda cada servicio (o al menos, cada servicio proporciona funcionalidad para los usuarios finales) ) su propio punto final REST. El último es un poco más complejo de configurar, ya que hay varios puntos finales HTTP para conectarse desde la interfaz, pero es más escalable y tiene menos puntos únicos de falla.

Vert.x tiene actualmente una serie de módulos oficiales para crear arquitecturas de microservicios que, en mi opinión, no existían en el momento en que se formuló su pregunta.

Estos son los módulos oficiales de microservicios :

  • Vert.x Service Discovery : publica, busca y se enlaza con cualquier tipo de servicios.
  • Interruptor de circuito Vert.x : proporciona una implementación del patrón de interruptor de circuito de Vert.x
  • Vert.x Config : proporciona una forma extensible de configurar las aplicaciones Vert.x.

Y hay más módulos oficiales que son útiles:

  • Métricas usando Dropwizard : obtiene las métricas de los componentes principales y las envía a Dropwizard.
  • Métricas usando el micrómetro : obtiene las métricas de los componentes principales y las envía al micrómetro.
  • Vert.x Health Check : proporciona una forma sencilla de exponer los controles de salud.
  • Vert.x Clustering : soporte para Hazelcast, Zookeeper, Apache Ignite e Infinicast
  • Servicios Vert.x : una forma simple y efectiva de encapsular la funcionalidad reutilizable para su uso en otros lugares.

Hay muchos más módulos oficiales que puede incorporar en el diseño de sus microservicios.

Y también hay algunos grandes artículos sobre cómo aplicarlos en la práctica:

Y, por último, si desea ver un código que va mucho más allá de HelloWorld , mire:

Y hay mucho más código que tener (como una puerta de enlace API , aunque Léame en chino).