1. Descripción de antecedentes
Vivo presentó RabbitMQ en 2016, basado en la expansión de código abierto RabbitMQ, para proporcionar servicios de middleware de mensajería a la empresa.
De 2016 a 2018, todas las empresas utilizaron un clúster. A medida que la escala empresarial crecía, la carga del clúster se hacía más pesada y las fallas del clúster ocurrían con frecuencia.
En 2019, RabbitMQ entró en la etapa de construcción de alta disponibilidad, completando el servicio de nombres MQ del componente de alta disponibilidad y la construcción activa dual dentro de la ciudad del clúster RabbitMQ.
Al mismo tiempo, se lleva a cabo la división física del clúster de uso comercial y la asignación y el ajuste dinámico del clúster de uso comercial se basan estrictamente en la carga del clúster y el tráfico comercial.
Desde la construcción de alta disponibilidad en 2019, el tráfico comercial se ha multiplicado por diez y el clúster no ha experimentado fallas graves.
RabbitMQ es un software de agente de mensajes de código abierto que implementa el protocolo AMQP, que se originó en el sistema financiero.
Tiene una gran cantidad de características:
Garantía de confiabilidad de mensajes: RabbitMQ garantiza la confiabilidad del envío de mensajes mediante el envío de confirmación, garantiza la confiabilidad de los mensajes en el cluster mediante clustering, persistencia de mensajes y colas de espejo, y garantiza la confiabilidad del consumo de mensajes por confirmación de consumo.
RabbitMQ ofrece a los clientes en varios idiomas.
Se proporcionan varios tipos de intercambios. Después de que los mensajes se envían al clúster, se enrutan a colas específicas a través del intercambio.
- RabbitMQ proporciona un fondo de administración completo y una API de administración, que se puede integrar rápidamente con el sistema de monitoreo autoconstruido a través de la API de administración.
Problemas descubiertos por RabbitMQ en una práctica específica:
Para garantizar una alta disponibilidad empresarial, se utilizan varios clústeres para el aislamiento físico y varios clústeres no tienen una plataforma unificada para la gestión.
El cliente nativo de RabbitMQ usa la dirección del clúster para conectarse. Cuando se utilizan varios clústeres, la empresa debe preocuparse por la dirección del clúster y el uso es confuso.
Native RabbitMQ solo tiene una verificación simple de nombre de usuario / contraseña y no autentica la parte de la aplicación comercial utilizada.Es fácil mezclar información de intercambio / cola para diferentes negocios, lo que genera aplicaciones comerciales anormales.
Se utilizan muchas aplicaciones comerciales y no existe una plataforma para mantener la información asociada del remitente y el consumidor del mensaje. Después de múltiples iteraciones de versiones, no se puede determinar la contraparte.
El cliente tiene un flujo ilimitado y el tráfico anormal repentino impacta o incluso derrota al clúster.
El cliente no tiene una estrategia de retransmisión de mensajes de excepción, que debe ser implementada por el usuario.
Cuando el clúster está bloqueado debido a un desbordamiento de memoria en el clúster, no se puede transferir rápida y automáticamente a otros clústeres disponibles.
Con las colas duplicadas, el nodo principal de la cola se ubicará en un nodo específico. Cuando el número de colas de clúster es grande, es probable que la carga del nodo no esté equilibrada.
- RabbitMQ no tiene capacidad de equilibrio automático de colas y es propenso a una carga desigual de nodos de clúster cuando hay muchas colas.
En segundo lugar, la estructura general
1. MQ-Portal: aplicación de uso de aplicaciones de soporte
En el pasado, cuando el equipo empresarial aplicaba RabbitMQ, el tráfico de la aplicación de la aplicación y la información de la aplicación acoplada se registraban en el formulario sin conexión, que estaba fragmentado y no se actualizaba a tiempo. Era imposible comprender con precisión el uso real actual de la empresa. Por lo tanto, mediante una visualización del proceso de solicitud, La plataforma establece la información de metadatos que utilizan las aplicaciones.
A través del proceso de solicitud de MQ-Portal (como se muestra en la figura anterior), se determina que la aplicación de envío de mensajes, la aplicación del consumidor, el uso de intercambio / cola, el envío de tráfico y otras aplicaciones de uso de información ingresarán al proceso de orden de trabajo interno vivo para su aprobación después del envío.
Una vez que se aprueba el proceso de la orden de trabajo, vuelva a llamar a través de la interfaz de la orden de trabajo, asigne el grupo específico utilizado por la aplicación y cree una relación de enlace de intercambio / cola en el grupo.
Debido al aislamiento físico de varios clústeres para garantizar una alta disponibilidad de servicios en el entorno formal, es imposible localizar el clúster utilizado simplemente por un nombre de intercambio / cola.
Cada intercambio / cola está asociado con el clúster a través de un par único de rmq.topic.key y rmq.secret.key, de modo que el clúster específico utilizado se pueda ubicar durante el proceso de inicio del SDK.
rmq.topic.key y rmq.secret.key se asignarán en la interfaz de devolución de llamada del ticket.
2. Descripción general de las capacidades del SDK del cliente
El SDK del cliente está encapsulado en base a spring-message y spring-rabbit, y sobre esta base proporciona capacidades como autenticación de aplicaciones, direccionamiento de clústeres, limitación de corriente del cliente, reinicio de producción y consumo y bloqueo de transferencia.
2.1, autenticación de uso de aplicaciones
El RabbitMQ de código abierto solo usa el nombre de usuario y la contraseña para determinar si permite la conexión al clúster, pero no se verifica si la aplicación permite el uso de intercambio / cola.
Para evitar mezclar intercambio / cola para diferentes servicios, la aplicación debe estar autenticada.
La autenticación de la aplicación se completa con la cooperación de SDK y MQ-NameServer.
Cuando se inicia la aplicación, primero informará la información rmq.topic.key de la configuración de la aplicación al MQ-NameServer, y MQ-NameServer determinará si la aplicación utilizada es coherente con la aplicación aplicada, y se realizará una verificación secundaria durante el envío del mensaje por SDK.
/**
* 发送前校验，并且获取真正的发送factory，这样业务可以声明多个，
* 但是用其中一个bean就可以发送所有的消息，并且不会导致任何异常
* @param exchange 校验参数
* @return 发送工厂
*/
public AbstractMessageProducerFactory beforeSend(String exchange) {
if(closed || stopped){
//上下文已经关闭抛出异常，阻止继续发送，减少发送临界状态数据
throw new RmqRuntimeException(String.format("producer sending message to exchange %s has closed, can't send message", this.getExchange()));
}
if (exchange.equals(this.exchange)){
return this;
}
if (!VIVO_RMQ_AUTH.isAuth(exchange)){
throw new VivoRmqUnAuthException(String.format("发送topic校验异常，请勿向无权限exchange %s 发送数据，发送失败", exchange));
}
//获取真正的发送的bean，避免发送错误
return PRODUCERS.get(exchange);
}2.2, direccionamiento de clúster
Como se mencionó anteriormente, las aplicaciones usan RabbitMQ para asignar clústeres estrictamente de acuerdo con la carga y el tráfico comercial del clúster. Por lo tanto, los diferentes intercambios / colas utilizados por una aplicación específica pueden asignarse en diferentes clústeres.
Para mejorar la eficiencia del desarrollo empresarial, es necesario proteger el impacto de múltiples clústeres en el negocio, por lo que los clústeres se direccionan automáticamente de acuerdo con la información rmq.topic.key configurada por la aplicación.
2.3, límite de corriente del cliente
El cliente SDK nativo no limita el tráfico de envío. Cuando algunas aplicaciones tienen anomalías y continúan enviando mensajes a MQ, el clúster de MQ puede verse abrumado. Y un clúster es utilizado por varias aplicaciones, y el impacto del clúster causado por una sola aplicación afectará a todas las aplicaciones que utilicen el clúster anormal.
Por lo tanto, es necesario proporcionar la capacidad de limitación de corriente del lado del cliente en el SDK y, cuando sea necesario, se puede restringir la aplicación de enviar mensajes al clúster para garantizar la estabilidad del clúster.
2.4. Reinicio de producción y consumo
(1) Con el crecimiento de la escala empresarial, la carga del clúster sigue aumentando. En este momento, el negocio del clúster debe dividirse. Para evitar reinicios comerciales durante el proceso de división, se requiere una función de reinicio de producción y consumo.
(2) Las anomalías en el clúster pueden hacer que los consumidores se desconecten. En este momento, el restablecimiento de la producción y el consumo puede aumentar rápidamente el consumo empresarial.
Para realizar el reinicio de producción y consumo, es necesario realizar el siguiente proceso:
Restablecer los parámetros de conexión de fábrica de la conexión
Restablecer conexión
Establecer una nueva conexión
- Reiniciar la producción y el consumo
CachingConnectionFactory connectionFactory = new CachingConnectionFactory();
connectionFactory.setAddresses(address);
connectionFactory.resetConnection();
rabbitAdmin = new RabbitAdmin(connectionFactory);
rabbitTemplate = new RabbitTemplate(connectionFactory);Al mismo tiempo, MQ-SDK tiene una estrategia de retransmisión de mensajes anormales, que puede evitar la transmisión de mensajes anormales causada por el proceso de reinicio de producción.
2.5, transferencia de bloqueo
RabbitMQ bloquea el envío de mensajes cuando el uso de la memoria excede el 40% o el uso del disco excede el límite.
Dado que el equipo de middleware vivo ha completado la construcción de RabbitMQ intra-city activo-activo, se puede restablecer al clúster activo-activo a través de la producción y el consumo para completar la transferencia rápida del bloqueo cuando un clúster está bloqueado.
2.6, programación de varios clústeres
Con el desarrollo de aplicaciones, un solo clúster no podrá satisfacer la demanda de tráfico de la aplicación, y las colas del clúster son todas colas duplicadas, y la expansión horizontal de un solo clúster de tráfico de soporte empresarial no se puede lograr simplemente agregando nodos de clúster.
Por lo tanto, el SDK es necesario para admitir capacidades de programación de múltiples clústeres y para satisfacer las necesidades del gran tráfico empresarial mediante la distribución del tráfico a múltiples clústeres.
3. MQ-NameServer: admite MQ-SDK para lograr una rápida conmutación por error
MQ-NameServer es un servicio sin estado, que puede garantizar su alta disponibilidad a través del despliegue de clústeres. Se utiliza principalmente para resolver los siguientes problemas:
MQ-SDK inicia la autenticación y las aplicaciones utilizan el posicionamiento de clúster.
Procese los informes del indicador de tiempo de MQ-SDK (número de mensajes enviados, número de mensajes consumidos) y devuelva la dirección de clúster disponible actual para garantizar que el SDK se vuelva a conectar de acuerdo con la dirección correcta cuando el clúster sea anormal.
- Controle MQ-SDK para restablecer la producción y el consumo.
4. Práctica de implementación de alta disponibilidad de MQ-Server
Todos los clústeres de RabbitMQ adoptan la arquitectura de implementación activo-activo en la misma ciudad, confiando en el direccionamiento del clúster y las capacidades de conmutación por error proporcionadas por MQ-SDK y MQ-NameServer para garantizar la disponibilidad del clúster.
4.1. Manejo de problemas de cerebro dividido en racimos
RabbitMQ ofrece oficialmente tres estrategias de recuperación del cerebro dividido en grupos.
（1） ignorar
Ignore el problema del cerebro dividido y no lo aborde. Se necesita la intervención humana para recuperarse cuando ocurre un cerebro dividido. Debido a la necesidad de intervención humana, se pueden perder algunos mensajes, que se pueden utilizar cuando la red es muy confiable.
（2） pause_minority
Cuando un nodo pierde la conexión con más de la mitad de los nodos del clúster, se suspenderá automáticamente hasta que detecte que se reanuda la comunicación con más de la mitad de los nodos del clúster. En casos extremos, todos los nodos del clúster se suspenden, lo que hace que el clúster no esté disponible.
（3） autocuración
Los nodos minoritarios se reiniciarán automáticamente. Esta estrategia se utiliza principalmente para dar prioridad a la disponibilidad del servicio, no a la confiabilidad de los datos, porque se perderán los mensajes al reiniciar los nodos.
Debido a que los clústeres de RabbitMQ se implementan en la misma ciudad, incluso si el tráfico comercial anormal de un solo clúster se puede migrar automáticamente al clúster de sala de computadoras de doble actividad, se elige la estrategia pause_minority para evitar el problema del cerebro dividido.
En 2018, los clústeres de cerebro dividido fueron causados por fluctuaciones de la red muchas veces. Después de que se modificó la estrategia de recuperación del cerebro dividido del clúster, el problema del cerebro dividido ya no apareció.
4.2, solución de alta disponibilidad de clúster
RabbitMQ adopta la implementación de clústeres y, dado que la estrategia de recuperación del cerebro dividido del clúster adopta el modo pause_minority, cada clúster requiere al menos 3 nodos.
Se recomienda utilizar 5 o 7 nodos para implementar un clúster de alta disponibilidad y controlar la cantidad de colas de clúster.
Las colas de clúster son todas colas duplicadas para garantizar que se realice una copia de seguridad de los mensajes y evitar la pérdida de mensajes causada por nodos anormales.
El intercambio, la cola y los mensajes están configurados para ser persistentes para evitar la pérdida de mensajes cuando el nodo se reinicia de forma anormal.
Todas las colas están configuradas en colas diferidas para reducir la fluctuación del uso de la memoria del nodo.
4.3. Construcción viva-activa en la misma ciudad
Los clústeres equivalentes se implementan en salas de computadoras duales y los clústeres duales se forman en clústeres de alianza a través del complemento de Federación.
Las máquinas de aplicación en la sala de informática se conectan preferentemente al grupo MQ en la sala de informática para evitar el uso anormal de la aplicación debido a la fluctuación de la línea dedicada.
Obtenga la información de clúster disponible más reciente a través del latido de MQ-NameServer y vuelva a conectarse al clúster activo-activo en caso de una excepción para lograr una recuperación rápida de las funciones de la aplicación.
3. Retos y perspectivas futuros
En la actualidad, el uso de RabbitMQ se ha mejorado principalmente en el lado de MQ-SDK y MQ-NameServer. La implementación del SDK es más complicada. Más adelante, se espera que se pueda construir la capa proxy del middleware de mensajes, lo que puede simplificar el SDK y realizar una gestión más detallada del tráfico empresarial.
Autor: derek