Nube de primavera

En este artículo presentamos principalmente el marco de desarrollo de microservicios: Spring Cloud. Aunque Spring Cloud tiene la palabra "Nube", no es una solución de computación en la nube, sino un conjunto de herramientas basado en Spring Boot que es un patrón común para construir rápidamente sistemas distribuidos.

Spring Cloud tiene las siguientes características:

Como se puede ver en la figura anterior, Spring Cloud nombra su número de versión en forma de palabra en inglés + SR + número. Entonces, ¿qué significan las palabras en inglés y SR respectivamente?

Debido a que Spring Cloud es un proyecto integral, contiene muchos subproyectos. Dado que los subproyectos también mantienen sus propios números de versión, Spring Cloud adopta este método de denominación para evitar confusiones con la versión del subproyecto. Entre ellos, palabras en inglés como Edware son los nombres de determinadas estaciones del metro de Londres y se publican en orden alfabético, lo que puede entenderse como la evolución de la versión principal. SR significa "Liberación de servicio", que generalmente significa reparación de errores.

La compatibilidad de la versión es la siguiente

Contenido de la versión

Consulte la documentación oficial: https://spring.io/projects/spring-cloud#overview

En mi último blog (Teoría de microservicios), hablé sobre dividir los servicios de una sola aplicación en microservicios individuales, y estos servicios son independientes entre sí. Entonces, ¿cómo conocemos las funciones de cada microservicio? Estado de salud, ¿cómo saber la existencia de un determinado microservicio? Por lo tanto, un marco con descubrimiento de servicios es particularmente importante. Por eso nació Eureka.

En resumen, Eureka garantiza la alta disponibilidad, flexibilidad y escalabilidad del sistema a través de la verificación de latidos, el almacenamiento en caché del cliente y otros mecanismos.

El registro y descubrimiento de microservicios se ha implementado mediante el uso de Eureka. Al iniciar cada microservicio, Eureka Client registrará su información de red con Eureka Server. Todo parece mejor. Sin embargo, dicha arquitectura todavía tiene algunos problemas, como el equilibrio de carga. En términos generales, cada microservicio implementará varias instancias. Entonces, ¿cómo distribuye un consumidor de servicios las solicitudes a múltiples instancias de proveedores de servicios?

Si el proveedor de servicios responde muy lentamente, la solicitud del consumidor al proveedor se verá obligada a esperar hasta que el proveedor responda o expire el tiempo de espera. En escenarios de alta carga, si no se abordan, estos problemas pueden provocar el agotamiento de los recursos de los consumidores de servicios o incluso el colapso de todo el sistema.

Los sistemas de aplicaciones de arquitectura de microservicios suelen contener múltiples capas de servicios. Los microservicios se comunican a través de la red para soportar todo el sistema de aplicaciones. Por lo tanto, es inevitable que existan dependencias entre los microservicios. Este fenómeno de "fallos en cascada" debido a "fallos de servicios básicos" se denomina efecto avalancha.

Como se muestra en la figura, A es el proveedor de servicios (servicio básico), B es el consumidor de servicios de A, y C y D son los consumidores de servicios de B. Cuando la indisponibilidad de A provoca la indisponibilidad de B, y la indisponibilidad se amplifica a C y D como una bola de nieve, se forma el efecto de avalancha.

Entonces, ¿cómo es Hystrix tolerante a fallas?

La siguiente es una breve explicación de este diagrama:

Zuul sirve como puerta de enlace de microservicios en la arquitectura de microservicios. La arquitectura de microservicios ya ha adoptado un prototipo básico mediante la combinación de los primeros componentes, entonces, ¿por qué seguimos utilizando una puerta de enlace de microservicios? Podemos imaginar que, en circunstancias normales, nuestra empresa no puede completar un requisito comercial con solo llamar a una interfaz.

Si al cliente se le permite comunicarse directamente con cada microservicio, habrá los siguientes problemas:

Como se muestra en la figura, la puerta de enlace del microservicio encapsula la estructura interna de la aplicación. y el cliente solo necesita comunicarse con la puerta de enlace Interacción sin llamar directamente a interfaces de microservicio específicas. Al mismo tiempo, también tiene las siguientes ventajas:

¿Por qué necesitamos gestionar las configuraciones de microservicios de la misma forma?

Para aplicaciones únicas tradicionales, los archivos de configuración se suelen utilizar para gestionar todas las configuraciones. Por ejemplo, una única aplicación desarrollada por un proyecto Spring Boot puede colocar el contenido de la configuración en el archivo application.yml. Si necesita cambiar de entorno, puede configurar varios perfiles y especificar spring.profile.active={profile} al habilitar la aplicación.

En la arquitectura de microservicios, la gestión de la configuración de microservicios generalmente tiene los siguientes requisitos: