Directorio de artículos
enlace largo nacos
1. Situación actual y antecedentes
Los respectivos canales de inserción de los módulos de configuración/nombre de la versión Nacos 1.x se implementan de acuerdo con sus propios modelos de diseño.
Los canales de envío de datos de los módulos de configuración y servidor no son uniformes , y la presión de rendimiento de las conexiones cortas http es enorme. En el futuro, Nacos necesita construir un canal de conexión largo que pueda admitir la configuración y los servicios al mismo tiempo, y reconstruir el canal push con un modelo de comunicación estándar .
2. Análisis de escena
1. Configuración
Configurar análisis de escenarios para conexiones
Entre SDK y servidor
-
El SDK del cliente necesita percibir la lista de nodos de servicio y seleccionar uno de los nodos para conectarse de acuerdo con una determinada estrategia;
cuando la conexión subyacente se desconecta, necesita cambiar el servidor para volver a conectarse. -
El cliente realiza
la comunicación de interfaz semántica RPC en campos de configuración como consulta, liberación, eliminación, supervisión y cancelación de supervisión en función de los enlaces largos disponibles actualmente. -
Para percibir el mensaje de cambio de configuración, es necesario enviar la notificación del mensaje de cambio de configuración al cliente que está escuchando actualmente; cuando la red es inestable, el cliente no puede
recibirlo y necesita admitir el reenvío y dar una alarma. -
Perciba el evento de desconexión del cliente, cierre la sesión y borre el contexto correspondiente a la conexión, como borrar el contexto de información de escucha
.
Comunicación entre servidores.
-
Un solo servidor necesita obtener la lista de todos los servidores en el clúster y crear un enlace largo independiente para cada servidor; cuando la conexión se desconecta, necesita volver a conectarse, y cuando la lista de servidores cambia, necesita crear un enlace largo del nuevo nodo Destruye el enlace largo de los nodos fuera de línea.
-
Se requiere sincronización de datos entre servidores, incluida la sincronización de información de cambio de configuración, información de número de conexión actual, sincronización de información de carga del sistema, sincronización de información de ajuste de carga, etc.
2. Servicio
Entre SDK y servidor
- El SDK del cliente necesita percibir la lista de nodos de servicio y seleccionar uno de los nodos para conectarse de acuerdo con una determinada estrategia; cuando la conexión subyacente se desconecta, necesita cambiar el servidor para volver a conectarse
- Comunicación de interfaz semántica RPC en el campo del descubrimiento de servicios, como consulta, registro, cierre de sesión, suscripción, cancelación de suscripción, etc. configurada por el cliente en función de los enlaces largos disponibles actualmente
- Al detectar cambios en el servicio, si hay un cambio en los datos del servicio, el servidor necesita enviar nuevos datos al cliente; se requiere confirmación de envío para facilitar que el servidor realice métricas y reenvíe juicios, etc.
- Perciba el evento de desconexión del cliente, cierre la sesión de la conexión y borre el contexto correspondiente a la conexión, como el servicio registrado y el servicio suscrito de la conexión del cliente
Comunicación entre servidores.
- El servidor necesita percibir el estado de supervivencia del par a través de la conexión larga y necesita informar el estado del servicio a través de la conexión larga (capacidad RPC síncrona)
- La sincronización de datos de AP Distro entre servidores requiere RPC asíncrono con capacidad de reconocimiento
3. Los requisitos básicos de los enlaces largos
1. Requisitos funcionales
cliente
Conocimiento en tiempo real del ciclo de vida de la conexión, incluidos los eventos de establecimiento y desconexión de la conexión.
El cliente llama al servidor para admitir tres modos: bloqueo síncrono, futuro asíncrono y devolución de llamada asíncrona.
Capacidad de conmutación automática de conexión inferior.
Responda al mensaje de restablecimiento de conexión del servidor para el cambio de conexión.
Selección de sitios/descubrimiento de servicios.
Servidor
Conocimiento en tiempo real del ciclo de vida de la conexión, incluidos los eventos de establecimiento y desconexión de la conexión.
El servidor envía activamente datos al cliente, y el cliente debe devolver un Ack para admitir un envío confiable, y debe volver a intentarlo en caso de falla.
El servidor empuja activamente la capacidad de ajuste de carga.
2. Requisitos de desempeño
Puede admitir la escala de millones de enlaces largos y el volumen de solicitudes y envíos, y debe ser lo suficientemente estable.
3. Equilibrio de carga
Estrategias comunes de equilibrio de carga: aleatorio, hash, round robin, peso, número mínimo de conexiones, velocidad de respuesta más rápida, etc.
-
Las similitudes y diferencias entre el equilibrio de carga de conexión corta y conexión larga: en conexión corta, debido a que la conexión se establece y destruye rápidamente, los cuatro métodos de "aleatorio, hash, sondeo, peso" pueden mantener aproximadamente el equilibrio general y el reinicio de el servidor no afectará el equilibrio general, en el que "número mínimo de conexiones, velocidad de respuesta más rápida" es un algoritmo con estado, porque es probable que los retrasos en los datos causen efectos de acumulación; las conexiones largas se deben a que después de que se establece la conexión, si no hay situación anormal, la conexión siempre se mantendrá. Es necesario volver a seleccionar un nuevo nodo de servicio. Cuando el nodo de servicio publique y se reinicie, la conexión final estará desequilibrada. La estrategia "aleatoria, por turnos, peso" puede ser se utiliza cuando el cliente se vuelve a conectar y cambia, y el "Número mínimo de conexiones, velocidad de respuesta más rápida" Al igual que las conexiones cortas, también habrá retrasos en los datos que causan efectos de acumulación. Una de las principales diferencias entre las conexiones largas y las conexiones cortas es que cuando la conexión general es estable, el servidor necesita un mecanismo de reequilibrio para reorganizar y asignar la cantidad de conexiones desde la perspectiva del clúster, tendiendo a otro estado estable.
-
Cliente aleatorio + ajuste flexible del servidor: la estrategia central es la estrategia de ajuste bidireccional cliente + servidor, selección aleatoria del cliente + ajuste flexible del tiempo de ejecución del servidor.
cliente al azar
El cliente obtiene la lista de servicios al inicio y selecciona nodos de acuerdo con reglas aleatorias. La lógica es relativamente simple y el conjunto puede mantenerse aleatorio.
Ajuste flexible del lado del servidor
(Versión implementada actualmente) Esquema de control manual
- La consola de carga del sistema desde la perspectiva del clúster proporciona vistas como el número de conexiones, la carga, etc. (ampliar el número de conexiones recién agregadas, carga, CPU y otra información, y sincronizar informes entre clústeres), realizar ajustes manuales de el número de conexiones de cada nodo del servidor, activar manualmente el reajuste y cortar manualmente los picos y llenar los valles.
- Proporciona una consola de carga desde la perspectiva del clúster: muestra la cantidad total de nodos, la cantidad total de enlaces largos, la cantidad promedio y la información de carga del sistema.
- La dirección de cada nodo, el número de enlaces largos, la diferencia del número promedio, valores positivos y negativos.
- Regule el número de nodos por encima del valor promedio, establezca el límite superior del número (temporal y persistente) y especifique los nodos de servicio para cambiar.
(Versión de estado final futuro) Solución de control de automatización
- Según la cantidad de conexiones entre cada servidor y la carga, calcula automáticamente la cantidad razonable de conexión de nodos, activa automáticamente el reajuste y corta automáticamente los picos y llena los valles. El ciclo de implementación es más largo y más dependiente de la precisión del algoritmo.
4. Ciclo de vida de la conexión
Mecanismo de mantenimiento de latidos del corazón
qué necesitamos
Percepción rápida y de bajo costo: el cliente necesita cambiar a un nuevo nodo de servicio lo antes posible cuando el servidor no está disponible, reducir el tiempo no disponible y poder percibir el evento de cambio de conexión subyacente y restablecer el contexto; el servidor necesita estar conectado cuando el cliente se desconecta Elimine el contexto correspondiente a la conexión del cliente, incluida la supervisión de la configuración, el contexto de suscripción del servicio y procese la instancia correspondiente a la conexión del cliente para que se desconecte.
- El cliente se reinicia normalmente: el cliente cierra activamente la conexión y el servidor lo percibe en tiempo real
- El servidor se reinicia normalmente: el servidor cierra activamente la conexión y el cliente lo percibe en tiempo real
Antivibración:
- Indisponibilidad temporal de la red: el cliente debe poder aceptar fluctuaciones de red a corto plazo, y se requiere un cierto mecanismo de reintento para evitar fluctuaciones de clúster. Después de que se supera el umbral, el servidor debe cambiarse automáticamente, pero se deben evitar las tormentas de solicitudes. .
Simulacro de desconexión de red:
- En el caso de una desconexión de la red, vuelva a intentarlo con una frecuencia razonable y podrá volver a conectarse y recuperarse rápidamente cuando finalice la desconexión de la red.
5. Seguridad
Admite funciones básicas de autenticación y cifrado de datos.
6. Implementación multilingüe de bajo costo
A nivel de cliente, es necesario admitir tantos idiomas como sea posible, al menos un canal de conexión del servidor Java, al que los clientes pueden acceder en varios idiomas principales, y se debe considerar el costo de implementar varios idiomas. Considere thin sdk para reducir el costo de la implementación en varios idiomas
Comparación de selección de enlaces largos
Modelo de consistencia basado en enlaces largos
1. Configurar el modelo de consistencia
consistencia del servidor sdk
Coherencia entre servidores.
Implementación liviana de recibir y procesar mensajes sincrónicos entre servidores y monitorear alarmas cuando fallan los reintentos.
Desconexión de la red: cuando la desconexión de la red es demasiado larga y la cola de tareas de reintento está llena, no existe una estrategia de eliminación.
2. Modelo de consistencia del servicio
Coherencia entre sdk-server
Coherencia entre servidores.
Diseño de componentes del modelo central
