Quand les servomoteurs rencontrent les microservices : tout sur l'architecture des données

Avez-vous déjà rencontré cette situation ? Des dizaines de servomoteurs sur la chaîne de production fonctionnent en même temps et les données affluent comme une marée. Les données d'angle d'asservissement ici n'ont pas encore été enregistrées et les informations de couple en temps réel du bras robotique ont été réintégrées. La base de données ne peut pas respirer et le système se bloque parfois pendant quelques millisecondes - mais ces quelques millisecondes peuvent parfois causer des maux de tête.

N'est-ce pas la situation à laquelle nous sommes souvent confrontés lors de projets d'automatisation ? Les appareils deviennent de plus en plus intelligents et la quantité de données est de plus en plus importante. L’architecture traditionnelle d’une base de données unique commence à paraître inadéquate.

Questions à choix multiples sur les bases de données à l'ère des microservices

Voici donc la question : comment la base de données doit-elle être conçue sous l'architecture des microservices ?

Une voix dit : « Comme il est simple pour tous les services de partager une base de données ! » Mais en pratique, vous constaterez que de nombreux problèmes se cachent derrière cette simplicité. Les modifications apportées à la structure des tables d'un certain service peuvent accidentellement affecter d'autres fonctions ; le couplage des données est trop étroit et il est difficile d'étendre un module spécifique.

Une autre façon de penser devient populaire : chaque microservice gère sa propre base de données. Cela semble raisonnable, non ? Laissez le module responsable du contrôle de l'appareil à gouverner gérer ses propres données de position et laissez le module qui surveille l'état du moteur stocker son propre journal de fonctionnement. Chacun exerce ses fonctions sans interférer les uns avec les autres.

Mais une nouvelle question se pose : une fois les données dispersées, que faire des requêtes de données qui nécessitent des services interservices ? Par exemple, si vous souhaitez analyser l'efficacité globale d'une certaine unité mécanique, vous devez examiner la vitesse de réponse du servomoteur, la précision de positionnement de l'appareil à gouverner concerné et les données de charge de la structure mécanique. Les données sont dispersées à différents endroits et leur compilation prend du temps et est laborieuse.

kpuissanceSolution : modèles et équilibre

Nous y réfléchissons depuis quelques jours. existerkpuissanceDans l'expérience réelle du projet, j'ai découvert que la clé est de trouver un « schéma de base de données » approprié - pas un modèle rigide, mais une méthode flexible d'organisation des données.

Par exemple, le modèle « base de données distincte pour chaque service » est particulièrement utile dans les systèmes de commande de moteurs. Les données du module de contrôle en temps réel sont stockées indépendamment pour garantir une vitesse de réponse ; le module d'analyse historique utilise un autre ensemble de stratégies de stockage pour faciliter l'analyse des tendances à long terme. Les limites des données sont claires et les services échangent les informations nécessaires via des interfaces claires au lieu de consulter directement les bases de données d'autres personnes.

Comment assurer la cohérence des données ? Nous adoptons souvent une approche événementielle. Lorsqu'un servo termine l'action spécifiée, il publiera un événement « action terminée ». D'autres services soucieux de cet état - comme le service d'enregistrement de trajectoires de mouvement - reçoivent et traitent cet événement et mettent à jour leurs propres données. Cette approche évite les dépendances directes de base de données entre les services.

De la théorie aux scénarios réels sur la chaîne de production

L'année dernière, nous avons participé à un projet de rénovation d'une ligne de production automatisée, qui a utilisé ces idées. Il y a douze servomoteurs travaillant ensemble sur la ligne de production, et chacun d'eux doit enregistrer les paramètres de fonctionnement, les codes d'erreur et l'historique de maintenance. Les servos des trois ensembles de bras robotiques doivent échanger des données de position en temps réel.

Si toutes les données sont regroupées dans une seule base de données, les données de contrôle et d’analyse en temps réel occuperont des ressources. Nous avons adopté une stratégie diviser pour régner : configurer une base de données de séries chronologiques hautes performances pour les services de contrôle en temps réel afin de stocker les valeurs en temps réel de la vitesse et du couple du moteur ; configurer une base de données relationnelle pour les services de gestion d'équipement afin de stocker les paramètres d'équipement et les enregistrements de maintenance ; et les services d'analyse obtiennent des données de différentes sources en fonction des besoins et effectuent un traitement complet.

Le résultat ? Le délai de réponse du contrôle en temps réel est réduit de 40 % et la vitesse de requête d'analyse des données est augmentée. Chaque base de données pouvant être ciblée sur ses propres tâches principales, il n’est pas nécessaire de jongler avec tous les types d’opérations sur les données.

Les détails en pratique

Lors du choix d'un schéma de base de données, nous posons généralement plusieurs questions :

Quel est le modèle d'accès aux données pour ce service ? S'agit-il de lectures et d'écritures fréquentes en temps réel de petites quantités de données, ou de requêtes d'analyse occasionnelles à grande échelle ?

Quelle est la croissance attendue des données ? Certaines données de capteurs génèrent plusieurs enregistrements par seconde, qui peuvent s’accumuler jusqu’à un nombre étonnant en un mois.

Quelle est la force des dépendances en matière de données entre les services ? Avez-vous vraiment besoin d’une synchronisation en temps réel, ou un court délai est-il acceptable ?

Après avoir répondu à ces questions, le choix du mode devient beaucoup plus clair. Les données de contrôle ayant des exigences élevées en temps réel peuvent convenir aux bases de données en mémoire ou aux bases de données de séries chronologiques spécifiques ; pour les données de configuration qui nécessitent des relations de requêtes complexes, les bases de données relationnelles traditionnelles peuvent être plus adaptées ; pour de grandes quantités de données de journaux historiques, les moteurs de stockage en colonnes fonctionnent parfois mieux.

Le modèle n'est pas du bondage mais de la danse

Un bon schéma de base de données ne doit pas être comme une camisole de force, mais comme une combinaison de travail bien ajustée qui vous permet de vous déplacer librement tout en fournissant le soutien nécessaire. existerkpuissanceDans notre expérience de projet, nous avons constaté que les mises en œuvre les plus réussies sont souvent celles qui savent faire preuve de flexibilité.

Ils choisissent un schéma de base de données primaire pour un service principal, associé à des solutions de stockage secondaires pour des fonctions spécifiques. Tout comme un système mécanique précis, chaque composant possède le matériau et la structure les plus adaptés, afin que sa combinaison puisse atteindre une efficacité maximale.

Parfois, en regardant ces données circulant sans problème entre différents services, vous penserez à ces systèmes de transmission bien conçus : la puissance est transmise entre les engrenages, chaque maillon est parfait et finalement converti en mouvement précis.

écrit en

La conception de bases de données sous microservices consiste en fin de compte à trouver un équilibre : l'équilibre entre l'indépendance du service et l'intégrité des données, l'équilibre entre les performances en temps réel et la flexibilité des requêtes, et l'équilibre entre l'efficacité du développement à court terme et les coûts de maintenance à long terme.

Il n’y a pas de réponse universelle, seulement des choix appropriés à des scénarios spécifiques. Chaque projet est une nouvelle exploration, du contrôle moteur à la coordination mécanique, l'architecture des données est toujours la pierre angulaire qui soutient tout en silence.

Lorsque la nuit tombe et que les équipements de la chaîne de production entrent en période de maintenance, ces bases de données fonctionnant silencieusement sont toujours en train de trier les données de la journée et de préparer un fonctionnement efficace demain - tout comme un ensemble de dispositifs mécaniques précis, chaque pièce est dans la bonne position et remplit sa mission.

Créée en 2005, Kpower se consacre à un fabricant professionnel d'unités de mouvement compactes, dont le siège est à Dongguan, dans la province du Guangdong, en Chine. Tirant parti des innovations en matière de technologie d'entraînement modulaire, Kpower intègre des moteurs hautes performances, des réducteurs de précision et des systèmes de contrôle multiprotocoles pour fournir des solutions de systèmes d'entraînement intelligents efficaces et personnalisées. Kpower a fourni des solutions de systèmes d'entraînement professionnelles à plus de 500 entreprises clientes dans le monde avec des produits couvrant divers domaines tels que les systèmes de maison intelligente, l'électronique automatique, la robotique, l'agriculture de précision, les drones et l'automatisation industrielle.