Rabbit MQ en el sistema de procesamiento de residentes



Recientemente, encargaron con éxito un sistema de procesamiento de usuarios para los ciudadanos. La conclusión es que cuando no tiene agua, calefacción o un gran agujero en la carretera cerca de su casa, puede quejarse de un problema en las agencias gubernamentales. Existen diferentes plataformas donde puede presentar una queja: sitios web de agencias gubernamentales, páginas en redes sociales, centros de llamadas.

Nuestra tarea consistía en crear una única tubería para procesar aplicaciones para todos los departamentos.
El objetivo principal del sistema es acelerar el proceso de procesamiento de llamadas tanto como sea posible: automatizar todo automatizado, controlar el tiempo en cada etapa del proceso, informar a los residentes sobre cada paso.

Una de las tareas específicas del proyecto fue la cuestión de la integración con una gran cantidad de sistemas externos.

  • Era necesario aprender de diferentes sitios para recoger todo el flujo de quejas, para poder comunicarnos con ellos sobre todos los cambios con las solicitudes, para llevar a cabo la correspondencia entre los funcionarios del gobierno y los ciudadanos para aclarar los detalles de las quejas.
  • Además de esto, regalamos algunas de las funciones a servicios externos.

Porque Llegaron muchos datos, a menudo tuvieron que funcionar en modo asíncrono, luego el equipo del proyecto tuvo que resolver el problema, para no estrangularse a sí mismo ni a los sistemas de terceros. La solución se encontró en el corredor de mensajes de software Rabbit MQ. Era una nueva tecnología para el equipo en ese momento.

A continuación se muestra una entrevista con el desarrollador del backend del proyecto, Alexander Shcheglov, WilyLynx , quien se ocupó del problema e implementó la integración.

- Sasha, hola! Cuéntanos en pocas palabras qué es Rabbit MQ.

El software está destinado principalmente a la implementación de mensajes retrasados ​​entre diferentes clientes, es decir cuando no necesita una respuesta en este momento.

- Entiendo correctamente que en general funciona así: el servicio de envío en la cola creada coloca los datos a medida que se generan, el servicio de recepción toma esta información según sea necesario.

Eso es exactamente lo que funciona.

- ¿Por qué (el equipo de desarrollo) eligió esta solución para el proyecto?

Por varias razones En primer lugar, en nuestro caso, el procesamiento sincrónico (recibido y procesado al mismo tiempo) no es crítico, es decir un mensaje puede quedar en la cola por un tiempo. Además, facilidad de uso: para recibir mensajes solo necesita declarar el nombre de la cola y no hay necesidad de escribir sus servicios. Bueno, la disponibilidad de bibliotecas para YP común. No es necesario inventar nada para trabajar con RabbitMQ.

- Entiendo correctamente que Rabbit MQ le permite controlar el intercambio de datos entre sistemas y servicios web.

En cambio, todavía gestionamos el intercambio, pero el "conejo" es una excelente herramienta para organizar este intercambio. Aquí tiene la vida útil de los mensajes en las colas, y la longitud máxima de la cola, y la configuración de acceso, la agrupación en clúster, y varios protocolos de intercambio, y un sistema de complemento y más.

- ¿Cómo se determina que el mensaje ha sido entregado? - es decir, ¿cómo se determina que el cliente ha prolongado algo después de la recepción o se ha bloqueado en el proceso?

Se considera entregado si, dentro de un cierto período de tiempo, llega una respuesta del cliente. De hecho, dice que recibió y estaba satisfecho con la vida. El cliente puede enviar una respuesta tan pronto como la reciba y luego tratar de procesar el mensaje. Tal vez, por el contrario, primero intente procesar y, si tiene éxito, envíe una respuesta. O puede decirle al conejo con anticipación para que no espere la confirmación de la entrega de usted y solo reciba mensajes. Todos los artículos enviados se considerarán entregados automáticamente.

- ¿Es posible, por ejemplo, recibir de alguna manera no todos los mensajes, pero por ejemplo suscribirse solo a mensajes en una aplicación específica?

Hay una situación ligeramente diferente. Hay una opción para enviar mensajes en los que los mensajes llegan a todos los clientes. Esta opción se llama "publicar / suscribirse". Un buen ejemplo: un nuevo mensaje en su público. Usted envió, todos los firmantes recibieron. Y ya al recibirlo, pensaron leer o no leer. En general, nadie te molesta para crear una cola separada para ti y trabajar solo con ella. En este caso, el enrutamiento ya estará en el nivel de aplicación, y el conejo como canal de comunicación.

- Sasha, dime, ¿hay una opción no para crear miles de colas, sino para filtrar y enrutar una?

De uno no funcionará, pero Rabbit permitirá que se realicen algunas rutas.

- Por favor cuéntanos más.

Uno de ellos no lo es, pero existen conceptos como "intercambio" y "clave de enrutamiento":

P - productor, el remitente del mensaje a cambio
X - intercambiarse
Rayas rojas - líneas
C1 y C2 - destinatarios



Pabbit puede enviar un mensaje a cambio de una determinada clave (por ejemplo, error / información / advertencia). Y como puede ver, diferentes destinatarios están orientados a recibir mensajes con diferentes claves de enrutamiento. Además, solo C2 recibirá un mensaje con la tecla "info", y ambos recibirán un mensaje con la tecla "error". También es posible recibir mensajes de acuerdo con la plantilla para la clave. Esto es para otro tipo de intercambio "Publicar / Suscribir", que mencioné anteriormente.



Como puede ver en cualquier caso, para cada uno de los destinatarios en este tipo de intercambios hay un giro, pero al final todavía tenemos cierta apariencia de filtrado / enrutamiento.

- ¿Qué puede recordar los problemas que surgieron durante el estudio y la implementación de Rabbit?

Además de la pereza, no. En serio, documentación clara, una gran cantidad de ejemplos.

- ¿Ya le ha transferido todos los intercambios con servicios y sistemas externos?

Ahora tenemos 38 colas: intercambio entre circuitos, sistemas externos, BI. Pero desafortunadamente, algunos servicios (departamentos de lectura) se resisten. porque Han implementado el descanso. Además, algunos tipos de interacciones implican la recepción simultánea de respuestas a las solicitudes.

- ¿Qué piensas, qué tan exitosa fue esta decisión?

¿Para la colaboración entre agencias que no requiere una respuesta sincrónica? Para mí, es una gran opción.

Listado de materiales utilizados

Source: https://habr.com/ru/post/441008/


All Articles