Desarrollo de Sistemas Empresariales Usando Microservicios Con Spring Boot

UNIVERSIDAD MAYOR DE SAN SIMÓN
FACULTAD DE CIENCIAS Y TECNOLOGÍA

CARRERA DE INGENIERÍA INFORMÁTICA
DESARROLLO DE SISTEMAS EMPRESARIALES USANDO

MICROSERVICIOS CON SPRING BOOT
ELABORADO POR: Daniel Rocha Perez
CARRERA: Ingeniería Informática
TUTOR: Ing. Edson Ariel Terceros Torrico
PERIODO: II - 2018
Cochabamba – Bolivia
Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.
Agradecimiento:
A mis padres Ciprian Rocha y Albina Perez,

sin ellos no hubiese sido posible terminar la
carrera; su apoyo incondicional para que
sea un hombre mejor lo agradezco de
corazón. Sus consejos siempre los tendré
en cuenta a lo largo de mi vida, ¡gracias!
2
CONTENIDO
RESUMEN .................................................................................................................................. 6
INTRODUCCIÓN ........................................................................................................................ 7
1. GENERALIDADES ................................................................................................................. 8
1.1 Antecedentes Generales .............................................................................................. 8
1.2 Antecedentes Específicos............................................................................................. 9
2. METODOLOGÍA ..................................................................................................................... 9
3. DESARROLLO DE MICROSERVICIOS ............................................................................... 10
3.1 Registro de Microservicios .......................................................................................... 10
3.2 API Gateway............................................................................................................... 14
3.3 Externalización de Configuraciones ............................................................................ 16
3.3.1 Pasos para implementar Config Server ............................................................... 17
3.4 Comunicación entre Microservicios ............................................................................ 18
3.4.1 Orquestación ....................................................................................................... 19
3.4.2 Coreografía ......................................................................................................... 20
3.4.3 Comunicación Síncrona ....................................................................................... 20
3.4.4 Comunicación Asíncrona ..................................................................................... 22
3.5 Pruebas en Microservicios .......................................................................................... 23
3.5.1 Pruebas de unidad .............................................................................................. 24
3.5.2 Pruebas de integración ........................................................................................ 24
3.5.3 Pruebas de contrato ............................................................................................ 24
3.5.4 Pruebas de Componente ..................................................................................... 25
3.5.5 Pruebas de extremo a extremo ............................................................................ 25
3.6 Monitoreo ................................................................................................................... 25
3.6.1 Logging................................................................................................................ 26
3.6.2 Análisis ................................................................................................................ 29
3.6.3 Alertas ................................................................................................................. 30
3
3.7 DevOps ...................................................................................................................... 33
3.7.1 Desarrollo ............................................................................................................ 35
3.7.2 Integración ........................................................................................................... 36
3.7.3 Tipos de Pruebas ................................................................................................ 36
3.7.4 Despliegue .......................................................................................................... 37
3.7.5 Seguimiento y retroalimentación .......................................................................... 37
4. CONCLUSIONES .............................................................................................................. 38
BIBLIOGRAFÍA ......................................................................................................................... 40
4
TABLA DE GRÁFICOS
Figura 1: Arquitectura Hexagonal................................................................................................ 8

Figura 2: Registro de Microservicios ......................................................................................... 11
Figura 3: Dependencia Eureka Server ...................................................................................... 11
Figura 4: Configuración Eureka Server ..................................................................................... 12
Figura 5: Configuración Eureka multi instancia ......................................................................... 12
Figura 6: Ejemplo de Registro de Microservicios ...................................................................... 13
Figura 7: Configuración Cliente Eureka..................................................................................... 13
Figura 8: Ejemplo de Consultas a Servicios .............................................................................. 14
Figura 9: Uso de API Gateway.................................................................................................. 15
Figura 10: Arquitectura Config Server ....................................................................................... 17
Figura 11: Director de Orquesta ................................................................................................ 19
Figura 12: Comunicación Síncrona ........................................................................................... 20
Figura 13: Ejemplo de uso Hystrix ............................................................................................ 22
Figura 14: Centro de Mensajes ................................................................................................. 23
Figura 15: Niveles de Logs ....................................................................................................... 26
Figura 16: Flujo de Registros en Microservicios ........................................................................ 27
Figura 17: Centralita de Registros............................................................................................. 27
Figura 18: Flujo de Monitoreo de logs ....................................................................................... 29
Figura 19: Panel de Visualización Grafana ............................................................................... 30
Figura 20: Alertas con Grafana ................................................................................................. 32
Figura 21: Sistema de Monitoreo Nagios .................................................................................. 33
Figura 22: Ciclo de DevOps ...................................................................................................... 35
5
RESUMEN
En esta monografía se cubre el tema del desarrollo de sistemas usando arquitectura de

microservicios con tecnología Spring.
Se cubrirán los siguientes tópicos:
Registro de Servicios: Una pieza fundamental si se quiere tener éxito en el desarrollo de

microservicios. Para llegar a tener alto grado de disponibilidad de los microservicios es necesario
tener varias instancias, las cuales necesitan de
API Gateway: Se habla de la necesidad de usar API Gateway, también se conocerá la

herramienta Zuul para usarlo en proyectos de Spring.
Externalización de Configuraciones: En esta sección se verá la implementación del servidor

Config, que permite centralizar y provisionar en un servicio las configuraciones de todos los
microservicios.
Comunicación entre Microservicios: Este tópico habla sobre los principios para una
comunicación efectiva entre microservicios, se verán las ventajas y desventajas de usar
comunicación síncrona o comunicación asíncrona usando ejemplos y diferentes tecnologías que
se usan para la comunicación entre microservicios.
Pruebas en Microservicios: Habla acerca de las diferentes pruebas que se tienen que hacer
para desarrollar microservicios de calidad y alta disponibilidad. Si no se realizan estas pruebas
desde el inicio y a la par del desarrollo será más complicado hacerlo al final del desarrollo.
Monitoreo: Microservicios requieren de estar vigilados las 24 horas del día los 7 días de la
semana. En esta sección se dará a conocer las herramientas que ayudan en esta actividad.
DevOps: En esta sección se explorará el ciclo de vida del desarrollo de microservicios. En lugar
de reinventar un proceso para microservicios se explorará los procesos y prácticas de DevOps
desde una perspectiva para microservicios.
Palabras clave: Microservicios, API, Gateway, Externalización, Configuraciones, Pruebas,

Monitoreo, DevOps
6
INTRODUCCIÓN
La arquitectura de microservicios es un patrón para modularizar la lógica de negocio de una

organización usando servicios de un solo propósito. Éste enfoque da un contraste al método
tradicional de realizar sistemas monolíticos que son pesados y complejos a tratar, un programador
nuevo que entra al equipo no se puede adaptar fácilmente porque tiene mucha documentación
que leer, tiene un panorama más amplio que entender antes de empezar a ser productivo. En las
aplicaciones monolíticas es complicado escalar. Cada pequeño cambio en el sistema requiere
que volver a compilar y empaquetar todo el sistema.
Mientras que al usar microservicios esas cosas son del pasado, cada cambio solo necesita
empaquetar el microservicio afectado, el programador nuevo incluido en el equipo fácilmente se
adapta; por naturaleza los microservicios tienden a tener una sola responsabilidad y el
programador solo tiene que ver esa lógica de negocio y rápidamente puede empezar a programar.
Pero no todo es de color rosa, los microservicios también tienen su desventaja. Hay mecanismos
extra que es necesario considerar como el Service Discovery, API Gateway que son temas que
se verán más adelante en la monografía. Algo tan sencillo como la comunicación entre módulos
en el sistema monolítico que solo consiste en llamar a métodos y funciones de las clases. En
microservicios la comunicación se vuelve un poco más complicado, y requiere de otros elementos
que se describirán en el subtema Comunicación entre Microservicios.
La siguiente monografía servirá para que los interesados en el desarrollo de sistemas

empresariales usando microservicios con Spring Framework, aprendan sobre los conceptos, las
herramientas tecnológicas, sobre la comunicación entre microservicios, la integración y
despliegue continuo de microservicios. En esta monografía no se llegará a implementar un caso
de estudio.
7
1. GENERALIDADES
1.1 Antecedentes Generales
Para representar a los microservicios se usa la figura de hexágono, esto gracias a Alister
Cockburn que en el 2005 se refirió a esta tendencia como arquitectura hexagonal.
Figura 1: Arquitectura Hexagonal
Fuente: (Rajesh, Spring 5.0 Microservices, 2017)
Microservicio es un estilo de arquitectura y un enfoque singular para el desarrollo de software que

satisface las modernas demandas de los negocios globalizados. Aclarar que los microservicios
no es una invención sino una evolución de arquitecturas previas como SOA (Service Oriented
Architecture) Arquitectura orientada al servicio.
Con la introducción de los términos cloud computing o computación en la nube, las diferentes
organizaciones y empresas de la talla de Netflix, Amazon. Migraron de la pesada arquitectura
monolítica a una arquitectura más flexible, liviana, fácil de mantener, extender y escalar horizontal
y verticalmente denominada microservicios.
Para una correcta aplicación de la arquitectura de microservicios es recomendable seguir los

principios de ingeniería de software para desarrollar aplicaciones citados por la Twelve-Factor
App.
8
1.2 Antecedentes Específicos
En la actualidad muchas empresas usan Spring Framework como su estándar para desarrollar
sus microservicios, dada las tecnologías desarrolladas como Spring Boot y Spring Cloud que
facilitan el desarrollo de aplicaciones modernas. Esa es la razón por la que Spring es popular en
la comunidad de programadores Java.
2. METODOLOGÍA
Para el presente trabajo se utilizarán los siguientes métodos de investigación:
 Método Bibliográfico, debido a que se realizará la lectura y compilación de libros

relacionados al tema de estudio.
 Método Analítico, debido a que se procederá a revisar y analizar ordenadamente
documentos relacionados al tema de estudio, para la redacción del presente trabajo.
9
3. DESARROLLO DE MICROSERVICIOS
3.1 Registro de Microservicios
El registro de microservicios esta basado en el patrón Service Registry, es una base fundamental
en el desarrollo de microservicios. El descubrimiento de servicios o (Service Discovery) es el
proceso de tomar el nombre de un servicio como entrada y obtener la dirección IP de una instancia
de microservicio. Para llegar a tener alto grado de disponibilidad de los microservicios es
necesario tener varias instancias, idealmente se escala el número de instancias según la carga
vaya incrementándose. (Hunter, 2017, pág. 73).
La comunicación entre microservicios se la realiza a través de una dirección URL. Una mala
práctica es anotar la IP dentro del código ya que la IP puede cambiar, para evitar problemas
futuros se los debe anotar en un archivo de configuración externo para realizar cualquier cambio
y no afecte la funcionalidad del servicio.
A medida que el sistema evoluciona, el número de microservicios se incrementa lo que ocasiona

que el ambiente de desarrollo se vuelva más dinámico, se asignarán IP’s al vuelo. Esto hará más
difícil el proceso de localizar un determinado servicio. Sin mencionar el desafío de monitorear los
servicios. Esto lleva a la necesidad de tener un mecanismo para localizar cualquier microservicio
de nuestro sistema. Ese mecanismo da a los programadores facilidad para iniciar o detener
servicios en cualquier orden, y reconfigurar servicios. Para lograr esto el mecanismo debería ser
capaz de proveer información del estado de los microservicios y su disponibilidad.
Según Umesh, a este mecanismo se le denomina Discovery Service, que es un tipo de base de
datos que lleva un registro de los microservicios disponibles en el sistema. Cada microservicio
que se añade se registra en esa base de datos, cada microservicio puede obtener los metadatos
como ser el puerto, host, la disponibilidad o el estatus de dicho servicio. (Umesh, 2017, pág. 77)
El Discovery Service será actualizado automáticamente cada que un microservicio se encienda

o apague o se realice cualquier cambio en su meta-datos.
Algunas soluciones que se pueden encontrar en el mercado que hagan de Discovery Service son:
 Eureka de Netflix
 Etcd de CoreOS
 Apache Zookeeper
 SkyDNS
 SmartStack de Airbnb
10
La Figura 2: Registro de Microservicios, muestra el auto registro de microservicios en el Service

Discovery. El servicio B envía una petición al servicio A. Cuando el servicio A se ejecuta lo primero
que hace es registrarse en el Discovery Service
Figura 2: Registro de Microservicios
Fuente: (Umesh, 2017, pág. 79)
Al tener dos o más microservicios, estos requieren comunicarse y lo hacen a través de un servicio
que su único propósito es hacer que los microservicios sepan en qué dirección encontrarse.
El equipo de ingenieros de Netflix desarrollaron Eureka, una herramienta que soporta múltiples
copias del mismo servicio que se registran en Eureka Server. Montar este servidor es
relativamente sencillo.
Primeramente, se añade la siguiente dependencia en el pom.xml en un proyecto nuevo de Maven.
Figura 3: Dependencia Eureka Server
Fuente: Elaboración propia
11
Una vez descargada la dependencia se procederá con la anotación @EnableEurekaServer en la

clase principal donde se encuentra el método main. Finalmente se crea un archivo de
configuraciones application.yml dentro la carpeta resources con la configuración de la Figura #4.
Figura 4: Configuración Eureka Server
Fuente: Elaboración Propia.
La Figura #4 indica que el servidor Eureka estará disponible en la dirección localhost en el puerto
estándar para este servicio 8761. Al no haber otros servidores de registro de servicios es
necesario deshabilitar su modo cliente poniéndolo en falso sus valores.
Los servidores Eureka también actúan en modo cliente, esto quiere decir que las múltiples
instancias del servidor no solo registraran microservicios, sino también se registraran entre sí. La
configuración para el modo de dos o más instancias, cada uno con diferente perfil de Spring seria
como se muestra en la Figura #5.
Figura 5: Configuración Eureka multi instancia
Fuente: Elaboración Propia
12
En el archivo application.yml los spring.profiles se separan con triple guion (---), esto permite
configurar múltiples perfiles en el mismo archivo de configuraciones. Para instanciar el servicio
de registro de microservicios con un determinado perfil se ejecuta añadiendo lo siguiente
spring.profiles.active=perfil1.
Luego de ejecutar el servicio de registro e instanciar los microservicios, cada uno se registrará en
Eureka. Para ver las aplicaciones disponibles entramos a la dirección http://localhost:8761 y
veremos algo similar a la figura #6.
Figura 6: Ejemplo de Registro de Microservicios
Lo que se ve en la Figura #6 son los microservicios registrados y disponibles en los puertos 8055
y 9000. Para que se registren de esa manera los microservicios necesitan añadir la siguiente
dependencia al archivo build.gradle compile('org.springframework.cloud:spring-cloud-starter-netflix-
eureka-client') luego se añade la anotación @EnableEurekaClient en la clase principal donde se ubica
el método main. Finalmente se requiere configurar el archivo application.yml
Figura 7: Configuración Cliente Eureka
Con esta última configuración que se muestra en la Figura #7 ya estaría listo el microservicio para
registrarse en Eureka. Cada treinta segundos se mandará notificaciones al servicio de registro,
sino se le notifica en noventa segundos el registro será depurado. Hay cinco estados diferentes
en las que puede estar un microservicio OUT_OF_SERVICE, DOWN, STARTING, UNKNOWN y UP.
(Eureka Netflix, 2018)
13
3.2 API Gateway
Un API Gateway que actúa como un proxy y balanceador de carga entre el cliente y los API REST
para evitar que los clientes interactuen directamente con los microservicios, esto da la impresión
que en frente se tiene un solo sistema. Este proxy se encarga de la seguridad cuando una llamada
ingresa e internamente las subsiguientes llamadas no requieren esa verificacion internamente,
permitiendo al desarrollador concentrarse en la logica del negocio.
Las webs dinámicas muestran diferentes cosas en una página, y hay mucha información que se
necesita mostrar, para esto el frontend dispara consultas a diferentes servicios. Como cada
microservicio tiene una responsabilidad entonces se entiende estas múltiples llamadas a recursos
REST para mostrar algo en una página.
Figura 8: Ejemplo de Consultas a Servicios
El problema con la figura #8 es la seguridad, no se puede exponer de esa manera los

microservicios, lo siguiente es las múltiples consultas que salen del cliente esas idas y vueltas
ciertamente toman su tiempo. He ahí la necesidad de un API Gateway que actúa como un proxy
entre el cliente y los API REST. Nada lo explicara mejor que la siguiente figura.
14
Figura 9: Uso de API Gateway
Fuente: (Richardson, 2018)
Al poner de intermediario al API Gateway, el cliente solo hace una consulta y el API Gateway se
encarga de obtener lo necesario de los demás microservicios y en menor tiempo retorna la
información al cliente.
Según el autor Umesh Ram, el API Gateway puede suplir la autenticación del cliente, luego de
eso se retiran los checkeos de seguridad de todas las llamadas internas lo cual decrece un poco
la latencia en la red y hace que el desarrollador se concentre en la lógica del negocio que en la
seguridad. (Umesh, 2017, pág. 93)
Algunas veces los microservicios pueden usar diferentes protocolos para hablar entre si. TCP,
UDP, RMI, SOAP, etc. Para los clientes sería complicado interactuar en ese ambiente, al poner
un API Gateway los clientes solo mandan consultas y reciben respuesta en protocolo HTTP.
El API Gateway puede actuar como balanceador de carga para manejar las consultas de forma
más eficiente. En este sentido NGINX podría ser un gran candidato. Sin embargo, Spring tiene
una buena alternativa denominada Zuul Proxy que es un servicio Gateway, fue desarrollado por
los ingenieros de Netflix.
15
3.3 Externalización de Configuraciones
La externalización de configuraciones es un principio dado por la Twelve-Factor App. Todos los

parámetros o propiedades de configuración del código deben ser puestos en archivos de
configuración. Para cambiar dinámicamente las configuraciones se usa el servidor de
configuraciones que facilita un recurso REST con las propiedades actualizadas, el cliente manda
una petición a ese recurso REST y actualiza su configuración en tiempo de ejecución.
Por lo general las configuraciones se deben externalizar en archivos denominados properties en

lugar de enterrarlos dentro el código, de esta manera será fácil realizar los cambios según el
ambiente de la aplicación. Si algunas configuraciones son la misma para múltiples microservicios
como la IP de la base de datos, una buena idea es mantener la configuración centralizada; de
esta manera si hay algún cambio solo se cambia en un lugar. De otra forma Sería una pesadilla
realizar cambios de configuración en el código de cada microservicio (Umesh, 2017, pág. 87)
Spring Boot tiene una forma particular de buscar configuraciones mencionadas en el código.
1. Busca argumentos ingresados por línea de comandos

2. Intenta encontrar propiedades en SPRING_APPLICATION_JSON
3. Busca propiedades de los atributos JNDI de java:comp/env

4. Busca en System.getProperties()
5. En las variables de entorno específicas del sistema operativo
6. En RandomValuePropertySources
7. En application-{profile}.properties que puede estar dentro o fuera del JAR
8. En anotaciones @PropertySource
Spring provee la anotación @PropertySource para especificar los archivos de configuración.
Spring Boot da un paso más y registra automáticamente el archivo application.properties Se

puede también crear configuraciones con perfiles específicos de esta manera:
application-{perfil}.properties Por ejemplo, application-dev.properties el cual contiene la
configuración para el ambiente de desarrollo. Este es un buen enfoque, ya que las propiedades
son trasladadas del código a archivos de configuraciones. Sin embargo, cuando los
microservicios son llevados de un ambiente a otro, estos archivos de propiedad cambian lo que
implica recompilar el artefacto del servicio. Hacer eso es una violación a los principios de la
Twelve-Factor application, el cual indica mover los binarios de un ambiente a otro sin volver a
recompilar o reiniciar el sistema o servicio. (The Twelve-Factor App, 2018)
Spring cuenta con herramientas más avanzadas para cambiar configuraciones sin la necesidad
de reiniciar el servicio. Zookeeper Configuration, Cónsul Configuration, y el popular Spring Cloud
16
Config Server, como su nombre lo indica es un servidor de configuraciones en la cual las

aplicaciones y servicios suscritos pueden acceder y cambiar las propiedades de su configuración
al vuelo o en tiempo de ejecución. Soporta también control de versiones de las propiedades de
configuración.
Figura 10: Arquitectura Config Server
Fuente: (Sharma, RV, & Gonzales, 2016, pág. 563)
Como se ve en la figura #10, El microservicio que quiere acceder a Config Server tiene que tener
la dependencia de Config Client, las propiedades de configuración pueden ser de lógica de
negocio o de infraestructura como puertos, credenciales, etc.
A diferencia de Spring Boot, Spring Cloud usa el contexto de bootstrap el cual es el contexto
padre de la aplicación principal. El contexto bootstrap es responsable de cargar las propiedades
de configuración del servidor Config.
3.3.1 Pasos para implementar Config Server
Los siguientes pasos son necesarios para implementar Config Server.
 Crear un nuevo proyecto Spring con la dependencia Config Server
 En la clase principal poner la anotación @EnableConfigServer

 Crear el archivo bootstrap.properties con los siguientes datos
17
 Generar un repositorio git exclusivo para los archivos de configuraciones, ejemplo de

cómo nombrar los archivos seria: appname-{profile}.properties
 iniciar el servidor, para ver el contenido del archivo podemos acceder a la URL
http://localhost:8888/appname/profile/master
 Crear un proyecto que tenga como dependencia Config Client y actuator, la anotación
respectiva en su clase principal @EnableConfigClient.
 Crear el archivo bootstrap.properties con el nombre único de la aplicación o microservicio:
spring.application.name = appname y spring.cloud.config.uri = http://configserv:8888
 En el controlador poner la anotación @RefreshScope para que las propiedades de
configuración se actualicen.
 Para conseguir la actualización de configuraciones es necesario llamar al recurso REST
de actuator denominado refresh.
3.4 Comunicación entre Microservicios
La comunicación entre microservicio puede ser diseñado en forma síncrona que es una
interacción bloqueante que se dá por medio de petición/respuesta HTTP, en la cual el cliente
espera respuesta de forma inmediata, mientras llega la respuesta no hace nada más. También
puede ser diseñado de forma asíncrona que es una interacción no bloqueante en la cual la
respuesta del servicio no es esperada de forma inmediata. El cliente realiza una petición y
continua con su trabajo.
En la actualidad, las aplicaciones móviles y las páginas web muestran muchas categorías
diferentes de datos, para servir diferentes categorías de datos se usan diferentes micro-servicios,
lo que constituye en una comunicación exhaustiva entre micro-servicios.
En una aplicación monolítica todo el código reside en el mismo lugar y en el mismo lenguaje. Así
que, la comunicación entre diferentes módulos es a través de llamadas de funciones o métodos.
Con microservicios el panorama es diferente. Cada microservicio es un proceso diferente que
corre en un contexto completamente diferente o en otro servidor que incluso puede estar en otro
país. Según (Umesh, 2017, págs. 127-132), hay 2 diferentes perspectivas en lo que refiere a la
comunicación entre microservicios.
Desde una perspectiva, el flujo de control y comunicación entre microservicios está dividido en
Orquestación y Coreografía. En el primer escenario hay un líder que sabe todo respecto a lo que
18
pasa con su equipo, en el segundo escenario no hay un líder y para saber algo del equipo se los
tiene que preguntar individualmente.
El primer escenario es la orquestación y el segundo escenario es la coreografía.
3.4.1 Orquestación
Figura 11: Director de Orquesta
Como el nombre sugiere, este patrón está liderado por una entidad, como el director en una
orquesta. El trabajo del director es pedir a los servicios que trabajen armónicamente. Es como
una orquesta sinfónica, cada uno de los músicos sabe hacer su trabajo y lo hacen bien, pero
necesitan de un director que los guie. Con la varita del director, cada músico sabe cuándo tocar
su instrumento y por cuanto tiempo.
El mismo concepto es aplicado en micro-servicios. Hay un director de servicios que envía

mensajes, estos mensajes pueden ser enviados a través de llamadas HTTP o llamadas vía
sockets. Estas llamadas pueden ser síncronas o asíncronas, en este escenario los servicios no
están diseñados para hablar directamente entre sí.
Hay desafíos en este enfoque, el director de servicios se vuelve el centro de atención y toda la
lógica reside ahí, el cual no es un buen diseño escalabilidad. La lógica dentro del director de
servicios lleva a la dependencia entre servicios. Por ejemplo, el director de servicios (Servicio de
19
préstamos) primero verifica el servicio histórico de compras y el servicio detalle bancario, luego
pide al servicio toma de decisión que diga si es apto o no para un préstamo.
3.4.2 Coreografía
En coreografía cada servicio se comunica con otro servicio directamente en una relación de uno
a uno, uno a muchos o muchos a muchos. Idealmente, en coreografía se prefiere usar la
comunicación asíncrona. Como no hay un servicio central, cada micro-servicio dispara un evento
cuando termina su trabajo con lo que se caracteriza como servicio desacoplado e independiente
de otros. Cada componente escuchara un evento o mensaje enviado por otro servicio y lo
procesara.
Los micro-servicios están conectados a través de canales de suscripción o tópicos para observar
su ambiente. Con la comunicación basada en mensajes, Coreografía será de mucha ayuda en
desacoplar y añadir nuevos servicios y eliminar servicios. Salva al sistema de lo que comúnmente
se denomina infierno de dependencia. Por otro lado, Coreografía aumenta la complejidad en el
sistema, cada servicio produce y consume mensajes en tiempo de ejecución, así que no hay una
manera adecuada de identificar el estado exacto en las transacciones. Cada servicio tiene que
tener su propia implementación para ver el estado actual del sistema.
Según el autor (Umesh, 2017) el flujo de datos y la comunicación entre microservicios se la puede
ver desde otra perspectiva, comunicación síncrona y comunicación asíncrona.
3.4.3 Comunicación Síncrona
Es una interacción bloqueante que se dá por medio de petición/respuesta HTTP, en la cual el

cliente espera respuesta de forma inmediata, mientras llega la respuesta no hace nada más, es
decir está bloqueado. Para entenderlo de mejor manera se tiene el siguiente ejemplo: Se tiene
una tienda online de celulares, el nuevo iPhone está en promoción y hay muchos interesados que
desean agregarlo a su carrito de compras. En este escenario el sistema de inventarios verifica si
aún hay ítems disponibles antes que el usuario pueda añadirlo a su carrito de compras. La
comunicación entre microservicios sería como la siguiente imagen.
Figura 12: Comunicación Síncrona
20
En la figura #12, el cliente/consumidor le dice al “API Gateway” que añada el producto a su carrito
de compras. El API Gateway envía al Cart Management el ID del producto. El Cart Management
le dice al Inventory Manager que bloquee el inventario de ese producto. En este nivel, el Cart
Management espera la respuesta de Inventory Manager que se encuentra revisando la
disponibilidad del producto, si lo encuentra lo bloquea para los demás usuarios y responde al Cart
Management, y este recién añade el producto al carrito de compras del usuario.
La principal causa de fallas en la arquitectura de microservicios será probablemente los tiempos

de espera, cuando al servicio le toma mucho tiempo responder se asume que la lentitud es una
falla y se recomienda arreglar todos los cuellos de botella en esos servicios, en lugar de aumentar
los tiempos de espera. Si el tiempo de espera sobre pasa un segundo debería ser inaceptable.
(Carneiro JR. & Schmelmer, 2016, pág. 79)
Para manejar y subsanar algunos errores en la comunicación de microservicios, el autor (Umesh,

2017, pág. 135) propone implementar el patrón disruptor mejor conocido como Circuit Breaker.
Afortunadamente si se usa el framework Spring, ya existe dicha implementación.
Según la documentación oficial de Spring (Hystrix, 2018). Hystrix es una librería que implementa
el patrón disruptor, nos permite gestionar las interacciones entre servicios en sistemas
distribuidos añadiendo lógica de latencia y tolerancia a fallos. Su finalidad es mejorar la fiabilidad
global del sistema, para ello Hystrix aísla los puntos de acceso de los microservicios; impidiendo
así los fallos en cascada proporcionando alternativas de respuesta, gestionando tiempos de
espera mientras se recupera el microservicio. Si una petición a un servicio alcanza un cierto límite
(veinte fallos en cinco segundos por defecto) Hystrix abrirá el circuito de forma que no se
realizaran más peticiones a dicho servicio lo que impedirá la propagación de los errores entre sus
dependientes. (Hystrix, 2018)
Para incluir Hystrix solo se necesita añadir su dependencia en el pom.xml y seguir el siguiente
ejemplo que muestra el uso.
21
Figura 13: Ejemplo de uso Hystrix
Fuente: Documentación Oficial de Spring
Como se ve en la figura #13 es necesario poner la anotación @EnableCircuitBreaker en la Clase

principal del proyecto y en cada método del componente o servicio que se quiera cubrir la
tolerancia a fallos la anotación @HystrixCommand con su respectivo método suplente.
3.4.4 Comunicación Asíncrona
Es una interacción no bloqueante en la cual la respuesta del servicio no es esperada de forma

inmediata. El cliente realiza una petición y continua con su trabajo.
Umesh Ram, dice que la comunicación asíncrona puede llevarse vía servicio REST full, Cada
microservicio manda su mensaje al centro de mensajes, ese centro de mensajes será
responsable de pasar los mensajes al microservicio respectivo. El siguiente diagrama muestra
este concepto.
22
Figura 14: Centro de Mensajes
Como se muestra en la figura #14, el servicio A termina su trabajo luego envía un mensaje al
centro de mensajes. Hay dos formas en las que el centro de mensajes puede actuar. Una forma
es hacer que envía el mensaje a todos los microservicios para que el servicio destinatario tome
las acciones requeridas y las demás ignoraran el mensaje. La segunda forma es hacer un centro
de mensajes más inteligente y que lea el paquete para mandarlo solo al destinatario correcto.
(Umesh, 2017, pág. 142).
RabbitMQ es uno de los agentes de mensajes más populares, está basado en el lenguaje Erlang.
Es la herramienta perfecta para enviar y recibir mensajes, se necesita añadir la dependencia
spring-boot-starter-amqp en el archivo de configuraciones.
3.5 Pruebas en Microservicios
En un ambiente complejo de microservicios, las pruebas se las realiza desde el inicio y a la par
del desarrollo de la aplicación. Hay muchos tipos de pruebas a ejecutarse, como parte del proceso
de entregas automatizadas, antes de declararlo listo para producción al sistema. Estas pruebas
son realizadas en diferentes ambientes los cuales son meticulosamente monitoreados. Algunas
de estas son las de unidad, integración, contrato, componente y de extremo a extremo.
En todo sistema necesita realizarse pruebas para garantizar su buen funcionamiento. Probar
microservicios manualmente puede llegar a ser tedioso y propenso a errores. Automatizar estas
pruebas será un ahorro de tiempo y dinero según (Carneiro JR. & Schmelmer, 2016, págs. 127 -
133).
23
3.5.1 Pruebas de unidad
El nivel más bajo de pruebas se tiene las pruebas de unidad que determinan si el sistema se
comporta como se espera. Se trata de identificar la pieza lógica más pequeña e independiente
para realizar pruebas positivas, negativas.
Cuando se dificulta implementar las pruebas de unidad, por lo general son un indicativo para
mejorar el diseño. La causa podría ser que la lógica de negocio necesita dividirse aún más. Para
que una prueba unitaria tenga la calidad suficiente se debe cumplir las siguientes características:
 Automatizable, no debería requerirse intervención manual.

 Completas, debería cubrir la mayor cantidad de código
 Reutilizables, no se deben crear pruebas que solo se usan una sola vez
 Independientes, la ejecución de una prueba no debe afectar a la ejecución de otra
Las herramientas que se usan para este tipo de pruebas son JUnit, TestNG.
3.5.2 Pruebas de integración
El propósito es el de verificar que cada módulo del servicio interactúe correctamente con sus
colaboradores. En este tipo de pruebas se identifican cualquier defecto en la comunicación entre
microservicios, de tal manera que cualquier código nuevo, o mejora puede ser llevado a
producción. Para conseguir ese fin se debe analizar la interacción con sus dependientes.
3.5.3 Pruebas de contrato
Cuando se implementa y mantiene un servicio, es esencial que las API’s expuestas sea un
acuerdo, un contrato con todos los consumidores o clientes. Si el microservicio tiende a cambiar
en el tiempo es importante que los recursos de cada servicio sigan cumpliendo con el contrato
estipulado en un inicio. Las pruebas de contrato son para verificar que el servicio se comporta
según lo anunciado.
Si en algún momento se detecta que el contrato fue roto, queda dos caminos. Convencer al cliente
que se actualice a la nueva versión o se procederá a mantener varias versiones del mismo
recurso, lo que tarde o temprano llevara a un infierno de versiones API. Actualmente se puede
evitar ese infierno usando GraphQL.
Las herramientas que se usan para las pruebas de integración son Pacto, Pact y Janus.
24
3.5.4 Pruebas de Componente
Las pruebas componente proveen de un ambiente de pruebas controlado, con el objetivo de

desencadenar cualquier caso de error aplicable de manera repetible. El alcance para estas
pruebas es intencionalmente limitado a un servicio aislado de otros componentes externos. Como
consecuencia, este nivel de prueba no puede asegurar que los microservicios funcionen
conjuntamente para satisfacer los requerimientos del negocio. Una ventaja de esta prueba es que
se obtiene retroalimentación precisa del servicio en cuestión. Herramientas como Moco o
Mountebank son usadas para estas pruebas.
3.5.5 Pruebas de extremo a extremo
Es la prueba final que se le hace al sistema para verificar si todas las pruebas son superadas.
Este nivel de pruebas permite evolucionar los microservicios en el tiempo. Para los sistemas que
requieren una directa manipulación por la interfaz de usuario, Selenium WebDriver es la mejor
opción. Es recomendable planear las pruebas contemplando cada posible escenario con el fin de
abarcar con los requerimientos de calidad del sistema.
Para implementar los casos de prueba en lenguaje más humano se usa Cucumber y Gauge.
Debido al esfuerzo grande que requiere este tipo de pruebas, algunos equipos de desarrolladores
simplemente se saltan esta prueba. Prefieren confiar en un entorno de producción más estricto y
alarmante, junto con un puñado de pruebas exploratorias de humo ejecutadas manualmente una
vez que se han realizado cambios.
3.6 Monitoreo
Uno de los grandes desafíos debido a la naturaleza distribuida de los microservicios es el análisis
de logs y monitoreo de cada uno de los microservicios. Es dificultoso el rastreo de las
transacciones mediante la correlación de logs emitidos por diferentes microservicios sin una
herramienta que ayude en el monitoreo. Las principales herramientas son Logging, Análisis y las
Alertas.
Para este cometido hay tres herramientas indispensables según Thomas (Hunter, 2017, pág. 131)
los cuales se detallaran a continuación. Logging, el registro temporal de todos los eventos
suscitados que dan información a detalle de todas las peticiones hechas al servicio. Analytics o
análisis estadístico de las interacciones realizadas y finalmente mecanismos de Alertas cuando
los microservicios fallan.
25
3.6.1 Logging
Logging es una parte vital para mantener los servicios estables y saludables. Estos registros
contienen información invaluable para analizar el flujo de las acciones que se han ejecutado en
el sistema. Al tener varias instancias del mismo servicio, es necesario pasar estos logs o registros
a un lugar en común, donde se los identificara por la dirección IP, el puerto y el id del proceso.
Log4j define los siguientes niveles.
Figura 15: Niveles de Logs
Fuente: Realización Propia
Según (Rajesh, Spring Microservices, 2016, pág. 284), Los logs o registros no son más que flujo
de eventos que vienen de procesos en ejecución. Para las aplicaciones típicas desarrolladas en
JEE existen varias librerías de registros como Log4j, Logback, Slf4j que soportan los protocolos
UDP y TCP. Las aplicaciones envían registros a la consola o a un archivo del sistema operativo,
en este caso es necesario reciclar los archivos periódicamente para evitar llenar el disco duro.
Mantener los registros en disco requiere gran capacidad de almacenamiento, quedarse sin
espacio en el disco significaría la caída del microservicio. Los frameworks de registro proveen
opciones para controlar los logs en tiempo de ejecución para restringir los registros que se
guardaran.
Los registros contienen importante información de alto valor si se los analiza apropiadamente,
por esa razón restringir los registros limitaría la habilidad de entender el comportamiento de la
aplicación.
26
Figura 16: Flujo de Registros en Microservicios
Fuente: (Rajesh, Spring Microservices, 2016, pág. 285)
En la figura #16 se ve a T1 llamar a M1 seguidamente a M3, ya que M1 y M3 se ejecutan en

diferentes maquinas, ambos escriben sus respectivos registros a diferentes archivos. Esto hace
difícil de seguir el flujo de las transacciones en los registros. Para solucionar este problema puede
centralizarse los registros.
Almacenar los registros de cada microservicio en un solo lugar. El principio fundamental

empleado en la nueva solución es desacoplar el almacén de registros y el ambiente de los
procesos del servicio en ejecución. En una centralita de registros, los registros serán enviados
desde el microservicio a una central de almacenamiento big data.
Las soluciones big data son las mejores para almacenar y procesar gran cantidad de registros
más efectivamente.
Figura 17: Centralita de Registros
27
Como se muestran en la Figura #17, la solución centralita de registros cuenta con los siguientes
componentes:
 Log Streams: Son los flujos de registros saliendo del microservicio.

 Log Shipper: Es el responsable de colectar los registros que vienen de las diferentes
microservicios. Luego envía estos registros directo a una base de datos o primeramente
a un procesador de registros en tiempo real.
 Log Store: Ahí es donde se almacena todos los registros para su análisis en tiempo real.
Por lo general esta base de datos es NoSQL como HDFS, capaz de manejar grandes
volúmenes de datos.
 Log Stream Processor: Es capaz de analizar en tiempo real los registros para tomar
decisiones rápidas. También envían información a un tablero, manda alertas e incluso
mandaría acciones para corregir problemas solo en caso de sistemas de auto
recuperación.
 Log Dashboard: es un panel que muestra los resultados de análisis a los registros en
gráficos y tablas.
El beneficio de este enfoque centralizado es que no hay escrituras bloqueantes en disco, también
no usa el espacio en disco de las maquinas. Esta arquitectura es similar a la arquitectura lambda
para procesamiento de big data.
Es muy importante tener todos los registros, su contexto, mensaje, y un ID. El contexto por lo
general tiene el timestamp, dirección IP, información de usuario, detalles del proceso (servicio,
clase, función), tipo de registro, etc. El mensaje será en simple texto plano. El ID será usado para
establecer el enlace entre llamadas de servicios.
Hay variadas soluciones para implementar una centralita de registros. Estas soluciones usan
diferentes enfoques, arquitecturas y tecnologías. Es importante entender las capacidades
requeridas y elegir la solución correcta para suplir esos requerimientos.
En el mercado hay varios servicios de registros en la nube. Loggly es uno de los servicios de
registro más populares en la nube. Los microservicios con Spring Boot pueden usar Log4j de
Loggly. Parpetrial, Logsene, Sumo Logic, Google Cloud Logging y Logentries son otros ejemplos
de soluciones de registros en la nube.
Los Logshipers o recolectores de registros se combinan con otras soluciones para formar un
manejador de registros completo. Logstash es una poderosa herramienta para colectar los
registros. Provee un mecanismo para aceptar flujo de registros de diferentes fuentes a diferentes
destinos. Logspout es otra herramienta similar, pero es más apropiada en un ambiente basado
en contenedores Docker.
28
Las tecnologías usadas para este propósito son Elasticsearch, Logstash y Kibana, son de código
abierto y mantenidos por Elastic.
Figura 18: Flujo de Monitoreo de logs
En la figura #18 se muestra una simple implementación de monitoreo de logs ELK
Kibana es una herramienta grafica donde se muestra los logs registrados. Se muestran en forma
de simples filas de texto o también en forma de grafos. Se puede filtrar por campos o valores
específicos. Por ejemplo, se puede filtrar todos los errores 5XX del día anterior.
Elasticsearch es un motor de base de datos especializado para realizar consultas en los logs. Es
frecuentemente usado en aplicaciones para proveer funcionalidad de búsqueda.
Logstash es una herramienta para consumir y transformar los registros en diferentes formatos a
un limpio y consistente formato.
3.6.2 Análisis
Las herramientas de análisis permiten ver un panel con interesantes estadísticas del microservicio
para diagnosticar problemas. Las herramientas apropiadas para esta tarea son Grafana, Graphite
y StatsD.
Grafana es una herramienta para mostrar datos gráficamente, hay muchas formas en las que se
puede crear graficas en Grafana. Un gráfico puede mostrar múltiples consultas a la vez con
diferentes unidades como bytes o porcentajes, linear o logarítmico, también se puede escoger
colores, calcular estadísticas y mostrarlas.
29
Figura 19: Panel de Visualización Grafana
Fuente: https://www.bigclown.com/doc/integrations/grafana-for-visualization/
Graphite es una herramienta de telemetría de fácil uso, según el autor Jason Dixon. Telemetría
se refiere a la colección de mediciones, típicamente de instrumentos remotos para el propósito
de monitorearlos y sacar estadísticas, gráficas y análisis. (Dixon, 2017)
StatsD es un demonio que escucha estadísticas transmitidas vía TCP o UDP para pasarlos a
Graphite.
3.6.3 Alertas
Puedes hacer lo mejor para desarrollar software estable, pero al final habrá errores en tiempo de
ejecución, habrá fallos en la red con las que no se contaba, el disco se quedará sin espacio o la
memoria se llenará. Cuando suceden estos errores en producción, se necesita de un mecanismo
de alerta. Quizá unos cuantos errores 5XX por aquí y por allá no sean la gran cosa, pero una vez
que se alcanza un cierto umbral de solicitudes fallidas, no querrás perder el tiempo en saltar a la
acción.
Dar con el umbral de errores puede ser un proceso interesante, según el autor Thomas hunter,
no se considera solo el numero neto de errores sino el porcentaje de todas las peticiones fallidas
(o incluso el cambio en la taza de fallos) Por ejemplo:
Hay un sitio web comercial que recibe 1,000 peticiones por minuto en horas pico. Si el error
excede el umbral, quizá 20 errores por minuto en el lapso de 5 minutos, se considera un caso de
alerta. Por las noches recibe menos tráfico en la web comercial, 10 peticiones por minuto cerca
30
a la media noche. A esta proporción solo valdría la pena tomarlo en cuenta si el nivel de error
excede 1 petición por minuto cada 5 minutos.
Un viernes de oferta (Black Friday) el sitio alcanzara su pico más alto; 100,000 mil peticiones por
minuto. Sin embargo, en este periodo la organización está en alerta roja. En lugar de manejar la
taza de errores permitida en dos órdenes de magnitud para que coincida con el tráfico. Sería más
apropiado manejarlo a razón de uno, tal que la taza de error de 200 peticiones por minuto
dispararía una alerta. (Hunter, 2017, pág. 147)
Claro que estas políticas no son mandamientos tallados en piedra, las organizaciones valoran su
caso y según sus necesidades sacan sus propias políticas de alerta. Cambiando su umbral de
errores según la ocasión que solo la experiencia les da.
Spring nos provee de herramientas como Zipkin, un sistema de rastreo distribuido que ayuda a
recolectar los datos necesarios por cada petición propagada entre servicios. Tiene una consola
sencilla donde muestra las estadísticas.
Sleuth es una librería disponible en el proyecto Spring Cloud, permite hacer el seguimiento del
progreso de los microservicios añadiendo encabezados (headers) a las peticiones HTTP.
Grafana 4.0 tiene ventajas respecto a otras herramientas. Si estas recolectando logs y
analizándolos usando StatsD y graficándolo con Grafana, hay la posibilidad de configurar limites
visuales usando datos históricos como en la figura #20.
31
Figura 20: Alertas con Grafana
Fuente: (Hunter, 2017, pág. 149)
Se puede escribir consultas, mandar notificaciones vía Slack, email.
También existen herramientas externas, las famosas SaaS (Software as a Service) Cada
herramienta en esta sección se especializa en algo diferente, la combinación apropiada de
herramientas trae buenos resultados.
PagerDuty es probablemente la herramienta más popular para manejo de incidentes. Ofrece un

API para crear incidentes, lanzar alertas, reconocer incidentes y finalmente resolver incidentes.
Las alertas son enviados por diferentes medios, email, SMS, llamadas a una o varias personas
de un equipo.
Pingdom es una herramienta para hacer peticiones externas a URL’s en intervalos de tiempo.
Estas peticiones son hechas desde diferentes partes del mundo y es usado para encontrar
incidentes en el DNS de diferentes localidades. Pingdom es más una herramienta de monitoreo,
pero ofrece la capacidad de emitir alertas.
Nagios Es probablemente la herramienta más completa para monitorear la salud de los servicios.
Revisa que tan bien se está comunicando la aplicación con la base de datos.
32
Figura 21: Sistema de Monitoreo Nagios
Fuente: (Nagios, 2018)
Revisa el uso de la CPU, memoria, disco, ancho de banda. Y manda una alerta cuando encuentra
alguna falla.
3.7 DevOps
El despliegue continuo es el proceso de despliegue de aplicaciones a uno o varios ambientes de

producción, que están apropiadamente configurados. El aprovisionamiento de infraestructura, la
dockerización de microservicios y las herramientas de automatización facilitaran el despliegue
continúo automatizado.
Antes de entrar en los procesos de DevOps, se detallarán algunas terminologías usadas en el

mundo de DevOps.
33
 Integración Continua (IC): Es automatizar el empaquetado, la verificación continua de

pruebas unitarias y de integración, esto cada cierto tiempo o cada commit realizado por el
programador.
 Entregas Continuas (EC): es automatizar de inicio a fin la entrega de software. Una común
interpretación de EC es la evolución de IC, que añade el ciclo de QA y hace el software
listo para el lanzamiento a producción.
 Despliegue Continuo (DC): Es un enfoque a automatizar el despliegue de una aplicación
en uno o varios ambientes de producción
Dependiendo de la naturaleza de la aplicación se traza un plan de DevOps. Inicialmente puede

llegar a ser costoso, ya que se necesita muchas herramientas y ambientes para llevar a cabo el
ciclo. Las organizaciones no verían el costo beneficio inmediatamente, en implementar la entrega
continua de software. Es menester tener diferentes ciclos para cada microservicio, esto también
ayudara a desacoplar las dependencias entre microservicios. El punto clave en el ciclo está en la
automatización de principio a fin, desde desarrollo hasta producción, y en fallar rápido si algo
malo pasa.
La Figura #22 es una referencia de ciclo DevOps para microservicios, explora diferentes
capacidades que se deben considerar cuando se implementa microservicios.
34
Figura 22: Ciclo de DevOps
Fuente: (Carneiro JR. & Schmelmer, 2016)
A continuación, se detalla el ciclo de entrega continua.
3.7.1 Desarrollo
La etapa de desarrollo tendrá las siguientes actividades, esta sección también indica algunas
herramientas que se pueden usar en esta etapa.
 Código: El equipo de desarrollo requiere un ambiente de desarrollo, plugins que detecten

alguna violación al estándar de desarrollo. SonarQube es un ejemplo que integra otros
plugins como Checkstyle para convención de código, PMD para detectar malas prácticas,
FindBugs para detectar potenciales bichos.
35
 Pruebas Unitarias: El equipo de desarrollo también realiza pruebas unitarias con Junit,
TestNG.
 Pruebas simuladas: Los desarrolladores también realizan pruebas simuladas con Mockito.
 Diseño por comportamiento: El equipo también escribe escenarios usando Cucumber.
 Repositorio de código: Un microservicio por repositorio es un patrón común usado por
muchas organizaciones, esto evitara que otros desarrolladores de otros microservicios
modifiquen alegremente el código. Git y Subversion son los más populares.
 Herramienta de construcción: Maven o Gradle son designadas para que se hagan cargo
de las dependencias y de la construcción del artefacto. Maven realiza tareas como
verificación básica de seguridad, pruebas unitarias.
 Repositorio de artefactos: Nexus es el más usado para almacenar artefactos de software.
3.7.2 Integración
Una vez que el código es subido al repositorio, la siguiente fase: integración continua; empezara
automáticamente. Esta fase construirá el código y generará artefactos de software desplegables.
Los eventos para dar marcha a la integración continua varían según la organización que lo
implemente. Para algunos la integración continua empieza cada vez que un desarrollador hace
commit, algunos lo hacen temporalmente, diario, semanal, etc.
Las herramientas que generalmente se usan para integración continua son Jenkins o Bamboo.
Las herramientas son configuradas con un flujo de actividades a ser invocadas. El flujo
automáticamente ejecuta los pasos configurados, pasos como empaquetado, pruebas,
despliegue, cada que el programador hace commit o cada cierto tiempo que se configure
empezara el flujo de integración continua.
3.7.3 Tipos de Pruebas
Existen varios tipos de pruebas para ejecutar antes de declarar la aplicación lista para producción
 Pruebas de sanidad: Al moverse de un ambiente a otro, es aconsejable correr algunas

pruebas de sanidad para asegurar que todo esté bien. Para ello es importante identificar
cuidadosamente todos los servicios críticos.
 Pruebas de regresión: Se asegura que los cambios realizados no afecten el sistema.
Karma y Jasmine son usados para este tipo de pruebas.
 Pruebas de funcionalidad: Son pruebas basadas en la funcionalidad de las historias de
usuario.
36
 Pruebas de aceptación: Es similar al anterior y es aplicado en la interfaz web de la

aplicación.
 Pruebas de rendimiento: Al aplicar estas pruebas se pueden identificar donde ocurren los
cuellos de botella. JMeter, Gatling y Grinder pueden ser usados.
 Pruebas con usuario real: Es una prueba realizada por un usuario real para medir la
usabilidad y el comportamiento adecuado del sistema.
 Prueba de seguridad: Es extremadamente importante asegurarse que la automatización
no viole las políticas de seguridad de la organización.
 Pruebas de exploración: Es un enfoque manual para validar escenarios específicos que
se piensan que las pruebas automatizadas no son aptas.
3.7.4 Despliegue
El despliegue continuo es el proceso de desplegar aplicaciones de un ambiente a otro, y

configurar y provisionar esos ambientes adecuadamente.
Desde la perspectiva de entrega de software, las imágenes Docker serán movidas a producción
automáticamente una vez que todas las pruebas pasen satisfactoriamente. El ambiente de
producción es basado en la nube con herramientas Como Mesos o Marathon. Ansible, Chef o
Puppet serán usados para mover configuraciones y binarios a producción.
3.7.5 Seguimiento y retroalimentación
Una vez que el despliegue de la aplicación haya sido exitosa, las herramientas de monitoreo y la
gestión de registros colectaran y analizaran información. Basados en la retroalimentación y en
las acciones correctivas necesarias, los desarrolladores implementaran mejoras. Herramientas
como APM, Open Web Analytics, Google Analytics, Webalizer sirven para monitorear
aplicaciones web. También QuBit, Boxever, Channel Site, Maxtraffic ayudan en analizar el
comportamiento de los usuarios.
37
4. CONCLUSIONES
 El registro de microservicios esta basado en el patrón Service Registry y es una base

fundamental en el desarrollo de microservicios. El descubrimiento de servicios o (Service
Discovery) es el proceso de tomar el nombre de un servicio como entrada y obtener la
dirección IP de una instancia de microservicio. Para llegar a tener alto grado de
disponibilidad de los microservicios es necesario tener varias instancias, idealmente se
escala el número de instancias según la carga vaya incrementándose. Para este fin se
puede usar Eureka Netflix por su simpleza y fácil implementación.
 Un API Gateway actúa como un proxy y balanceador de carga entre el cliente y los API
REST para evitar que los clientes interactuen directamente con los microservicios, esto
da la impresión que en frente se tiene un solo sistema. Este proxy se encarga de la
seguridad cuando una llamada ingresa e internamente las subsiguientes llamadas no
requieren esa verificacion internamente, permitiendo al desarrollador concentrarse en la
logica del negocio. Se dio a conocer las herramientas hechas para este fin, Zuul y Nginx.
Donde Zuul destaca por ser más compatible con proyectos hechos con Spring.
 La externalización de configuraciones es un principio dado por la Twelve-Factor App.

Todos los parámetros o propiedades de configuración del código deben ser puestos en
archivos de configuración. Para cambiar dinámicamente las configuraciones se usa el
servidor de configuraciones que facilita un recurso REST con las propiedades
actualizadas, el cliente manda una petición a ese recurso REST y actualiza su
configuración en tiempo de ejecución. Se vio la herramienta que se puede usar para
cambiar configuraciones en tiempo de ejecución y los pasos para su implementación.
 La comunicación entre microservicio puede ser diseñado en forma síncrona que es una
interacción bloqueante que se dá por medio de petición/respuesta HTTP, en la cual el
cliente espera respuesta de forma inmediata, mientras llega la respuesta no hace nada
más. También puede ser diseñado de forma asíncrona que es una interacción no
bloqueante en la cual la respuesta del servicio no es esperada de forma inmediata. El
cliente realiza una petición y continua con su trabajo. Se menciono los diferentes tipos de
comunicación que se puede usar para conectar microservicios. Se ha visto conveniente
usar la comunicación asíncrona ya que no es bloqueante.
38
 En un ambiente complejo de microservicios, las pruebas se las realiza desde el inicio y a

la par del desarrollo de la aplicación. Hay muchos tipos de pruebas a ejecutarse, como
parte del proceso de entregas automatizadas, antes de declararlo listo para producción al
sistema. Estas pruebas son realizadas en diferentes ambientes los cuales son
meticulosamente monitoreados. Algunas de estas son las de unidad, integración, contrato,
componente y de extremo a extremo.
 Uno de los grandes desafíos debido a la naturaleza distribuida de los microservicios es el

análisis de logs y monitoreo de cada uno de los microservicios. Es dificultoso el rastreo
de las transacciones mediante la correlación de logs emitidos por diferentes microservicios
sin una herramienta que ayude en el monitoreo. Las principales herramientas son Logging,
Análisis y las Alertas. Al respecto de las herramientas se vio que destaca Nagios por ser
muy completa y de código abierto.
 El despliegue continuo es el proceso de despliegue de aplicaciones a uno o varios

ambientes de producción, que están apropiadamente configurados. El aprovisionamiento
de infraestructura, la dockerización de microservicios y las herramientas de
automatización facilitaran el despliegue continúo automatizado. Esto descrito es el ciclo
de vida que contempla el desarrollo de microservicios. Se analizó los procesos y las
tecnologías requeridas para practicar la cultura DevOps.
Se ha logrado revisar los conceptos y mecanismos necesarios para desarrollar sistemas usando
la arquitectura de microservicios con la tecnología Spring. Y se vio los beneficios de usar Spring
Framework, Spring Boot, y Spring Cloud, claramente ayudan al desarrollo moderno de
aplicaciones Java de alta escalabilidad sin mucho esfuerzo.
39
BIBLIOGRAFÍA
Carneiro JR., C., & Schmelmer, T. (2016). Microservices from Day One. Florida: Apress.
Dixon, J. (2017). Monitoring with Graphite. California: O'Reilly Media.
Eureka Netflix. (2018, Octubre 21). service registration and discovery. Recuperado el Octubre
2018, de spring.io: https://spring.io/guides/gs/service-registration-and-discovery/
Hunter, T. (2017). Advanced Microservices. San Francisco: Apress.
Hystrix. (2018, Octubre 21). circuit-breaker. Retrieved Octubre 2018, from spring.io:
https://spring.io/guides/gs/circuit-breaker/
Krochmalski, J. (2017). Docker and Kubernetes for Java Developers. Birmingham: Packt.
Laviery, D., Verhas, P., & Lee, J. (2018). Java 9: Building Robust Modular Applications. Mumbai:
Packt.
Macero, M. (2017). Learn Microservices with Spring Boot. New York: Apress.
Nagios. (2018, Octubre 10). Nagios. Recuperado el Octubre 2018, de Nagios: www.nagios.org
Rajesh, R. (2016). Spring Microservices. Birmingham: Packt.
Rajesh, R. (2017). Spring 5.0 Microservices. Mumbai: Packt.
Richardson, C. (2018, Octubre 5). microservices.io. Recuperado el Octubre 2018, de

https://microservices.io/patterns/apigateway.html
Sharma, S., RV, R., & Gonzales, D. (2016). Microservices: Building Scalable Software.
Birmingham - Mumbai: Packt.
The Twelve-Factor App. (2018, Octubre 10). The Twelve-Factor App. Recuperado el Octubre
2018, de https://12factor.net/
Turnquist, G. L. (2017). Learning Spring Boot 2.0. Birmingham: Packt.
Umesh, R. (2017). Practical Microservices. Birmingham: Packt.
40

Desarrollo de Sistemas Empresariales Usando Microservicios Con Spring Boot

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Desarrollo de Sistemas Empresariales Usando Microservicios Con Spring Boot

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSIDAD MAYOR DE SAN SIMÓN

FACULTAD DE CIENCIAS Y TECNOLOGÍA

DESARROLLO DE SISTEMAS EMPRESARIALES USANDO

ELABORADO POR: Daniel Rocha Perez

CARRERA: Ingeniería Informática

TUTOR: Ing. Edson Ariel Terceros Torrico

A mis padres Ciprian Rocha y Albina Perez,

1.1 Antecedentes Generales .............................................................................................. 8

1.2 Antecedentes Específicos............................................................................................. 9

3. DESARROLLO DE MICROSERVICIOS ............................................................................... 10

3.1 Registro de Microservicios .......................................................................................... 10

3.2 API Gateway............................................................................................................... 14

3.3 Externalización de Configuraciones ............................................................................ 16

3.3.1 Pasos para implementar Config Server ............................................................... 17

3.4 Comunicación entre Microservicios ............................................................................ 18

3.4.1 Orquestación ....................................................................................................... 19

3.4.2 Coreografía ......................................................................................................... 20

3.4.3 Comunicación Síncrona ....................................................................................... 20

3.4.4 Comunicación Asíncrona ..................................................................................... 22

3.5 Pruebas en Microservicios .......................................................................................... 23

3.5.1 Pruebas de unidad .............................................................................................. 24

3.5.2 Pruebas de integración ........................................................................................ 24

3.5.3 Pruebas de contrato ............................................................................................ 24

3.5.4 Pruebas de Componente ..................................................................................... 25

3.5.5 Pruebas de extremo a extremo ............................................................................ 25

3.6 Monitoreo ................................................................................................................... 25

3.6.2 Análisis ................................................................................................................ 29

3.6.3 Alertas ................................................................................................................. 30

3.7 DevOps ...................................................................................................................... 33

3.7.1 Desarrollo ............................................................................................................ 35

3.7.2 Integración ........................................................................................................... 36

3.7.3 Tipos de Pruebas ................................................................................................ 36

3.7.4 Despliegue .......................................................................................................... 37

3.7.5 Seguimiento y retroalimentación .......................................................................... 37

Figura 1: Arquitectura Hexagonal................................................................................................ 8

En esta monografía se cubre el tema del desarrollo de sistemas usando arquitectura de

Se cubrirán los siguientes tópicos:

Registro de Servicios: Una pieza fundamental si se quiere tener éxito en el desarrollo de

API Gateway: Se habla de la necesidad de usar API Gateway, también se conocerá la

Externalización de Configuraciones: En esta sección se verá la implementación del servidor

Palabras clave: Microservicios, API, Gateway, Externalización, Configuraciones, Pruebas,

La arquitectura de microservicios es un patrón para modularizar la lógica de negocio de una

La siguiente monografía servirá para que los interesados en el desarrollo de sistemas

1.1 Antecedentes Generales

Figura 1: Arquitectura Hexagonal

Fuente: (Rajesh, Spring 5.0 Microservices, 2017)

Microservicio es un estilo de arquitectura y un enfoque singular para el desarrollo de software que

Para una correcta aplicación de la arquitectura de microservicios es recomendable seguir los

1.2 Antecedentes Específicos

Para el presente trabajo se utilizarán los siguientes métodos de investigación:

 Método Bibliográfico, debido a que se realizará la lectura y compilación de libros

3.1 Registro de Microservicios

A medida que el sistema evoluciona, el número de microservicios se incrementa lo que ocasiona

El Discovery Service será actualizado automáticamente cada que un microservicio se encienda

La Figura 2: Registro de Microservicios, muestra el auto registro de microservicios en el Service

Figura 2: Registro de Microservicios

Fuente: (Umesh, 2017, pág. 79)

Primeramente, se añade la siguiente dependencia en el pom.xml en un proyecto nuevo de Maven.

Figura 3: Dependencia Eureka Server

Fuente: Elaboración propia

Una vez descargada la dependencia se procederá con la anotación @EnableEurekaServer en la

Figura 4: Configuración Eureka Server

Fuente: Elaboración Propia.

Figura 5: Configuración Eureka multi instancia