MicroServicio ¿Qué es? : Hoy en día, los Microservicios son uno de los enfoques más populares para construir aplicaciones escalables y fáciles de mantener. Si estás en el mundo del desarrollo en Java, seguramente habrás escuchado hablar de Spring Boot como una de las mejores herramientas para crear Microservicios. En este artículo, veremos de forma sencilla qué son los Microservicios y cómo podemos construir dos de ellos usando Spring Boot. Uno publicará un saludo, y otro lo consumirá usando RestTemplate haciendo del rol de cliente.
¿Qué es un Microservicio?
Un microservicio es simplemente una pequeña aplicación que se encarga de hacer una única tarea. A diferencia de una aplicación monolítica, donde todo está junto en un único bloque, los microservicios dividen esa gran aplicación en pequeñas partes que funcionan de manera independiente. Cada microservicio tiene su propio ciclo de vida: puedes desplegar, actualizar y escalar uno sin que afecte a los demás.
Docker y su relación
Docker y los Microservicios se complementan porque estos dividen una aplicación en partes más pequeñas e independientes, mientras que Docker facilita ejecutar cada una de esas partes (microservicios) en contenedores aislados. Esto simplifica el despliegue, la gestión y la escalabilidad de cada uno, ya que los contenedores son ligeros, portátiles y aseguran que cada servicio tenga su propio entorno de ejecución sin conflictos con otros servicios.
Ventajas de los Microservicios con Spring Boot
Spring Boot hace que la creación de microservicios sea rápida y sencilla gracias a su enfoque minimalista y su integración con el ecosistema de Spring. Algunas de las ventajas clave de usar Spring Boot para microservicios son:
- Desarrollo rápido: Menos configuración, más código funcional.
- Despliegue independiente: Cada microservicio es un servicio independiente que puedes desplegar sin tocar los demás.
- Escalabilidad: Puedes escalar solo los microservicios que lo necesiten.
Ejemplo Práctico
Vamos a crear dos Micros muy simples. El primer Micro va a exponer un saludo, y el segundo va a consumir ese saludo y mostrárnoslo. Vamos a usar RestTemplate para que el segundo consuma el API del primero.
Micro 1: Publicar un Saludo
Este primeo es responsable de devolver un mensaje de saludo cuando le hacemos una petición HTTP.
Paso 1: Añadimos las dependencias en pom.xml partiendo de un proyecto de Spring Boot Initializer
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>
Paso 2: Creamos el Controlador
Este controlador será el encargado de manejar la petición y devolver el saludo.
package com.example.microservicio1;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class SaludoController {
@GetMapping("/saludo")
public String saludar() {
return "Hola desde el primer microservicio";
}
}
Cuando alguien haga una solicitud a http://localhost:8080/saludo, este controlador responderá con el mensaje: “Hola desde el primer microservicio”.
Paso 3: Clase Principal del MicroServicio
Esta es la clase principal que inicia el micro
package com.example.microservicio1;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class Micro1Application {
public static void main(String[] args) {
SpringApplication.run(Micro1Application.class, args);
}
}
Micro 2: Consumir el Saludo
Este segundo micro va a usar RestTemplate para hacer una petición al primer micro y mostrar el saludo que recibe.
Paso 1: Añadimos las dependencias en pom.xml
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>
Paso 2: Configuramos el RestTemplate
RestTemplate es la herramienta que vamos a usar para consumir el API del primer micro.
package com.example.microservicio2;
import org.springframework.boot.web.client.RestTemplateBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.client.RestTemplate;
@Configuration
public class RestTemplateConfig {
@Bean
public RestTemplate restTemplate(RestTemplateBuilder builder) {
return builder.build();
}
}
Paso 3: Creamos el Controlador
Este controlador será el encargado de consumir el saludo del primero y devolverlo al usuario.
package com.example.microservicio2;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;
@RestController
public class ConsumidorController {
@Autowired
private RestTemplate restTemplate;
@GetMapping("/consumir-saludo")
public String consumirSaludo() {
String saludo = restTemplate.getForObject("http://localhost:8080/saludo", String.class);
return "El saludo recibido es: " + saludo;
}
}
En este caso, cuando hagamos una solicitud a http://localhost:8081/consumir-saludo, este microservicio va a hacer una petición al primero en http://localhost:8080/saludo y nos devolverá el saludo que recibe.
Paso 4: Clase Principal del Segundo:
package com.example.microservicio2;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class Micro2Application {
public static void main(String[] args) {
SpringApplication.run(Microservicio2Application.class, args);
}
}
Ejecutando
- Primer Micro: Inicia el primer microservicio en el puerto 8080 ejecutando la clase Microservicio1Application.
- Segundo Micro: Inicia el segundo microservicio en un puerto diferente, como 8081, ejecutando la clase Microservicio2Application
.
Cuando visites http://localhost:8081/consumir-saludo, verás el saludo: “El saludo recibido es: Hola desde el primer microservicio”.
Conclusión
Este ejemplo muestra lo sencillo que es construir MicroService en Java usando Spring Boot. Con herramientas como RestTemplate, puedes hacer que los MicroServices se comuniquen entre sí de forma fácil y rápida. Este enfoque te permitirá tener aplicaciones más modulares y fáciles de mantener a largo plazo.
No tienes en cuenta la transaccionalidad que puede darse entre los distintos microservicios, ni la necesidad de hacer rollback si alguno de ellos falla, que fallarán, ni la necesidad de comunicar los distintos microservicios mediante algun broker de mensajes para paliar la sincronicidad propia de los servicios REST que impide escalar de manera natural dichos microservicios.
Tienes razón , faltan cosas . espero en los próximos meses tener tiempo para generar más contenidos de microservicios 🙂 . Un saludo
Actualmente estoy en el proceso de digerir el libro “Microservices patterns”, de Chris Richardson, libro que te recomiendo. Actualmente se está terminando de escribir, creo que va por el capitulo 8 de 10, yo por el capitulo 5, pero se puede leer ya como livebook en Manning. Muy recomendable, te introduce en como manejar dicha transaccionalidad distribuida usando el concepto lógico de sagas como un conjunto de eventos que ocurren en las distintas máquinas gestionadas como si fuesen una maquina de estados distribuidas de manera que solo se avanza al siguiente estado cuando se resuelve la transacción ACID localmente y se ha insertado el siguiente evento en el broker de mensajes, solo entonces, el orquestador central decide el siguiente estado o el coreógrafo. Personalmente entiendo mejor las figura del orquestador mas que la del coreógrafo, pero creo que todavía me falta terminar el libro, luego volverlo a releer y después jugar programando los distintos componentes que pueden aparecer en una arquitectura distribuida orientada a microservicios. Es mucho mas complicado que simplemente diseñar distintos componentes REST con spring boot, dokerizarlos y ponerlos detrás de kubernetes o Marathon/DCOS para que escalen de manera natural. Un ejemplo, imagínate que tienes 3 contenedores del mismo servicio, con la misma lógica y cada uno con una base de datos en local idéntica, el proxy te asigna uno de los 3 contenedores para trabajar, haces la transacción local y el orquestador decide el siguiente paso, elige otro contenedor que contenga la siguiente lógica de negocio y actualiza la transacción acid local y asi hasta que llegas a una transacción en un contenedor Cn que falla. Que ocurre aquí, que tienes que hacer rollback en todas las transacciones anteriores que han ocurrido en los distintos contenedores, algo ya de por si complejo, pero imagina que todas las transacciones han ido bien y tienes todos esos contenedores con esas bd coherentes entre si, pero tienes las otras instancias de los mismo servicios idénticos escalados inconsistentes en datos con respecto al anterior ejemplo. Que hacemos aqui? Me imagino que sería necesario que el orquestador enviara la misma secuencia de comandos a los distintos servicios escalados para que cuando el proxy elija que actúe uno de estos, tenga las mismas opciones de poner actuar correctamente pues tendría los mismos datos replicados sin inconsistencias.
Esta claro que es una arquitectura compleja y que supone grandes retos
Estamos buscando devs que manejen este tema y sean muy buenos en Java para que se unan a nuestro equipo de Rappi 😉 espero no spamiar esta gran discución con ofertas de empleo, pero este es un tema relacionado y estamos buscando personas muy buenas cómo el autor y algunos de los que han comentado.
Gracias.
Soy programadorm y domino la tecnolgía JEE, como framework web utilicé Primefaces y como IDE Netbeans. En fin, me interesa tu propuesta y si me envías tu dirección te puedo enviar mi CV.
mateo.escobar@rappi.com
Primefaces ya fue 😛 y no tiene nada que ver con micro servicios, actualmente para esta tecnología existe spring boot y esta orientado a las clouds y no para los servers habituales
Saludos
A que correo envio hoja de vida ?
Hola muy interesante tu descripción quería aprovechar para mencionar que tengo un canal donde estoy subiendo como hacer microservicios, les comparto el link por si desean darle una mirada:
https://www.youtube.com/user/xazpentx
Muchas gracias por el aporte 🙂
Osea si entiendo bien solo tengo que hacer digamos varios servicios en respuestas JSON(por ejemplo) y consumirlos como REST?, el conjunto de todos los servicios se hace un microservicio?. Eso es todo?
Ademas a día de hoy se desplegarían independientes completamente a través de soluciones tipo docker 🙂
Cecilio, muy bueno el post!
Te cuento que estoy trabajando sobre una arquitectura en capas(3), con tecnologías como Jsf, Spring, e Hibernate.
Tendrás algún ejemplo de como implementar microservicios sobre una arquitectura así? Gracias!
JSF no esta orientado a eso en principio. Tendrías que separar lo que es la parte JSF del resto
Tengo una gran duda con respecto a los microservicios, una aplicación monolítica la podías construir por módulos y tener cada módulo en un jar, agregabas tus jar a tu classpath y agregabas Spring Security y listo, tenias una aplicación web con cierto grado de seguridad (autenticación y autorización).
¿Cómo se maneja este tema en una arquitectura de microservicios? Entiendo que mi aplicación web (Front End) podria seguir bajo el esquema planteado con anterioridad, con la única diferencia de que no tendría que integrar varios jar ya que la funcionalidad que estos brindaban está ahora en un microservicio. Pero ¿cómo garantizo que los microservicios estén solo disponibles para las personas correctas, con las credenciales correctas?
Deberas tener un MicroServicio que gestione la seguridad , pero todo esto es empezando 🙂 hay que ver como evoluciona todo
Funciona de la misma forma, mira tu aplicación web (el front) no debería llamar directamente a cada uno de los microservicios, más bien, tu aplicación web (el front) debe consumir digamos un proxy en su propio backend, es decir un servicio interno el cual funcione como proxy a un Gateway el cual es un microservicio que a su vez, sabe a que microservicio llamar. Un ejemplo en palabras vanas seria, tu front, llama a un api interna en tu aplicación llamada /miServicio y esta uri estará protegida con spring security. Esta uri /miServicio, llamara a un gateway por ejemplo /gateway/servicioX el cual será responsable de llamar al servicio esperado por ejemplo /microservicioA/ejecutarServicio. La aplicación front nunca sabe donde esta o en que puerto se ejecuta /microservicioA/ejecutarServicio puesto que los microservicios pueden ser arrancados o finalizados y escalados en cualquier momento. En otras palabras, te dejo mi comentario, una arquitectura de microservicos es para construir apis que den forma o ayuden a construir otras aplicaciones, en otras palabras, mediante arquitecturas de microservicios tu crearás todos los servicios necesarios para que una aplicacionX pueda funcionar, delegando toda la lógica de negocio en los microservicios que estan ocultos de la aplicación consumidora gracias al gateway el cual es el responsable de saber en donde esta cada microservicio y tu aplicación solo debe saber donde esta ese gateway.
Lo que a mi me complica de los microservicios es la interdependencia, por ej si un microservicio es usado por 10 app web distintas y este microservio se cae, las 10 app no podran funcionar full.
En cambio si cada una de ellas tiene este mismo servicio como parte de la aplicación, entonces si una se cae, solo ella se cae.
Eso me tiene un poco indeciso acerca de este enfoque.
Pongo como ejemplo un microservicio de Login usado por distintas web. Al final si se cae, muchas web pueden quedar sin servicio y en vez de ser independientes, se vuelven dependientes
Es una arquitectura en la cual el tema de cluster y escalabilidad será clave 🙂
En la práctica lo que comentas no sucede, si un microservicio se cae, en teoría deberías mantener más de uno desplegado, es decir tener varias instancias del mismo microservicio activo, es decir, escalado, y los clientes o consumidores de ese microservicio deben implementar un balanceador de carga el cual es el encargado de dirigir las peticiones al microservicio más sano o más disponible con el fin de que ninguno caiga, sin embargo, si uno cae, estarán activos otros microservicios que darán soporte a tu aplicación. no tiene sentido que implementes una arquitectura de microservicios desplegando un único microservicio de cada tipo, este tipo de arqutiectura es para evitar la baja disponibilidad que te da un fallo en una gran aplicación monolitica que, cuando se cae, se cae completa.
Como bien dices, una gran ventaja es el despliegue. Podemos desplegar nuevas versiones sin tener que reiniciar ni reempaquetar otras aplicaciones que consuman estos microservicios. Pero hay que ir con cuidado a la hora de reiniciar servidores, puede que una aplicación se despliegue antes que un microservicio y se queje de que no está disponible.
Si esas cosas vamos a tener que valorarlas ya que por ahora los standares que yo recuerde no tienen nada para decidir ordenes de despliegue 🙁
Pero recordemos también que un MicroServicio tiene que ser lo más independiente posible
Hola Cecilio, caí en tu página ya que soy reclutadora y me han pedido cubrir una vacante de perfil Microservicios, la problemática que tengo es que no me queda claro que tecnologías buscar, además, mi cartera de candidatos se reduce en JAVA, .NET, Analistas/PM etc, pero ninguna en Microservicios, puedes ayudarme a saber en qué cartera encontrarlo y de que tecnologías básicas se apoya esta herramienta?.
En principio normalmente la gente de Java y .NET pueden tener perfil orientados a microservicios , pero hay que sumar conocimientos en temas como docker , devops , kubernetes y arquitecturas REST y Web Api. Espero te ayuden mis comentarios 🙂