La respuesta en tiempo real siempre es emocionante, al igual que cuando ves a la otra parte escribiendo en WeChat, si respondes a todo en el Cañón de los Reyes, como el 666 con el que todos están de acuerdo en el bombardeo en vivo, todos ellos son inseparables del Conexión larga Soporte tecnológico.
Casi todas las empresas de Internet tienen un conjunto de sistemas de conexión persistente, que se utilizan en recordatorios de noticias, mensajería instantánea, push, bombardeo en vivo, juegos, posicionamiento compartido, cotizaciones de acciones y otros escenarios. Cuando la empresa se desarrolla a una cierta escala y los escenarios comerciales se vuelven más complejos, es más probable que varias empresas necesiten utilizar el sistema de conexión persistente al mismo tiempo.
El diseño de conexiones largas por separado entre empresas conducirá a un fuerte aumento de los costos de I+D y mantenimiento, desperdicio de infraestructura, mayor consumo de energía de los clientes e incapacidad de reutilizar la experiencia existente. El sistema de conexión persistente compartida también necesita coordinar los requisitos de autenticación, autenticación, aislamiento de datos, expansión del protocolo, garantía de entrega de mensajes, etc. entre diferentes sistemas. Durante el proceso de iteración, el protocolo debe ser compatible con versiones anteriores. El sistema también aumentará la dificultad de la gestión de la capacidad.
Después de más de un año de desarrollo y evolución, a través de nuestros servicios para varias aplicaciones internas y externas, acceda a más de una docena de servicios de conexión a largo plazo con diferentes necesidades y formas, millones de dispositivos en línea al mismo tiempo y grandes cambios repentinos. escalar el envío de mensajes Después de moderar los escenarios, hemos extraído una solución general para la puerta de enlace del sistema de conexión persistente, que resuelve varios problemas encontrados cuando varios servicios comparten conexiones largas.
La puerta de enlace de conexión persistente de Zhihu se dedica a desacoplar datos comerciales, distribuir mensajes de manera eficiente, resolver problemas de capacidad y brindar un cierto grado de garantía de confiabilidad de los mensajes.
¿Cómo diseñamos el protocolo de comunicación?
desacoplamiento empresarial
La puerta de enlace de conexión larga que admite múltiples servicios en realidad está conectada a múltiples clientes y backends de múltiples servicios al mismo tiempo, es una relación de muchos a muchos y solo se utiliza una conexión larga para la comunicación entre ellos.
Este sistema de muchos a muchos debería evitar un acoplamiento fuerte al diseñar. La lógica del lado empresarial también se ajustará dinámicamente: si el protocolo y la lógica empresarial se combinan con la puerta de enlace, todas las empresas participarán entre sí y las actualizaciones y el mantenimiento del protocolo serán extremadamente difíciles.
Por lo tanto, intentamos utilizar el modelo clásico de publicación-suscripción para desacoplar la puerta de enlace de conexión persistente del cliente y el backend empresarial. Solo necesitan acordar un tema para publicar y suscribirse libremente entre sí. El mensaje transmitido son datos binarios puros y la puerta de enlace no necesita preocuparse por la especificación del protocolo específico ni el método de serialización de la parte comercial.
control de acceso
Usamos publicación-suscripción para desacoplar la implementación de la puerta de enlace y el lado comercial. Aún necesitamos controlar el permiso del cliente para publicar y suscribirse al tema para evitar la contaminación de datos intencional o no intencional o el acceso no autorizado.
Si el conferenciante está dando una conferencia en el canal 165218 de Zhihu Live, cuando el cliente ingresa a la sala e intenta suscribirse al tema del canal 165218, el backend de Zhihu Live debe determinar si el usuario actual ha pagado. Los permisos en este caso son realmente muy flexibles: los usuarios pueden suscribirse después de pagar; de lo contrario, no pueden suscribirse. El estado de los permisos solo lo conoce el backend de Zhihu Live Business, y la puerta de enlace no puede emitir juicios independientes.
Por lo tanto, hemos diseñado un mecanismo de autenticación basado en devolución de llamada en las reglas de ACL y podemos configurar la suscripción a temas relacionados con Live y las acciones de publicación para enviarlas al juicio del servicio back-end de Live a través de devoluciones de llamada HTTP.
Al mismo tiempo, según nuestra observación del negocio interno, en la mayoría de los escenarios, lo que el negocio necesita es solo un tema privado del usuario actual para recibir notificaciones o mensajes del servidor, lo cual es muy engorroso.
Por lo tanto, diseñamos una variable de plantilla de tema en la regla ACL para reducir el costo de acceso del lado comercial. Configuramos el lado comercial para permitir que el tema a suscribirse incluya el identificador de variable de nombre de usuario conectado, lo que indica que solo los usuarios pueden suscribirse o enviar mensajes a su propio tema. .
En este momento, la puerta de enlace puede determinar de forma independiente y rápida si el cliente tiene permiso para suscribirse o enviar mensajes al tema sin comunicarse con la parte comercial.
Garantía de confiabilidad del mensaje
Como centro de transmisión de mensajes, la puerta de enlace está conectada al backend empresarial y al cliente al mismo tiempo. Al reenviar mensajes, es necesario garantizar la confiabilidad de los mensajes durante la transmisión.
TCP solo puede garantizar el orden y la confiabilidad del proceso de transmisión, pero cuando el estado de TCP es anormal, la lógica de recepción del cliente es anormal o se produce una falla, los mensajes en transmisión se perderán.
Para garantizar que los mensajes enviados o cargados sean procesados normalmente por el interlocutor, hemos implementado las funciones de recepción y retransmisión. Los mensajes comerciales importantes deben enviarse al cliente después de que se reciban y procesen correctamente. La puerta de enlace guarda temporalmente los mensajes no recibidos del cliente. La puerta de enlace juzgará la recepción del cliente e intentará enviarlos nuevamente hasta que la recepción del mensaje del cliente se reciba correctamente. .
Ante el escenario de gran tráfico del negocio de servidores, el método de enviar un recibo por cada mensaje enviado por el servidor a la puerta de enlace es ineficiente. También proporcionamos un método de recepción y envío basado en colas de mensajes, que se describirá en detalle más adelante al publicar y suscribirse.
Al diseñar el protocolo de comunicación, nos referimos a la especificación MQTT, ampliamos la autenticación y el diseño de autenticación, completamos el aislamiento y desacoplamiento de los mensajes comerciales y garantizamos un cierto grado de confiabilidad de la transmisión. Al mismo tiempo, mantiene un cierto grado de compatibilidad con el protocolo MQTT, lo que nos facilita el uso directo de clientes MQTT para la implementación, lo que reduce el costo de acceso del lado comercial.
¿Cómo diseñamos la arquitectura del sistema?
Al diseñar la arquitectura general del proyecto, nuestras prioridades son:
-
fiabilidad
-
Escalabilidad horizontal
-
Madurez del componente dependiente
Lo simple es digno de confianza.
Para garantizar la confiabilidad, no consideramos todo el almacenamiento interno de datos, la computación, el enrutamiento de mensajes y otros componentes en un gran sistema distribuido para el mantenimiento como los sistemas de conexión persistentes tradicionales, lo que aumenta la complejidad de la implementación y el mantenimiento del sistema. Intentamos separar los componentes de estas partes y dejar el almacenamiento y el enrutamiento de mensajes a sistemas profesionales, para que las funciones de cada componente sean lo más simples y claras posible.
Al mismo tiempo, también necesitamos capacidades de expansión horizontal rápida. Diversas actividades de marketing en el escenario de Internet pueden conducir a un fuerte aumento en el número de conexiones. Al mismo tiempo, el número de mensajes entregados en el sistema modelo de publicación-suscripción aumentará linealmente con el número de suscriptores del tema. La presión de almacenamiento también aumenta duplicado. Después de desmontar cada componente y reducir el estado interno del proceso, podemos implementar servicios en contenedores y utilizar contenedores para lograr una expansión horizontal rápida y casi ilimitada.
La arquitectura del sistema diseñada final es la siguiente:
El sistema consta principalmente de cuatro componentes principales:
1. La capa de acceso se implementa mediante OpenResty, que es responsable del equilibrio de carga de la conexión y el mantenimiento de la sesión.
2. Agente de conexión a largo plazo, implementado en el contenedor, responsable del análisis de protocolo, autenticación y autenticación, sesión, publicación y lógica de suscripción.
3. Almacenamiento de Redis, datos de sesión persistentes.
4. Cola de mensajes de Kafka, que distribuye mensajes a corredores o partes comerciales.
Entre ellos, Kafka y Redis son componentes básicos ampliamente utilizados en la industria, se han plataformatizado y contenedorizado en Zhihu y también pueden lograr una rápida expansión en minutos.
¿Cómo construimos una puerta de enlace de conexión larga?
capa de acceso
OpenResty es una solución de extensión Nginx ampliamente utilizada que admite Lua en la industria. Tiene excelente flexibilidad, estabilidad y rendimiento. También consideramos usar OpenResty en la selección de la solución de capa de acceso.
La capa de acceso es el lado más cercano al usuario y se deben hacer dos cosas en esta capa:
1. Equilibrio de carga, para garantizar que la cantidad de conexiones en cada instancia de Broker conectada durante mucho tiempo esté relativamente equilibrada
2. Persistencia de la sesión: un solo cliente se conecta al mismo Broker cada vez, lo que se utiliza para garantizar la confiabilidad de la transmisión de mensajes.
En realidad, existen muchos algoritmos que pueden implementar el equilibrio de carga, ya sea aleatorio o varios algoritmos Hash se pueden implementar relativamente bien, y lo más problemático es la retención de sesiones.
La estrategia común de equilibrio de carga de cuatro capas es realizar un Hash consistente de acuerdo con la IP de la fuente de conexión, lo que puede garantizar que el Hash vaya al mismo Broker cada vez que el número de nodos permanezca sin cambios y se pueda encontrar con una alta probabilidad. incluso cuando el número de nodos cambia ligeramente, nodos previamente conectados.
También hemos utilizado la estrategia IP Hash de origen antes, pero existen dos desventajas principales:
1. La distribución no es suficiente: parte de la IP de origen es la salida NAT de una LAN grande y la cantidad de conexiones en ella es grande, lo que resulta en una cantidad desequilibrada de conexiones en el Broker.
2. El cliente no se puede identificar con precisión. Cuando el cliente móvil se desconecta y cambia de red, es posible que no pueda volver a conectarse al Broker anterior.
Por lo tanto, consideramos el equilibrio de carga de siete capas y realizamos un hash consistente basado en el identificador único del cliente, de modo que la aleatoriedad sea mejor y, al mismo tiempo, también pueda garantizar el enrutamiento correcto después del cambio de red. El método convencional consiste en analizar completamente el protocolo de comunicación y luego reenviar los paquetes de acuerdo con el protocolo, lo que es muy costoso y aumenta el riesgo de errores en el análisis del protocolo.
Finalmente, elegimos utilizar el mecanismo de lectura previa de Nginx para lograr el equilibrio de carga de siete capas, que es menos intrusivo para la implementación de intermediarios de conexión a largo plazo y la sobrecarga de recursos de la capa de acceso también es pequeña.
Cuando Nginx acepta una conexión, puede especificar leer previamente los datos de la conexión en el búfer de lectura previa. Extraemos la ID del cliente analizando el primer mensaje enviado por el cliente en el búfer de lectura previa y luego usamos esta ID de cliente para realizar un Hash consistente. .Conseguí un corredor fijo.
publica y suscríbete
Presentamos Kafka, una cola de mensajes ampliamente utilizada en la industria, como centro para la transmisión de mensajes internos. Algunas de las razones de este uso se mencionaron anteriormente:
-
Reducir el estado interno del Broker conectado durante mucho tiempo, para que el Broker pueda expandirse sin presión.
-
Zhihu se ha plataformatizado internamente y admite la expansión horizontal.
Algunas otras razones son:
-
Utilice el recorte de picos en la cola de mensajes para evitar que los mensajes repentinos ascendentes o descendentes abrumen el sistema.
-
Kafka se utiliza ampliamente en sistemas empresariales para transmitir datos, lo que reduce el costo de acoplamiento con partes comerciales.
Entre ellos, es fácil entender el uso de colas de mensajes para reducir picos. Veamos cómo usar Kafka para completar mejor la conexión con el lado comercial.
(1) publicar
El agente de conexión persistente publicará el mensaje en el tema de Kafka de acuerdo con la configuración de enrutamiento, y también consumirá Kafka de acuerdo con la configuración de suscripción y enviará el mensaje al cliente suscriptor. Las reglas de enrutamiento y las reglas de suscripción se configuran por separado, por lo que pueden ocurrir cuatro situaciones:
1. Los mensajes se enrutan a Kafka Topic, pero no se consumen, lo cual es adecuado para escenarios de informes de datos.
2. Los mensajes se enrutan a Kafka Topic y se consumen en escenarios comunes de mensajería instantánea.
3. Consumir y distribuir directamente desde Kafka Topic, que se utiliza en escenarios de envío puro de mensajes.
4. Los mensajes se enrutan a un tema y luego se consumen desde otro tema, que se utiliza en escenarios donde los mensajes deben filtrarse o preprocesarse.
La flexibilidad de diseño de este conjunto de estrategias de enrutamiento es muy alta y puede resolver las necesidades de enrutamiento de mensajes de casi todos los escenarios. Al mismo tiempo, debido a que la publicación-suscripción se basa en Kafka, puede garantizar la confiabilidad del mensaje al procesar datos a gran escala.
(2) suscríbete
Cuando el agente de conexión persistente consume el mensaje del tema Kafka, buscará la relación de suscripción local y luego distribuirá el mensaje a la sesión del cliente.
Inicialmente utilizamos HashMap para almacenar directamente la relación de suscripción del cliente. Cuando el cliente se suscribe a un tema, colocamos el objeto de sesión del cliente en el mapa de suscripción con el tema como clave. Al verificar la relación de suscripción del mensaje, podemos usar el tema directamente para obtener el valor del mapa.
Debido a que esta relación de suscripción es un objeto compartido, cuando se produce la suscripción y la cancelación de la suscripción, habrá conexiones que intentarán operar este objeto compartido. Para evitar la escritura concurrente, agregamos un bloqueo a HashMap, pero el conflicto de este bloqueo global es muy grave y afecta seriamente el rendimiento.
Al final, refinamos la granularidad de los bloqueos mediante fragmentación para dispersar los conflictos de bloqueo.
Cree cientos de HashMaps localmente al mismo tiempo. Cuando necesite acceder a datos en una clave, busque uno de los HashMaps a través de Hash y módulo y luego realice operaciones. Esto dispersará los bloqueos globales entre cientos de HashMaps, lo que reducirá en gran medida los conflictos de operación. También mejora el rendimiento general.
conversación
(1) Sostenibilidad
Una vez que el mensaje se distribuye al objeto Sesión, la Sesión controla la entrega del mensaje.
La sesión juzgará si el mensaje es un mensaje de tema importante; en caso afirmativo, marque el mensaje con el nivel de QoS 1, almacene el mensaje en la cola de mensajes no recibidos de Redis y envíe el mensaje al cliente. Espere a que el cliente confirme el mensaje y luego elimine el mensaje en la cola no reconocida.
Algunas soluciones industriales mantienen una lista en la memoria y esta parte de los datos no se puede migrar durante la expansión o contracción de la capacidad. También existen algunas soluciones industriales que mantienen un almacenamiento de memoria distribuido en un clúster de conexión persistente, lo que también aumentará la complejidad de la implementación.
Colocamos la cola de mensajes no confirmados en el almacenamiento persistente externo para garantizar que después de que un único corredor caiga, el cliente pueda restaurar los datos de la sesión incluso si el cliente se conecta a otros corredores, lo que reduce la carga de expansión y contracción.
(2) Ventana corredera
Al enviar un mensaje, cada mensaje QoS 1 debe ser transmitido, procesado por el cliente y devuelto con un ACK para confirmar que la entrega se completó y que la ruta lleva mucho tiempo. Si la cantidad de mensajes es grande, cada mensaje tiene que esperar una confirmación tan larga antes de enviar el siguiente y el ancho de banda del canal de envío no se puede utilizar por completo.
Para garantizar la eficiencia del envío, diseñamos un mecanismo de envío paralelo con referencia a la ventana deslizante de TCP. Establecemos un cierto umbral como ventana deslizante para el envío, lo que significa que puede haber tantos mensajes transmitiéndose y esperando confirmación en el canal al mismo tiempo.
La ventana deslizante diseñada por nuestra capa de aplicación es en realidad algo diferente de la ventana deslizante de TCP.
No se puede garantizar que los paquetes IP en la ventana deslizante de TCP lleguen en orden, y nuestra comunicación se basa en TCP, por lo que los mensajes comerciales en nuestra ventana deslizante están en orden, lo cual solo es posible cuando el estado de la conexión es anormal, el cliente la lógica es anormal, etc. Provoca que los mensajes estén desordenados en algunas ventanas.
Debido a que el protocolo TCP garantiza el orden en que se reciben los mensajes, no es necesario volver a intentar un solo mensaje durante el proceso de envío normal y los mensajes no confirmados en la ventana se reenvían solo después de que el cliente se vuelve a conectar. El extremo receptor del mensaje también reservará un búfer del tamaño de una ventana para la deduplicación de mensajes para garantizar que los mensajes recibidos por el lado comercial no se repitan.
La ventana deslizante que construimos basada en TCP garantiza el orden de los mensajes y mejora en gran medida el rendimiento de la transmisión.
escribe al final
El grupo de infraestructura es responsable de la entrada de tráfico de Zhihu y la construcción de infraestructura interna. Externamente, estamos luchando en la primera línea del tráfico masivo. Internamente, proporcionamos una infraestructura sólida para todas las empresas. Una solicitud y cada llamada en la intranet están estrechamente relacionadas. a nuestro sistema.
Fuente del artículo: https://zhuanlan.zhihu.com/p/66807833
Me pregunto si quieres saber más casos de Zhihu después de leer este artículo. Del 6 al 7 de julio, en el 43º Taller MPD de la Estación de Beijing, invitamos al arquitecto de pruebas de Zhihu, Wang Shouyu, a compartir en profundidad durante 3 horas:
Resumen del curso: El objetivo principal del equipo de control de calidad es garantizar la calidad de la entrega del producto. Durante el proceso de trabajo, nos encontraremos con muchos problemas comunes: mala calidad de las pruebas, muchas pruebas manuales y muchas fallas en línea. En este tema, el equipo de control de calidad de Zhihu brindó una nueva solución al problema: obtener productos de alta calidad mediante la construcción de una cultura de calidad en la que todos los empleados presten atención a la calidad y participen en el control de calidad.
Además de Zhihu, expertos de primera línea y expertos técnicos de Ali, Baidu, Tencent, Sina, Qunar, Didi, NetEase, VIPKID y otras empresas participarán en la competencia a través de discursos, ejercicios prácticos, discusiones grupales y PK entre grupos. etc., hablar con casos, restaurar escenarios de trabajo reales y brindar habilidades laborales reales.