La práctica de RocketMQ en gobernanza de mensajes distribuidos y gobernanza de microservicios
Hello se ha convertido en una plataforma integral de viajes móviles, que incluye viajes en dos ruedas (Hello bicicleta, Hello ciclomotor, Hello coche eléctrico, cambio de batería Xiaoha) y viajes en cuatro ruedas (Hello autostop, llamada de taxi en red completa). , Hola taxi), y exploré múltiples ecologías de vida local, como hoteles y tiendas.
A medida que el negocio de la empresa continúa desarrollándose, el tráfico también aumenta. Descubrimos que algunos accidentes importantes en la producción a menudo desaparecen debido al tráfico repentino. Por lo tanto, es particularmente importante controlar y proteger el tráfico y garantizar una alta disponibilidad del sistema.
En este artículo, compartiremos la experiencia de Hello en la gestión del tráfico de mensajes y llamadas de microservicios.
Liang Yong (Lao Liang), uno de los autores de la columna de "RocketMQ Practice and Advancement", participó en la revisión del manuscrito de "RocketMQ Technology Insider". Conferenciante en la Conferencia ArchSummit Global Architects y en la QCon Case Study Society.
Actualmente se dirige principalmente al middleware back-end. En la cuenta oficial de WeChat, Guannong Laoliang ha publicado más de 100 artículos sobre batallas de código fuente, que cubren la serie RocketMQ, la serie Kafka, la serie GRPC, la serie Nacosl, la serie Sentinel y la serie Java NIO. Actualmente trabajando en Hellobike como experto técnico senior.
Antes de comenzar, hablemos de gobernanza. El siguiente es el entendimiento personal de Lao Liang:
La compañía ha usado RabbitMQ antes. Los siguientes son los puntos débiles al usar RabbitMQ. Muchos de ellos se deben al límite actual del clúster RabbitMQ.
Existe tal error: varias empresas utilizan una base de datos. Durante el período pico de la tarde, el tráfico aumentó drásticamente y la base de datos se suspendió.
Pensamiento: Tanto las noticias como los servicios requieren medidas de gobernanza sólidas.
Cuáles son nuestros indicadores clave y cuáles son nuestros indicadores secundarios es la cuestión principal en la supervisión de noticias.
Objetivos de diseño
Tiene como objetivo proteger la complejidad del middleware subyacente (RocketMQ/Kafka) y enrutar mensajes dinámicamente a través de una identificación única. Al mismo tiempo, se construye una plataforma de gestión de mensajes que integra gestión de recursos, recuperación, monitoreo, alarmas, inspección, recuperación ante desastres y operación y mantenimiento visual para garantizar el funcionamiento fluido y saludable del middleware de mensajes.
Es la capacidad de simplificar problemas complejos.
API unificada simplificada
Proporciona un SDK unificado que encapsula dos tipos de middleware de mensajes (Kafka/RocketMQ).
La creación automática de grupos de consumidores temáticos no es adecuada para entornos de producción, provocará una pérdida de control y no favorece la gestión del ciclo de vida completo ni la estabilidad del clúster. El proceso de solicitud debe controlarse, pero mantenerse lo más simple posible. Por ejemplo, solicitar que todos los entornos entren en vigor a la vez, generar reglas de alarma relevantes, etc.
Supervisar si el cliente se utiliza de forma estandarizada y encontrar medidas adecuadas para controlarlo.
Tráfico instantáneo y control de flujo del clúster en el escenario 1
Supongamos que ahora hay 65,438+00000 Tps en el clúster y instantáneamente se convierte en 20,000 o más. Este tipo de tráfico es An. Un aumento excesivamente pronunciado probablemente conducirá a un control del flujo del grupo. Para este escenario, es necesario monitorear la velocidad de envío del cliente y hacer que el envío sea más suave después de alcanzar la velocidad y el umbral de aumento pronunciado.
Escenario 2: Noticias de última hora y fluctuación del clúster
Cuando el cliente envía mensajes grandes, como mensajes de cientos de KB o incluso varios megabytes, puede provocar tiempos de E/S prolongados y fluctuación del clúster. . Para este tipo de gestión de escenarios, es necesario monitorear el tamaño de los mensajes enviados. Utilizamos servicios que identifican mensajes grandes mediante inspección post-mortem y promueven el uso de la compresión o reconstrucción de compañeros de clase. Los mensajes se controlan dentro de 10 KB.
Escenario 3 Versión baja del cliente
Con la iteración de funciones, la versión del SDK también se actualizará y los cambios además de las funciones pueden introducir riesgos. Cuando se utiliza una versión de bajo perfil, una es que no puede admitir funciones y la otra es que puede haber riesgos de seguridad.
Para comprender el uso del SDK, puede informar la versión del SDK y promover su uso entre los estudiantes a través de inspecciones.
Escenario 4 Extracción y recuperación del flujo de consumo
La eliminación y recuperación del flujo de consumo suelen tener los siguientes escenarios de uso. La primera es que el tráfico debe eliminarse primero cuando se lanza la aplicación, y la segunda es que el tráfico debe eliminarse primero y luego verificarse al localizar el problema. Para admitir este escenario, es necesario monitorear los eventos de eliminación/restauración en el lado del cliente y pausar y reanudar el consumo.
Escenario 5 Transmisión/Consumo Detección que requiere mucho tiempo
¿Cuánto tiempo se tarda en enviar/consumir un mensaje? Al monitorear e inspeccionar situaciones que requieren mucho tiempo, podemos identificar aplicaciones con bajo rendimiento y promover una transformación específica para mejorar el rendimiento.
El escenario 6 mejora la eficiencia de la investigación y el posicionamiento.
Al solucionar un problema, a menudo es necesario recuperar información relacionada con el ciclo de vida del mensaje, como qué mensajes se enviaron, dónde existían y cuándo se utilizaron. Esta parte puede conectar el ciclo de vida del mensaje a través de msgId. Además, los mensajes se unen en una solicitud incorporando identificadores de enlace similares a rpcId/traceId en el encabezado del mensaje.
Información de seguimiento requerida
Medidas de control comunes
Monitorear el uso de recursos de los grupos de consumidores temáticos.
Escenario 1: El impacto del retraso en el consumo en las empresas
Algunos escenarios empresariales son más sensibles a la acumulación de consumo, mientras que algunas empresas no son sensibles al retraso en el consumo, siempre y cuando se pongan al día y consumir más tarde. Por ejemplo, desbloquear una bicicleta solo lleva unos segundos y los escenarios de procesamiento por lotes relacionados con la agregación de información no son sensibles a los retrasos. Al recopilar indicadores de acumulación de consumo, se emiten alarmas en tiempo real para las aplicaciones que alcanzan el umbral para notificar a los estudiantes a cargo de las aplicaciones, lo que les permite conocer el estado del consumo en tiempo real.
Influencia del Escenario 2 Consumo/Velocidad de Envío
¿Alarma si la velocidad de envío/consumo es cero? En algunos casos, es imposible reducir la velocidad a cero. Si cae a cero, significa que el negocio no es normal. Al recopilar métricas de velocidad, se pueden emitir alertas en tiempo real a las aplicaciones que alcanzan los umbrales.
Escenario 3: El nodo consumidor está desconectado.
Cuando el nodo consumidor se desconecta, se debe notificar a los estudiantes responsables de la aplicación. Este tipo de información del nodo debe recopilarse y, cuando se desconecta, se puede activar una notificación de alarma en tiempo real.
Escenario 4 Transmisión/consumo desequilibrado
La transmisión/consumo desequilibrado a menudo afecta su rendimiento. Recuerdo que durante una consulta, un compañero de clase configuró la clave para enviar mensajes a una constante. De forma predeterminada, la partición tiene un hash según la clave y todos los mensajes ingresan a una partición. Este rendimiento no se puede mejorar pase lo que pase. Además, también es necesario detectar el consumo atrasado de cada partición y activar notificaciones de alarma en tiempo real cuando se produce un desequilibrio excesivo.
Información de seguimiento requerida
Controles comunes
¿Cuáles son los indicadores básicos para medir la salud del clúster?
Prueba de estado del clúster del escenario 1
La prueba de estado del clúster responde a una pregunta: ¿Es bueno este clúster? Este problema se resuelve detectando la cantidad de nodos del clúster, el latido de cada nodo en el clúster, el nivel de agua de Tps escrito por el clúster y el nivel de agua de Tps consumido por el clúster.
Escenario 2: Estabilidad del clúster
El control de flujo del clúster a menudo refleja un rendimiento insuficiente del clúster y la fluctuación del clúster también puede provocar tiempos de espera de envío del cliente. Al recopilar el consumo de tiempo de latido de cada nodo en el clúster y la tasa de cambio de nivel de agua en Tps de las escrituras del clúster, puede saber si el clúster es estable.
Alta disponibilidad del clúster en el escenario 3
La alta disponibilidad está dirigida principalmente a la indisponibilidad de una determinada área disponible en escenarios extremos, o a las anomalías de ciertos temas y grupos de consumidores en el cluster, que requiere tomar algunas medidas específicas. Por ejemplo, MQ se puede resolver mediante la implementación cruzada de maestros y esclavos en la misma ciudad en las regiones disponibles, la migración dinámica de temas y grupos de consumidores a clústeres de recuperación ante desastres y múltiples actividades.
Información de seguimiento requerida
Controles comunes
¿Cuál de estos indicadores clave es el más importante? Yo elegiría la detección de latidos de cada nodo en el clúster, que es el tiempo de respuesta (RT). Echemos un vistazo a las posibles causas que afectan a la RT.
Siempre encontraremos un hoyo y lo llenaremos cuando lo encontremos.
**
Los nodos esclavos y maestros de RocketMQ con frecuencia experimentan un alto nivel de CPU, lo cual es un problema obvio. Muchas veces, el nodo esclavo cuelga directamente.
Solo el registro del sistema tiene mensajes de error
2020-03-16t 17:56:07.505715+08:00 vecs 0 xxxx kernel: []? _ _ alloc _ páginas _ máscara de nodo+0x7e 1/0x 9602020-03-16t 17:56:07.505717:08:00 vecs 0 xxxx kernel: java: Error en la asignación de página. orden: 0, modo: 0x 202020-03-16t 17:56:07.505719:08:00 vecs 0 xxxx kernel: Pid: 12845, comm: java no infectado 2.6.32-754.17.1.el6.x86_ 64 # 10_ _ alloc _ páginas _ máscara de nodo+0x7e 1/0x 9602020-03-16t 17:56:07.505726+08:00 vecs 0 xxxx kernel:[]? dev_queue_xmit+0xd 0/0x 3602020-03-16t 17:56:07.505729+08:00 vecs 0 xxxx kernel:[]? IP_finish_output+0x 192/0x 3802020-03-16t 17:56:07.505732+08:00 vecs 0 xxxx kernel:[]?
Varios parámetros del sistema de depuración sólo pueden ralentizarlo pero no eliminarlo, y los fallos aún superan el 50%.
Se actualizaron todos los sistemas en el clúster de centos 6 a centos 7, se actualizó la versión del kernel de 2.6 a 3.10 y el problema de la CPU desapareció.
La versión predeterminada de RocketMQ Community Edition admite 18 niveles de latencia y los consumidores consumen cada nivel con precisión en el momento establecido. Con este fin, también probamos específicamente si el intervalo de consumo es preciso y los resultados de la prueba muestran que es muy preciso. Sin embargo, una caracterización tan precisa es problemática. Resulta extraño recibir un mensaje retrasado de un grupo en la línea jerárquica de estudiantes de negocios.
Mover "delayOffset.json" y "Consumption Queue/Schedule _ Topic _ XXXX" a otros directorios equivale a eliminarlos uno por uno; Después de reiniciar, se verificó que la función de mensaje retrasado se puede enviar y consumir normalmente.
¿Cuáles son nuestros servicios principales y cuáles son nuestros servicios complementarios? Ésta es la cuestión principal de la gobernanza de los servicios.
El servicio puede hacer frente a aumentos repentinos de tráfico, especialmente para garantizar el buen funcionamiento de los servicios principales.
Las aplicaciones se dividen en cuatro niveles según las dos dimensiones de impacto en el usuario y en el negocio.
S1: productos principales, cuya falla provocará que los usuarios externos no puedan usarlos o causen grandes pérdidas financieras, como los enlaces principales del negocio principal, como bicicletas y ciclomotores, y la emisión. y recepción de órdenes de viaje, etc. Enlaces principales y aplicaciones de las que dependen en gran medida los enlaces principales.
S2: No afecta directamente la transacción, pero está relacionado con la configuración importante del negocio front-end o la gestión y mantenimiento de la función de procesamiento comercial back-end.
S3: la falla del servicio tiene poco impacto en los usuarios o la lógica de los productos principales, no tiene ningún impacto en el negocio principal o una pequeña cantidad de nuevas herramientas importantes para los usuarios internos no afecta directamente al negocio; Y las funciones de gestión relacionadas tienen un impacto en el negocio front-end No es grande.
S4: Para los usuarios internos, el sistema no afecta directamente al negocio o debe desconectarse más adelante.
El negocio S1 es el negocio principal de la empresa y un objetivo de protección clave. Es necesario garantizar que no se vea afectado accidentalmente por el tráfico comercial no principal.
**
**