L'équipe de la communauté open source chinoise a réalisé sa première diffusion en direct, racontant l'histoire de la communauté open source chinoise au nom du partage.

Cet article est partagé par la communauté Huawei Cloud « Sermant's Practice in Remote Multi-Active Scenarios », auteur : Huawei Cloud Open Source.

La communauté Sermant a lancé successivement le plug-in d'interdiction de consommation de file d'attente de messages et le plug-in d'interdiction d'écriture de base de données dans les versions 1.3.0 et 1.4.0 , respectivement pour résoudre le problème de coupure de flux et de protection de la cohérence des données dans des scénarios multi-actifs à distance. Cet article analysera la pratique de Sermant dans des scénarios multi-activités à distance.

1. Vivez davantage dans un endroit différent

1.1 Qu'est-ce que vivre dans différents endroits ?

Pour un système logiciel, nous espérons qu'en cas de panne, le système pourra toujours fournir normalement des services au monde extérieur. Cette fonctionnalité du système logiciel est appelée haute disponibilité, et l'architecture multiactive à distance est utilisée pour résoudre le problème de haute disponibilité. .

La première architecture système est généralement une architecture à machine unique. Lorsque la base de données tombe en panne, l'activité peut être interrompue pendant une longue période. Afin de résoudre ce problème, la base de données a été développée pour se composer d'une base de données maître et d'une base de données esclave. La base de données maître est responsable des opérations de lecture et d'écriture, et la base de données esclave ne fournit que les opérations de lecture. être synchronisé avec la base de données esclave en temps réel pour maintenir la cohérence et l'intégrité des données. Lorsqu'un problème survient dans la bibliothèque principale, la bibliothèque esclave passe à la bibliothèque principale et continue de fonctionner. Cependant, ces services sont déployés dans la même salle informatique ou même dans la même armoire. Lorsque la salle informatique tombe en panne, le système ne peut toujours pas fournir les services externes normaux.

À l'heure actuelle, actif-actif dans la même ville est devenu une bonne solution. Deux salles informatiques sont déployées dans une ville. Les deux salles informatiques déploient le même environnement logiciel et fournissent des services. Lorsqu'une des salles informatiques tombe en panne, le trafic peut être basculé vers une autre salle informatique pour poursuivre l'exécution afin d'assurer la haute disponibilité du système. Comme le montre la figure 1, la base de données de la salle informatique 1 est la base de données principale. Toutes les opérations d'écriture dans les deux salles informatiques opèrent sur la base de données principale de la salle informatique 1, et les opérations de lecture peuvent lire la base de données dans cette salle informatique. La distance physique entre les deux salles informatiques est relativement proche. Dans le même temps, les deux salles informatiques peuvent utiliser des lignes dédiées pour la connexion réseau. Par conséquent, la latence du réseau pour les appels de service dans les différentes salles informatiques est faible. salle informatique 2 à la base de données de la salle informatique 1 se situe dans une plage acceptable.

Figure 1 : Schéma d'architecture double-active dans la même ville

L'architecture active-active dans la même ville résout le problème de la haute disponibilité des systèmes logiciels. Cependant, si une catastrophe naturelle survient dans une ville, comme un tremblement de terre, une inondation, etc., toutes les salles informatiques déployées dans la même ville le seront toujours. endommagé et cesser de fournir des services. Et comme ces catastrophes sont très destructrices, le cycle de réparation du système sera relativement long, ce qui affectera sérieusement le fonctionnement normal des activités de l'entreprise. Dans ce cas, il est évident que ces salles informatiques doivent être déployées dans différentes régions. Dans le même temps, l'éloignement géographique de ces régions doit être suffisamment éloigné pour résister aux risques de catastrophes naturelles. l'architecture multi-active à distance.

Comme le montre la figure ci-dessus, si la salle informatique 1 et la salle informatique 2 sont déployées dans deux villes, elles deviendront actives-actives à distance. Afin de mieux résister aux risques, les salles informatiques peuvent être déployées dans plusieurs régions de cette manière. actif-actif sera mis à niveau vers actif-actif à distance.

Le schéma d'architecture du multi-actif à distance est illustré à la figure 2. Le trafic client est distribué via la couche de routage vers différentes salles informatiques régionales pour exécution. La différence avec l'architecture active-active d'une même ville est que les salles informatiques des différentes régions sont physiquement éloignées les unes des autres. Le coût du déploiement de lignes réseau dédiées est énorme et irréaliste. Le délai d'accès au réseau entre les différentes salles informatiques ne peut donc être ignoré. il est nécessaire d'exploiter la base de données dans la salle informatique locale. Elle ne peut pas être exploitée dans plusieurs salles informatiques. Dans le cadre de l'architecture distante multiactive, la base de données de chaque salle informatique est la base de données principale, et les données des différentes salles informatiques seront synchronisées avec la salle informatique centrale, puis synchronisées de la salle informatique centrale vers les autres salles informatiques. Étant donné que les bases de données de toutes les salles informatiques peuvent être écrites, lorsque différentes salles informatiques modifient le même élément de données, des conflits de données sont inévitablement introduits. Afin de résoudre les conflits de données, une partie du trafic peut être transférée de manière fixe vers une certaine salle informatique selon la politique de fragmentation au niveau de la couche de routage. La politique de fragmentation du trafic peut être basée sur le type d'entreprise ou l'emplacement géographique. Grâce au partage du trafic, il est garanti que les demandes pertinentes du même utilisateur seront acheminées vers la même salle informatique pour effectuer toutes les opérations commerciales, et le trafic dans la salle informatique est garanti de circuler uniquement au sein de la salle informatique locale, réduisant ainsi la latence du réseau.

Figure 2 : Schéma d'architecture multi-active à distance

1.2 Scénarios typiques d'activités multiples dans différents lieux

L'architecture multi-active à distance déploie des salles informatiques dans différentes régions pour fournir des services externes afin de résister aux risques causés par les catastrophes naturelles. C'est un moyen efficace d'atteindre une haute disponibilité du système. Cependant, l’architecture multi-active à distance rend également le système plus complexe et introduit de nouvelles exigences en termes de coupure de pannes et de cohérence des données :

Dans un scénario de service cloud, lorsqu'une panne se produit dans une zone de disponibilité, les consommateurs dans la zone de panne doivent cesser d'extraire les messages pour les consommer, et en même temps, les files d'attente de messages allouées sont rééquilibrées vers les consommateurs dans la zone de disponibilité normale pour le traitement. afin d'éviter de provoquer des exceptions commerciales.
Le multi-actif à distance peut résoudre efficacement le problème de cohérence des données en fragmentant le trafic. Mais pour les données globales, telles que la quantité de produits, lors de l'écriture des données, seule la base de données globale située dans la salle informatique centrale est autorisée à fonctionner. Généralement, le trafic destiné à exploiter les données globales doit être acheminé vers la salle informatique centrale, et les autres salles informatiques ne sont autorisées qu'à lire la base de données. Lorsque le trafic est mal acheminé, il peut toujours être écrit dans la base de données située dans une salle informatique non centrale, provoquant ainsi des conflits de données. A ce stade, il est nécessaire d'ajouter une protection à la base de données globale et d'interdire l'exécution d'opérations d'écriture dans les salles informatiques non centrales.

En réponse aux deux problèmes typiques ci-dessus, Sermant a développé le plug-in d'interdiction de consommation de file d'attente de messages et le plug-in d'interdiction d'écriture de base de données pour les résoudre, qui seront présentés en détail ci-dessous.

2. La file d'attente des messages interdit la consommation de plug-ins

2.1 Introduction au plug-in d'interdiction de consommation de file d'attente de messages

Le plug-in d'interdiction de consommation de file d'attente de messages permet aux microservices d'ajuster dynamiquement le comportement de consommation des consommateurs du middleware de file d'attente de messages en fonction des besoins réels dans l'état d'exécution, garantissant que dans des environnements ou des états anormaux, les messages dans le processus de traitement métier sont correctement gérés et évitent les inutiles. Impact sur les entreprises. Par exemple, dans un système d'architecture multi-active distant, si une panne régionale se produit et que le trafic doit être interrompu, la fonction d'interdiction de consommation de la file d'attente de messages peut être activée dans la zone de disponibilité où la panne s'est produite, permettant aux consommateurs dans la zone de disponibilité normale pour gérer l'entreprise et éviter La zone défectueuse consomme du trafic, provoquant des anomalies commerciales, garantissant une haute disponibilité du système. Une fois le défaut traité, la consommation peut redémarrer.

Le plug-in d'interdiction de consommation de file d'attente de messages prend actuellement en charge deux middlewares de messages : Kafka et RocketMQ. Du côté de Kafka, le plug-in implémente des fonctions d'interdiction de consommation et de récupération au niveau du sujet. Pour RocketMQ, la granularité du contrôle de la consommation se situe au niveau de l'instance du consommateur. Sermant prend en charge l'émission de types de files d'attente de messages et de sujets spécifiques dont la consommation doit être interdite via le centre de configuration.

Pour plus d'informations sur le plug-in d'interdiction de la file d'attente de consommation, les instructions de configuration et les démonstrations de scènes, veuillez vous référer au document du site officiel Interdiction de la consommation de la file d'attente de messages .

2.2 Application de l'interdiction de la file de messages en cas de panne du plug-in de consommation et de scénario de coupure de flux

Scénario d'application : un système logiciel utilise Kafka comme file d'attente de messages et le producteur produit des messages vers le sujet de test de sujet. Le message de sujet contient quatre partitions. La zone de disponibilité A et la zone de disponibilité B ont chacune deux consommateurs qui rejoignent le groupe de consommateurs de test et consomment les messages de test de sujet. Chaque consommateur se voit attribuer une partition. La zone de disponibilité A et la zone de disponibilité B sont réparties dans différentes régions, c'est-à-dire à des endroits différents. . Deux autres salles informatiques. Comme indiqué ci-dessous.

Dans ce scénario, une fois que le service consommateur a désactivé l'exécution du plug-in de consommation en montant la file d'attente de messages de Sermant, il peut contrôler les sujets consommés par le consommateur en temps réel, garantissant ainsi que les messages du processus de traitement métier sont correctement gérés dans environnements ou états anormaux.

Lorsque la zone de disponibilité A échoue, les consommateurs de la zone de disponibilité A doivent cesser de consommer. Émettez une configuration globale dans la zone de disponibilité A pour interdire au consommateur A et au consommateur B de consommer le sujet de test de sujet, et libérez la file d'attente de messages allouée.

La configuration du plug-in d'interdiction de consommation de file d'attente de messages est la suivante. EnableKafkaProhibition signifie activer la fonctionnalité d'interdiction de consommation de file d'attente Kafka, et kafkaTopics spécifie les sujets d'abonnement dont la consommation doit être interdite. Pour la méthode de livraison de la configuration, veuillez vous référer au document du site officiel. La file d'attente des messages interdit la consommation :

activerKafkaProhibition : vrai  
crâneSujets :  
 - sujet-test

Une fois la configuration livrée, les consommateurs de la zone de disponibilité A cessent de consommer et les consommateurs de la zone de disponibilité B réaffectent les partitions du sujet de test de sujet, comme illustré dans la figure suivante.

Une fois la zone de disponibilité A revenue à la normale, la configuration peut être à nouveau émise via le centre de configuration dynamique pour permettre aux consommateurs A et B d'utiliser le sujet de test de sujet. Après avoir activé la livraison de la configuration de consommation, Kafka déclenchera le rééquilibrage et les consommateurs dans les zones de disponibilité A et B se verront réattribuer des partitions.

Le plug-in d'interdiction de consommation de la file d'attente de messages réalise la capacité de coupure des pannes de la file d'attente de messages dans le scénario multi-actif à distance, garantissant ainsi la disponibilité du système.

3. Plug-in d'interdiction d'écriture dans la base de données

3.1 Introduction au plug-in d'interdiction de consommation de file d'attente de messages

Une fois le service démarré en montant le plug-in d'interdiction d'écriture de la base de données, il peut activer ou désactiver dynamiquement la capacité d'interdiction d'écriture pour la base de données spécifiée. Dans un scénario multi-actif à distance, les utilisateurs souhaitent arrêter les opérations d'écriture sur une ou toutes les bases de données et autoriser uniquement la lecture des données pour garantir l'intégrité, la cohérence et la sécurité des données du système de base de données. Par exemple, l'écriture de données globales dans une base de données d'entreprise n'est autorisée que dans la salle informatique centrale. En activant le plug-in d'interdiction d'écriture de la base de données, le routage du trafic anormal ne peut pas être écrit dans la base de données de la salle informatique non centrale dans un emplacement multiple. et dans le scénario multi-écriture, le trafic est coupé avant d'être coupé manuellement. La salle informatique du flux interdit d'abord l'écriture dans la base de données et attend que la synchronisation des données dans d'autres salles informatiques soit terminée avant de couper le flux. L'utilisation du plug-in d'interdiction d'écriture de base de données dans le scénario ci-dessus garantit la cohérence des données de la base de données.

Le plug-in d'interdiction d'écriture de base de données prend actuellement en charge les bases de données MySQL, MongoDB, PostgreSQL et OpenGauss. Lorsque le microservice est en cours d'exécution, le type et le nom de la base de données interdite en écriture peuvent être émis via le centre de configuration. Pour les opérations d'écriture spécifiques et l'utilisation de plug-ins prenant en charge l'interdiction d'écriture, veuillez vous référer à l' interdiction d'écriture de la base de données de documents du site officiel .

3.2 Le plug-in d'interdiction d'écriture de la base de données protège les applications de cohérence des données

Scénario d'application : dans le cadre de l'architecture distante multiactive, un microservice métier est utilisé pour modifier les données globales telles que l'inventaire des produits. En même temps, les données globales sont stockées dans une base de données MySQL nommée globale. Pour ces données globales, les opérations d'écriture ne sont autorisées que pour faire fonctionner la base de données globale dans la salle informatique centrale, et les bases de données globales dans d'autres salles informatiques ne peuvent lire que les données. Afin de garantir la cohérence des données, lorsque les données globales sont modifiées, le trafic est acheminé vers la salle informatique centrale pour être exécuté au niveau de la couche de routage, et d'autres opérations de lecture peuvent être acheminées vers n'importe quelle salle informatique, comme le montre la figure ci-dessous.

Lorsque la couche de routage commet une erreur de routage pour le trafic écrivant des données globales et l'exécute dans une salle informatique non centrale, si la salle informatique centrale et la salle informatique non centrale modifient la quantité du même produit en même temps, elle peut provoquer des conflits de données. Afin d'éviter que cela ne se produise, les microservices commerciaux peuvent monter le plug-in d'interdiction d'écriture de la base de données de Sermant pour interdire l'écriture dans la base de données globale dans les salles informatiques non centrales.

L'écriture dans la base de données globale est interdite dans les salles informatiques non centrales et la configuration suivante doit être émise via le centre de configuration dynamique :

activateMySqlWriteProhibition : vrai  
mySqlDatabases :  
 - mondial

Parmi eux, activateMySqlWriteProhibition signifie activer la possibilité d'interdire l'écriture sur la base de données MySQL, et mySqlDatabases est utilisé pour spécifier le nom de la base de données spécifique interdite en écriture. Cet exemple est la base de données globale.

Une fois la configuration émise, lorsque le trafic avec un routage anormal est écrit dans la base de données globale dans la salle informatique non centrale, le plug-in d'interdiction d'écriture de la base de données lève une exception java.sql.SQLException au microservice métier et interdit l'écriture dans la base de données. . Le système d'entreprise doit gérer cette exception, par exemple en ajoutant une opération de nouvelle tentative pour rediriger le trafic vers la salle informatique centrale pour exécution afin de garantir le fonctionnement normal du système. La logique d'exécution est illustrée dans la figure ci-dessous.

Le plug-in d'interdiction d'écriture de base de données désactive l'écriture dans la base de données spécifiée dans un scénario multiactif à distance, ce qui peut empêcher les opérations d'écriture de trafic anormales et garantir la cohérence des données dans les bases de données des différentes salles informatiques.

4. Résumé

Dans le scénario multi-actif à distance, le plug-in d'interdiction de consommation de la file d'attente de messages de Sermant peut résoudre le problème de coupure du flux de file d'attente de messages en cas de défaillance de la zone de disponibilité, permettant aux consommateurs de la zone de disponibilité normale de consommer les données du plug-in d'interdiction d'écriture de la base de données ; utilisé pour interdire l'écriture dans la base de données spécifiée et n'affecte pas la lecture de la base de données pour éviter les conflits de données.

Sermant a atteint de riches capacités de gouvernance des services dans des scénarios multi-activités à distance. À l'avenir, Sermant continuera à travailler dur pour construire progressivement un système de capacités de gouvernance des services plus complet.

En tant que cadre d'amélioration du bytecode axé sur le domaine de la gouvernance des services, Sermant s'engage à fournir une expérience de gouvernance des services hautes performances, évolutive, facile d'accès et riche en fonctionnalités, et prendra en charge les performances, les fonctionnalités et l'expérience. dans chaque version, tout le monde est largement invité à participer.

Site officiel de Sermant : https://sermant.io
Adresse de l'entrepôt GitHub : https://github.com/huaweicloud/Sermant

Cliquez pour suivre et découvrir les nouvelles technologies de Huawei Cloud dès que possible~

Pratique de Sermant dans des scénarios multi-activités dans des endroits éloignés