Esta es la primera parte de una serie de artículos sobre los conceptos básicos de las arquitecturas de microservicios.
En él, se familiarizará con el concepto de microservicios y aprenderá a crear microservicios utilizando Spring Boot y Spring Cloud.
Esta guía lo ayudará a aprender los conceptos básicos de las arquitecturas de microservicios. También comenzaremos a ver la implementación básica de microservicios con Spring Boot.
Crearemos un par de microservicios y haremos que se comuniquen entre sí utilizando los servidores de nombres Eureka (Eureka Naming Server) y Ribbon para equilibrar la carga en el lado del cliente.
Este artículo es parte de la serie Spring Boot Microservices:
Aprenderás
- ¿Qué es un monolito?
- ¿Qué es un microservicio?
- ¿Cuáles son los problemas con los microservicios?
- ¿Cómo Spring Boot y Spring Cloud hacen que los microservicios sean más fáciles de desarrollar?
- ¿Cómo implementar el equilibrio de carga del lado del cliente usando Ribbon?
- ¿Cómo implementar un servidor de nombres (Eureka Naming Server)?
- ¿Cómo conectar microservicios con un servidor de nombres y una cinta de opciones?
Resumen de recursos
En este tutorial, crearemos un recurso para estudiantes que brinde tres servicios utilizando los URI y métodos HTTP apropiados:
- Obtenga una lista de todos los estudiantes: @GetMapping ("/ students")
- Obtenga información sobre un estudiante específico: @GetMapping ("/ students / {id}")
- Eliminar información del alumno: @DeleteMapping ("/ students / {id}")
- Crear una nueva entrada de estudiante: @PostMapping ("/ students")
- Actualizar información del estudiante - @PutMapping ("/ students / {id}")
Descripción general de los microservicios: el panorama general
En esta serie de artículos, crearemos dos microservicios:
- Servicio de Forex - FS para abreviar
- Servicio de Conversión de Moneda - CCS para abreviar
No se preocupe si algunas cosas no le quedan claras. La idea es darle una idea general antes de comenzar el desarrollo y crear microservicios paso a paso.
Servicio de Forex
El servicio de Forex (FS, Servicio de Forex) es un proveedor de servicios. Proporciona tasas de cambio de moneda para varias monedas. Supongamos que se comunica con Forex Exchange y proporciona el valor actual del intercambio entre monedas. A continuación se muestra un ejemplo de una solicitud y respuesta:
GET to http:
{ id: 10002, from: "EUR", to: "INR", conversionMultiple: 75, port: 8000, }
La respuesta a la solicitud anterior es el tipo de cambio del Euro al INR. La respuesta de ConversionMultiple es 75.
Hablaremos sobre el campo del puerto un poco más tarde.
Servicio de conversión de divisas
El Servicio de Conversión de Moneda (CCS) puede convertir muchas monedas a otra moneda. Utiliza el servicio Forex para obtener los valores actuales de cambio de divisas. CCS es un consumidor de servicios. A continuación se muestra un ejemplo de una solicitud y respuesta:
GET to http:
{ id: 10002, from: "EUR", to: "INR", conversionMultiple: 75, quantity: 10000, totalCalculatedAmount: 750000, port: 8000, }
La solicitud anterior le permite determinar el valor de 10.000 euros en rupias indias.
El monto total calculado es de 750,000 INR. El siguiente diagrama muestra la relación entre CCS y FS.
Servidor de nombres y cinta Eureka
Dependiendo de la carga, podemos tener varias copias del Servicio de conversión de divisas y el Servicio de Forex.
Y el número de instancias para cada servicio puede cambiar con el tiempo. La figura a continuación muestra un ejemplo específico donde se crean 5 instancias del servicio Forex.
Lo que debería suceder en la situación anterior es que la carga debe distribuirse uniformemente entre estas 5 instancias.
En esta serie de artículos, utilizaremos Ribbon para equilibrar la carga y el servidor de nombres Eureka para registrar todos los microservicios.
¿Qué es una aplicación monolítica?
¿Alguna vez has trabajado en un proyecto ...
- Que se produce (se pone en producción) una vez cada pocos meses
- Que tiene una amplia gama de características y capacidades.
- En el que trabaja un equipo de más de 50 personas.
- Donde los problemas de depuración son un gran problema
- Donde introducir nuevas tecnologías y nuevos procesos es casi imposible
Estas son características típicas de las aplicaciones monolíticas.
Las aplicaciones monolíticas suelen ser enormes: más de 100.000 líneas de código. En algunos casos, incluso más de un millón de líneas de código.
Los monolitos se caracterizan por lo siguiente:
- Gran tamaño de aplicación
- Ciclos de liberación largos
- Grandes equipos
Los problemas típicos incluyen:
- Problemas de escalabilidad
- Adopción de nuevas tecnologías.
- Nuevos procesos: ¿ágil?
- Difícil de automatizar las pruebas
- Es difícil adaptarse a las prácticas actuales de desarrollo.
- Es difícil adaptarse al rápido crecimiento de un proyecto.
Microservicios
Las arquitecturas de microservicios han evolucionado para abordar los desafíos de escalabilidad e innovación con arquitecturas monolíticas. Hay una serie de definiciones sugeridas para microservicios.
Pequeños servicios independientes que trabajan juntos: Sam Newman
Desarrollo de una aplicación separada en forma de un conjunto de pequeños servicios, cada uno de los cuales funciona en su propio proceso e interactúa con mecanismos livianos, a menudo la API de recursos HTTP. Estos servicios se basan en oportunidades comerciales y se pueden implementar de forma independiente mediante un mecanismo de implementación totalmente automatizado. Existe un nivel mínimo de gestión centralizada de estos servicios, que puede escribirse en diferentes lenguajes de programación y utilizar diferentes tecnologías de almacenamiento: James Lewis y Martin Fowler
Aunque no existe una única definición aceptada para microservicios, existen varias características importantes:
- REST: construido en torno a recursos RESTful. La comunicación entre servicios puede basarse en eventos o en el protocolo HTTP.
- Pequeños bloques desplegables bien seleccionados - Contexto limitado
- Características de la nube: escala dinámica
¿Cómo es la arquitectura de microservicios?
Así se verá el monolito. Una aplicación para todo.
Esto se verá como la misma aplicación cuando se desarrolle usando Arquitectura de microservicios.
Las arquitecturas de microservicios incluyen varios componentes de mensajería pequeños y bien diseñados.
Beneficios de los microservicios
Ventajas:
- Usar nuevas tecnologías y procesos de adaptación se vuelve más fácil. Puede probar nuevas tecnologías con los nuevos microservicios que crearemos.
- Ciclos de lanzamiento más rápidos
- Escalamiento de la nube
Problemas de arquitectura de microservicios
Si bien el desarrollo de algunos componentes pequeños puede parecer fácil, existen varias dificultades inherentes asociadas con las arquitecturas de microservicios.
Veamos algunos de los problemas:
- Requiere configuración rápida : no puede pasar un mes configurando cada microservicio. Debería poder crear rápidamente microservicios.
- Automatización : dado que en lugar del monolito hay una serie de componentes más pequeños, debe automatizar todo: ensamblajes, implementación, monitoreo, etc.
- Visibilidad : ahora tiene varios componentes pequeños para la implementación y el mantenimiento. Quizás 100 o 1000 componentes. Debería poder rastrear e identificar problemas automáticamente. Necesita una excelente visibilidad de todos los componentes.
- Contexto limitado : definir los límites de un microservicio no es una tarea fácil. El contexto limitado del diseño del dominio es un buen punto de partida. Su comprensión del dominio se desarrolla durante un período de tiempo. Debe asegurarse de que los límites del microservicio están evolucionando.
- Gestión de la configuración : necesita mantener configuraciones para cientos de componentes en diferentes entornos. Necesitará una solución de gestión de configuración
- Aumento y disminución dinámicos : los beneficios de los microservicios se realizarán solo si sus aplicaciones pueden escalar fácilmente en la nube.
- Baraja de cartas : si falla el microservicio en la parte inferior de la cadena de llamadas, puede afectar a todos los demás microservicios. Los microservicios deben ser tolerantes a fallas.
- Depuración : cuando surge un problema que debe abordarse, es posible que deba examinar varios servicios en diferentes componentes. Se necesitan registros centralizados y paneles para facilitar los problemas de depuración.
- Consistencia : no puede tener una amplia gama de herramientas que resuelvan el mismo problema. Si bien es importante impulsar la innovación, también es importante contar con una administración descentralizada de los lenguajes, plataformas, tecnologías y herramientas utilizadas para implementar / implementar / monitorear microservicios.
Soluciones de arquitectura de microservicios
Bota de primavera
Spring Boot le permite crear rápidamente aplicaciones listas para usar y proporciona las siguientes características no funcionales:
- servidores integrados (facilidad de implementación mediante contenedores)
- monitoreo de métricas
- monitoreo de salud
- configuración externa
Nube de primavera
Spring Cloud proporciona soluciones de activación en la nube para sus microservicios. Utiliza y se basa en algunas de las soluciones en la nube creadas por Netflix (Netflix OSS).
Módulos importantes de Spring Cloud
- Escalado dinámico hacia arriba y hacia abajo. Usando una combinación de:
- Servidores de nombres Eureka
- Cinta de opciones (equilibrio de carga en el lado del cliente)
- Fingir (simplifica el desarrollo de clientes REST)
- Visibilidad y monitoreo con:
- Rastro distribuido de Zipkin
- Netflix API Gateway
- Gestión de la configuración con Spring Cloud Config Server
- Tolerancia a fallos con Hystrix
En esta serie de artículos, crearemos dos microservicios:
Nota perev. El autor además repite parcialmente lo que se ha dicho. Edición original guardada (sin eliminar repeticiones)
- Servicio de Forex - FS para abreviar
- Servicio de Conversión de Moneda - CCS para abreviar
El siguiente diagrama muestra la relación entre CCS y FS. Estableceremos una conexión entre estos dos componentes.
Nos gustaría poder aumentar y disminuir dinámicamente el número de instancias de cada uno de estos servicios.
Y el número de instancias para cada servicio puede cambiar con el tiempo. La figura a continuación muestra un ejemplo específico donde se crean 5 instancias del servicio Forex.
La implementación de una solución para aumentar y disminuir dinámicamente requiere responder dos preguntas:
- ¿Cómo descubre el Servicio de Conversión de Moneda (CCS) cuántas instancias del Servicio de Forex (FS) están activas?
- ¿Cómo distribuye el Servicio de conversión de moneda (CCS) la carga entre las instancias activas?
Dado que queremos que esto sea dinámico, no podemos codificar URL en servicios FS para CCS. Es por eso que estamos presentando un servidor de nombres.
Todas las instancias de componentes (CCS y FS) están registradas en el servidor de nombres Eureka. Cuando FS necesite llamar a CCS, solicitará a Eureka Naming Server sobre instancias activas. Usaremos Ribbon para equilibrar la carga en el lado del cliente entre diferentes instancias de FS.
A continuación se muestra un diagrama de secuencia de alto nivel de lo que sucederá cuando se solicite de CCS a FS.
Además en esta serie de artículos:
- Crear un microservicio de Forex. Crearemos un servicio REST simple basado en Spring Boot Starter Web y Spring Boot Started JPA. Usaremos Hibernate para implementar JPA y conectarnos a la base de datos H2.
- Creación del servicio de conversión de moneda CCS. Crearemos un servicio REST simple usando Feign para llamar al microservicio de Forex.
- Use la cinta para equilibrar la carga.
- Implemente Eureka Naming Service y conecte FS y CCS a través de Eureka.