• Author / Uploaded
• Digital Harbor Bolivia

• Categories
• Transferencia de estado representacional
• Sistema operativo
• Servidor (Computación)
• Servidor proxy
• Computación en la nube

Citation preview

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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 3.4

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

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

3.7

4.

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

CONCLUSIONES .............................................................................................................. 38

BIBLIOGRAFÍA ......................................................................................................................... 40

4

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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 Fuente: Elaboración Propia

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-netflixeureka-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 Fuente: Elaboración Propia

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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 Fuente: (Umesh, 2017, pág. 91)

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.



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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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 Fuente: (Umesh, 2017, pág. 129)

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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 Fuente: (Umesh, 2017, pág. 135)

20

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

Figura 14: Centro de Mensajes Fuente: (Umesh, 2017, pág. 142)

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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 Fuente: (Rajesh, Spring Microservices, 2016, pág. 286)

27

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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 Fuente: (Rajesh, Spring Microservices, 2016, pág. 290)

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.



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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.



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.



3.7.2

Repositorio de artefactos: Nexus es el más usado para almacenar artefactos de software.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.



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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.



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

Desarrollo de Sistemas usando Microservicios con Spring Boot – Daniel Rocha P.

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