Prefacio:
Como proveedor de audio y video en tiempo real, ZEGO es un proveedor de audio y video en tiempo real. La estabilidad del sistema afecta directamente la experiencia subjetiva de los usuarios. Cómo garantizar una alta disponibilidad del servicio y una experiencia de usuario óptima es un desafío para la industria. exploración y práctica de la estructura sobre arquitectura y operación de alta disponibilidad, espero que pueda ser útil o inspirador para todos.
1. Antecedentes y desafíos
La red global es compleja y cambiante, y la infraestructura de red en cada región es desigual. A menudo, debido al tiempo de inactividad de la máquina, la falla de la sala de computadoras y la fluctuación de los enlaces de la red pública entre los IDC, la transmisión push-pull falla o la calidad del video se deteriora. ¿Cómo aborda ZEGO los problemas causados por los factores irresistibles mencionados anteriormente?
Primero, permítanme presentarles varios escenarios de fallas comunes:
- falla independiente
- Falla en la sala de cómputo
- Ráfaga de gran tráfico
- Fallo de servicio externo ZEGO
- Falla del centro de control/clúster
- Fallo de línea de red local entre salas de ordenadores
En segundo lugar, cuando los nodos perimetrales de transmisión de medios acceden a las redes de los usuarios finales, se enfrentan principalmente a los siguientes desafíos:
- La resolución de IP puede no ser precisa
- Limitación del protocolo UDP del entorno de red del usuario
- Restricciones de puerto del entorno de red del usuario
- Hay múltiples salidas en el entorno de red del usuario.
- El nodo de negocio en la nube no tiene buen acceso a un determinado operador
A continuación, se describirá en detalle cómo ZEGO diseña un sistema RTC con alta disponibilidad y fuerte tolerancia a desastres y fallas para resolver los problemas y desafíos anteriores y crear una experiencia RTC estable para los clientes.
2. Es decir, cómo lidiar con diferentes problemas de fallas
Un escenario de aplicación simple: un ancla en Beijing inicia una solicitud de programación y el centro de control utiliza la estrategia del acceso más cercano para emitir una lista de nodos: [ip1:puerto,ip2:puerto,ip3:puerto...], el La prioridad predeterminada es usar el primer nodo que empuja y extrae flujos, de modo que el ancla pueda empujar flujos al nodo 1. La audiencia en Shenzhen también hizo una solicitud de programación para obtener el nodo 6 e inició una solicitud de transmisión al nodo. El nodo 6 realizó una extracción entre servidores en el nodo 1 para unir las transmisiones, realizando un escenario de transmisión push-pull simple.
Figura 1: Gráfico de escena de flujo push-pull simple
1. Falla independiente
Las fallas de una sola máquina son relativamente comunes y, por lo general, solo se requiere la implementación de varias máquinas. Los nodos anormales se eliminan automáticamente cuando ocurre una falla. ZEGO SDK admite la lógica de reintento. Después de desconectar la conexión, vuelva a intentar el siguiente nodo. Como se muestra en la Figura 1, cuando los anclajes de Beijing solicitan la programación, obtendrán múltiples nodos. Cuando el nodo 1 falla, el sdk volverá a intentarlo automáticamente en el nodo 2.
2. Fallo en la zona de disponibilidad/sala de ordenadores
La probabilidad de este riesgo es mucho menor que la de una sola máquina, pero no es del todo imposible, en situaciones reales, todavía hay una cierta probabilidad.
Lo más común es que la fibra que conduce a la sala de computadoras se corte o el IDC en algunas áreas no esté disponible debido a ataques DDOS o la calidad de la red sea deficiente. ZEGO generalmente adopta un esquema de implementación de sala de múltiples computadoras. Cuando se devuelve el resultado de la programación, incluye al menos 2 o más nodos en la sala de computadoras, y el SDK volverá a intentar en la sala de computadoras normal.
3. Mucho tráfico repentino
Este tipo de riesgo es relativamente común, y ZEGO cuenta principalmente con los siguientes métodos para prevenirlo y controlarlo.
- La interfaz externa del propio servicio tiene medidas de limitación de frecuencia, limitación de corriente y fusibles, un mecanismo de expansión automática rápida;
- Para el despliegue del modelo de embudo superior en operación y mantenimiento, la capacidad de servicio de la capa más externa es menor que la capacidad de la siguiente capa, y el flujo está restringido en la capa más externa para proteger el flujo existente;
- Cuando el cliente accede, el acceso se divide en cubos. Además de compartir la capa de datos, los nodos de servicio se implementan de forma aislada. Cuando un cliente tiene una ráfaga de tráfico pesado, puede evitar afectar a más clientes.
4. Fallo del servicio externo ZEGO
Tomando como ejemplo la falla de retuitear CDN, existen dos casos de mala calidad de retuiteo y retuiteo fallido, ZEGO tiene principalmente los siguientes métodos para solucionarlo:
- Cuando falla el retweet, el servicio se basará en la IP de la resolución del nombre de dominio de CDN para el reintento de sondeo;
- La mala calidad del retweet generalmente se refiere a la fluctuación de la red entre el nodo ZEGO y el nodo CDN que hace que la transmisión de video se congele. La causa raíz de la mala calidad puede ser el problema del propio nodo CDN, o puede ser causada por el error de resolución DNS local del nodo. Para la mala calidad de los nodos retuiteados, el mecanismo inteligente de detección y programación desarrollado por ZEGO puede habilitar Nodos ZEGO para obtener la mejor lista actual de nodos CDN.
5. Falla del centro de control/clúster
En general, la probabilidad de falla del centro de control es muy rara. Cuando todo el centro de control falla, generalmente significa que todas las salas de computadoras en toda la región de un determinado proveedor de nube están caídas.
Ante tales fallas a nivel de desastre, ZEGO ha implementado una arquitectura multicéntrica global. Cuando el centro de control A falla, la entrada del centro de fallas puede cerrarse a tiempo. Consulte la Figura 2, el diagrama de arquitectura de versión simple multicentro:
Figura 2: Diagrama de estructura de la versión simple del multicentro global
6. Fallo de línea de red local entre salas de ordenadores
ZEGO en sí mismo es implementado globalmente por proveedores de múltiples nubes, y los enlaces de red pública entre nodos a menudo fluctúan. ¿Cómo resolver el punto de dolor de esta industria? El sistema MSDN de enrutamiento inteligente de desarrollo propio de ZEGO, lo siguiente presentará nuestra construcción y exploración de MSDN.
Basándose en los nodos globales de los principales proveedores de la nube, ZEGO ha implementado más de 200 salas de computadoras en todo el mundo sin cobertura de puntos muertos y un servicio MSDN de desarrollo propio para construir un enlace de comunicación multinube global confiable.
Puedo presentar brevemente el concepto de diseño central de ZEGO MSDN:
A través de la red de reenvío de datos de 3 capas autoconstruida, los nodos de origen y destino se comunican para planificar múltiples enlaces, detectar en tiempo real, dar prioridad a la línea óptima y cambiar de línea sin problemas cuando la línea actual falla o la calidad se deteriora.
Figura 3: Introducción a MSDN
A continuación, se utiliza un caso práctico para presentar cómo ZEGO MSND resuelve el problema de la falla de la red entre las salas de computadoras.
Introducción del caso :
Aproximadamente a las 15:00 del 01-15, hubo una gran pérdida de paquetes en la red pública de Mumbai, A, a A, Frankfurt, y la calidad del enlace se deterioró, como se muestra en la Figura 4:
Figura 4: Vista de monitoreo de tasa de pérdida de paquetes de red
Luego, MSDN activa automáticamente el cambio de enlace: como se muestra en la Figura 5. Después de cambiar, el enlace se convierte en Mumbai (proveedor de la nube T) --> Frankfurt (proveedor de la nube T) --> Frankfurt (proveedor de la nube A)
Figura 5: El número de cambios de enlace activados entre salas de ordenadores defectuosas
Debido al cambio de línea, el tráfico en Frankfurt (T Cloud Business) ha aumentado, como se muestra en la Figura 6:
Figura 6: Número de flujos simultáneos en la sala de computadoras
Resumen: Debido a la gran pérdida de paquetes en la red pública de Mumbai de T Cloud Business a A Cloud Business Frankfurt, MSDN cambia automáticamente el enlace. Después del cambio, el enlace se convierte en Mumbai (T Cloud Business) -->Frankfurt (T Cloud Business) ) --> Frankfurt (un proveedor de la nube), todo el proceso se ha cambiado sin problemas y el usuario no tiene percepción.
3. ¿Cómo accede de manera óptima el nodo perimetral de medios de transmisión a la red de usuarios finales?
1. ¿Cómo resolver el problema de la resolución de IP inexacta?
Este fenómeno es relativamente común, la imprecisión de la base de datos de IP afecta directamente la experiencia del usuario, por ejemplo, si una IP africana se resuelve a los Estados Unidos, el resultado es que el usuario está conectado al nodo ZEGO en los Estados Unidos. A veces, está claro que un análisis de IP es inexacto, y enviar comentarios al fabricante de la biblioteca de IP a menudo lleva mucho tiempo antes de que se pueda reparar una nueva versión. En respuesta a la situación anterior, ZEGO corrige la IP conocida o el segmento de IP que se analizó incorrectamente y detecta y analiza periódicamente los cambios en el segmento de IP, y actualiza el servicio a tiempo para resolver el problema.
2. ¿Cómo resolver la limitación del protocolo UDP en el entorno de red del usuario?
Este tipo de problema es relativamente común. Generalmente está limitado por el conmutador del enrutador del usuario y otros equipos. El protocolo UDP está prohibido, lo que resulta en la incapacidad de comunicarse con el nodo de transmisión de medios. El propio nodo de medios de transmisión de ZEGO proporciona capacidades multiprotocolo UDP y TCP. Cuando el protocolo de usuario es limitado, el SDK intentará cambiar los protocolos para la comunicación de medios de transmisión.
3. ¿Cómo resolver la restricción de puertos del entorno de red del usuario?
Este tipo de problema también es relativamente común. Generalmente es más común en el entorno de la oficina. Algunas empresas consideran problemas de seguridad y algunos puertos están prohibidos. ZEGO ha optimizado la estrategia de programación. Los nodos que proporcionan devoluciones de programación son generalmente puertos diferentes. Cuando el puerto del cliente está limitado, el SDK intentará cambiar los nodos para transmitir la comunicación multimedia.
4. ¿Cómo resolver el problema del entorno de salida múltiple en el entorno de red del usuario?
Este tipo de situación también es bastante común. Teniendo en cuenta la situación de recuperación ante desastres, la oficina de la empresa suele conectar dos líneas de diferentes operadores. Algunas empresas tienen un entorno más complicado, como el enrutamiento para restringir algo del tráfico para pasar por la salida VPN. ¿Por qué el entorno de red de múltiples salidas afecta la experiencia del usuario?
Por ejemplo:
Cuando el usuario inicia una solicitud de programación, la red de salida utiliza una VPN (si la VPN llega a los Estados Unidos).En este momento, la solicitud iniciada por el usuario identificado por el servicio de programación ZEGO como Estados Unidos volverá a los Estados Unidos. primero el nodo de transmisión de medios; al conectarse, la salida de la red se cambia a la predeterminada (si la línea predeterminada es Guangdong Mobile), se convierte en una situación en la que un usuario de Guangdong Mobile se conecta al nodo de medios de EE. UU., y la calidad de esto es definitivamente relativamente pobre.
Entonces, ¿cómo lo resuelve ZEGO?
ZEGO SDK está optimizado junto con el servidor. El principio es: cuando el usuario se conecta al nodo de medios, el nodo de medios devolverá la IP percibida del cliente del usuario al SDK. Cuando el SDK encuentra una inconsistencia al comparar y enviar la IP del cliente, el SDK enviará al cliente IP percibida por el nodo de medios para comenzar de nuevo Programación, de modo que se obtenga el nodo de medios de transmisión que coincida con el entorno de red de transmisión push-pull real del usuario.
5. ¿Cómo resolver el problema de que los nodos comerciales de la nube no pueden acceder a un determinado operador sin problemas?
El entorno de red en sí es complejo y cambiante, ¿cómo acceder mejor a los usuarios finales? Este es también el punto más desafiante, ZEGO lo ha optimizado desde la perspectiva del SDK y el servicio en segundo plano.
1) Puntos de optimización en el lado del SDK: detección en tiempo real y lógica de programación dinámica
- La primera es la detección de calidad en tiempo real. Si el usuario inicia sesión por primera vez, el SDK realizará una detección de calidad de múltiples nodos en los resultados de la programación y obtendrá el nodo con la mejor calidad para la conexión.
- En segundo lugar, para los usuarios que tienen registros de flujo push-pull existentes, el SDK impulsa el cálculo del nodo óptimo en función de los datos históricos para la programación dinámica.
- Finalmente, la calidad del nodo superior conectado no es buena durante el uso, y el rtt y la tasa de pérdida de paquetes son relativamente altos. El SDK volverá a detectar todos los nodos y seleccionará el nodo con la mejor calidad para la reconexión.
2) Puntos de optimización en el lado del servicio de fondo: el fondo ajusta dinámicamente la estrategia de programación del clúster a través del análisis a gran escala del sistema operativo de calidad y retroalimenta al sistema de programación.
- Utilice el algoritmo de calidad para calificar la red del usuario final para evaluar la calidad del flujo push-pull. El algoritmo específico puede entenderse como la suma de puntos cuando el rtt del usuario y la tasa de pérdida de paquetes caen en una buena área, y restando puntos si caen. en una zona mala Puntos, cuanto menor sea el rtt y la pérdida de paquetes, mayor será el coeficiente de bonificación, y cuanto mayor sea el rtt y la pérdida de paquetes, mayor será el coeficiente de deducción para obtener un puntaje percentil.
- A través de este puntaje, se puede llevar a cabo un análisis de datos multidimensional. Puede observar el puntaje de la dimensión del país solo para medir la calidad de acceso general de un país. La Figura 7 es el puntaje de calidad de los 5 países principales; Nivel área administrativa, isp, puntaje de calidad de la sala de computadoras de idc, cuando se descubre que el puntaje de calidad de un determinado operador en una determinada región de un determinado país continúa disminuyendo, el sistema de operación de calidad analizará la cobertura óptima de la sala de computadoras y la sincronizará con el servicio de despacho, y el servicio de programación se combinará con la sala de cómputo Factores como la capacidad hacen ajustes de programación reales para restaurar la calidad.
Figura 7: Puntuaciones de calidad de los 5 países principales
- Por supuesto, habrá un ligero retraso en el tiempo de retroalimentación del sistema operativo de calidad dependiente de la programación, que es más adecuado para situaciones que no se han restaurado durante mucho tiempo. Para la fluctuación de fase de la red a nivel de un minuto, la sala de computadoras del nodo realizará una detección en tiempo real de los principales operadores en los países cubiertos por la red y realizará ajustes oportunos y dinámicos cuando se descubra que la calidad de un determinado operador en la sala de computadoras ha disminuido. rechazado
4. Resumen y perspectiva
Lo anterior es la introducción de la operación de alta disponibilidad y la garantía de capacidad de ZEGO, la lógica de reintento de ZEGO SDK, el esquema de implementación de recuperación ante desastres del servidor, el diseño de la arquitectura multicéntrica, la aplicación de MSDN y otros medios son importantes para mejorar el SLA del efecto del servicio.
La operación de alta disponibilidad de RTC no solo es una dirección de investigación popular, sino también un sistema complejo. Aquí solo se menciona una parte del trabajo. ¡Continuaremos explorando y optimizando para brindar a los clientes una experiencia de servicio de alta calidad!