¡Un análisis exhaustivo de los "conceptos básicos distribuidos" le permite comprender los sistemas distribuidos en segundos! 【uno】

prefacio

Aprende estas tecnologías en el proyecto, profundiza en su uso y comprensión profunda. El siguiente resumen proviene de la información del caso del proyecto Guli Mall

1. ¿Qué es un microservicio?

       El estilo arquitectónico de microservicio es como desarrollar una sola aplicación como un conjunto de pequeños servicios, cada uno de los cuales se ejecuta en su propio proceso y se comunica mediante un mecanismo liviano , generalmente una API HTTP. Estos servicios se basan en capacidades comerciales y se implementan de forma independiente a través de mecanismos de implementación totalmente automatizados. Estos servicios están escritos en distintos lenguajes de programación, así como en distintas tecnologías de almacenamiento de datos, y mantienen una mínima gestión centralizada.

En resumen: rechace las aplicaciones monolíticas grandes, los servicios de microdivisión basados ​​en los límites comerciales, e implemente y ejecute cada servicio de forma independiente.

inserte la descripción de la imagen aquí

2. Clúster, distribuido, nodo

El clúster es una forma física, y distribuido es una forma de trabajar.

Siempre que sea un grupo de máquinas, se le puede llamar un clúster, nadie sabe si trabajan juntas o no;

"Principios y paradigmas del sistema distribuido" define: "Un sistema distribuido es una colección de computadoras independientes que aparecen ante los usuarios como un solo sistema relacionado"
.

Distribuido se refiere a la distribución de diferentes negocios en diferentes lugares .

El agrupamiento se refiere a reunir varios servidores para lograr el mismo negocio .

Por ejemplo: Jingdong es un sistema distribuido, muchas empresas se ejecutan en diferentes máquinas y todas las empresas forman un gran grupo empresarial. Para cada pequeña empresa, como los sistemas de usuarios, un servidor no es suficiente cuando la presión de acceso es alta. Deberíamos implementar el sistema de usuario en varios servidores, es decir, cada sistema empresarial también se puede agrupar;

Cada nodo del sistema distribuido se puede utilizar como un clúster. Y el clúster no está necesariamente distribuido.

Nodo: un servidor en un clúster

3. Llamada remota

En un sistema distribuido, cada servicio puede estar ubicado en diferentes hosts, pero los servicios inevitablemente necesitan llamarse entre sí, lo que llamamos llamadas remotas.

Use HTTP+JSON para completar llamadas remotas en Spring Cloud

inserte la descripción de la imagen aquí

4. Equilibrio de carga

Llegaron diez millones de solicitudes, y toda la presión se le dio a un servidor. Eso no es algo muy peligroso, es mejor configurar algunos servidores más para compartir una ola de presión.

       En un sistema distribuido, el servicio A necesita llamar al servicio B, y el servicio B existe en varias máquinas, y A puede llamar a cualquier servidor para completar la función.
       Para evitar que cada servidor esté demasiado ocupado o demasiado inactivo, podemos llamar a cada servidor de manera equilibrada para mejorar la solidez del sitio web.

Algoritmo de equilibrio de carga común:
turno rotativo : seleccione el primer servidor backend en el grupo saludable para la primera solicitud, y luego selecciónelo secuencialmente hasta el último, y luego haga un bucle.

Conexión mínima : Prioriza el servidor back-end con el menor número de conexiones, es decir, la menor presión.Este método se puede considerar en el caso de sesiones largas.

Hash : Selecciona el servidor a reenviar según el hash (hash) de la IP de origen de la solicitud. Este enfoque puede garantizar hasta cierto punto que usuarios específicos puedan conectarse al mismo servidor. Considere este enfoque si su aplicación necesita manejar el estado y requiere que el usuario pueda conectarse al mismo servidor que antes.

inserte la descripción de la imagen aquí

5. Registro de servicios/Centro de descubrimiento y registro

Esto también es relativamente fácil de entender: cómo los diferentes servicios perciben la existencia de los demás, y cada servicio registra los servicios que brinda al centro de registro. Al igual que alquilar una casa, el arrendador primero envía la información relevante sobre su casa al intermediario y luego puede encontrar la casa a través del intermediario.

       El servicio A llama al servicio B. El servicio A no sabe en qué servidores está actualmente el servicio B, cuáles son normales y qué servicios han estado fuera de línea. Para solucionar este problema, se puede introducir el centro de registro;

inserte la descripción de la imagen aquí
Si algunos servicios se desconectan, el resto de nosotros podemos percibir el estado de otros servicios en tiempo real, para evitar llamar a servicios no disponibles

6. Centro de configuración

       Cada servicio termina con mucha configuración y cada servicio puede implementarse en varias máquinas. A menudo necesitamos cambiar la configuración, podemos dejar que cada servicio obtenga su propia configuración en el centro de configuración.

El centro de configuración se utiliza para gestionar de forma centralizada la información de configuración de los microservicios

       Por ejemplo, configuración de conexión de base de datos, configuración de conexión de redis, configuración relacionada de nginx, configuración de registro y descubrimiento de servicios, etc. ¿No sería problemático modificar el código cada vez? Al usar el centro de configuración para administrar la configuración unificada, puede completar fácilmente estas configuraciones en forma de una interfaz de operación visual.

inserte la descripción de la imagen aquí

7. Disyuntor de servicio y degradación del servicio

Cuando el servicio remoto al que llama está inactivo, aún accede a este servicio, eso no es una tontería. Después de esperar mucho tiempo, no hubo respuesta y finalmente se informó un error. Explosión de mentalidad, use el mecanismo de fusible de servicio, cuando el servicio llamado muera, llámelo, devuelva un valor predeterminado directamente. Dile que mi servicio no está disponible temporalmente. Degradación del servicio, cuando se accede mucho a un servicio

En la arquitectura de microservicios, los microservicios se comunican a través de la red y existe interdependencia, cuando uno de los servicios no está disponible, puede causar un efecto de avalancha. Para evitar tal situación, se deben implementar mecanismos tolerantes a fallas para proteger el servicio.

inserte la descripción de la imagen aquí

  • 1. Fusible de servicio
    • a. Establecer el tiempo de espera del servicio. Cuando el servicio llamado a menudo no alcanza un cierto umbral, podemos habilitar el mecanismo de protección del interruptor de circuito, y las solicitudes posteriores ya no llamarán a este servicio. El local devuelve directamente los datos por defecto
  • 2. Degradación del servicio
    • a. Durante el período de operación y mantenimiento, cuando el sistema está en su punto máximo y los recursos del sistema son escasos, podemos degradar el negocio secundario. Degradación: algunos servicios no manejan, o simplemente manejan [lanzar excepción, devolver NULL, usar datos simulados, llamar a Fallback para procesar lógica].

8. Puerta de enlace API

En la arquitectura de microservicios, API Gateway es un componente importante de la arquitectura general. Abstrae las funciones públicas requeridas en los microservicios y, al mismo tiempo, proporciona equilibrio de carga del cliente, fusible de servicio automático, liberación gris, autenticación unificada y limitación y flujo de corriente. control. , estadísticas de registro y otras funciones ricas nos ayudan a resolver muchos problemas de administración de API

inserte la descripción de la imagen aquí

Supongo que te gusta

Origin blog.csdn.net/weixin_43304253/article/details/130340340
Recomendado
Clasificación