Building Reactive - Final

Universidad Nacional Del Santa
Ing. Sistemas e Informática
“Año de la lucha contra la corrupción e impunidad"
UNIVERSIDAD NACIONAL DEL SANTA

Escuela Profesional de Ingeniería de Sistemas e Informática
“Construcción de Microservicios Reactivos en JAVA”
ASIGNATURA: Gestión Financiera T.I.
INTEGRANTES:
 Chapa Carranza Kathiuska
 Lara Soto Jhonatan
 López Zapata Francisco
 Reyes Avalos Deivy
 Valverde Solís Abraham
DOCENTE:
 Mg. Camilo Suarez Rebaza
CICLO: IX
NUEVO CHIMBOTE – PERÚ
2019
Microservicios Reactivos en JAVA 1
Contenido
1 ENTENDIENDO LOS MICROSERVICIOS REACTIVOS Y VERT.X ...................... 2
1.1 Programación reactiva ............................................................................................. 2
1.2 RXJAVA2 ................................................................................................................ 4
1.3 Flujos reactivos ........................................................................................................ 5
1.4 Sistemas reactivos .................................................................................................... 5
1.5 Microservicios reactivos .......................................................................................... 6
1.6 Modelo de desarrollo asíncrono ............................................................................... 7
1.7 Vértices: los Building Blocks .................................................................................. 9
1.8 De devoluciones de llamada a observables ............................................................ 10
2 CONSTRUCCIÓN DE MICROSERVICIOS REACTIVOS....................................... 17
2.1. .................................................................................................................................... 17
2.2. .................................................................................................................................... 18
2.3. .................................................................................................................................... 22
2.4. .................................................................................... Error! Bookmark not defined.
2.5. El bus de eventos Vert.x: una red troncal de mensajería ........................................... 27
2.6. Microservicios basados en mensajes ......................................................................... 28
2.6.1. Creación de proyectos ........................................................................................ 28
2.6.2. Escribir el artículo dirigido por el mensaje .................................................... 28
2.7. Iniciar interacciones basadas en mensajes ................................................................. 29
2.8. ¿Somos reactivos ahora? ............................................................................................ 32
2.8.1. Elasticidad .......................................................................................................... 32
2.8.2. Resistencia .......................................................................................................... 32
3 CONSTRUCCIÓN DE SISTEMAS DE MICROSERVICIOS REACTIVOS. ........... 34
3.1 Descubrimiento de servicios .................................................................................. 34
3.1.1. Descubrimiento de servicios del lado del cliente y del servidor .................... 35
3.1.3. Descubrimiento de servicios Vert.x.................................................................... 36
3.2 Patrones de Estabilidad y Resiliencia .................................................................... 38
3.2.1 Gestión de Fallos en Microservicios Reactivos .............................................. 39
3.2.2 Usando tiempos de espera .............................................................................. 40
3.2.3 Rompedores de circuito .................................................................................. 42
3.2.4 Controles de Salud y de Conmutación por error ............................................ 44

4 DESPLIEGUE DE MICROSERVICIOS REACTIVOS EN OPENSHIFT. ............... 45

4.1 ¿Qué es OpenShift? ............................................................................................... 46
4.1.1 Construir la configuración .............................................................................. 48
4.1.2 Configuraciones de implementación .............................................................. 48
4.1.3 Pods ................................................................................................................ 49
4.1.4 Servicios y Rutas ............................................................................................ 49
4.2 Instalación de OpenShift en su máquina ................................................................ 49
5 DESPLIEGUE DE UN MICROSERVICIO EN OPENSHIFT ................................... 51
5.1 Descubrimiento de servicios .................................................................................. 53
5.2 Escalar hacia arriba y hacia abajo .......................................................................... 56
5.3 Comprobación de estado y conmutación por error ................................................ 57
5.4 Usando un disyuntor .............................................................................................. 59
5.5 Pero espera, ¿somos reactivos? .............................................................................. 61
5.6 Resumen................................................................................................................. 63
6 CONCLUSIÓN ............................................................................................................ 63
Los microservicios no son fáciles ..................................................................................... 64
La evolución del microservicio......................................................................................... 65
Versatilidad Vert.x ............................................................................................................ 66

CONSTRUCCIÓN DE MICROSERVICIOS
REACTIVOS EN JAVA
1 ENTENDIENDO LOS MICROSERVICIOS REACTIVOS Y VERT.X

Los microservicios no son realmente una cosa nueva. Surgieron de una investigación
realizada en la década de 1970 y se han convertido en el centro de atención recientemente
porque los microservicios son una forma de moverse más rápido, de entregar valor con mayor
facilidad y de mejorar la agilidad. Sin embargo, los microservicios tienen sus raíces en los
sistemas basados en actores, el diseño de servicios, los sistemas dinámicos y autónomos, el
diseño basado en dominios y los sistemas distribuidos. El diseño modular de microservicios
de grano fino lleva inevitablemente a los desarrolladores a crear sistemas distribuidos. Como
estoy seguro de que se ha dado cuenta, los sistemas distribuidos son difíciles. Fallan, son
lentos, están sujetos a los teoremas de CAP y FLP. En otras palabras, son muy complicados
de construir y mantener. Ahí es donde entra el reactivo.
¿Pero qué es reactivo? Reactivo es un término sobrecargado en estos días. El diccionario de

Oxford define reactivo como "mostrar una respuesta a un estímulo". Entonces, el software
reactivo reacciona y adapta su comportamiento en función de los estímulos que recibe. Sin
embargo, la capacidad de respuesta y la adaptabilidad promovidas por esta definición son
desafíos de programación porque
Entendiendo los microservicios reactivos y Vert.x
el flujo de cálculo no está controlado por el programador, sino por los estímulos. En este
capítulo, veremos cómo Vert.x lo ayuda a ser reactivo al combinar:
Programación reactiva: un modelo de desarrollo que se enfoca en la observación de flujos de
datos, reacciona a los cambios y los propaga.
Sistema reactivo: se utiliza un estilo de arquitectura. para construir sistemas distribuidos

robustos y de respuesta basados en el paso asíncrono de mensajes Un microservicio reactivo
es el componente básico de los sistemas de microservicio reactivos.
1.1 Programación reactiva

La programación reactiva es un modelo de desarrollo orientado en torno a los flujos de
datos y la propagación de datos. En la programación reactiva, los estímulos son los
datos que transitan en el flujo, que se denominan flujos. Hay muchas formas de
implementar un modelo de programación reactivo. En este informe, vamos a usar las
Extensiones reactivas (http://reactivex.io/).

Para que estos conceptos sean menos abstractos, veamos un ejemplo utilizando RxJava
(https://github.com/ReactiveX/RxJava), una biblioteca que implementa las
Extensiones reactivas en Java.
En este fragmento, el código está observando (suscribiéndose) a un Observable y se le

notifica cuando los valores transitan en el flujo. El suscriptor puede recibir tres tipos
de eventos. Se llama a onNext cuando hay un nuevo valor, mientras que se llama a
onError cuando se emite un error en el flujo o una etapa lanza una excepción. La
devolución de llamada onComplete se invoca cuando se alcanza el final de la
secuencia, lo que no se produciría para las secuencias ilimitadas.
RxJava v1.x define diferentes tipos de flujos de la siguiente manera
 Los observables son flujos limitados o ilimitados que se espera que contengan
una secuencia de valores.

 Los solteros son flujos con un solo valor, generalmente el resultado diferido de
una operación, similar a los futuros o promesas.
 Los complementos son flujos sin valor, pero con una indicación de si una
operación se completó o falló.
1.2 RXJAVA2
Si bien RxJava 2.x se ha lanzado recientemente, este informe aún utiliza la versión
anterior (RxJava 1.x). RxJava 2 introdujo el tipo Maybe, que modela una secuencia en
la que podría haber 0 o 1 elemento o un error.
¿Qué podemos hacer con RxJava? Por ejemplo, podemos describir secuencias de
acciones asíncronas y organizarlas. Imaginemos que desea descargar un documento,
procesarlo y cargarlo. Las operaciones de descarga y carga son asíncronas. Para
desarrollar esta secuencia, usas algo como:
También puede orquestar tareas asíncronas. Por ejemplo, para combinar los resultados
de dos operaciones asíncronas, utiliza el operador zip que combina valores de
diferentes flujos
El uso de estos operadores le brinda superpoderes: puede coordinar tareas asíncronas
y flujo de datos de manera declarativa y elegante. ¿Cómo se relaciona esto con los
microservicios reactivos? Para responder a esta pregunta, echemos un vistazo a los
sistemas reactivos.

1.3 Flujos reactivos

Es posible que haya oído hablar de flujos reactivos Los flujos reactivos son una
iniciativa para proporcionar un estándar para el procesamiento de flujos asíncronos con
contrapresión. Proporciona un conjunto mínimo de interfaces y protocolos que
describen las operaciones y las entidades para lograr los flujos asíncronos de datos con
presión de retorno sin bloqueo. No define a los operadores que manipulan los flujos, y
se utiliza principalmente como una capa de interoperabilidad. Esta iniciativa es
compatible con Netflix, Lightbend y Red Hat, entre otros.
1.4 Sistemas reactivos

Si bien la programación reactiva es un modelo de desarrollo, los sistemas reactivos son
un estilo arquitectónico utilizado para construir sistemas distribuidos. Es un conjunto
de principios que se utiliza para lograr la capacidad de respuesta y crear sistemas que
respondan a las solicitudes de manera oportuna, incluso con fallas o bajo carga. Para
construir un sistema de este tipo, los sistemas reactivos adoptan un enfoque impulsado
por el mensaje. Todos los componentes interactúan utilizando mensajes enviados y
recibidos de forma asíncrona. Una dirección es un identificador de destino, como una
cadena opaca o una URL. Se pueden registrar varios receptores en la misma dirección;
la entrega depende de la semántica.
En la tecnología subyacente. Los remitentes no bloquean y esperan una respuesta. El

remitente puede recibir una respuesta más tarde, pero mientras tanto, puede recibir y
enviar otros mensajes. Este aspecto asíncrono es particularmente importante y afecta la
forma en que se desarrolla su aplicación. El uso de interacciones de paso de mensajes
asíncronas proporciona sistemas reactivos con dos propiedades críticas:

Elasticidad: la capacidad de escalar horizontalmente.

Resiliencia: la capacidad de manejar fallas y recuperar.
Puede adaptarse a cargas más altas o más bajas y continuar atendiendo solicitudes ante
altas cargas o fallas. Este conjunto de principios es primordial cuando se construyen
sistemas de microservicio que están altamente distribuidos, y cuando se trata de servicios
que están fuera del control de la persona que llama. Es necesario ejecutar varias instancias
de sus servicios para equilibrar la carga y manejar las fallas sin interrumpir la
disponibilidad.
1.5 Microservicios reactivos

Al crear un sistema de microservicio (y, por lo tanto, distribuido), cada servicio puede
cambiar, evolucionar, fallar, mostrar lentitud o ser retirado en cualquier momento.
Tales problemas no deben afectar el comportamiento de todo el sistema. Su sistema
debe aceptar cambios y ser capaz de manejar fallas.
Puede ejecutarse en un modo degradado, pero su sistema aún debería poder manejar
las solicitudes. Para asegurar tal comportamiento, los sistemas de microservicio
reactivos están compuestos por microservicios reactivos. Estos microservicios tienen
cuatro características:
 Autonomía
 Asincronización
 Resiliencia
 Elasticidad
Los microservicios reactivos son autónomos. Pueden adaptarse a la disponibilidad o
indisponibilidad de los servicios que los rodean. Sin embargo, la autonomía viene
emparejada con el aislamiento. Los microservicios reactivos pueden manejar el fracaso
localmente, actuar de manera independiente y cooperar con otros según sea necesario.
Un microservicio reactivo utiliza el paso asíncrono de mensajes para interactuar con
sus pares. También recibe mensajes y tiene la capacidad de producir respuestas a estos
mensajes.
Gracias a la transmisión asíncrona de mensajes, los microservicios reactivos pueden
enfrentar fallas y adaptar su comportamiento en consecuencia.Cuando un

microservicio explota, el microservicio del consumidor debe manejar la falla y no

propagarla. Este principio de aislamiento es una característica clave para evitar que los
fallos broten y rompan todo el sistema. La resiliencia no se trata solo de gestionar el
fracaso, sino también de la autocuración. Un microservicio reactivo debe implementar
estrategias de recuperación o compensación cuando se producen fallas. Finalmente, un
microservicio reactivo debe ser elástico, de modo que el sistema pueda adaptarse a la
cantidad de instancias para administrar la carga.
¿Qué pasa con Vert.x?
Vert.x es un conjunto de herramientas para construir sistemas reactivos y distribuidos
utilizando un modelo de desarrollo asíncrono sin bloqueo. Como se trata de un kit de
herramientas y no de un marco, utiliza Vert.x como cualquier otra biblioteca. No
restringe cómo construyes o estructuras tu sistema; tu usas como quieras Vert.x es muy
flexible. Puede elegir cualquiera de estos módulos además de Vert.x Core (el
componente principal de Vert.x) para construir su sistema. Con Vert.x puedes construir
microservicios reactivos. Al crear un microservicio con Vert.x, infunde una de sus
características principales al microservicio: se vuelve asíncrono en todo momento.
1.6 Modelo de desarrollo asíncrono

Todas las aplicaciones creadas con Vert.x son asíncronas. Las aplicaciones Vert.x son
controladas por eventos y no bloqueantes. Su aplicación es notificada cuando sucede
algo interesante. Veamos un ejemplo concreto. Vert.x proporciona una manera fácil de
crear un servidor HTTP. Este servidor HTTP es notificado cada vez que se recibe una
solicitud HTTP:
En este ejemplo, configuramos un requestHandler para recibir las solicitudes HTTP

(evento) y enviar hello Vert.x de vuelta (reacción). Un controlador es una función
llamada cuando ocurre un evento. En nuestro ejemplo, el código del controlador se

ejecuta con cada solicitud entrante. Tenga en cuenta que un controlador no devuelve
un resultado. Sin embargo, un controlador puede proporcionar un resultado.
Con muy pocas excepciones, ninguna de las API en Vert.x bloquea el subproceso de
llamada. Si un resultado puede ser proporcionado inmediatamente, será devuelto; de lo
contrario, un controlador se utiliza para recibir eventos en un momento posterior. Se
notifica al controlador cuando un evento está listo para ser procesado o cuando se ha
calculado el resultado de una operación asíncrona.
En la programación imperativa tradicional, escribirías algo como:
En este código, esperas el resultado del método. Cuando se cambia a un modelo de

desarrollo sin bloqueo asíncrono, se pasa un controlador invocado cuando el resultado
está listo:
En el último fragmento, el proceso ya no devuelve un resultado, por lo que no espere

hasta que este resultado se calcule y se devuelva. Pasas un controlador que se llama
cuando el resultado está listo. Gracias a este modelo de desarrollo sin bloqueo, puede
manejar una carga de trabajo altamente concurrente utilizando un pequeño número de
subprocesos. En la mayoría de los casos, Vert.x llama a sus manejadores utilizando un
subproceso denominado bucle de eventos.
El modelo de subprocesamiento propuesto por el bucle de eventos tiene un gran
beneficio: simplifica la concurrencia. Como solo hay un subproceso, siempre recibe la
llamada del mismo subproceso y nunca al mismo tiempo. Sin embargo, también tiene
una regla muy importante que debes obedecer.
Debido a que nada bloquea, un bucle de eventos puede entregar una gran cantidad de
eventos en un corto período de tiempo. Esto se llama el patrón del reactor Imaginemos,
por un momento, que rompes la regla. En el fragmento de código anterior, el
controlador de solicitudes siempre se llama desde el mismo bucle de eventos. Por lo
tanto, si el procesamiento de solicitudes HTTP bloquea en lugar de responder al usuario

inmediatamente, las otras solicitudes no se manejarán de manera oportuna y se pondrán

en cola, a la espera de que se libere el subproceso. Perdería el beneficio de escalabilidad
y eficiencia de Vert.x. Entonces, ¿qué puede estar bloqueando? El primer ejemplo
obvio es el acceso a bases de datos JDBC. Los cálculos largos también están
bloqueando. Por ejemplo, un código que calcula Pi hasta el punto decimal número
200.000 definitivamente está bloqueando. No se preocupe, Vert.x también proporciona
construcciones para lidiar con el código de bloqueo. En una implementación de reactor
estándar, hay un solo subproceso de bucle de evento que se ejecuta en un bucle que
entrega todos los eventos a todos los controladores a medida que llegan. El problema
con un solo hilo es simple: solo puede ejecutarse en un solo núcleo de CPU al mismo
tiempo. Vert.x funciona de manera diferente aquí.
Los eventos son enviados por los diferentes bucles de eventos. Sin embargo, una vez
que un manejador ejecuta un bucle de eventos, siempre será invocado por este bucle
de eventos, aplicando los beneficios de concurrencia de patrón del reactor. Si, como en
la Figura 2-4, tiene varios bucles de eventos, puede equilibrar la carga en diferentes
núcleos de CPU. ¿Cómo funciona eso con nuestro ejemplo HTTP? Vert.x registra el
escucha de socket una vez y envía las solicitudes a los diferentes bucles de eventos.
1.7 Vértices: los Building Blocks

Vert.x le dan mucha libertad en la forma en que puede dar forma a su aplicación y
código. Pero también proporciona ladrillos para comenzar a escribir fácilmente
aplicaciones Vert.x y viene con un modelo de implementación y concurrencia simple,
escalable y similar a un actor. Los vértices son fragmentos de código que se
implementan y ejecutan por Vert.x. Un artículo generalmente crea servidores o
clientes, registra un conjunto de Manejadores y encapsula una parte de la lógica de
negocios del sistema. Los verticles regulares se ejecutan en el bucle de eventos Vert.x
y nunca se pueden bloquear. Vert.x garantiza que cada artículo se ejecute siempre por
el mismo subproceso y nunca de forma simultánea, evitando así las construcciones de
sincronización. En Java, un verticle es una clase que extiende la clase Abstract Verticle:

Verticle de trabajo
A diferencia de las verticles normales, las verticles de trabajo no se ejecutan en el bucle
de eventos, lo que significa que pueden ejecutar código de bloqueo. Sin embargo, esto
limita su escalabilidad.
Los vértices tienen acceso al miembro vertx (proporcionado por la clase
AbstractVerticle) para crear servidores y clientes e interactuar con los otros verticles.
Los vértices también pueden implementar otros verticles, configurarlos y establecer el
número de instancias para crear. Las instancias están asociadas con los diferentes
bucles de eventos (implementando el patrón de multirreactor), y Vert.x equilibra la
carga entre estas instancias.
1.8 De devoluciones de llamada a observables

Como se vio en las secciones anteriores, el modelo de desarrollo Vert.x utiliza
devoluciones de llamada. Cuando se organizan varias acciones asíncronas, este modelo
de desarrollo basado en devolución de llamada tiende a producir código complejo. Por
ejemplo, veamos cómo recuperar datos de una base de datos. Primero, necesitamos una
conexión a la base de datos, luego enviamos una consulta a la base de datos,
procesamos los resultados y liberamos la conexión. Todas estas operaciones son
asíncronas. Usando devoluciones de llamada, escribiría el siguiente código usando el
cliente JDBC de Vert.x:

Aunque aún es manejable, el ejemplo muestra que las devoluciones de llamada pueden
conducir rápidamente a código ilegible. También puede usar Vert.x Futures para
manejar acciones asíncronas. A diferencia de los futuros de Java, los futuros de Vert.x
no están bloqueados. Los futuros proporcionan operadores de composición de nivel
superior para construir secuencias de acciones o para ejecutar acciones en paralelo.
Normalmente, como se demuestra en el siguiente fragmento de código, componemos
futuros para construir la secuencia de acciones asíncronas:
Sin embargo, aunque los futuros hacen que el código sea un poco más declarativo,
estamos recuperando todas las filas en un lote y procesándolas. Este resultado puede

ser enorme y llevar mucho tiempo recuperarlo. Al mismo tiempo, no necesita todo el
resultado para comenzar a procesarlo. Podemos procesar cada fila una por una tan
pronto como las tengas. Afortunadamente, Vert.x proporciona una respuesta a este
desafío de modelo de desarrollo y le ofrece una manera de implementar microservicios
reactivos utilizando un modelo de desarrollo de programación reactiva. Vert.x
proporciona las API de RxJava para:
• Combinar y coordinar tareas asíncronas
• Reaccionar a los mensajes entrantes como un flujo de entrada Reescribamos el
código anterior utilizando las API de RxJava:
Además de mejorar la legibilidad, la programación reactiva le permite suscribirse a un

flujo de resultados y procesar elementos tan pronto como estén disponibles. Con Vert.x
puedes elegir el modelo de desarrollo que prefieras. En este informe, utilizaremos
ambas devoluciones de llamada y RxJava.
1.9 Comencemos a codificar

Es hora de que te ensucies las manos. Vamos a utilizar Apache Maven y el
complemento Vert.x Maven para desarrollar nuestra primera aplicación Vert.x. Sin
embargo, puede utilizar la herramienta que desee (Gradle, Apache Maven con otro
complemento de empaquetado o Apache Ant). Encontrará diferentes ejemplos en el
repositorio de código (en el directorio packaging-examples). El código que se muestra
en esta sección se encuentra en el directorio hello-vertx.

Creación de proyectos
Cree un directorio llamado my-first-vertx-app y avance a este directorio:
Luego, emita el siguiente comando:
Este comando genera la estructura del proyecto Maven, configura el plugin vertx-
maven-plugin y crea una clase de vertículo (io.vertx.sam ple.MyFirstVerticle), que no
hace nada.
Escribe tu primer vertículo
Ahora es el momento de escribir el código para su primer vértice. Modifique el archivo
src / main / java / io / vertx / sample / MyFirstVerticle.java con el siguiente contenido:

Para ejecutar esta aplicación, inicie:
Si todo salió bien, debería poder ver su aplicación abriendo http: // localhost: 8080 en
un navegador. El objetivo vertx: run inicia la aplicación Vert.x y también observa las
alteraciones del código. Entonces, si edita el código fuente, la aplicación se recompilará
y reiniciará automáticamente.
Veamos ahora el resultado de la aplicación:
La solicitud ha sido procesada por el bucle de eventos 0. Puede intentar emitir más
solicitudes. Las solicitudes siempre serán procesadas por el mismo bucle de eventos,
aplicando el modelo de concurrencia de Vert.x. Presiona Ctrl + C para detener la
ejecución.
Usando RxJava
En este punto, echemos un vistazo al soporte RxJava proporcionado por Vert.x para
comprender mejor cómo funciona. En su archivo pom.xml, agregue la siguiente
dependencia:
A continuación, cambie la propiedad <vertx.verticle> para que sea io.vertx.sam

ple.MyFirstRXVerticle. Esta propiedad le dice al plugin Vert.x Maven qué vertical es
el punto de entrada de la aplicación. Cree la nueva clase de vertículo
(io.vertx.sample.MyFirstRXVerticle) con el siguiente contenido:

Las variantes RxJava de las API Vert.x se proporcionan en paquetes con rxjava en su
nombre. Los métodos RxJava tienen el prefijo rx, como rxListen. Además, las API se
mejoran con métodos que proporcionan objetos Observables en los que puede
suscribirse para recibir los datos transmitidos.
Empaquetando su aplicación como Fat Jar

El complemento Vert.x Maven empaqueta la aplicación en Fat Jar. Una vez
empaquetado, puede iniciar fácilmente la aplicación usando java -jar <nombre> .jar:

La aplicación está nuevamente activa, escuchando el tráfico HTTP en el puerto

especificado. Presiona Ctrl + C para detenerlo.
Como un kit de herramientas no opinado, Vert.x no promueve un modelo de empaque

sobre otro, usted es libre de usar el modelo de empaque que prefiera. Por ejemplo,
podría usar frascos gruesos, un enfoque de sistema de archivos con bibliotecas en un
directorio específico, o incrustar la aplicación en un archivo war e iniciar Vert.x
mediante programación.
En este informe, usaremos frascos gruesos, es decir, JAR autónomos que incorporen el
código de la aplicación, sus recursos y todas sus dependencias. Esto incluye Vert.x, los
componentes Vert.x que está utilizando y sus dependencias. Este modelo de empaque
utiliza un mecanismo de cargador de clase plana, lo que facilita la comprensión del
inicio de la aplicación, el pedido de dependencias y los registros. Más importante aún,
ayuda a reducir la cantidad de piezas móviles que deben instalarse en la producción.
No implemente una aplicación en un servidor de aplicaciones existente. Una vez que
está empaquetado en su frasco gordo, la aplicación está lista para ejecutarse con un
simple java -jar <name.jar>. El complemento Vert.x Maven crea un tarro gordo para
usted, pero también puede usar otro complemento Maven como el complemento
maven-shader.
Registro, monitoreo y otros elementos de producción.

Tener Fat Jar es un excelente modelo de empaque para microservicios y otros tipos de
aplicaciones, ya que simplifican la implementación y el lanzamiento. Pero, ¿qué pasa
con las características que generalmente ofrecen los servidores de aplicaciones que
preparan la producción de su aplicación? Por lo general, esperamos poder escribir y
recopilar registros, supervisar la aplicación, impulsar la configuración externa, agregar
comprobaciones de estado, etc.
No se preocupe: Vert.x ofrece todas estas funciones. Y debido a que Vert.x es neutral,
ofrece varias alternativas, permitiéndole elegir o implementar la suya. Por ejemplo,

para el registro, Vert.x no aplica un marco de registro específico, sino que le permite
utilizar el marco de registro que desee, como Apache Log4J 1 o 2, SLF4J o incluso
JUL (la API de registro JDK). Si está interesado en los mensajes registrados por Vert.x,
el registro interno de Vert.x se puede configurar para usar cualquiera de estos marcos
de registro. La supervisión de las aplicaciones Vert.x generalmente se realiza mediante
JMX. El módulo Métrico Vert.x Dropwizard proporciona métricas Vert.x a JMX.
También puede optar por publicar estas métricas en un servidor de monitoreo como
Prometheus (https://prometheus.io/) o CloudForms (https://www.redhat.com/en/
technologies / management / cloudforms).
2 CONSTRUCCIÓN DE MICROSERVICIOS REACTIVOS

En este capítulo, crearemos nuestros primeros microservicios con Vert.x. Como la
mayoría de los sistemas de microservicios utilizan interacciones HTTP, vamos a
comenzar con microservicios HTTP. Pero debido a que los sistemas consisten en
múltiples microservicios de comunicación, crearemos otro microservicio que consume
el primero. Luego, demostraremos por qué tal diseño no abarca por completo los
microservicios reactivos. Finalmente, implementaremos microservicios basados en
mensajes para ver cómo la mensajería mejora la reactividad.
2.1. Primeros microservicios

En este capítulo vamos a implementar el mismo conjunto de microservicios dos veces.
El primer microservicio expone un servicio de saludo que llamaremos microservicio
de saludo. Otro consume este servicio dos veces (simultáneamente). El consumidor se
llamará hola consumidor microservicio. Este pequeño sistema ilustra no solo cómo se
sirve un servicio, sino también cómo se consume. En el lado izquierdo de la Figura 3-
1, los microservicios están utilizando interacciones HTTP. El microservicio hello
consumer utiliza un cliente HTTP para invocar el microservicio hello. En el lado
derecho, el microservicio hello consumer utiliza mensajes para interactuar con el
microservicio hello. Esta diferencia impacta la reactividad del sistema.

Figura 2.1: Los micro servicios implementados en este

capítulo usando HTTP
En el capítuloe anterior,
interacciones basadas
vimos en mensajes
dos formas diferentes de usar las API de Vert.x:
devoluciones de llamada y RxJava. Para ilustrar las diferencias y ayudarlo a encontrar
su enfoque preferido, los microservicios hola se implementan utilizando el modelo de
desarrollo basado en devolución de llamada, mientras que los consumidores se
implementan utilizando RxJava.
2.2. Implementación de microservicios HTTP

Los microservicios a menudo exponen su API a través de HTTP y se consumen
mediante solicitudes HTTP. Veamos cómo se pueden implementar estas interacciones
HTTP con Vert.x. El código desarrollado en esta sección está disponible en el
directorio microservicios / hello-microservice-http del repositorio de código.
Empezando
Cree un directorio llamado hello-microservice-http y luego genere la estructura del
proyecto:

Este comando genera el proyecto Maven y configura el complemento Vert.x Maven.

Además, agrega la dependencia de vertx-web. Vert.x Web es un módulo que
proporciona todo lo que necesita para crear aplicaciones web modernas además de
Vert.x.
El verticle
Abra src / main / java / io / vertx / book / http / HelloMicroser vice.java. El código
generado del vértice no hace nada muy interesante, pero es un punto de partida:
Ahora, inicie el siguiente comando Maven:
Ahora puede editar la vertical. Cada vez que guarde el archivo, la aplicación se
recompilará y reiniciará automáticamente.

Microservicio HTTP
Es hora de hacer que nuestra clase MyVerticle haga algo. Comencemos con un servidor
HTTP. Como se vio en el capítulo anterior, para crear un servidor HTTP con Vert.x
solo usa:
Una vez agregado y guardado, debería poder ver hola en http: // localhost: 8080 en un
navegador. Este código crea un servidor HTTP onport 8080 y registra un
requestHandler que se invoca en cada solicitud HTTP entrante. Por ahora, solo
escribimos hola en la respuesta.
Using Routes and Parameters

Muchos servicios se invocan a través de URL web, por lo que verificar la ruta es crucial
para saber qué es lo que solicita la solicitud. Sin embargo, hacer la verificación de ruta
en requestHandler para implementar diferentes acciones puede ser complicado.
Afortunadamente, Vert.x Web proporciona un enrutador en el que podemos registrar
rutas. Las rutas son el mecanismo por el cual Vert.x Web comprueba la ruta e invoca
la acción asociada. Reescribamos el método de inicio, con dos rutas:

Una vez que hemos creado el objeto Router, registramos dos rutas. El primero maneja
las solicitudes en / y solo escribe hola. La segunda ruta tiene un parámetro de ruta (:
nombre). El controlador agrega el valor pasado al mensaje de saludo. Finalmente,
cambiamos el requestHandler del servidor HTTP para usar el método accept del
enrutador.
Si no detuvo la ejecución de vertx: run, debería poder abrir un navegador para:
Produciendo JSON
JSON se usa a menudo en microservicios. Modifiquemos la clase anterior para producir
cargas JSON:
Vert.x proporciona una clase JsonObject para crear y manipular estructuras JSON. Con
este código, debe poder abrir un navegador para:

Packaging y funcionamiento
Detenga el vertx: ejecute la ejecución usando Ctrl + C y ejecute el siguiente comando
desde el mismo directorio:
Esto produce un tarro gordo en el directorio de destino: hellomicroservice- http-1.0-

SNAPSHOT.jar. Mientras que los tarros gordos tienden a ser gordos, aquí el JAR tiene
un tamaño razonable (~ 6.3 MB) y contiene todo para ejecutar la aplicación:
Puede verificar si se está ejecutando abriendo: http: // host local: 8080. Mantenga el
proceso en ejecución ya que el próximo microservicio lo invocará.
2.3. Consumir microservicios HTTP

Un microservicio no forma una aplicación; Necesita un sistema de microservicios.
Ahora que tenemos nuestro primer microservicio en funcionamiento, escriba un
segundo microservicio para consumirlo. Este segundo microservicio también
proporciona una fachada HTTP para invocarlo, y en cada invocación llama al
microservicio que acabamos de implementar. El código que se muestra en esta sección
está disponible en el directorio microservicios / helloconsumermicroservice-http del
repositorio de código.
Creación de proyectos
Como de costumbre, vamos a crear un nuevo proyecto:
El último comando agrega otra dependencia: el cliente web Vert.x, un cliente HTTP
asíncrono. Utilizaremos este cliente para llamar al primer microservicio. El comando
también ha agregado el enlace Vert.x RxJava que vamos a usar más adelante.

Ahora edite el archivo src / main / java / io / vertx / book / http / HelloConsumer
Microservice.java y actualícelo para que contenga:
En el método de inicio, creamos un WebClient y un enrutador. En el enrutador creado,

registramos una ruta en "/" e iniciamos el servidor HTTP, pasando el método de
aceptación del enrutador como requestHandler. El controlador de la ruta es una
referencia de método (hola). Este método utiliza el cliente web para invocar el primer

microservicio con una ruta específica (/vert.x) y escribir el resultado en la respuesta

HTTP.
Una vez que se crea la solicitud HTTP, llamamos enviar para emitir la solicitud. El
controlador que pasamos se invoca cuando llega la respuesta o se produce un error. El
bloque if-else verifica si la invocación ha tenido éxito. No olvide que es una interacción
remota y tiene muchas razones para fallar. Por ejemplo, el primer microservicio puede
no estar ejecutándose. Cuando tiene éxito, escribimos la carga recibida en la respuesta;
de lo contrario, respondemos con una respuesta de 500.
Llamar al servicio más de una vez

Ahora cambiemos el comportamiento actual para llamar al microservicio hello dos
veces con dos parámetros diferentes (ruta):
Estas dos solicitudes son independientes y pueden ejecutarse simultáneamente. Pero

aquí queremos escribir una respuesta que reúna ambos resultados. El código requerido
para invocar el servicio dos veces y ensamblar los dos resultados puede ser complicado.
Necesitamos verificar si la otra solicitud se ha completado o no cuando recibimos una
de las respuestas. Si bien este código aún sería manejable para dos solicitudes, se
vuelve demasiado complejo cuando necesitamos manejar más. Afortunadamente,
como se señaló en el capítulo anterior, podemos usar programación reactiva y RxJava
para simplificar este código.
Le indicamos al plugin vertx-maven-plugin que importe la API Vert.x RxJava. En

HelloConsumerMicroservice, reemplazamos las declaraciones de importación con:

Con RX, el código complejo que habríamos escrito para llamar a las dos solicitudes y
generar una respuesta a partir de ellas se vuelve mucho más simple:
Observe las llamadas al método rxSend. Los métodos RxJava de Vert.x tienen el prefijo
rx para ser fácilmente reconocibles. El resultado de rxSend es Single, es decir, un
elemento observable de un elemento que representa el resultado diferido de una
operación. El método single.zip toma como entrada un conjunto de Single, y una vez
que todos han recibido su valor, llama a una función con los resultados. Single.zip
produce otro Single que contiene el resultado de la función. Finalmente, nos
suscribimos. Este método toma dos funciones como parámetros:

1. Se llama al primero con el resultado de la función zip (un objeto JSON).

Escribimos la carga de recepción JSON en la respuesta HTTP.
2. Se llama al segundo si algo falla (tiempo de espera, excepción, etc.). En este

caso, respondemos con un objeto JSON vacío.
Con este código, si abrimos http: // localhost: 8081 y el microservicio hola aún se está
ejecutando, deberíamos ver:
2.4. ¿Son estos microservicios microservicios reactivos?

En este punto tenemos dos microservicios. Son independientes y se pueden
implementar y actualizar a su propio ritmo. También interactúan usando un protocolo
ligero (HTTP). ¿Pero son microservicios reactivos? No, ellos no son. Recuerde, para
ser llamado reactivo, un microservicio debe ser:
 Autónomo
 Asincrónico
 Elástico
 Elástico
El problema principal con el diseño actual es el acoplamiento estrecho entre los dos
microservicios. El cliente web está configurado para apuntar al primer microservicio
explícitamente. Si falla el primer microservicio, no podremos recuperarnos llamando a
otro. Si estamos bajo carga, crear una nueva instancia del hola microservicio no nos
ayudará. Gracias al cliente web Vert.x, las interacciones son asíncronas. Sin embargo,
como no utilizamos una dirección virtual (destino) para invocar el microservicio, sino
su URL directa, no proporciona la resistencia y elasticidad que necesitamos.
Es importante tener en cuenta que el uso de la programación reactiva como en el
segundo microservicio no le brinda los beneficios del sistema reactivo. Proporciona un

modelo de desarrollo elegante para coordinar acciones asincrónicas, pero no

proporciona la resistencia y elasticidad que necesitamos.
2.5. El bus de eventos Vert.x: una red troncal de mensajería

Vert.x ofrece un bus de eventos que permite que los diferentes componentes de una
aplicación interactúen mediante mensajes. Los mensajes se envían a direcciones y
tienen un conjunto de encabezados y un cuerpo. Una dirección es una cadena opaca
que representa un destino. Los consumidores de mensajes se registran en direcciones
para recibir los mensajes. El bus de eventos también está agrupado, lo que significa
que puede enviar mensajes a través de la red entre remitentes distribuidos y
consumidores. Al iniciar una aplicación Vert.x en modo de clúster, los nodos se
conectan para habilitar la estructura de datos compartidos, la detección de fallos de
parada y la comunicación de grupo de equilibrio de carga. El bus de eventos puede
enviar mensajes entre todos los nodos del clúster. Para crear tal configuración en
clúster, puede usar Apache Ignite, Apache Zookeeper, Infinispan o Hazelcast. Mientras
Infinispan (o la tecnología que elija) administra el descubrimiento y el inventario de
nodos, la comunicación del bus de eventos utiliza conexiones TCP de igual a igual. El
bus de eventos proporciona tres tipos de semánticas de entrega. Primero, el método de
envío permite que un componente envíe un mensaje a una dirección. Un solo
consumidor va a recibir el mensaje. Si hay más de un consumidor registrado en esta
dirección, Vert.x aplica una estrategia de turnos para seleccionar un consumidor:
En contraste con el envío, puede utilizar el método de publicación para enviar el

mensaje a todos los consumidores registrados en la dirección. Finalmente, el método
de envío se puede utilizar con un controlador de respuesta. Este mecanismo de solicitud
/ respuesta permite implementar interacciones asíncronas basadas en mensajes entre
dos componentes:

2.6. Microservicios basados en mensajes

Vamos a volver a implementar el microservicio, esta vez utilizando un bus de eventos
en lugar de un servidor HTTP para recibir la solicitud. El microservicio respondió al
mensaje para proporcionar la respuesta.
2.6.1. Creación de proyectos
Vamos a crear un nuevo proyecto. Esta vez vamos a agregar la dependencia de
Infinispan, una cuadrícula de datos en memoria que se utilizará para administrar el
clúster:
Una vez generado, es posible que tengamos que configurar Infinispan para construir
el clúster. La configuración predeterminada utiliza multidifusión para descubrir los
nodos. Si su red admite multidifusión, debería estar bien. De lo contrario, compruebe
el directorio de recursos / clúster del repositorio de código
2.6.2. Escribir el artículo dirigido por el mensaje

Edite el archivo src / main / java / io / vertx / book / message / HelloMicroservice.java
y actualice el método de inicio para que sea:

Este código recupera el eventBus del objeto vertx y registra un consumidor en la

dirección hola. Cuando se recibe un mensaje, éste responde. Dependiendo de si el
mensaje entrante tiene o no un cuerpo vacío, calculamos una respuesta diferente.
Como en el ejemplo del capítulo anterior, devolvemos un objeto JSON. Quizás se
esté preguntando por qué agregamos la entrada servida por en JSON.
Verás por qué muy pronto. Ahora que el artículo está escrito, es hora de lanzarlo con:
El -cluster le dice a Vert.x que comience en modo cluster. Ahora vamos a escribir un
microservicio que consume este servicio.
2.7. Iniciar interacciones basadas en mensajes

En esta sección, crearemos otro microservicio para invocar el microservicio de saludo
enviando un mensaje a la dirección de saludo y obteniendo una respuesta. El
microservicio volverá a implementar la misma lógica que en el capítulo anterior e
invocará el servicio dos veces (una vez con Luke y otra con Leia). Como de costumbre,
vamos a crear un nuevo proyecto:
Aquí también agregamos el soporte de Vert.x RxJava para beneficiarse de las API de
RXified proporcionadas por Vert.x. Si actualizó la configuración de Infinispan en la

sección anterior, necesita copiarla en este nuevo proyecto. Ahora edite el vicio
io.vertx.book.message.HelloConsumerMicroser. Como vamos a usar RxJava, cambie
la declaración de importación para que coincida con
io.vertx.rxjava.core.AbstractVerticle. Luego implementa el método de inicio con:
Este código es muy similar al código del capítulo anterior. En lugar de usar un
WebClient para invocar un punto final HTTP, usaremos el bus de eventos para enviar
un mensaje a la dirección de saludo y extraer el cuerpo de la respuesta. Usamos la
operación zip para recuperar las dos respuestas y generar el resultado final. En el
método de suscripción, imprimimos el resultado final en la consola o imprimimos el
seguimiento de la pila. Combinemos esto con un servidor HTTP. Cuando se recibe una
solicitud HTTP, invocamos el servicio de saludo dos veces y devolvemos el resultado
generado como respuesta:

El último código simplemente envuelve las interacciones del bus de eventos en un

requestHandler y se ocupa de la respuesta HTTP. En caso de fallo, devolvemos un
objeto JSON que contiene un mensaje de error.

2.8. ¿Somos reactivos ahora?

El código está muy cerca del microservicio basado en HTTP que escribimos
anteriormente. La única diferencia es que usamos un bus de eventos en lugar de HTTP.
¿Cambia esto nuestra reactividad?
2.8.1. Elasticidad
La elasticidad es una de las características no aplicadas por la versión HTTP del
microservicio. Debido a que el microservicio estaba dirigido a una instancia
específica del microservicio (usando una URL codificada), no proporcionó la
elasticidad que necesitamos. Pero ahora que estamos usando mensajes enviados a una
dirección, esto cambia el juego. Veamos cómo se comporta este sistema de
microservicio. Recuerda la salida de la ejecución anterior. Los objetos JSON
devueltos muestran el artículo que ha calculado el mensaje de saludo. La salida
siempre muestra el mismo artículo. El mensaje indicaba la misma instancia.
Esperábamos esto porque teníamos una sola instancia en ejecución. Ahora veamos
que pasa con dos. Detenga el vertx: ejecute la ejecución del microservicio y ejecute:
mvn clean package
Luego, abra dos terminales diferentes en el directorio hello-microservicemessage y
ejecute el siguiente comando (en cada terminal):
Esto lanza dos instancias del microservicio Hello. Vuelva a su navegador y actualice
la página y debería ver algo como:
Se utilizan las dos instancias de Hello. El clúster Vert.x conecta los diferentes nodos,
y el bus de eventos está agrupado. Gracias al round-robin del bus de eventos, el bus de
eventos Vert.x envía mensajes a las instancias disponibles y, por lo tanto, equilibra la
carga entre los diferentes nodos que escuchan la misma dirección.
2.8.2. Resistencia
¿Qué pasa con la resiliencia? En el código actual, si fallase el microservicio de saludo,
obtendríamos un error y ejecutaríamos este código:

A pesar de que el usuario recibe un mensaje de error, no nos caemos, no limitamos

nuestra escalabilidad y aún podemos manejar las solicitudes. Sin embargo, para
mejorar la experiencia del usuario, siempre debemos responder de manera oportuna
al usuario, incluso si no recibimos las respuestas del servicio.
Para implementar esta lógica, podemos mejorar el código con un tiempo de espera.
Para ilustrar esto, modifiquemos el microservicio Hello para inyectar fallas y malos
comportamientos. Este código se encuentra en el directorio microservices / hello-
microservice-faulty del repositorio de códigos.
Este nuevo método de inicio selecciona aleatoriamente una de las tres estrategias: (1)
responder con un error explícito, (2) olvidar responder (lo que lleva a un tiempo de
espera en el lado del consumidor), o (3) enviar el resultado correcto.
Vuelva a empaquetar y reinicie las dos instancias del microservicio Hello. Con esta
inyección de fallas implementada, debemos mejorar la tolerancia a fallas de nuestros
consumidores. De hecho, el consumidor puede obtener un tiempo de espera o recibir
una falla explícita. En el microservicio de consumo hola, cambie la forma en que
invocamos el servicio de saludo para:

Este código se encuentra en el directorio microservices / hello-

consumermicroservice-timeout del repositorio de códigos. El método de tiempo de
espera emite una falla si no recibimos una respuesta en el tiempo dado. El método de
reintento vuelve a intentar recuperar el valor si se produce un error en forma de tiempo
de espera o un error explícito. El método subscribeOn indica en qué hilo deben
realizarse las invocaciones. Usamos el bucle de eventos Vert.x para llamar a nuestras
devoluciones de llamada. Sin esto, los métodos serían ejecutados por un subproceso
del conjunto de subprocesos RxJava predeterminado, rompiendo el modelo de
subprocesos Vert.x. La clase RXHelper es proporcionada por Vert.x. Reintentar
ciegamente las invocaciones de servicio no es una estrategia de tolerancia a fallos
muy inteligente. Incluso puede ser perjudicial.
3 CONSTRUCCIÓN DE SISTEMAS DE MICROSERVICIOS

REACTIVOS.
3.1 Descubrimiento de servicios

Cuando tiene un conjunto de microservicios, la primera pregunta que debe responder
es: ¿cómo se ubicarán estos microservicios? Para comunicarse con otro par, un
microservicio necesita saber su dirección. Como hicimos en el capítulo anterior,
podríamos codificar la dirección (dirección del bus de eventos, URL, detalles de
ubicación, etc.) en el código o externalizarla en un archivo de configuración. Sin
embargo, esta solución no permite la movilidad. Su aplicación será bastante rígida y
las diferentes piezas no podrán moverse, lo que contradice lo que intentamos lograr
con microservicios.

3.1.1. Descubrimiento de servicios del lado del cliente y del servidor

Los microservicios necesitan ser móviles pero direccionables. Un consumidor debe
poder comunicarse con un microservicio sin saber de antemano su ubicación exacta,
especialmente porque esta ubicación puede cambiar con el tiempo. La transparencia
de la ubicación proporciona elasticidad y dinamismo: el consumidor puede llamar a
diferentes instancias del microservicio utilizando una estrategia round-robin, y entre
dos invocaciones el microservicio puede haberse movido o actualizado. La
transparencia de la ubicación se puede abordar mediante un patrón llamado
descubrimiento de servicios. Cada microservicio debe anunciar cómo puede
invocarse y sus características, incluida su ubicación, por supuesto, pero también
otros metadatos, como políticas de seguridad o versiones. Estos anuncios se
almacenan en la infraestructura de descubrimiento de servicios, que generalmente es
un registro de servicios proporcionado por el entorno de ejecución. Un microservicio
también puede decidir retirar su servicio del registro. Un microservicio que busca otro
servicio también puede buscar en este registro de servicios para encontrar servicios
coincidentes, seleccionar el mejor (utilizando cualquier tipo de criterio) y comenzar
a usarlo.
Se pueden utilizar dos tipos de patrones para consumir servicios. Cuando se utiliza la
detección de servicios del lado del cliente, el servicio del consumidor busca un
servicio basado en su nombre y metadatos en el registro de servicios, selecciona un
servicio coincidente y lo usa. La referencia recuperada del registro de servicios
contiene un enlace directo a un microservicio. Como los microservicios son entidades
dinámicas, la infraestructura de descubrimiento de servicios no solo debe permitir
que los proveedores publiquen sus servicios y que los consumidores busquen
servicios, sino que también proporcionen información sobre las llegadas y salidas de
servicios. Cuando se utiliza la detección de servicios del lado del cliente, el registro
de servicios puede adoptar diversas formas, como una estructura de datos

distribuidos, una infraestructura dedicada como Consul, o puede almacenarse en un

servicio de inventario como Apache Zookeeper o Redis.
Alternativamente, puede usar la detección de servicios del lado del servidor y dejar
que un equilibrador de carga, un enrutador, un proxy o una puerta de enlace de la API
administren la detección por usted.El consumidor sigue buscando un servicio basado
en su nombre y metadatos, pero recupera una dirección virtual. Cuando el consumidor
invoca el servicio, la solicitud se enruta a la implementación real. Utilizaría este
mecanismo en Kubernetes o cuando utilice el Elastic Load Balancer de AWS.
3.1.3. Descubrimiento de servicios Vert.x

Vert.x proporciona un mecanismo de descubrimiento de servicio extensible. Puede
usar la detección de servicios del lado del cliente o del servidor utilizando la misma
API. El descubrimiento de servicios Vert.x puede importar o exportar servicios de
muchos tipos de infraestructuras de descubrimiento de servicios, como Cónsul o
Kubernetes. También se puede utilizar sin ninguna infraestructura dedicada de
descubrimiento de servicios. En este caso, utiliza una estructura de datos distribuida
compartida en el clúster Vert.x

Puede recuperar servicios por tipos para obtener un cliente de servicio configurado
listo para ser utilizado. Un tipo de servicio puede ser un punto final HTTP, una
dirección de bus de eventos, una fuente de datos, etc. Por ejemplo, si desea recuperar
el punto final HTTP llamado hola que implementamos en el capítulo anterior,
escribiría el siguiente código:
El WebClient recuperado se configura con la ubicación del servicio, lo que significa

que puede usarlo inmediatamente para llamar al servicio. Si su entorno utiliza el
descubrimiento del lado del cliente, la URL configurada se dirige a una instancia
específica del servicio. Si está utilizando el descubrimiento del lado del servidor, el
cliente usa una URL virtual.
Dependiendo de su infraestructura de tiempo de ejecución, es posible que deba
registrar su servicio. Pero cuando usa el descubrimiento de servicios del lado del
servidor, generalmente no tiene que hacer esto ya que declara su servicio cuando se

implementa. De lo contrario, necesita publicar su servicio explícitamente. Para

publicar un servicio, debe crear un Registro que contenga el nombre del servicio, la
ubicación y los metadatos:
El descubrimiento de servicios es un componente clave en una infraestructura de

microservicios. Permite dinamismo, transparencia de ubicación y movilidad. Cuando
se trata de un pequeño conjunto de servicios, el descubrimiento de servicios puede
parecer engorroso, pero es imprescindible cuando su sistema crece. El descubrimiento
de servicios Vert.x le proporciona una API única, independientemente de la
infraestructura y el tipo de descubrimiento de servicios que utilice. Sin embargo,
cuando su sistema crece, también hay otra variable que crece exponencialmente: las
fallas.
3.2 Patrones de Estabilidad y Resiliencia

Cuando se trata de sistemas distribuidos, los fallos son ciudadanos de primera clase y hay
que vivir con ellos. Sus microservicios deben tener en cuenta que los servicios que invocan
pueden fallar por muchas razones. Cada interacción entre microservicios eventualmente
fallará de alguna manera, y usted debe estar preparado para esa falla. La falla puede tomar
diferentes formas, desde varios errores de red hasta errores semánticos.

3.2.1 Gestión de Fallos en Microservicios Reactivos

Los microservicios reactivos son responsables de gestionar los fallos localmente. Deben
evitar propagar el fallo a otro microservicio. En otras palabras, no debe delegar la papa
caliente a otro microservicio. Por lo tanto, el código de un microservicio reactivo considera
las fallas como ciudadanos de primera clase.
El modelo de desarrollo Vert.x hace que los fallos sean una entidad central. Cuando se utiliza
el modelo de desarrollo de devolución de llamada, los Manejadores a menudo reciben un
AsyncResult como parámetro. Esta estructura encapsula el resultado de una operación
asíncrona. En el caso de éxito, puede recuperar el resultado. En caso de fallo, contiene un
Throwable que describe el fallo:
client.get("/").as(BodyCodec.jsonObject())
.send(ar -> {
if (ar.failed()) {
Throwable cause = ar.cause();
// Necesitas gestionar el fallo.
} else {
// Es un exito
JsonObject json = ar.result().body();
}
});
Cuando se usan las API de RxJava, la administración de fallas se puede hacer en el método
de suscripción:
.rxSend()
.map(HttpResponse::body)
.subscribe(
json -> { /* success */ },
err -> { /* failure */ }
);
Si se produce una falla en una de las secuencias observadas, se llama al manejador de errores.
También puede manejar el error antes, evitando el controlador de errores en el método de
suscripción:
.rxSend()
.map(HttpResponse::body)

.onErrorReturn(t -> {
// Llamado si rxSend produce una falla
// Podemos devolver un valor por defecto
return new JsonObject();
})
.subscribe(
json -> {
// Siempre llamado, ya sea con el resultado
real.
// o con el valor por defecto.
}
);
Gestionar errores no es divertido pero hay que hacerlo. El código de un microservicio

reactivo es responsable de tomar una decisión adecuada ante un fallo. También debe estar
preparado para ver fallar sus solicitudes a otros microservicios.
3.2.2 Usando tiempos de espera

Cuando se trata de interacciones distribuidas, a menudo utilizamos tiempos de espera. Un
tiempo de espera es un mecanismo simple que le permite dejar de esperar una respuesta una
vez que piensa que no llegará. Los tiempos de espera bien colocados proporcionan
aislamiento de fallas, asegurando que la falla se limite al microservicio al que afecta y
permitiéndole manejar el tiempo de espera y continuar su ejecución en un modo degradado.
client.get(path)
.rxSend() // Invocar el servicio
// Necesitamos estar seguros de usar el bucle de eventos Vert.x
.subscribeOn(RxHelper.scheduler(vertx))
// Configurar el tiempo de espera, si no hay respuesta, publica
// un fallo en lo observable
.timeout(5, TimeUnit.SECONDS)
// En caso de éxito, extraer el cuerpo.
.map(HttpResponse::bodyAsJsonObject)
// De lo contrario, use un resultado de reserva.
// tiempo de espera u otra excepción
return new JsonObject().put("message", "D'oh! Timeout");
})
.subscribe(
json -> {
System.out.println(json.encode());

}
);
Los tiempos de espera a menudo se utilizan junto con los reintentos. Cuando se produce un
tiempo de espera, podemos intentarlo de nuevo. Inmediatamente, volver a intentar una
operación después de una falla tiene varios efectos, pero solo algunos de ellos son
beneficiosos.
Si la operación falló debido a un problema importante en el microservicio llamado, es

probable que vuelva a fallar si se reintenta de inmediato. Sin embargo, algunos tipos de fallas
transitorias se pueden superar con un reintento, especialmente fallas en la red, como mensajes
caídos. Puede decidir si volver a intentar la operación de la siguiente manera:
client.get(path)
.rxSend()
.subscribeOn(RxHelper.scheduler(vertx))
.timeout(5, TimeUnit.SECONDS)
// Configurar el número de reintentos.
// Aquí reintentamos solo una vez.
.retry(1)
return new JsonObject().put("message", "D'oh! Timeout");
})
.subscribe(
json -> System.out.println(json.encode())
);
También es importante recordar que un tiempo de espera no implica un fallo de operación.

En un sistema distribuido, hay muchas razones para el fracaso. Veamos un ejemplo. Tiene
dos microservicios, A y B. A está enviando una solicitud a B, pero la respuesta no llega a
tiempo y A obtiene un tiempo de espera. En este escenario, podrían haber ocurrido tres tipos
de fallas:
1. El mensaje entre A y B se ha perdido, la operación no se ejecuta.

2. La operación en B falló: la operación no ha completado su ejecución.
3. El mensaje de respuesta entre B y A se ha perdido: la operación se ejecutó con éxito,
pero A no obtuvo la respuesta.
Este último caso es a menudo ignorado y puede ser perjudicial. En este caso, la combinación
del tiempo de espera con un reintento puede romper la integridad del sistema. Los reintentos
solo se pueden usar con operaciones idempotentes, es decir, con operaciones que puede

invocar varias veces sin cambiar el resultado más allá de la llamada inicial. Antes de volver
a intentarlo, compruebe siempre que su sistema puede manejar las operaciones reintentadas
con gracia.
Reintentar también hace que el consumidor espere aún más para obtener una respuesta, lo
cual tampoco es bueno. A menudo es mejor devolver un respaldo que reintentar una
operación demasiadas veces. Además, martillar continuamente un servicio que falla no puede
ayudarlo a volver a la pista. Estas dos preocupaciones son manejadas por otro patrón de
resiliencia: el interruptor automático.
3.2.3 Rompedores de circuito

Un interruptor de circuito es un patrón que se usa para tratar fallas repetitivas. Protege a un
microservicio de llamar a un servicio fallido una y otra vez. Un interruptor automático es un
autómata de tres estados que gestiona una interacción (Figura 4-4). Comienza en un estado
cerrado en el que el disyuntor ejecuta operaciones como de costumbre. Si la interacción tiene
éxito, no pasa nada. Sin embargo, si falla, el interruptor toma nota de la falla. Una vez que el
número de fallas (o la frecuencia de las fallas, en casos más sofisticados) excede un umbral,
el interruptor automático cambia a un estado abierto. En este estado, las llamadas al
interruptor automático fallan inmediatamente sin ningún intento de ejecutar la interacción
subyacente. En lugar de ejecutar la operación, el interruptor de circuito puede ejecutar un
repliegue, proporcionando un resultado predeterminado. Después de una cantidad de tiempo
configurada, el interruptor de circuito decide que la operación tiene posibilidades de éxito,
por lo que entra en un estado medio abierto. En este estado, la siguiente llamada al interruptor
automático ejecuta la interacción subyacente. Dependiendo del resultado de esta llamada, el
interruptor automático se restablece y regresa al estado cerrado, o regresa al estado abierto
hasta que transcurra otro tiempo de espera.
Figura 4-4. Estados de disyuntor
La implementación de interruptores automáticos más conocida en Java es Hystrix

(https://github.com/Net ﬂ ix / Hystrix). Si bien puede usar Hystrix en un microservicio Vert.x

(usa un grupo de subprocesos), necesita cambiar explícitamente al bucle de eventos Vert.x

para ejecutar las diferentes devoluciones de llamada. Alternativamente, puede utilizar el
disyuntor de circuito Vert.x creado para operaciones asíncronas y aplicar el modelo de
desarrollo asíncrono sin bloqueo Vert.x.
Imaginemos un microservicio de hola fallido. El consumidor debe proteger las interacciones

con este servicio y usar un interruptor automático de la siguiente manera:
CircuitBreaker circuit = CircuitBreaker.create("my-circuit",
vertx, new CircuitBreakerOptions()
.setFallbackOnFailure(true)// Llame a la alternativa
// en fallas
.setTimeout(2000) // Establecer el tiempo de espera de la operación
.setMaxFailures(5) // Número de fallos anteriores
// cambiar a
// estado 'open'
.setResetTimeout(5000) // Tiempo antes de intentar
// reiniciar
// el interruptor de circuito
);
// ...
circuit.rxExecuteCommandWi thFallback(
future ->
client.get(path)
.rxSend()
.subscribe(future::complete, future::fail),
t -> new JsonObject().put("message", "D'oh! Fallback")
).subscribe(
json -> {
// Obtener el json real o el valor de reserva
System.out.println(json.encode());
}
);
En este código, la interacción HTTP está protegida por el interruptor automático. Cuando el
número de fallas alcanza el umbral configurado, el interruptor de circuito dejará de llamar al
microservicio y, en su lugar, llamará un repliegue. Periódicamente, el interruptor automático
dejará pasar una invocación para verificar si el microservicio está de nuevo en marcha y
actuará en consecuencia. Este ejemplo utiliza un cliente web, pero cualquier interacción
puede administrarse con un interruptor de circuito y protegerlo contra servicios escamosos,
excepciones y otros tipos de fallas.

Un interruptor de circuito que cambie a un estado abierto debe ser supervisado por su equipo
de operaciones. Tanto Hystrix como el interruptor de circuito Vert.x tienen capacidades de
monitoreo.
3.2.4 Controles de Salud y de Conmutación por error

Si bien los tiempos de espera y los interruptores automáticos permiten a los consumidores
lidiar con fallas de su lado, ¿qué pasa con los accidentes? Cuando se enfrenta a un bloqueo,
una estrategia de conmutación por error reinicia las partes del sistema que han fallado. Pero
antes de poder lograr esto, debemos poder detectar cuando un microservicio ha muerto.
Una comprobación de estado es una API proporcionada por un microservicio que indica su
estado. Le dice a la persona que llama si el servicio es bueno o no. La invocación a menudo
utiliza interacciones HTTP pero no es necesaria. Después de la invocación, se ejecuta un
conjunto de comprobaciones y el estado global se calcula y se devuelve. Cuando se detecta
que un microservicio no es saludable, no debe volver a llamarse, ya que el resultado
probablemente será un fracaso. Tenga en cuenta que llamar a un microservicio saludable
tampoco garantiza un éxito. Una comprobación de estado simplemente indica que el
microservicio se está ejecutando, no que manejará su solicitud con precisión o que la red
responderá.
Dependiendo de su entorno, puede tener diferentes niveles de controles de salud. Por

ejemplo, puede tener una verificación de preparación utilizada en el momento del despliegue
para determinar cuándo el microservicio está listo para atender solicitudes (cuando todo se
ha inicializado correctamente). Las comprobaciones de vitalidad se utilizan para detectar
comportamientos erróneos e indicar si el microservicio puede gestionar las solicitudes
correctamente. Cuando no se puede ejecutar una verificación de vida porque el microservicio
seleccionado no responde, es probable que el microservicio se haya bloqueado.
En una aplicación Vert.x, hay varias formas de implementar controles de estado.

Simplemente puede implementar una ruta que devuelva el estado, o incluso usar una solicitud
real. También puede utilizar el módulo de comprobación de estado Vert.x para implementar
varias comprobaciones de estado en su aplicación y componer los diferentes resultados. El
siguiente código da un ejemplo de una aplicación que proporciona dos niveles de controles
de estado:
Router router = Router.router(vertx);
HealthCheckHandler hch = HealthCheckHandler.create(vertx);
// Un procedimiento para verificar si podemos obtener una //conexión
de base de datos.
hch.register("db-connection", future -> {
client.rxGetConnection()
.subscribe(c -> {
future.complete();
c.close();

},
future::fail
);
});
// Un segundo procedimiento (comercial)
hch.register("business-check", future -> {
// ...
});
// Mapa/salud para el controlador de control de salud
router.get("/health").handler(hch);
// ...
Una vez que haya completado las comprobaciones de estado, puede implementar una
estrategia de conmutación por error. En general, la estrategia simplemente reinicia la parte
muerta del sistema, esperando lo mejor. Si bien la infraestructura de tiempo de ejecución a
menudo proporciona la conmutación por error, Vert.x ofrece una conmutación por error
integrada, que se activa cuando un nodo del clúster muere. Con la conmutación por error
Vert.x incorporada, no necesita una comprobación de estado personalizada, ya que el clúster
Vert.x emite nodos periódicamente. Cuando Vert.x pierde la pista de un nodo, Vert.x elige
un nodo en buen estado del clúster y vuelve a desplegar la parte muerta.
La conmutación por error mantiene el sistema en funcionamiento, pero no solucionará la

causa raíz de su trabajo. Cuando una aplicación muere inesperadamente, se debe realizar un
análisis de autopsia
4 DESPLIEGUE DE MICROSERVICIOS REACTIVOS EN

OPENSHIFT.
Hasta ahora, solo hemos implementado nuestros microservicios en una máquina local. ¿Qué
sucede cuando implementamos un microservicio en la nube? La mayoría de las plataformas
en la nube incluyen servicios para facilitar su implementación y operaciones. La capacidad
de escalar hacia arriba y hacia abajo y el equilibrio de carga son algunas de las características
comunes que son particularmente relevantes para el desarrollo de microservicios reactivos.
En este capítulo, veremos cómo se pueden usar estas características (y otras) para desarrollar
e implementar microservicios reactivos. Para ilustrar estos beneficios, utilizaremos

OpenShift (https://www.openshift.org/). Sin embargo, la mayoría de las plataformas de

nube modernas incluyen las características que usamos aquí. Al final de este capítulo, verá
cómo la nube facilita la reactividad para todos.
4.1 ¿Qué es OpenShift?

RedHat OpenShift v3 es una plataforma de contenedor de código abierto. Con OpenShift
usted implementa aplicaciones que se ejecutan en contenedores, lo que facilita su
construcción y administración. OpenShift está construido sobre Kubernetes
(https://kubernetes.io/).
Kubernetes (en azul en la Figura 5-1) es un proyecto con mucha funcionalidad para ejecutar
clústeres de microservicios dentro de contenedores de Linux a escala. Google ha
empaquetado más de una década de experiencia con contenedores en Kubernetes. OpenShift
se basa en esta experiencia y la amplía con la automatización de compilación y despliegue
(en verde en la Figura 5-1). Los casos de uso, como las actualizaciones sucesivas, los
despliegues de canarios y los procesos de entrega continua se proporcionan de forma
inmediata.

Figura 5-1. Plataforma de contenedores Te OpenShift
OpenShift tiene un puñado de entidades simples, como se muestra en la Figura 5-2, que
debemos comprender antes de ponerlo en funcionamiento.

Figura 5-2. Las entidades de OpenShift
4.1.1 Construir la configuración

La compilación es el proceso de creación de imágenes de contenedor que OpenShift utilizará
para crear una instancia de los diferentes contenedores que conforman una aplicación. Las
compilaciones de OpenShift pueden usar diferentes estrategias:
• Docker: crea una imagen desde un Dockerfile

• Fuente a imagen (S2I): cree una imagen a partir de la fuente de la aplicación, creada
en OpenShift por una imagen de constructor.
• Jenkins Pipeline: genere una imagen utilizando un pipeline de Jenkins
(https://jenkins.io/doc/book/pipeline) que posiblemente contenga múltiples etapas,
como compilación, pruebas e implementación.
Una configuración de compilación puede activarse automáticamente mediante un impulso de

Git, un cambio en la configuración o una actualización en una imagen dependiente y,
obviamente, de forma manual.
4.1.2 Configuraciones de implementación

Una configuración de implementación define la creación de instancias de la imagen
producida por una construcción. Define qué imagen se usa para crear los contenedores y la
cantidad de instancias que necesitamos para mantenernos vivos. También describe cuándo se
debe activar una implementación. Una implementación también actúa como un controlador
de replicación y es responsable de mantener los contenedores con vida. Para lograr esto, se
pasa el número de instancias deseadas. El número de instancias deseadas se puede ajustar a

lo largo del tiempo o en función de la fluctuación de la carga (escala automática). La

implementación también puede especificar controles de estado para administrar
actualizaciones continuas y detectar contenedores muertos.
4.1.3 Pods
Los “pods” son un grupo de uno o más contenedores. Sin embargo, normalmente se compone
de un solo contenedor. La organización, programación y administración de pod se delegan a
Kubernetes. Las vainas son fungibles y pueden ser reemplazadas en cualquier momento por
otra instancia. Por ejemplo, si el contenedor falla, se generará otra instancia.
4.1.4 Servicios y Rutas

Debido a que los pods son entidades dinámicas (la cantidad de instancias puede cambiar con
el tiempo), no podemos confiar en sus direcciones IP directas (cada pod tiene su propia
dirección IP). Los servicios nos permiten comunicarnos con los pods sin depender de sus
direcciones pero utilizando la dirección virtual del servicio. Un servicio actúa como un proxy
frente a un grupo de pods. También puede implementar una estrategia de equilibrio de carga.
Otras aplicaciones que se ejecutan en OpenShift pueden acceder a la funcionalidad que

ofrecen los pods a través del servicio, pero las aplicaciones externas necesitan una ruta. Una
ruta expone un servicio en un nombre de host como www.myservice.com para que los
clientes externos puedan acceder a él por su nombre.
4.2 Instalación de OpenShift en su máquina

Son suficientes conceptos abstractos. Ahora es el momento de la acción. Vamos a instalar
Openshift en su máquina utilizando Minishift (https://github.com/minishift/minishift).
Alternativamente, puede usar OpenShift en línea (https://www.openshift.com/devpreview/)
o el RedHat Container Development Kit v3 (https://developers.redhat.com/products/cdk/
download/).
Instalación de Minishift (https://github.com/minishift/minishift#installation) requiere un

hipervisor para ejecutar la máquina virtual que contiene OpenShift. Dependiendo de su
sistema operativo host, tiene una opción de hipervisores; Consulte la guía de instalación de
Minishift para más detalles.

Para instalar Minishift, simplemente descargue el archivo más reciente para su sistema
operativo desde la página de lanzamientos de Minishift
(https://github.com/minishift/minishift/releases), desempaquételo en su ubicación preferida y
agregue el binario de minishift a su RUTA Variable ambiental. Una vez instalado, inicie
Minishift usando:
minishift start
Una vez que comience, debería poder conectarse a su OpenShift nstance en

https://192.168.64.12:8443. Es posible que tenga que validar el certificado SSL. Inicia con
developer/developer.
También necesitamos el cliente OpenShift (oc), una utilidad de línea de comandos que se
utiliza para interactuar con su instancia de OpenShift. Descargue la versión más reciente del
cliente de OpenShift desde https://github.com/openshift/origin/releases/latest.
Descomprímalo en su ubicación preferida y agregue el binario oc a su variable de entorno
PATH.
Luego, conéctese a su instancia de OpenShift usando:
oc login https://192.168.64.12:8443 -u developer -p developer
OpenShift tiene un concepto de espacio de nombres llamado proyecto. Para crear proyectos
para los ejemplos que vamos a implementar, ejecute:
oc new-project reactive-microservices
oc policy add-role-to-user admin developer -n
reactive-microservices
oc policy add-role-to-user view -n reactive-microservices
-z default
En su navegador, abra https://192.168.64.12:8443/console/project/reactive-microservices/.
Debería poder ver el proyecto, que no es muy interesante en este momento ya que no hemos
implementado nada (Figura 5-3).

Figura 5-3. Proyecto creado
5 DESPLIEGUE DE UN MICROSERVICIO EN OPENSHIFT
Es hora de desplegar un microservicio a OpenShift. El código que somos El despliegue se

incluye en openshift / hellomicroservice- Abre el directorio del repositorio de códigos. El
artículo Está muy cerca del hello microservicio (HTTP) que desarrollamos más temprano:
package io.vertx.book.openshift;
import io.vertx.core.AbstractVerticle;
import io.vertx.core.http.HttpHeaders;
import io.vertx.core.json.JsonObject;
import io.vertx.ext.web.*;
public class HelloHttpVerticle extends AbstractVerticle {
static final String HOSTNAME = System.getenv("HOSTNAME");
@Override
public void start() {
router.get("/").handler(this::hello);
router.get("/:name").handler(this::hello);
vertx.createHttpServer()
.requestHandler(router::accept)
.listen(8080);

}
private void hello(RoutingContext rc) {
String message = "hello";
if (rc.pathParam("name") != null) {
message += " " + rc.pathParam("name");
}
JsonObject json = new JsonObject()
.put("message", message)
.put("served-by", HOSTNAME);
rc.response()
.putHeader(HttpHeaders.CONTENT_TYPE, "application/json")
.end(json.encode());
}
}
Este código no se basa en construcciones o API específicas de OpenShift. Es tu aplicación

como la habrías desarrollado en tu máquina.
La separación del código Java de las opciones de implementación debe ser una elección
deliberada de diseño para que el código pueda ejecutarse en cualquier plataforma de nube.
Podríamos crear todas las entidades de OpenShift manualmente, pero utilicemos el

complemento de Maven (https://maven.fabric8.io/) proporcionado por Fabric8, una
plataforma de desarrollo de extremo a extremo para Kubernetes. Si abres el archivo pom.xml,
verá que este complemento está configurado en el perfil de cambio abierto y colabora con el
complemento Vert.x Maven para crear las entidades de OpenShift.
Para empaquetar e implementar nuestro microservicio en OpenShift, inicie: mvn fabric8:

deploy –Popenshift. Este comando interactúa con su instancia de OpenShift (en la que ha
iniciado sesión con oc) para crear una compilación (utilizando la estrategia de compilación
de origen a imagen) y desencadenarla. Esta primera compilación puede llevar algo de tiempo,
ya que necesita recuperar la imagen del constructor. No te preocupes, una vez todo se
almacena en caché, las compilaciones se crearán más rápido. La configuración de
implementación utiliza la salida de la compilación (y la imagen), que también es creada por

el complemento Fabric8 Maven. Por defecto, crea un pod. El complemento también crea un
servicio. Puede encontrar toda esta información en el panel de OpenShift, como se muestra
en la Figura 5-4.
Figura 5-4. Entidades creadas durante nuestro primer despliegue
Las rutas no se crean de forma predeterminada por el complemento Fabric8 Maven. Sin
embargo, creamos uno a partir de su descripción (src / main / fabric8 / route.yml). Si abre su
navegador en http://hello-microservicereactive-microservices.192.168.64.nip.io/Luke,
debería ver algo como:
{"message":"hello Luke","served-by":
"hello-microservice-1-9r8uv"}
hello-microservice-1-9r8uv es el nombre del pod que sirve la solicitud.
5.1 Descubrimiento de servicios

Ahora que hemos implementado el microservicio hello, consumámoslo desde otro
microservicio. El código que vamos a implementar en esta sección se encuentra en el
directorio openshift / hello-microserviceconsumer-openshift del repositorio de
códigos.

Para consumir un microservicio, primero tenemos que encontrarlo. OpenShift

proporciona un mecanismo de descubrimiento de servicios. La búsqueda de servicios
se puede realizar utilizando variables de entorno, DNS o el descubrimiento del servicio
Vert.x que utilizamos aquí. El proyecto pom.xml está configurado para importar el
descubrimiento del servicio Vert.x, el importador del servicio Kubernetes y el
descubrimiento del servicio del lado del servidor. No tiene que registrar explícitamente
el servicio en el lado del proveedor ya que el complemento Fabric8 Maven declara un
servicio para nosotros. Nuestro consumidor va a recuperar este servicio OpenShift y
no los pods.
@Override
router.get("/").handler(this::invokeHelloMicroservice);
// Create the service discovery instance
ServiceDiscovery.create(vertx, discovery -> {
// Look for an HTTP endpoint named "hello-microservice"
// you can also filter on 'label'
Single<WebClient> single = HttpEndpoint.rxGetWebClient
(discovery, rec -> rec.getName().equals
("hello-microservice"),
new JsonObject().put("keepAlive", false));
single.subscribe(
client -> {
// the configured client to call the microservice
this.hello = client;
.listen(8080);
},
err -> System.out.println("Oh no, no service")
);

});
}
En el método de inicio, usamos el descubrimiento de servicios para encontrar el

microservicio hello. Luego, si el servicio está disponible, iniciamos el servidor HTTP
y mantenemos una referencia en el WebClient recuperado. También pasamos una
configuración al WebClient y deshabilitamos la configuración de mantener viva
(veremos la razón de esto en unos minutos). En el invocoHelloMicroservice, no
tenemos que pasar el puerto y el host al método rxSend (como hicimos anteriormente).
De hecho, el WebClient está configurado para apuntar al servicio de saludo:
HttpRequest<JsonObject> request1 = hello.get("/Luke")

.as(BodyCodec.jsonObject());
HttpRequest<JsonObject> request2 = hello.get("/Leia")
Single<JsonObject> s1 = request1.rxSend()
.map(HttpResponse::body);
Single<JsonObject> s2 = request2.rxSend()
.map(HttpResponse::body);
// ...
En una terminal, navegue hasta el directorio openshift / hello-microservices consumer-

openshift para compilar e implementar este consumidor con:
mvn fabric8:deploy –Popenshift
Ruta (http://bit.ly/2o4xaSk). Si abre la ruta asociada con el servicio hello-consumer

(http://bit.ly/2p2aHTK), debería ver:
{
"luke" : "hello Luke hello-microservice-1-sa5pf",
"leia" : "hello Leia hello-microservice-1-sa5pf"
}
Es posible que vea una página de error 503, ya que el pod aún no se ha iniciado. Solo
actualiza hasta que obtengas la página correcta. Hasta ahora, nada sorprendente. Los

valores de publicación mostrados siempre indican el mismo pod (ya que solo tenemos
uno).
5.2 Escalar hacia arriba y hacia abajo

Si estamos utilizando una plataforma en la nube, es principalmente por motivos de
escalabilidad.
Queremos poder aumentar y disminuir el número de instancias de nuestra aplicación

dependiendo de la carga. En el panel de OpenShift podemos escalar el número de pods
hacia arriba y hacia abajo, como se muestra en la Figura 5-5.
Figura 5-5. Escalar hacia arriba y hacia abajo
También puede establecer el número de réplicas usando la línea de comando oc:
# scale up to 2 replicas
oc scale --replicas=2 dc hello-microservice
# scale down to 0
Vamos a crear una segunda instancia de nuestro microservicio de saludo. Luego, espere
hasta que el segundo microservicio se haya iniciado correctamente (el tiempo de espera
es molesto, pero lo solucionaremos más adelante), y vuelva a la página de
helloconsumer en un navegador. Deberías ver algo como:
{
"luke" : "hello Luke hello-microservice-1-h6bs6",

"leia" : "hello Leia hello-microservice-1-keq8s"

}
Si actualiza varias veces, verá que el servicio OpenShift equilibra la carga entre las dos
instancias. Te acuerdas de la ¿Mantenemos la configuración para mantenernos vivos?
Cuando la conexión HTTP usa una conexión de mantenimiento, OpenShift reenvía la
solicitud al mismo pod, proporcionando afinidad de conexión. Tenga en cuenta que en
la práctica, keep-alive es un encabezado muy deseable ya que permite reutilizar las
conexiones.
En el escenario anterior hay un pequeño problema. Cuando escalamos, OpenShift

comienza a enviar solicitudes al nuevo pod sin verificar Si la aplicación está lista para
atender estas solicitudes. Entonces nuestro el consumidor puede llamar a un
microservicio que no está listo y obtener un fallo.
Hay un par de maneras de abordar esto:
1. Uso de controles de salud en el microservicio.

2. Esté preparado para enfrentar la falla en el código del consumidor
5.3 Comprobación de estado y conmutación por error

En OpenShift puedes declarar dos tipos de cheques. Controles de preparación. Se
utilizan para evitar el tiempo de inactividad al actualizar un microservicio. En un
balanceo actualización, OpenShift espera hasta que la nueva versión esté lista antes
apagando la versión anterior. Hace ping al chequeo de preparación punto final del
nuevo microservicio hasta que esté listo, y verifica que El microservicio ha sido
inicializado con éxito. Controles de vitalidad se utilizan para determinar si una vaina
está viva. OpenShift invoca el Revisar el punto final de forma periódica. Si un pod no
responde positivamente Al cheque, se reiniciará. Una verificación de vida se centra en
Los recursos críticos requeridos por el microservicio para comportarse correctamente.
En el siguiente ejemplo usaremos el mismo punto final para ambos cheques Sin
embargo, es mejor utilizar dos puntos finales diferentes.

El código de este ejemplo se encuentra en openshift / hellomicroservice-Directorio de

openshift-health-checks. Si abres en el artículo, verá el controlador HealthCheck que
verifica si o no se ha iniciado el servidor HTTP:
private boolean started;

@Override
router.get("/health").handler(
HealthCheckHandler.create(vertx)
.register("http-server-running",
future -> future.complete(
started ? Status.OK() : Status.KO())));
router.get("/").handler(this::hello);
router.get("/:name").handler(this::hello);
.listen(8080, ar -> started = ar.succeeded());
}
El complemento Fabric8 Maven está configurado para usar / health para las
comprobaciones de estado de preparación y vida. Una vez implementada esta versión
de hello microservice, todas las implementaciones posteriores utilizarán la verificación
de preparación para evitar el tiempo de inactividad, como se muestra en la Figura 5-6.

Figura 5-6. Actualizaciones sucesivas
Cuando el pod está listo, OpenShift enruta las solicitudes a este pod y apaga el viejo.
Cuando escalamos, OpenShift no enrutar las solicitudes a un pod que no esté listo.
5.4 Usando un disyuntor

Mientras se usan las comprobaciones de salud, se evita llamar a un microservicio que
no está listos y reinicia los muertos, todavía necesitamos protegernos de otros fallos
como tiempos de espera, cortes de red, errores en el llamado. microservicio, y así
sucesivamente. En esta sección vamos a proteger el hola consumidor usando un
interruptor de circuito. El código de esta sección es ubicado en el openshift / hello-
microservice-consumeropenshift- directorio de disyuntores.
En el artículo, estamos usando un solo interruptor para proteger Contra las dos llamadas
al hola microservicio. El siguiente código usa este diseño; Sin embargo, es sólo uno
entre un gran conjunto de posibles enfoques, como el uso de un interruptor automático
por llamada, el uso de un solo interruptor de circuito pero protegiendo las dos llamadas
de forma independiente, etc .:
private void invokeHelloMicroservice(RoutingContext rc) {

circuit.rxExecuteCommandWithFallback(
future -> {
HttpRequest<JsonObject> request1 = hello.get("/Luke")

HttpRequest<JsonObject> request2 = hello.get("/Leia")
Single<JsonObject> s1 = request1
.rxSend().map(HttpResponse::body);
Single<JsonObject> s2 = request2
.rxSend().map(HttpResponse::body);
Single
.zip(s1, s2, (luke, leia) -> {
// We have the result of both request in Luke and Leia
return new JsonObject()
.put("Luke", luke.getString("message")
+ " " + luke.getString("served-by"))
.put("Leia", leia.getString("message")
+ " " + leia.getString("served-by"));
})
.subscribe(future::complete, future::fail);
},
error -> new JsonObject().put("message", "hello (fallback, "
+ circuit.state().toString() + ")")
).subscribe(
x -> rc.response().end(x.encodePrettily()),
t -> rc.response().end(t.getMessage()));
}
En caso de error, proporcionamos un mensaje de respaldo que indica el estado del

interruptor. Esto nos ayudará a entender lo que está pasando.
Implementar este proyecto usando:
mvn fabric8:deploy –Popenshift
Ahora reduzcamos el microservicio de saludo a 0. Para hacer esto, podemos haga clic
en la flecha hacia abajo cerca del pod, o ejecute:

Ahora si actualiza la página del consumidor (http://hello-consumerreactive-

microservicios.192.168.64.12.nip.io/), debería ver el respaldo mensaje. Las tres
primeras solicitudes muestran:
{
"message" : "hello (fallback, CLOSED)"
}
Una vez que se alcanza el número de fallas, devuelve:

{
"message" : "hello (fallback, OPEN)"
}
Si restaura el número de réplicas a 1 con:
debería recuperar la salida normal una vez que el microservicio esté listo.
5.5 Pero espera, ¿somos reactivos?

Sí somos. A ver por qué.
Todas nuestras interacciones son asíncronas. Utilizan asíncronos y Solicitudes y
respuestas HTTP sin bloqueo. Además, gracias a el servicio OpenShift, estamos
enviando las solicitudes a una dirección, virtual que permite la elasticidad. El servicio
equilibra la carga. Entre un conjunto de vainas. Podemos fácilmente escalar hacia
arriba y hacia abajo ajustando el número de vainas o mediante el escalado automático.
También somos resistentes.
Gracias a los controles de salud, tenemos un mecanismo de conmutación por error que
garantiza. Siempre tenemos el número correcto de pods corriendo. En el consumidor
Por otro lado, podemos usar varios patrones de resiliencia como tiempos de espera,
reintentos, o disyuntores para proteger el microservicio de fallos. Entonces nuestro el
sistema es capaz de manejar solicitudes de manera oportuna bajo carga y
ante las fallas: ¡somos receptivos!

¿Puede cualquier sistema que utilice HTTP sin bloqueo asíncrono ser reactivo?
Sistema en una nube que proporciona equilibrio de carga y cierta capacidad de
recuperación. ¿caracteristicas? Sí, pero no olvides los costes. Vert.x usa un bucle de
evento para manejar un alto nivel de concurrencia con un mínimo de subprocesos,
Exhibiendo una nube nativa de la naturaleza. Cuando se utilizan enfoques basados en
grupos de subprocesos, necesitará
1) ajustar el grupo de subprocesos para encontrar el Talla correcta;
2) manejar la concurrencia en su código, lo que significa depuración de puntos muertos,
condiciones de carrera y cuellos de botella; y
3) monitor
actuación. Los entornos de nube se basan en la virtualización, y la programación de
subprocesos puede convertirse en un problema importante cuando tiene muchos hilos.
Hay muchas tecnologías de no bloqueo, pero no todas utilizan El mismo modelo de
ejecución para manejar la naturaleza asíncrona. Puede clasificar estas tecnologías en
tres categorías:
1. Enfoques utilizando un grupo de subprocesos en segundo plano: luego se enfrentan
a un reto de ajuste, programación y concurrencia cambiando la carga a ops.
2. Enfoques que usan otro hilo para las devoluciones de llamada: todavía necesita para
gestionar la seguridad de subprocesos de su código y evitar puntos muertos y cuellos
de botella.
3. Enfoques, como Vert.x, que usan el mismo hilo: se usa un un pequeño número de
subprocesos y se liberan de la depuración de puntos muertos.
¿Podríamos usar sistemas de mensajería en la nube para implementar reactivos?
sistemas de microservicio? Por supuesto. Podríamos haber utilizado el Vert.x Bus de
eventos para construir nuestro microservicio reactivo en OpenShift. Pero No habría
demostrado servicio de dirección virtual y balanceo de carga. proporcionado por
OpenShift como habría sido manejado por Vert.x en sí. Aquí decidimos ir con HTTP,
un diseño entre un número infinito de opciones. Da forma a tu sistema de la forma que
quieras ¡eso!

5.6 Resumen
En este capítulo, desplegamos microservicios en OpenShift y vimos cómo se combinan
las características de Vert.x y OpenShift para construir reactivo microservicios
Combinando servidores y clientes HTTP asíncronos, Servicios OpenShift, balanceo de
carga, failover y del lado del consumidor La resiliencia nos da las características de un
sistema reactivo.
Este informe se centra en reactivo. Sin embargo, al construir un microservicio sistema,
muchas otras preocupaciones deben gestionarse como seguridad, configuración,
registro, etc. La mayoría de las plataformas en la nube, incluyendo OpenShift, brinda
servicios para manejar estas inquietudes. Si desea obtener más información sobre estos
temas, consulte los siguientes recursos:
• Sitio web de OpenShift
• Conceptos básicos de OpenShift
• sitio web de kubernetes
• Documentación de controles de salud de OpenShift
6 CONCLUSIÓN
Estamos al final de nuestro viaje juntos, pero ustedes tienen muchos nuevas avenidas
para explorar. ¡Hemos cubierto mucho contenido en este pequeño informe, pero
ciertamente no cubrió todo! Acabamos de arañar la superficie. Hay más cosas a
considerar cuando se mueve hacia Microservicios reactivos. Vert.x tampoco se limita a
microservicios y puede manejar un gran conjunto de diferentes casos de uso.
¿Qué hemos aprendido?
Entonces, ¿qué aprendiste en este informe? Primero, comenzamos con microservicios.
Y cuáles son los microservicios reactivos. Aprendimos que reactiva microservicios son
los bloques de construcción de microservicio de respuesta sistemas También vimos
cómo la programación reactiva ayuda a construir estos microservicios Descubrimos
Eclipse Vert.x, un kit de herramientas utilizado para construir microservicios reactivos
(entre muchas otras cosas). Vert.x proporciona el perfecto paradigma para abarcar
microservicios: asíncronos, fallas como ciudadanos de primera clase, y sin bloqueo. Para
domesticar el desarrollo asíncrono. Modelo, Vert.x combina su poder con RxJava.
Nuestro descubrimiento

Comenzó con microservicios HTTP y cómo consumirlos. Mientras HTTP se usa a

menudo en microservicios, también vimos una de sus limitaciones cuando nos referimos
directamente a una instancia de un microservicio. A Para ello, utilizamos el bus de
eventos Vert.x y vimos cómo se basaba en el mensaje. microservicios le permiten
construir microservicios reactivos y por lo tanto sistemas reactivos.
Por supuesto, un microservicio no hace una aplicación. Ellos
vienen en sistemas. Para construir sistemas, tenemos que usar el descubrimiento de
servicios.
El descubrimiento de servicios permite la transparencia y movilidad de la ubicación, dos
Características importantes en los sistemas de microservicio. Nosotros tambien
cubrimos
Patrones de resiliencia, ya que los sistemas de microservicio son sistemas distribuidos.
y tienes que estar preparado para el fracaso.
En el último capítulo, desplegamos nuestros microservicios sobre Open‐
Shift, una plataforma de contenedor de código abierto basada en Kubernetes. los
La combinación de Vert.x y OpenShift simplifica la implementación y
Ejecución de microservicios reactivos y mantiene todo el sistema en marcha.
pista.
Entonces, ¿es este el fin? ¡No! Es solo el final de la primera etapa.
Los microservicios no son fáciles

Se espera que los microservicios mejoren la agilidad general. Esta mejora no es solo
un problema técnico, es también un problema de organización. Si su organización no
abarca microservicios de una organización Punto de vista, ninguna tecnología te
ayudará. Si bien los microservicios de construcción pueden parecer simples, en
realidad hay muchos más a eso. Los sistemas de microservicio son sistemas
distribuidos, y por lo tanto Implican las leyes informáticas distribuidas. Los fracasos
también son inevitables. Cada microservicio debe poseer sus datos, y normalmente
necesitará Varias tecnologías de persistencia. Para construir sistemas de microservicio,
hay un par de temas para estudiar promover. Primero, para habilitar la agilidad
prometida, vas a desplegar Los diferentes microservicios con mucha más frecuencia.
Por lo tanto, continua La entrega es clave. También es necesario automatizar el

lanzamiento y la implementación de sus microservicios tanto como sea posible. No

olvides que sus microservicios son fungibles, y la entrega de imágenes inmutables es
una Característica imprescindible para escalar. Sin embargo, si nuestros microservicios
desplegados son inmutables, ¿cómo podemos ¿Pasar información de configuración y
potencialmente reconfigurarlas? Por ejemplo, ¿cómo cambiamos el nivel de registro,
configuramos la base de datos? ¿ubicación y credenciales, alternar características, y así
sucesivamente? La configuración es una parte muy importante de los sistemas
distribuidos y es difícil con microservicios Todos los sistemas son diferentes y no hay
una bala de plata, pero hay una amplia gama de soluciones, desde variables de entorno
hasta Git repositorios y servidores de configuración dedicados. Las plataformas en la
nube también proporcionan capacidades de configuración. Para mitigar esta diversidad,
Vert.x es capaz de recuperar configuraciones desde casi cualquier lugar.
Una vez que implementa y configura sus microservicios, necesita mantener su sistema
en la pista. El registro, las métricas y el rastreo son preocupaciones importantes que se
deben tener en cuenta al diseñar y desarrollar un sistema de microservicio. Debe
recuperar los mensajes registrados, las medidas y los rastros de sus microservicios para
agregarlos de forma centralizada para habilitar la correlación y la visualización.
Mientras que el registro y la supervisión son generalmente bien entendidos, el rastreo
distribuido a menudo se ignora. Sin embargo, los rastros no tienen precio en los
microservicios porque le ayudarán a identificar las tendencias, la afinidad entre los
microservicios y le darán una buena idea de la capacidad de respuesta de su sistema.
La evolución del microservicio

Los microservicios de Paradigm son dinámicos y siempre evolucionan. Recientemente,
la tendencia sin servidor, también llamada función como servicio, está ganando mucho
atractivo. En este nuevo paradigma, su unidad de despliegue es una función. Estas
funciones reciben y procesan mensajes. El paradigma sin servidor hace hincapié en las
instalaciones de despliegue, registro y rastreo, pero promueve un modelo de desarrollo
simple y mejora la escalabilidad del sistema como puede instanciar tantas instancias de
funciones como necesites para manejar la carga.

HTTP / 2 también está haciendo una entrada notable en el microservicio mundo.

Mejora el rendimiento y la escalabilidad de HTTP 1.1 y Permite multiplexar varias
solicitudes en una sola conexión TCP.
También ofrece comunicación bidireccional. gRPC es un procedimiento remoto marco
de llamadas (RPC) que se basa en HTTP / 2 y proporciona un alto rendimiento,
interacciones multilingües, seguras, bidireccionales. Eso Puede conectar
eficientemente servicios en y entre centros de datos con enchufable soporte para
balanceo de carga, rastreo, control de estado y autenticación. También es aplicable
dispositivos integrados, móviles.
Aplicaciones, y navegadores. Mientras RPC fue inicialmente considerado Es dañino
en los sistemas de microservicio, todavía es muy popular. gRPC aborda los problemas
encontrados con los mecanismos tradicionales de RPC, como el bloqueo de llamadas
y fallos parciales. Sin embargo, tenga en cuenta que compartiendo un contrato
(interfaz) entre el microservicio proveedor y los consumidores pueden limitar su
agilidad. Vert.x proporciona HTTP / 2 cliente y servidores. Además, tiene la capacidad
de crear y consumir. Servicios gRPC.
Versatilidad Vert.x
Si bien este informe se ha centrado en microservicios reactivos, esto es solo una sola
faceta de Vert.x. La riqueza del ecosistema Vert.x te permite Desarrollar muchas
aplicaciones diferentes. Gracias a su modelo de ejecución, sus aplicaciones serán
asíncronas y abarcarán las reactivas. mantra del sistema. Las aplicaciones web
modernas proporcionan una experiencia interactiva en tiempo real para los usuarios.
La información se envía al navegador y se muestra sin problemas El bus de eventos
Vert.x se puede utilizar como la red troncal para entregar tal experiencia. El navegador
se conecta al bus de eventos y recibe mensajes, y también puede enviar mensajes e
interactuar con el backend o con otros navegadores conectados al bus de eventos.
El Internet de las cosas (IoT) es un dominio emocionante pero también muy
heterogéneo.
Hay muchos protocolos utilizados por los dispositivos inteligentes. mensajes a menudo
hay que traducirlos de un protocolo a otro. Vert.x proporciona clientes para un gran
conjunto de protocolos para implementar estos Las traducciones y su modelo de

ejecución pueden manejar la alta concurrencia. Necesario para construir puertas de

enlace IoT. Estos dos ejemplos ilustran la riqueza del ecosistema Vert.x.
Vert.x ofrece un conjunto infinito de posibilidades donde usted está a cargo. Puedes
configurar tu sistema usando el lenguaje de programación que Prefiere y el modelo de
desarrollo que más te guste. No dejes un marco plomo - usted está a cargo.

Building Reactive - Final

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Building Reactive - Final

Hochgeladen von

Copyright:

Verfügbare Formate

Universidad Nacional Del Santa

Ing. Sistemas e Informática

“Año de la lucha contra la corrupción e impunidad"

UNIVERSIDAD NACIONAL DEL SANTA

“Construcción de Microservicios Reactivos en JAVA”

ASIGNATURA: Gestión Financiera T.I.

Microservicios Reactivos en JAVA 0

4 DESPLIEGUE DE MICROSERVICIOS REACTIVOS EN OPENSHIFT. ............... 45

Microservicios Reactivos en JAVA 1

1 ENTENDIENDO LOS MICROSERVICIOS REACTIVOS Y VERT.X

¿Pero qué es reactivo? Reactivo es un término sobrecargado en estos días. El diccionario de

Sistema reactivo: se utiliza un estilo de arquitectura. para construir sistemas distribuidos

1.1 Programación reactiva

Microservicios Reactivos en JAVA 2

En este fragmento, el código está observando (suscribiéndose) a un Observable y se le

RxJava v1.x define diferentes tipos de flujos de la siguiente manera

Microservicios Reactivos en JAVA 3

Microservicios Reactivos en JAVA 4

1.3 Flujos reactivos

1.4 Sistemas reactivos

En la tecnología subyacente. Los remitentes no bloquean y esperan una respuesta. El

Microservicios Reactivos en JAVA 5

Elasticidad: la capacidad de escalar horizontalmente.

1.5 Microservicios reactivos

Microservicios Reactivos en JAVA 6

microservicio explota, el microservicio del consumidor debe manejar la falla y no

1.6 Modelo de desarrollo asíncrono

En este ejemplo, configuramos un requestHandler para recibir las solicitudes HTTP

Microservicios Reactivos en JAVA 7

En este código, esperas el resultado del método. Cuando se cambia a un modelo de

En el último fragmento, el proceso ya no devuelve un resultado, por lo que no espere

Microservicios Reactivos en JAVA 8

inmediatamente, las otras solicitudes no se manejarán de manera oportuna y se pondrán

1.7 Vértices: los Building Blocks

Microservicios Reactivos en JAVA 9

1.8 De devoluciones de llamada a observables

Microservicios Reactivos en JAVA 10

Microservicios Reactivos en JAVA 11

Además de mejorar la legibilidad, la programación reactiva le permite suscribirse a un

1.9 Comencemos a codificar

Microservicios Reactivos en JAVA 12

Luego, emita el siguiente comando:

Microservicios Reactivos en JAVA 13

Para ejecutar esta aplicación, inicie:

Veamos ahora el resultado de la aplicación:

A continuación, cambie la propiedad <vertx.verticle> para que sea io.vertx.sam

Microservicios Reactivos en JAVA 14

Empaquetando su aplicación como Fat Jar

Microservicios Reactivos en JAVA 15

La aplicación está nuevamente activa, escuchando el tráfico HTTP en el puerto

Como un kit de herramientas no opinado, Vert.x no promueve un modelo de empaque

Registro, monitoreo y otros elementos de producción.

Microservicios Reactivos en JAVA 16

2 CONSTRUCCIÓN DE MICROSERVICIOS REACTIVOS

2.1. Primeros microservicios

Microservicios Reactivos en JAVA 17

Figura 2.1: Los micro servicios implementados en este

2.2. Implementación de microservicios HTTP

Microservicios Reactivos en JAVA 18

Este comando genera el proyecto Maven y configura el complemento Vert.x Maven.

Ahora, inicie el siguiente comando Maven:

Microservicios Reactivos en JAVA 19

Using Routes and Parameters

Microservicios Reactivos en JAVA 20