El equipo de la comunidad de código abierto de China realizó su primera transmisión en vivo, contando la historia detrás de la comunidad de código abierto de China en nombre de compartir".

Este artículo es compartido por la comunidad de Huawei Cloud " Práctica de Sermant en escenarios remotos multiactivos ", autor: Huawei Cloud Open Source.

La comunidad Sermant ha lanzado sucesivamente el complemento de prohibición de consumo de cola de mensajes y el complemento de prohibición de escritura de base de datos en las versiones 1.3.0 y 1.4.0 , respectivamente, para resolver el problema del corte de flujo y la protección de la coherencia de los datos en escenarios remotos multiactivos. Este artículo analizará la práctica de Sermant en escenarios remotos de múltiples actividades.

1. Vive más en un lugar diferente

1.1 ¿Qué es vivir en diferentes lugares?

Para un sistema de software, esperamos que cuando el sistema falle, aún pueda proporcionar servicios al mundo exterior normalmente. Esta característica del sistema de software se llama alta disponibilidad y se utiliza la arquitectura remota multiactiva para resolver el problema de alta disponibilidad. .

La arquitectura del sistema más antigua es generalmente una arquitectura de una sola máquina. Cuando la base de datos falla, el negocio puede verse interrumpido durante mucho tiempo. Para resolver este problema, la base de datos se desarrolló para que conste de una base de datos maestra y una base de datos esclava. La base de datos maestra es responsable de las operaciones de lectura y escritura, y la base de datos esclava solo proporciona operaciones de lectura. sincronizarse con la base de datos esclava en tiempo real para mantener la coherencia y la integridad de los datos. Cuando ocurre un problema en la biblioteca principal, la biblioteca esclava cambia a la biblioteca principal y continúa funcionando. Sin embargo, estos servicios se implementan en la misma sala de computadoras o incluso en el mismo gabinete. Cuando la sala de computadoras falla, el sistema aún no puede proporcionar servicios externos normales.

En este momento, activo-activo en la misma ciudad se ha convertido en una buena solución. Se implementan dos salas de computadoras en una ciudad. Las dos salas de computadoras implementan el mismo entorno de software y brindan servicios. Cuando una de las salas de computadoras falla, el tráfico se puede cambiar a otra sala de computadoras para continuar la ejecución y garantizar una alta disponibilidad del sistema. Como se muestra en la Figura 1, la base de datos en la sala de computadoras 1 es la base de datos principal. Todas las operaciones de escritura en las dos salas de computadoras operan en la base de datos principal en la sala de computadoras 1, y las operaciones de lectura pueden leer la base de datos en esta sala de computadoras. La distancia física entre las dos salas de computadoras es relativamente cercana. Al mismo tiempo, las dos salas de computadoras pueden usar líneas dedicadas para la conexión de red. Por lo tanto, la latencia de la red de las llamadas de servicio en diferentes salas de computadoras es baja. sala de ordenadores 2 a la base de datos de la sala de ordenadores 1 está dentro de un rango aceptable.

Figura 1: Diagrama de arquitectura dual-activa en la misma ciudad

La arquitectura activo-activo en la misma ciudad resuelve el problema de la alta disponibilidad de los sistemas de software. Sin embargo, si ocurre un desastre natural en una ciudad, como terremotos, inundaciones, etc., todas las salas de computadoras implementadas en la misma ciudad seguirán estando. dañados y dejar de prestar servicios. Y debido a que estos desastres son altamente destructivos, el ciclo de reparación del sistema será relativamente largo, lo que afectará seriamente el funcionamiento normal del negocio de la empresa. En este caso, es obvio que estas salas de computadoras deben implementarse en diferentes regiones. Al mismo tiempo, la distancia geográfica de estas regiones debe ser lo suficientemente grande como para resistir el riesgo de desastres naturales. la arquitectura remota multiactiva.

Como se muestra en la figura anterior, si la sala de computadoras 1 y la sala de computadoras 2 se implementan en dos ciudades, se volverán activas y remotas. Para resistir mejor los riesgos, las salas de computadoras se pueden implementar en múltiples regiones. activo-activo se actualizará a activo-activo remoto.

El diagrama de arquitectura del multiactivo remoto se muestra en la Figura 2. El tráfico del cliente se distribuye a través de la capa de enrutamiento a diferentes salas de computadoras regionales para su ejecución. La diferencia con la arquitectura activa-activa de la misma ciudad es que las salas de computadoras en diferentes regiones están físicamente alejadas. El costo de implementar líneas de red dedicadas es enorme y no se puede ignorar el retraso en el acceso a la red entre diferentes salas de computadoras. es necesario operar la base de datos en la sala de computadoras local. No se puede operar entre salas de computadoras. Bajo la arquitectura remota multiactiva, la base de datos de cada sala de computadoras es la base de datos principal, y los datos en diferentes salas de computadoras se sincronizarán con la sala de computadoras central y luego se sincronizarán desde la sala de computadoras central con otras salas de computadoras. Debido a que se puede escribir en las bases de datos de todas las salas de computadoras, cuando diferentes salas de computadoras modifican el mismo dato, inevitablemente se introducen conflictos de datos. Para resolver conflictos de datos, parte del tráfico se puede reenviar de manera fija a una determinada sala de computadoras de acuerdo con la política de fragmentación en la capa de enrutamiento. La política de fragmentación del tráfico puede basarse en el tipo de negocio o la ubicación geográfica. Mediante la fragmentación del tráfico, se garantiza que las solicitudes relevantes del mismo usuario se enrutarán a la misma sala de computadoras para completar todas las operaciones comerciales, y se garantiza que el tráfico en la sala de computadoras fluirá solo dentro de la sala de computadoras local, lo que reduce la latencia de la red.

Figura 2: Diagrama de arquitectura remota multiactiva

1.2 Escenarios típicos de múltiples actividades en diferentes lugares

La arquitectura remota multiactiva implementa salas de ordenadores en diferentes regiones para proporcionar servicios externos para resistir los riesgos causados por desastres naturales. Es un medio eficaz para lograr una alta disponibilidad del sistema. Sin embargo, la arquitectura remota multiactiva también hace que el sistema sea más complejo e introduce nuevos requisitos en términos de corte de fallas y coherencia de los datos:

En un escenario de servicio en la nube, cuando ocurre una falla en una zona de disponibilidad, los consumidores en la zona de falla deben dejar de extraer mensajes para su consumo y, al mismo tiempo, las colas de mensajes asignadas se reequilibran a los consumidores en la zona de disponibilidad normal para su procesamiento. para evitar causar excepciones comerciales.
Los multiactivos remotos pueden resolver eficazmente el problema de la coherencia de los datos fragmentando el tráfico. Pero para datos globales, como la cantidad de producto, al escribir datos, solo se permite operar la base de datos global en la sala de computadoras central. Generalmente, el tráfico para operar datos globales debe enrutarse a la sala de computadoras central, y otras salas de computadoras solo pueden leer la base de datos. Cuando el tráfico se enruta incorrectamente, es posible que aún se escriba en la base de datos en una sala de computadoras no central, lo que provoca conflictos de datos. En este momento, es necesario agregar protección a la base de datos global y prohibir la ejecución de operaciones de escritura en salas de computadoras no centrales.

En respuesta a los dos problemas típicos anteriores, Sermant desarrolló el complemento de prohibición de consumo de colas de mensajes y el complemento de prohibición de escritura de base de datos para solucionarlos, que se presentarán en detalle a continuación.

2. La cola de mensajes prohíbe el consumo de complementos.

2.1 Introducción al complemento de prohibición de consumo de colas de mensajes

El complemento de prohibición del consumo de la cola de mensajes permite a los microservicios ajustar dinámicamente el comportamiento de consumo del middleware de la cola de mensajes por parte de los consumidores de acuerdo con las necesidades reales en el estado de ejecución, garantizando que en entornos o estados anormales, los mensajes en el proceso de procesamiento empresarial se administren adecuadamente y eviten innecesarios. Impacto de negocios. Por ejemplo, en un sistema remoto de arquitectura multiactiva, si ocurre una falla regional y es necesario cortar el tráfico, la función de prohibición de consumo de la cola de mensajes se puede habilitar en la zona de disponibilidad donde ocurrió la falla, lo que permite a los consumidores en la zona de disponibilidad normal para manejar el negocio y evitar El área defectuosa consume tráfico, provocando anomalías comerciales, asegurando una alta disponibilidad del sistema. Una vez solucionada la avería, se puede reiniciar el consumo.

El complemento de prohibición del consumo de colas de mensajes actualmente admite dos middlewares de mensajes: Kafka y RocketMQ. En el lado de Kafka, el complemento implementa funciones de recuperación y prohibición del consumo a nivel de tema. Para RocketMQ, la granularidad del control del consumo está en el nivel de instancia del consumidor. Sermant admite la emisión de tipos de colas de mensajes y temas específicos cuyo consumo debe prohibirse a través del centro de configuración.

Para obtener más información sobre el complemento de prohibición de cola de consumo, instrucciones de configuración y demostraciones de escenas, consulte el documento oficial del sitio web Prohibición de consumo de cola de mensajes .

2.2 Aplicación de la prohibición de la cola de mensajes de falla del complemento de consumo y escenario de corte de flujo

Escenario de aplicación: un sistema de software utiliza Kafka como cola de mensajes y el productor produce mensajes para el tema de prueba. El mensaje del tema contiene cuatro particiones. La Zona de disponibilidad A y la Zona de disponibilidad B tienen cada una dos consumidores que se unen al grupo de consumidores de prueba y consumen mensajes de prueba de tema. A cada consumidor se le asigna una partición. La Zona de disponibilidad A y la Zona de disponibilidad B se distribuyen en diferentes regiones, es decir, en diferentes lugares. 2 salas de informática más. Como se muestra abajo.

En este escenario, después de que el servicio al consumidor deshabilita la ejecución del complemento de consumo al montar la cola de mensajes de Sermant, puede controlar los temas consumidos por el consumidor en tiempo real, asegurando así que los mensajes en el proceso de procesamiento comercial se administren adecuadamente en entornos o estados anormales.

Cuando la zona de disponibilidad A falla, los consumidores en la zona de disponibilidad A deben dejar de consumir. Emita una configuración global en la zona de disponibilidad A para prohibir que el consumidor A y el consumidor B consuman el tema de prueba y libere la cola de mensajes asignada.

La configuración del complemento de prohibición del consumo de la cola de mensajes es la siguiente: enableKafkaProhibition significa habilitar la capacidad de prohibición del consumo de la cola de Kafka, y kafkaTopics especifica los temas de suscripción cuyo consumo debe prohibirse. Para conocer el método de entrega de la configuración, consulte el documento del sitio web oficial. La cola de mensajes prohíbe el consumo :

enableKafkaProhibition: verdadero  
cráneoTemas:  
 - prueba de tema

Una vez entregada la configuración, los consumidores de la zona de disponibilidad A dejan de consumir y los consumidores de la zona de disponibilidad B reasignan las particiones del tema de prueba, como se muestra en la siguiente figura.

Una vez que la zona de disponibilidad A vuelve a la normalidad, la configuración se puede emitir nuevamente a través del centro de configuración dinámica para permitir que los consumidores A y B consuman el tema de prueba. Después de habilitar la entrega de la configuración de consumo, Kafka activará el reequilibrio y a los consumidores en las zonas de disponibilidad A y B se les reasignarán particiones.

El complemento de prohibición del consumo de la cola de mensajes implementa la capacidad de corte de fallas de la cola de mensajes en el escenario remoto multiactivo, asegurando la disponibilidad del sistema.

3. Complemento de prohibición de escritura en la base de datos

3.1 Introducción al complemento de prohibición del consumo de colas de mensajes

Una vez que se inicia el servicio montando el complemento de prohibición de escritura de la base de datos, puede habilitar o deshabilitar dinámicamente la capacidad de prohibición de escritura para la base de datos especificada. En un escenario multiactivo remoto, los usuarios desean dejar de escribir operaciones en bases de datos individuales o en todas y solo permitir que los datos se lean para garantizar la integridad, coherencia y seguridad de los datos del sistema de base de datos. Por ejemplo, la escritura de datos globales en una base de datos empresarial solo se permite en la sala de computadoras central. Al habilitar el complemento de prohibición de escritura de la base de datos, el enrutamiento del tráfico anormal no se puede escribir en la base de datos de la sala de computadoras no central en una ubicación múltiple. En el escenario de escritura múltiple, el tráfico se corta antes de cortarlo manualmente. La sala de computadoras de la secuencia primero prohíbe la escritura en la base de datos y espera a que se complete la sincronización de datos en otras salas de computadoras antes de cortar la secuencia. El uso del complemento de prohibición de escritura de la base de datos en el escenario anterior garantiza la coherencia de los datos de la base de datos.

El complemento de prohibición de escritura en la base de datos actualmente admite bases de datos MySQL, MongoDB, PostgreSQL y OpenGauss. Cuando el microservicio se está ejecutando, el tipo y nombre de la base de datos prohibida de escritura se pueden emitir a través del centro de configuración. Para operaciones de escritura específicas y uso de complementos que admiten la prohibición de escritura, consulte la prohibición de escritura de la base de datos de documentos del sitio web oficial .

3.2 El complemento de prohibición de escritura en la base de datos protege las aplicaciones de coherencia de datos

Escenario de aplicación: en la arquitectura remota multiactiva, se utiliza un microservicio empresarial para modificar datos globales, como el inventario de productos. Al mismo tiempo, los datos globales se almacenan en una base de datos MySQL denominada global. Para estos datos globales, las operaciones de escritura solo pueden operar la base de datos global en la sala de computadoras central, y las bases de datos globales en otras salas de computadoras solo pueden leer datos. Para garantizar la coherencia de los datos, cuando se modifican los datos globales, el tráfico se enruta a la sala de computadoras central para su ejecución en la capa de enrutamiento, y otras operaciones de lectura se pueden enrutar a cualquier sala de computadoras, como se muestra en la figura siguiente.

Cuando la capa de enrutamiento comete un error de enrutamiento para el tráfico que escribe datos globales y los ejecuta en una sala de computadoras no central, si la sala de computadoras central y la sala de computadoras no central modifican la cantidad del mismo producto al mismo tiempo, puede causar conflictos de datos Para evitar que esto suceda, los microservicios empresariales pueden montar el complemento de prohibición de escritura de la base de datos de Sermant para prohibir la escritura en la base de datos global en salas de computadoras no centrales.

Está prohibido escribir en la base de datos global en salas de computadoras no centrales y se debe emitir la siguiente configuración a través del centro de configuración dinámica:

enableMySqlWriteProhibition: verdadero  
bases de datos mySql:  
 - global

Entre ellos, enableMySqlWriteProhibition significa habilitar la capacidad de prohibir la escritura en la base de datos MySQL, y mySqlDatabases se usa para especificar el nombre de la base de datos específica prohibida para la escritura. Este ejemplo es la base de datos global.

Después de emitir la configuración, cuando el tráfico con enrutamiento anormal se escribe en la base de datos global en la sala de computadoras no central, el complemento de prohibición de escritura de la base de datos genera una excepción java.sql.SQLException al microservicio empresarial y prohíbe la escritura en la base de datos. . El sistema empresarial necesita manejar esta excepción, como agregar una operación de reintento para redirigir el tráfico a la sala de computadoras central para su ejecución y garantizar el funcionamiento normal del sistema. La lógica de ejecución se muestra en la siguiente figura.

El complemento de prohibición de escritura de la base de datos deshabilita la escritura en la base de datos especificada en un escenario multiactivo remoto, lo que puede evitar operaciones de escritura de tráfico anormales y garantizar la coherencia de los datos en las bases de datos en diferentes salas de computadoras.

4. Resumen

En un escenario remoto multiactivo, el complemento de prohibición de consumo de cola de mensajes de Sermant puede solucionar el problema del corte del flujo de la cola de mensajes cuando falla la zona de disponibilidad, lo que permite a los consumidores en la zona de disponibilidad normal consumir datos del complemento de prohibición de escritura de la base de datos; se utiliza para prohibir la escritura en la base de datos especificada y no afecta la lectura de la base de datos para evitar conflictos de datos.

Sermant ha logrado ricas capacidades de gobernanza de servicios en escenarios remotos de múltiples actividades. En el futuro, Sermant continuará trabajando arduamente para construir gradualmente un sistema de capacidades de gobernanza de servicios más completo.

Como marco de mejora de código de bytes que se centra en el campo de la gobernanza de servicios, Sermant se compromete a proporcionar una experiencia de gobernanza de servicios de alto rendimiento, escalable, de fácil acceso y rica en funciones, y se encargará del rendimiento, la funcionalidad y la experiencia. en cada versión, todos son bienvenidos a unirse.

Sitio web oficial de Sermant : https://sermant.io
Dirección del almacén de GitHub : https://github.com/huaweicloud/Sermant

Haga clic para seguir y conocer las nuevas tecnologías de Huawei Cloud lo antes posible ~

La práctica de Sermant en escenarios de múltiples actividades en ubicaciones remotas