Registro de servicios y descubrimiento de arquitectura de microservicios (1)

¿Qué debemos hacer si no existe un centro de registro de servicios?

En las industrias tradicionales, las siguientes soluciones son las más comunes en la arquitectura de proyectos:

Esta arquitectura es la más sencilla de desarrollar e implementar y generalmente es adecuada para situaciones pequeñas y medianas. Cuando el número de visitas no es demasiado grande, cada sistema puede atender a una máquina. Las llamadas entre sistemas también obtienen conexiones directas al PUERTO IP de cada uno.

A continuación, tal vez porque la aplicación B comienza a acceder a una gran cantidad de máquinas individuales, ya no puede satisfacer nuestras necesidades, por lo que aparecerán algunas herramientas de proxy inverso. Esta es la arquitectura más común, como Apache y. Nigix Evolution:

En comparación con el acceso anterior de una sola máquina a la aplicación B, aunque este método de proxy nginx reduce la presión sobre el servidor, Nginx puede bloquearse y todo el servicio no estará disponible, por lo que existe. Tenemos esta estructura:

Mirándolo de esta manera, el programa es perfecto. Entonces las cosas no van tan bien como se esperaba. Esto es solo la aplicación A que llama a la aplicación B. Si la aplicación A llama a las aplicaciones B, C, D, E ... esto es completamente inconsciente de sí misma. La arquitectura de lo que se hará más adelante. Parece estar bien, pero definitivamente agotará la operación y el mantenimiento (la configuración de nginx será muy confusa, lo que conducirá directamente a la imposibilidad de realizar la operación y el mantenimiento).

¿Qué hace el registro de servicios?

El tipo de mano de obra mencionado anteriormente (principalmente operación y mantenimiento) es relativamente engorroso y difícil de mantener. También existen algunos inconvenientes: cambios en la dirección del servicio de la aplicación, adición del servidor de eventos Double Eleven, etc. Por lo tanto, podemos adoptar dicha arquitectura. Entonces podemos tener una arquitectura de este tipo:

El registro de servicios mantiene principalmente la lista de puertos IP de cada servicio de aplicación, mantiene la comunicación con cada servicio de aplicación y realiza la detección de latidos dentro de un cierto intervalo de tiempo. no se puede alcanzar, la lista de IP del servicio se eliminará y se notificará a otros servicios de aplicaciones para que se actualicen. Del mismo modo, si se agrega un nuevo servicio, el servicio de la aplicación se registra en el registro y el registro del servicio notifica a otros servicios de la aplicación para que se actualicen. Cada aplicación tiene una lista de direcciones que necesitan llamar al servicio de aplicación correspondiente, por lo que solo se maneja el equilibrio de carga del lado del cliente al realizar llamadas.

2. Registro de microservicios

1. Zookeeper

ZooKeeper es un servicio de coordinación de aplicaciones distribuidas de código abierto proporcionado por Chubby de código abierto. La implementación es un componente importante de Hadoop y Hbase. Es un software que proporciona servicios consistentes para aplicaciones distribuidas. Las funciones proporcionadas incluyen mantenimiento de configuración, servicios de nombres de dominio, sincronización distribuida, servicios grupales, etc.

El texto anterior está tomado directamente de la Enciclopedia Baidu. Muchas empresas nacionales que realizan desarrollo distribuido eligen inicialmente el marco dubbo. El centro de registro de dubbo framework utiliza principalmente zookeeper. La comunicación subyacente entre el servidor zookeeper y el cliente es netty. ZooKeeper adopta la teoría CAP de CP y, en general, la implementación de un clúster requiere al menos 3 unidades. Una implementación de clúster general requiere al menos 3 máquinas.

2.Euraka

Echemos un vistazo a la arquitectura de euraka:

Registro: registro de servicio

Cuando el cliente Eureka envía una solicitud a Eureka Cuando un servidor se registra, proporciona sus propios metadatos, como dirección IP, puerto, URL del indicador de tiempo de ejecución, página de inicio, etc.

Renovación: Renovación del Servicio

El cliente Eureka envía un latido cada 30 segundos para renovar el contrato. La renovación notifica al servidor Eureka y el cliente Eureka aún existe sin ningún problema.

Normalmente, si el servidor Eureka no recibe una renovación del cliente Eureka dentro de los 90 segundos, elimina la instancia del registro. Se recomienda no cambiar el intervalo de actualización.

Obtener el registro: Obtenga la información del registro

El cliente Eureka obtiene la información del registro del servidor y la almacena en caché localmente. El cliente utiliza esta información para buscar otros servicios a los que llamar de forma remota. La información del registro se actualiza periódicamente (cada 30 segundos). La información de la lista de registro devuelta cada vez puede ser diferente de la información almacenada en caché por el cliente Eureka, y el cliente Eureka manejará automáticamente esta información. Si por algún motivo la información del registro no puede coincidir a tiempo, el cliente Eureka volverá a leer toda la información del registro. El servidor Eureka almacena en caché la información del registro. Todo el registro y la información de cada aplicación están comprimidos, y el contenido comprimido es idéntico al contenido sin comprimir. El cliente Eureka y el servidor Eureka pueden comunicarse utilizando el formato JSON/XML. De forma predeterminada, el cliente Eureka utiliza el formato JSON comprimido para obtener información de la lista de registro.

Cancelar: cierre del servicio

Cuando se cierra el programa, el cliente Eureka enviará una solicitud de cancelación al servidor Eureka. Una vez enviada la solicitud, la información de la instancia del cliente se elimina del registro de instancias del servidor. Esta solicitud de cancelación no se realiza automáticamente, requiere llamar al siguiente comando:

DiscoveryManager.getInstance().shutdownComponent()

Servicio de desalojo

Predeterminado; Bajo esta condición, cuando el cliente Eureka no envía actualizaciones del servicio (es decir, latidos) al servidor Eureka durante 90 segundos consecutivos, el servidor Eureka eliminará la instancia del servicio de la lista de registro del servicio, es decir, el desalojo del servicio.

Mecanismo de autoprotección:

Dado que el servidor Eureka elimina periódicamente los servicios que no se han renovado después del tiempo de espera, puede haber una situación en la que la red sea anormal durante un período de tiempo y todos Ninguno de los servicios fue renovado y el servidor Eureka excluiría todos los servicios, lo cual obviamente no es razonable. Por lo tanto, Eureka Server tiene un mecanismo de autoprotección. Al contar la proporción de fallas de renovación en un corto período de tiempo, si alcanza un cierto umbral, se activará el mecanismo de autoprotección. Bajo este mecanismo, Eureka Server no seleccionará. cualquier microservicio hasta que sea normal. Luego salga del mecanismo de autoprotección. Interruptor de autoprotección (eureka.server.enableelf-preservation: false)

3.Consul

Diagrama de arquitectura recomendado por Consul:

Consul no está tan implementado como Euraka Simple, está desarrollado en lenguaje Go y requiere una implementación separada para operación y mantenimiento. También proporciona conexión de cliente Java y utiliza CAP CP. Nacos

Euraka se recomendó en las primeras versiones de Spring Cloud Netflix. Posteriormente, euraka1.0 ya no se mantuvo y euraka2.0 fue de código cerrado. Esto resultó en el desarrollo de muchos proyectos nuevos basados ​​en Spring Cloud Netflix. elegir utilizar Consul.

Nacos es el centro de registro de servicios de código abierto de Alibaba y se puede integrar con Spring Cloud Aliaba.

Introducción oficial de Nacos:

Nacos se compromete a ayudarlo a descubrir, configurar y administrar microservicios. Nacos proporciona un conjunto de funciones fácil de usar que le ayuda a implementar el descubrimiento dinámico de servicios, la gestión de la configuración de servicios y la gestión de servicios y tráfico.

Nacos te ayuda a crear, entregar y gestionar microservicios de forma más ágil y sencilla.

Nacos es una infraestructura de servicios para construir arquitecturas de aplicaciones modernas centradas en servicios (por ejemplo, paradigma de microservicios, paradigma nativo de la nube).

Mapa de Nacos

Mapa del ecosistema de Nacos

Como se muestra en el Panorama de Nacos, Nacos admite a la perfección múltiples ecosistemas importantes de código abierto, como

Spring Cloud

Apache Dubbo y Dubbo Mesh TODO

Kubernetes y CNCF. Kubernetes y CNCF TODO

En tercer lugar, la elección de la tecnología de descubrimiento y registro de servicios

El siguiente contenido proviene del intercambio en línea:

Además del contenido anterior, También recomiendo utilizar Nacos actúa como un registro de servicios.

Motivo de la recomendación:

Estructura de registro de servicios de Nacos Maplt; espacio de nombres, Maplt; grupo:: serviceName, Servicegt; Y se lanza el modo Canary compatible, el mecanismo de sincronización de latidos también es más rápido y las actualizaciones del servicio son más oportunas.