├── diagrama-arquitectura.png ├── docker-compose.yml └── README.md /diagrama-arquitectura.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SebaGQ/microservicios-spring-docker/HEAD/diagrama-arquitectura.png -------------------------------------------------------------------------------- /docker-compose.yml: -------------------------------------------------------------------------------- 1 | version: '3' 2 | 3 | # Una buena practica es que el orquestador (o un servidor de configuraciones) entregue a la aplicación sus variables de entorno. 4 | # Aun no se implementa esto debido a que se buscó agilizar un poco el trabajo, en la proxima versión se piensa implementar. 5 | 6 | services: 7 | eureka: 8 | image: sebagq/microservicios-springcloud:eureka-v1 9 | ports: 10 | - "8761:8761" 11 | networks: 12 | - microservicios-network 13 | 14 | gateway: 15 | image: sebagq/microservicios-springcloud:gateway-v1 16 | depends_on: 17 | - eureka 18 | ports: 19 | - "8081:8081" 20 | networks: 21 | - microservicios-network 22 | 23 | reserva-service: 24 | image: sebagq/microservicios-springcloud:reservas-v1 25 | depends_on: 26 | - eureka 27 | ports: 28 | - "8083:8083" 29 | networks: 30 | - microservicios-network 31 | 32 | cliente-mesa-service: 33 | image: sebagq/microservicios-springcloud:cliente-mesa-v1 34 | depends_on: 35 | - eureka 36 | ports: 37 | - "8082:8082" 38 | networks: 39 | - microservicios-network 40 | 41 | networks: 42 | microservicios-network: 43 | driver: bridge 44 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Microservicios con Spring y Docker 2 | 3 | Ecosistema de microservicios desarrollado con **Spring Cloud** y contenerizado con **Docker**. Se han seguido los principios SOLID, además de buenas prácticas de desarrollo, tales como: código limpio, manejo robusto de excepciones, manejo eficiente de dependencias en los contenedores, entre otras. El objetivo de este proyecto es demostrar dominio en el desarrollo de arquitecturas sólidas basadas en microservicios. 4 | 5 | Estas aplicaciones se encuentran contenerizadas con Docker y están publicadas en el siguiente repositorio público: https://hub.docker.com/r/sebagq/microservicios-springcloud 6 | 7 | El `docker-compose.yml` que se encuentra en el branch main puede usarse para cargar las imagenes desde ahí y ejecutar la aplicación fácilmente, en la sección **Cómo ejecutar** se encuentran los detalles. 8 | 9 | 10 | > **Nota**: Este README no está terminado. 11 | 12 | ## Contenido 13 | 14 | Cada microservicio está en su propia branch y cuenta con una documentación detallada. En ellos, se explican las buenas prácticas aplicadas y las razones por las que se tomó cada decisión. La documentación se puede encontrar en diversas capas de la aplicación, como en los `controllers`, `services`, `entities`, etc. También se documentan archivos clave de configuración como los `Dockerfile` o los `application.yml`. 15 | 16 | ### Microservicios Actuales 17 | 18 | - **Eureka**: Servicio de descubrimiento. 19 | - **Gateway**: Puerta de enlace para la comunicación. 20 | - **Cliente-Mesa-APP**: API Rest. 21 | - **Reservas-APP**: API Rest. 22 | 23 | Los servicios `Cliente-Mesa-APP` y `Reservas-APP` son API Rest que funcionan en conjunto. En cambio, `Eureka` y `Gateway` son componentes clave del ecosistema Spring Cloud. 24 | 25 | ## Arquitectura proyecto 26 | 27 | Imagen 1 28 | 29 | #### Manejo de solicitudes 30 | El Gateway funciona como un punto de entrada a las solicitudes, es decir, todas las solicitudes se dirigirán al Gateway, y este las redireccionará al servicio correspondiente según nuestras configuraciones. Para saber hacia qué dirección debe dirigir las solicitudes le pide una lista de los servicios registrados a Eureka. 31 | 32 | 33 | #### Descubrimiento de servicios 34 | Eureka se encarga del descubrimiento de servicios, significa que registra la dirección actual de los servicios, y esto es necesario para que puedan comunicarse entre sí, por ello es que todos se registran en Eureka, y Eureka mediante comprobaciones de salud (heartbeats) verifica que los servicios se encuentren funcionando correctamente. Usando esta información se encarga además de repartir las solicitudes entre las diferentes instancias de los servicios (diciendole al gateway hacia qué instancia apuntar), por ejemplo si tengo 2 instancias de reserva-app funcionando y 1 de ellos está saturado entonces eureka se encargará de decirle al gateway que la solicitud se debe dirigir al que está libre. 35 | 36 | 37 | #### Lógica de la aplicación 38 | La aplicación consiste en un sistema de reserva de mesas para un restaurant, la lógica de negocio es bastante simple, permite añadir/editar/eliminar mesas y clientes, y hacer reservas en base a ello. `reservas-app` y `cliente-mesa-app` son aplicaciónes que consisten en API Rest con CRUD de las entidades principales y sus respectivos métodos, trabajan en coonjunto comunicándose mediante FeignClient. 39 | 40 | Estas API se desarrollaron según las buenas prácticas de diseño y respetando los principios SOLID, esto se ve reflejado por ejemplo en: 41 | - Se definen los nombres de variables, métodos, atributos y endpoints según las convenciones, lo que facilita la legibilidad y permite una rápida adaptación por parte de otros desarrolladores. 42 | - Cada capa de la aplicación tiene una única responsabilidad y esto se respeta de manera estricta. 43 | - Uso de DTO para evitar exposición de información y reducir la cantidad de datos en las solicitudes, lo que permite reducir tiempos de respuestas y costos. 44 | - Métodos desarrollados cuidadosamente para mantener la legitibidad, separar responsabilidades y facilitar futuras modificaciones y nuevas funcionalidades. 45 | - Uso de un Manejador Global de excepciones, apoyado de implementación de logs personalizados y un cuidadoso manejo de posibles excepciones para mejorar la depuración y robustez de la aplicación. 46 | - Definición de un Dockerfile que permite que las dependencias se manejen en la etapa de construccion de la imagen, esto implica un uso eficiente de recursos a la hora de desplegar la aplicación. 47 | 48 | ## Cómo ejecutar 49 | 50 | Para ejecutar la aplicación basta con ejecutar el `docker-compose.yml` que se encuentra en el branch main. 51 | Para ejecutarlo debemos tener instalado Docker, y GIT. 52 | 1. Ir a algún directorio donde queramos descargar el `docker-compose.yml` . 53 | 2. Ejecutar en la terminal: **git clone -b main https://github.com/SebaGQ/microservicios-spring-docker.git** 54 | 3. Ir al directorio /microservicios-spring-docker que se acaba de crear y ejecutar **docker-compose up** . 55 | 4. Esperar a que inicie la aplicación (puede demorar un poco en descargarse, depende del internet), es importante tener docker abierto. 56 | 57 | 58 | ## Pendientes 59 | 60 | Hay ciertas funcionalidades y características que no se implementaron, como: 61 | 62 | - Servicio de centralización de configuraciones. 63 | - Seguridad con Oauth2. 64 | - Herramientas de metricas y monitoreo. 65 | 66 | Se decidió no implementar estas características de momento para no añadir complejidad innecesaria, ya que la finalidad de este proyecto es mostrar conocimiento sobre microservicios y buenas practicas. Tal vez se agreguen en el futuro. 67 | --------------------------------------------------------------------------------