Explicación detallada de la arquitectura de microservicios de SpringCloud

Alibaba

1.1 Clúster distribuido monolítico

Monolito : también conocido como estructura independiente, un proyecto se implementa en un servidor y todos los recursos de servicio de todo el proyecto son proporcionados por este servidor.

Distribuido : a medida que el proyecto se vuelve más y más grande, la capacidad de procesamiento del servidor en el sistema único es limitada, por lo que el servicio del proyecto y el servicio MySQL se almacenan en dos o más servidores respectivamente, y el hardware del servidor se puede controlar mediante una implementación razonable. del proyecto Personalización.

Clúster : en una estructura distribuida, puede haber un problema de punto único de falla. En este momento, se realiza una copia de seguridad del servicio para brindar el mismo servicio, formando así un "clúster", y cada servidor en el clúster es un nodo; en Para hacer estos nodos, todos pueden tener la misma carga de trabajo y el balanceador de carga funcionará.

nombre	ventaja	defecto
monómero	Fácil de desarrollar, implementar y probar	La capacidad de procesamiento de una sola máquina es limitada, y el negocio crece hasta cierto punto, y los recursos de hardware no pueden satisfacer las necesidades del negocio.
repartido	Configurar el hardware del servidor según el proyecto y racionalizar los recursos	Hay un problema de punto único de falla, una vez que el servidor se cae, no se puede proporcionar el servicio
grupo	Terminó el problema de falla de una sola máquina, balanceo de carga	Es relativamente complicado de implementar, y una vez que el clúster es enorme, es difícil mantener cada nodo.

1.2 Evolución de la arquitectura del sistema

Arquitectura de aplicación única -> Arquitectura de aplicación vertical -> Arquitectura distribuida -> Arquitectura SOA -> Arquitectura de microservicio

1.2.1 Arquitectura de aplicación monolítica

En los primeros días de Internet, las aplicaciones eran relativamente pequeñas y sencillas, y todos los códigos funcionales se implementaban juntos para reducir los costos de desarrollo, implementación y mantenimiento.

ventajas :

• La estructura del proyecto es simple y el costo de desarrollo es bajo para proyectos pequeños.
• El proyecto se implementa en un nodo, que es fácil de mantener.

Desventajas :

• Todas las funciones están integradas en un proyecto, que no es fácil de desarrollar y mantener para proyectos grandes
• Acoplamiento estrecho entre los módulos del proyecto, baja tolerancia a fallas de un solo punto
• No se puede realizar la optimización dirigida y la expansión horizontal para diferentes módulos

1.2.2 Arquitectura de aplicación vertical

Con el aumento de visitas, la estructura única solo se puede tratar agregando nodos, pero se encuentra que no todos los módulos tienen una gran cantidad de visitas.Tomando el comercio electrónico anterior como ejemplo, el aumento de visitas de usuarios puede afectar Solo se utilizan los módulos de usuario y de pedido, pero el impacto en el módulo de mensajes es relativamente pequeño. Por lo tanto, en este momento esperamos agregar solo algunos módulos de pedidos más, pero no el módulo de mensajes. En este momento, la aplicación única no puede se debe hacer, y se debe usar la aplicación vertical.Y nació.

La llamada arquitectura de aplicación vertical consiste en dividir una aplicación original en varias aplicaciones independientes para mejorar la eficiencia. Por ejemplo, podemos dividir la aplicación única de comercio electrónico anterior en:

• Sistema de comercio electrónico (gestión de usuarios, gestión de productos, gestión de pedidos)
• Sistema de fondo (gestión de usuarios, gestión de pedidos, gestión de clientes)
• Sistema CMS (gestión de publicidad gestión de marketing)

ventajas :

• La división del sistema permite compartir el tráfico, resuelve problemas de concurrencia y puede optimizarse y expandirse horizontalmente para diferentes módulos
• Los problemas en un sistema no afectarán a otros sistemas, mejorando la tolerancia a fallas

Desventajas :

• Los sistemas son independientes entre sí y no pueden llamarse entre sí.
• Los sistemas son independientes entre sí, y habrá tareas de desarrollo repetidas.

1.2.3, arquitectura en capas

Pero con más y más aplicaciones verticales, habrá más y más códigos comerciales duplicados. Consideramos extraer códigos repetitivos, lo que forma una arquitectura en capas que combina la capa de presentación y la capa de servicio. La capa empresarial contiene la lógica empresarial; la capa de presentación solo necesita manejar las interacciones de la página.

ventajas :

• Extraiga funciones comunes como capa de servicio para mejorar la reutilización del código

Desventajas :

• El grado de acoplamiento entre los sistemas se vuelve alto y la relación entre las aplicaciones es intrincada y difícil de mantener.

1.2.4, arquitectura SOA

Bajo el desarrollo distribuido, el desperdicio de pequeños recursos de servicio está emergiendo gradualmente Agregue un centro de programación para administrar el clúster en tiempo real, programación de recursos de usuario y centro de gobierno, enfatizando la orientación al servicio

ventajas :

• Utilice el centro de registro para resolver el ajuste automático de la relación de llamadas entre servicios

Desventajas :

• Habrá dependencias entre servicios, y una vez que un determinado enlace falla, tendrá un mayor impacto (avalancha de servicios)
• La relación de servicio es compleja y la operación y mantenimiento, las pruebas y la implementación son difíciles

1.2.5 Arquitectura de microservicios

La arquitectura de microservicios es, hasta cierto punto, el siguiente paso en el desarrollo continuo de la arquitectura SOA orientada a servicios, que pone más énfasis en la "división completa" de los servicios.

ventajas :

• La división atomizada de servicios, paquetes independientes, implementación y actualizaciones aseguran una división clara de tareas de cada microservicio y facilitan la expansión
• Los microservicios usan protocolos Http livianos como RESTful para llamarse entre sí

Desventajas :

• El costo técnico del desarrollo de sistemas distribuidos es alto (tolerancia a fallas, transacciones distribuidas, etc.)

1.3 Introducción a la arquitectura de microservicios

Arquitectura de microservicio : en pocas palabras, consiste en dividir aún más la aplicación única en servicios más pequeños, y cada servicio es un proyecto que se puede ejecutar de forma independiente.

1.4 Introducción a Spring Cloud

Spring Cloud es una colección de marcos . El uso del desarrollo de Spring Boot simplifica el desarrollo de sistemas distribuidos, como el registro de detección de servicios, el centro de configuración, el bus de mensajes, el equilibrio de carga, los interruptores automáticos y el monitoreo de datos; Spring Cloud combina los marcos maduros y probados de varias empresas y finalmente desarrolla Un conjunto de herramientas de desarrollo de sistemas distribuidos que son fáciles de entender, implementar y mantener.

​ SpringBoot se enfoca en el desarrollo rápido y conveniente de microservicios individuales; mientras que SpringCloud se enfoca en el marco de gobernanza y coordinación de microservicios globales, que integra y administra microservicios individuales desarrollados por SpringBoot para proporcionar administración de configuración, servicios de integración para el descubrimiento de servicios, disyuntores, enrutamiento, bus de eventos, sistemas distribuidos, etc. En general: SpringBoot se enfoca en el desarrollo rápido y conveniente de microservicios individuales, y SpringCloud se enfoca en la colección de componentes de gobernanza de servicios globales.

Gobernanza del servicio Nacos Discovery

2.1 ¿Qué es la gobernanza del servicio?

Gobernanza de servicios : el módulo más central y básico en la arquitectura de microservicios, los usuarios pueden realizar el registro automático y el descubrimiento de cada microservicio

Registro del servicio : cada unidad de servicio primero registra la información detallada de su propio servicio en el centro de registro. El centro de registro de servicios comprueba si los servicios de la lista están disponibles mediante latidos y elimina los servicios no disponibles.

Descubrimiento de servicios : la persona que llama al servicio consulta el centro de registro de servicios para acceder a instancias de servicios específicas.

2.2 Centros de registro comunes

• Zookeeper: es un marco de servicio distribuido, utilizado principalmente para resolver algunos problemas de gestión de datos en aplicaciones distribuidas, como: servicio de sincronización de estado, gestión de clústeres.
• Eureka: La función principal es hacer el registro y descubrimiento de servicios.
• Cónsul: proporciona principalmente funciones de registro de servicios, descubrimiento de servicios y gestión de configuración para sistemas distribuidos y orientados a servicios.
• Nacos: es una plataforma dinámica de descubrimiento de servicios, gestión de configuración y gestión de servicios que es fácil de crear aplicaciones nativas de la nube.

2.3 Introducción a Nacos

nacos se compromete a descubrir, configurar y administrar microservicios, y realiza rápidamente la configuración dinámica del servicio de descubrimiento de servicios, los metadatos del servicio y la administración del tráfico.

Funciones básicas :

• Registro de servicio : envíe una solicitud REST para registrar su propio servicio con Nacos Server
• Service heartbeat : Nacos Server se mantiene a través del mecanismo heartbeat, indicando que el servicio está siempre disponible para evitar que sea eliminado, por defecto se envía un heartbeat cada 5s
• Sincronización de servicios : los clústeres sincronizarán las instancias de servicio entre sí para garantizar la coherencia de la información del servicio.
• Detección de servicios : el consumidor del servicio obtiene la lista de servicios registrada en el servidor Nacos, la almacena en caché localmente en el cliente Nacos e inicia una tarea programada en el cliente Nacos para extraer la información de registro más reciente del servicio y actualizarla en el caché local.
• Comprobación del estado del servicio : inicie una tarea programada para comprobar el estado de la instancia del servicio. Si la instancia no tiene latidos durante más de 15 s, su propiedad saludable se establecerá en falso y si la instancia no tiene latidos durante más de 30 s. Elimine la instancia directamente y vuelva a registrarse si la instancia eliminada responde al latido

2.4 Primeros pasos con Nacos

2.4.1 Instalar Nacos

下载地址: https://github.com/alibaba/nacos/releases 
下载zip格式的安装包，然后进行解压缩操作,上课使用的Nacos Server版本是1.3.2

2.4.2 Iniciar Nacos

# 进入bin目录
cd bin
#在cmd中启动
startup.cmd -m standalone

2.4.3 Acceso a Nacos

Abra el navegador e ingrese http://localhost:8848/nacos para acceder al servicio.La contraseña predeterminada es nacos/nacos

2.5 Cómo usarlo en el proyecto

2.5.1 Agregar dependencia de Nacos en pom.xml

<!--nacos客户端-->
<dependency>
	<groupId>com.alibaba.cloud</groupId>
	<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

2.5.2 Pegue la anotación **@EnableDiscoveryClient** en la clase de inicio

@SpringBootApplication
@EnableDiscoveryClient
public class ProductServer {
    
    
    public static void main(String[] args) {
    
    
        SpringApplication.run(ProductServer.class,args);
    }
}

2.5.3 Agregue la dirección del servicio Nacos en application.yml

spring:
  cloud: 
    nacos: 
      discovery: 
        server-addr: localhost:8848

Cinta de balanceo de carga de llamadas remotas

Balanceo de carga : Consiste en distribuir la carga a múltiples unidades operativas para su operación, de acuerdo a la ubicación de la ocurrencia, se divide en balanceo de carga del lado del servidor y balanceo de carga del lado del cliente .

En los microservicios, generalmente usamos el equilibrio de carga del lado del cliente, es decir, la parte que llama al servicio decide qué servicio brindar.