Hace unos días, Michelle Yeoh hizo una pregunta en Knowledge Planet, diciendo que la compañía cambiaría MQ y actualizaría de un antiguo proveedor de servicios a un nuevo proveedor de servicios, y preguntó si había algún buen plan.
Se estima que esta demanda es bastante común, aquí hay algunas experiencias para compartir.
1. Breve descripción de la arquitectura MQ
Como se muestra en la figura anterior, el uso de la comunicación asíncrona MQ generalmente se divide en tres capas:
Remitente del mensaje: use el cliente MQ para generar mensajes.
MQ-client :: SendMsg (tema, mensaje);
Servicio MQ: retransmisión de mensajes.
Receptor de mensajes: utilice el cliente MQ para consumir mensajes.
MQ-client :: RecvMsg (tema, mensaje, CALLBACK_FUNC);
Esta es una arquitectura típica de pub-sub. Si desea reemplazar un proveedor de MQ, debe reemplazar al menos tres lugares:
- Remitente mq-client
- Servidor MQ
Cómo migrar sin problemas el receptor mq-client es un tema que se discutirá hoy.
2. Plan de migración fluido
El objetivo de una migración sin problemas es: servicio continuo y actualización sin problemas.
Si hay muchos temas, debe migrar uno por uno. La migración de cada tema se divide en tres pasos.
Paso 1: suscripción bidireccional del consumidor
Como se muestra en la figura anterior, establezcamos:
- El rosa es el antiguo sistema MQ
- El azul es el
objetivo final de la migración sin problemas del nuevo sistema MQ , que consiste en actualizar las tres capas de "publicación-servicio-suscripción" de rosa a azul.
El primer paso es actualizar el consumidor El mismo tema debe suscribirse al MQ antiguo y al nuevo MQ.
En este momento, aunque hay una conexión TCP entre "Nuevo servicio-Nueva suscripción", pero "Nueva versión" no está en línea, no se enviará ningún mensaje (la línea de puntos en la figura anterior), y los mensajes aún pasan por el antiguo MQ (la figura anterior muestra línea).
Paso 2: el fabricante actualiza a la nueva versión
El segundo paso es actualizar el productor, de la versión anterior de MQ a la nueva versión de MQ.
En este momento, se establecerá una conexión TCP entre "nueva versión-nuevo servicio-nueva suscripción" y el mensaje se transferirá al nuevo canal (línea continua en la figura anterior). Aunque existe una conexión TCP entre "servicio antiguo-suscripción anterior", en realidad no es Se enviará un mensaje (la línea de puntos en la figura anterior).
Paso 3: consumidores sin conexión a suscripciones antiguas
El tercer paso es actualizar el consumidor, desconectar la suscripción anterior y completar la migración de todo el MQ.
Tres, inspiración arquitectónica
MQ cambia de proveedor de servicios, las hormigas se mueven y se mueven sin problemas paso a paso, el costo es bastante alto.
La razón por la que es tan problemático y no se puede actualizar de manera unificada es el acoplamiento entre el negocio y los detalles de la infraestructura subyacente (es decir, qué MQ usar). Si la empresa puede "superficializar una capa de encapsulación" en la planificación inicial del sistema técnico, puede aislar el "código comercial" de los "detalles de la infraestructura subyacente".
Da un ejemplo más popular.
Si no hay una capa de encapsulación, el código comercial es:
ActiveMQ-client::SendMsg(topic, msg);
ActiveMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);Es decir, el lado comercial debe preocuparse por ActiveMQ. Si la infraestructura se actualiza a RabbitMQ, el código comercial debe actualizarse.
Si hay un paquete poco profundo:
ShenJianMQ::SendMsg(topic, msg){
ActiveMQ-client::SendMsg(topic,msg);
}
ShenJianMQ::RecvMsg(topic, msg,CALLBACK_FUNC)
ActiveMQ-client::RecvMsg(topic,msg, CALLBACK_FUNC);
}El lado comercial no necesita preocuparse por el MQ subyacente, solo necesita depender del componente básico ShenJianMQ.
En este momento, si la infraestructura se actualiza a RabbitMQ, solo es necesario actualizar el componente básico ShenJianMQ.
El primer paso: RecvMsg se actualiza a una suscripción bidireccional.
ShenJianMQ::RecvMsg(topic, msg,CALLBACK_FUNC)
ActiveMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);
RabbitMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);
}Paso 2: actualice SendMsg a una nueva versión.
ShenJianMQ::SendMsg(topic, msg){
RabbitMQ-client::SendMsg(topic, msg);
}Paso 3: Suscripción antigua sin conexión a RecvMsg.
ShenJianMQ::RecvMsg(topic, msg,CALLBACK_FUNC)
RabbitMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);
}
Descubrirá que, además de actualizar y confiar en la nueva versión de los componentes básicos de ShenJianMQ, el código comercial no necesita modificar el código.
No solo MQ, el cliente del caché y la base de datos, un paquete superficial también puede realizar el desacoplamiento del código comercial y los componentes básicos. Cuando se reemplazan los componentes básicos o se actualizan los componentes básicos, el código comercial no necesita actualizarse.
Voz en off: después de un paquete poco profundo, la monitorización / alarma / recopilación de datos y otras tareas son más fáciles de lograr unificadas.
Con respecto a si usar código abierto, empaquetado superficial o auto-investigación, "Componentes básicos, ¿necesita auto-investigación?" "Hay una discusión más detallada.
Con respecto a la migración sin problemas de MQ, hablemos mucho primero, con la esperanza de responder a la pregunta de Michelle Yeoh. 
Knowledge Planet: Acabo de empezar a jugar
Knowledge Planet. Bienvenido a hacer preguntas.
Voz en off: Todas las preguntas serán respondidas cuidadosamente (como esta).
La última vez se abrieron 200 lugares y se llenó, y luego se abrieron 500 lugares (no mucha gente, me temo que no puedo contestar).
sugerencia relacionada:
"Componentes básicos, ¿necesito auto-investigar? "¿
Cuándo no puede utilizar MQ?"
"¿Cuándo debería utilizar MQ?"
"Alcance del mensaje MQ + idempotencia + diseño de arquitectura de retardo"
Investigación:
¿Su empresa tiene un paquete poco profundo? ¿O autoestudio? ¿O es un acoplamiento nativo?