1. ¿Qué es la nube primaveral?

Spring Cloud es una colección ordenada de una serie de marcos. Utiliza la conveniencia de desarrollo del Spring Boot para simplificar inteligentemente el desarrollo de la infraestructura del sistema distribuido, como el registro de descubrimiento de servicios, el centro de configuración, el bus de mensajes, el equilibrio de carga, los disyuntores, el monitoreo de datos, etc., todo se puede hacer en el estilo de desarrollo Spring Boot. Para iniciar e implementar con un clic.

2. ¿Cuáles son los componentes centrales de la nube de primavera?

Eureka: registro de servicio en el momento del descubrimiento
Fingir: Basado en el mecanismo de proxy dinámico, de acuerdo con la anotación y la máquina seleccionada, empalmando la dirección URL de la solicitud para iniciar la solicitud.
Cinta de opciones: para lograr el equilibrio de carga, elija una de varias máquinas en un servicio.
Hystrix: Proporciona un grupo de subprocesos. Los diferentes servicios utilizan diferentes grupos de subprocesos, lo que se da cuenta del aislamiento de diferentes llamadas de servicio y evita el problema de la avalancha de servicios.
Zuul: Gestión de la pasarela, la pasarela Zuul reenvía la solicitud al servicio correspondiente.

3. ¿Qué es feigin? Cuales son sus ventajas?

Fingir utiliza anotaciones basadas en interfaz
Fingir integra cinta y tiene la capacidad de equilibrar la carga
Integrado con Hystrix, con capacidad de fusión

4. ¿Cuál es la diferencia entre Ribbon y Fingir?

Ribbon llama a otros servicios, pero de diferentes formas
Las anotaciones de la clase de inicio son diferentes, Ribbon es @RibbonClient fingir es @EnableFeignClients
La ubicación especificada por el servicio es diferente: Ribbon se declara en la anotación @RibbonClient, mientras que Feign usa la declaración @FeignClient en la interfaz que define el método abstracto.
El método de llamada es diferente. Ribbon necesita construir una solicitud http por sí misma, simular la solicitud http y luego usar RestTemplate para enviarla a otros servicios. Los pasos son bastante engorrosos. Fingir necesita definir el método llamado como un método abstracto

5. ¿Qué es Spring Cloud Bus?

Spring Cloud Bus conecta nodos distribuidos con un intermediario de mensajes liviano. Se puede usar para transmitir cambios de archivos de configuración o comunicación de servicio directa, y también se puede usar para monitorear.
Si se modifica el archivo de configuración y se envía una solicitud, todos los clientes volverán a leer el archivo de configuración.

6. Tanto Eureka como ZooKeeper pueden proporcionar funciones de registro y descubrimiento de servicios. Díganos la diferencia entre los dos

ZooKeeper garantiza CP, Eureka garantiza AP
ZooKeeper tiene roles de líder y seguidor. Los nodos de Eureka son iguales (los nodos de Eureka son iguales. Siempre que haya un Eureka, se puede garantizar que el servicio esté disponible y los datos consultados no sean los más recientes)
ZooKeeper adopta el principio de más de la mitad de supervivencia y Eureka adopta un mecanismo de autoprotección para resolver el problema de la partición.
Eureka es esencialmente un proyecto, mientras que ZooKeeper es solo un proceso
Eureka puede lidiar con la situación de que algunos nodos pierdan contacto debido a fallas en la red, y no paralizará todo el sistema de registro como ZooKeeper (el servicio de registro de ZooKeeper está paralizado durante la elección, aunque el servicio eventualmente se recuperará, pero no estará disponible durante la elección)
Eureka aún puede aceptar solicitudes de registro y consulta de nuevos servicios, pero no se sincronizará con otros nodos (alta disponibilidad)

7. ¿Qué es Hystrix? ¿Lo necesitamos?

Arma anti-avalancha, con degradación de servicios, fusión de servicios, aislamiento de dependencias, monitoreo (Hystrix Dashboard)
Por algunas razones, el servicio expuesto por user-service arroja una excepción, en este caso, Hystrix se utiliza para definir un método alternativo. Si ocurre una excepción, se devolverán algunos valores predeterminados. (El propósito del disyuntor es dar tiempo al método en el que ocurre la excepción o este método puede llamar a otros métodos y, en última instancia, conducir a la recuperación de la excepción)

Servicio de degradación: doble once indicaciones ouch, exprimido

Priorice los servicios básicos, y los servicios no básicos no están disponibles o están débilmente disponibles. Especifique mediante la anotación HystrixCommand.
FallbackMethod (función de respaldo) implementa específicamente la lógica de degradación.

principio del guardián del zoológico

Zookeeper también se puede utilizar como registro para la gestión de servicios (zookeeper tiene otros usos, como bloqueos de transacciones distribuidas, etc.).
Cada vez que se inicia un microservicio, se registrará un nodo secundario temporal en zookeeper, por ejemplo: 5 servicios de pedidos, 4 servicios básicos (5 nodos temporales creados bajo el catálogo de pedidos en zk), (4 (4 contactos temporales creados bajo el catálogo de productos en zk).
Cuando un servicio está inactivo, el nodo se eliminará inmediatamente porque es un contacto temporal, y los microservicios suscritos al servicio serán notificados para actualizar la lista de servicios (hay vigilancia en zk, y siempre que haya una actualización de nodo, se notificará a los microservicios suscritos al servicio Lista de servicios de actualización de servicios).
Siempre que se registre un nuevo microservicio, se creará un nodo secundario temporal en el directorio correspondiente y se notificará al microservicio suscrito al servicio para que actualice la lista de servicios.
Cada microservicio 30 obtiene una nueva lista de servicios de zk.

GORRA

Distribuido tiene tres indicadores: consistencia (consistencia), disponibilidad (disponibilidad), tolerancia de partición (tolerancia de partición), denominado CAP. Eric propuso que el CAP no se puede lograr por completo Este es el teorema del CAP.

Dado que los requisitos de disponibilidad como registro son más altos que la coherencia, eureka parece ser más razonable que zookeeper.

Consistencia

La coherencia significa que debemos leer y escribir datos exactamente igual . Por ejemplo, un dato se almacena en dos servidores, usuario-servidor1 y usuario-servidor2.
Ahora modificamos los datos a a los datos b a través del servidor1. En este momento, si visitamos server1, debería ser b.
Pero cuando visitamos el servidor2, si la a devuelta todavía no está modificada, entonces no se cumple la consistencia, y si la b devuelta es la consistencia de los datos.

Disponibilidad

Esto es más fácil de entender, es decir, siempre que envíe una solicitud al servidor, el servidor debe responderme para asegurarse de que el servidor esté siempre disponible.

Tolerancia de partición

En términos generales, los sistemas distribuidos se distribuyen en múltiples ubicaciones. Por ejemplo, uno de nuestros servidores está en Beijing y el otro está en Shanghai. Quizás debido al clima y otras razones, los dos servidores no pueden comunicarse directamente entre sí y los datos no se pueden sincronizar. Esta es la tolerancia a fallas de la partición. Creemos que la tolerancia a la partición es inevitable. En otras palabras, P debe existir.

garantía eureka ap

** Eureka prioriza la disponibilidad: ** En la plataforma Eureka, si un servidor deja de funcionar, Eureka no tendrá un proceso de elección de líder similar a ZooKeeper; las solicitudes de los clientes cambiarán automáticamente al nuevo nodo de Eureka; cuando se caiga Una vez que se restaure el servidor, Eureka lo incorporará nuevamente a la administración del clúster de servidores; para ello, todo lo que tiene que hacer es sincronizar alguna información de registro de servicio nuevo. Por lo tanto, no hay necesidad de preocuparse por el riesgo de que el servidor "dejado atrás" sea eliminado del clúster de servidores de Eureka después de su restauración.
Eureka está incluso diseñado para hacer frente a una gama más amplia de fallas de segmentación de red y lograr requisitos de mantenimiento de tiempo de inactividad "0". Cuando ocurre una falla en la segmentación de la red, cada nodo de Eureka continuará brindando servicios al mundo exterior (Nota: ZooKeeper no lo hará): recibirá nuevos registros de servicios y los proporcionará a las solicitudes de descubrimiento de servicios posteriores. De esta manera, se puede implementar en la misma subred y aún se pueden descubrir y acceder a los servicios recién lanzados.

Cada nodo de Eureka es igual y la falla de varios nodos no afectará el trabajo de los nodos normales, y los nodos restantes aún pueden proporcionar servicios de registro y consulta. Cuando el cliente de Eureka se registra con un Eureka o descubre que la conexión falla, cambiará automáticamente a otros nodos. Mientras haya un Eureka, el servicio de registro puede estar garantizado (disponibilidad garantizada), pero la información encontrada Puede no estar actualizado (no se garantiza una consistencia sólida).
Además, Eureka también tiene un mecanismo de autoprotección. Si más del 85% de los nodos no tienen un latido normal dentro de los 15 minutos, entonces Eureka cree que hay una falla de red entre el cliente y el registro, y lo siguiente ocurrirá en este momento Sucediendo:

Eureka ya no elimina los servicios de la lista de registro que deberían caducar porque no han recibido latidos durante mucho tiempo.
Eureka aún puede aceptar nuevas solicitudes de registro y consulta de servicio, pero no se sincronizará con otros nodos (es decir, para garantizar que el nodo actual todavía esté disponible)
Cuando la red sea estable, la nueva información de registro de la instancia actual se sincronizará con otros nodos

Eureka también tiene una función de almacenamiento en caché del lado del cliente (Nota: Eureka se divide en dos partes: un programa del cliente y un programa del lado del servidor, y el programa del cliente es responsable de proporcionar interfaces de servicio de registro y descubrimiento). Por lo tanto, incluso si todos los nodos del clúster de Eureka fallan o si se produce una falla en la segmentación de la red, el cliente no puede acceder a ningún servidor de Eureka; los consumidores del servicio de Eureka aún pueden obtener la información de registro del servicio existente a través de la caché del cliente de Eureka. Incluso en el entorno más extremo, todos los nodos normales de Eureka no responden a las solicitudes, y no existe una mejor solución de servidor para resolver este problema; gracias a la tecnología de almacenamiento en caché de clientes de Eureka, los servicios al consumidor aún pueden pasar Eureka El cliente consulta y obtiene información del servicio de registro.

zookeeper garantiza cp

Como servicio colaborativo distribuido, ZooKeeper es muy bueno, pero no es adecuado para el servicio de descubrimiento de servicios , porque para el servicio de descubrimiento de servicios, incluso si devuelve un resultado que contiene información falsa, es mejor que nada ; Para el servicio de descubrimiento de servicios, es mejor devolver la información sobre qué servidores estaba disponible un determinado servicio hace 5 minutos y no encontrar un servidor disponible debido a una falla temporal de la red sin devolver ningún resultado . Por lo tanto, definitivamente es incorrecto utilizar ZooKeeper para realizar el servicio de descubrimiento de servicios.
Debido a que el guardián del zoológico tendrá tal situación, cuando el nodo maestro pierde contacto con otros nodos debido a una falla en la red, los nodos restantes volverán a elegir al líder. El problema es que el tiempo de elección del líder es demasiado largo, 30 ~ 120 segundos, y todo el grupo zk no está disponible durante la elección, lo que conduce a la parálisis del servicio de registro durante la elección. En un entorno de implementación en la nube, existe una alta probabilidad de que el clúster zk pierda el nodo principal debido a problemas de red. Aunque el servicio puede eventualmente restaurarse, la indisponibilidad a largo plazo del registro causada por el largo tiempo de elección es intolerable

Preguntas de la entrevista de SpringCloud