pourquoi nous utilisons Kafka dans les microservices

Avez-vous déjà essayé de contrôler un grand groupe de servomoteurs afin qu'ils se synchronisent comme un orchestre symphonique ?

J'ai déjà travaillé sur un projet de ligne de production automatisée, dans lequel des dizaines de bras robotiques fonctionnaient en même temps et les données des capteurs continuaient d'affluer. Au début, j'utilisais une file d'attente de messages régulière, mais j'ai découvert que lorsque la quantité de données dans un certain lien augmentait soudainement, l'ensemble du système commençait à « bégayer », tout comme une intersection aux heures de pointe, où toutes les voitures étaient bloquées, et le bras robotique derrière ne pouvait qu'attendre.

À ce stade, vous vous demanderez : existe-t-il un moyen de faire en sorte que les données telles que la circulation sur l'autoroute soient fluides, même si une certaine section est encombrée, les autres voies sont toujours libres ?

Plus tard, j'ai eu l'idée d'utiliser Kafka pour traiter des microservices. En termes simples, c'est comme un système de tapis roulant qui ne se bouche jamais. Chacun de vos microservices, comme un programme chargé d'analyser les données de position de l'appareil à gouverner ou un autre service qui enregistre les fréquences de vibrations mécaniques, peut indépendamment extraire les paquets de données dont il a besoin de ce tapis roulant et gérer ses propres affaires sans interférer les uns avec les autres.

Donnez un exemple. Supposons que vous disposiez de trois microservices : A reçoit les signaux des capteurs, B calcule les trajectoires de mouvement et C enregistre les journaux d'exécution. Dans l'architecture traditionnelle, B attend que A termine le traitement avant de pouvoir fonctionner, et C doit attendre B. Mais après avoir utilisé Kafka, A met les données d'origine sur le « tapis roulant », et B et C peuvent y accéder en même temps et travailler indépendamment. Même si C est temporairement plus lent, cela ne ralentira pas A et B.

Pourquoi est-ce particulièrement important pour les projets mécaniques ? Parce que les systèmes mécaniques fonctionnent souvent en temps réel et hautement simultanés. Les servomoteurs de chaque articulation d'un robot à six axes renvoient des données au niveau de la milliseconde. S’il y a un retard dans la chaîne de traitement des données, l’ensemble du mouvement perdra sa coordination. La conception du « journal persistant » de Kafka garantit que même si un service est redémarré, les données pendant le temps d'arrêt ne seront pas perdues - tout comme un enregistrement continu du journal en cours d'exécution de chaque appareil, qui peut être lu à tout moment.

Quelqu'un m'a demandé : « Ça a l'air bien, mais est-ce que ça va être compliqué ? En fait, la clé n’est pas la profondeur de la technologie elle-même, mais son adéquation à votre scénario. Si vous ne contrôlez que deux ou trois servos pour effectuer des swings simples, cela peut ne pas être utile ; mais si vous êtes confronté à un groupe entier d'équipements d'automatisation d'atelier avec des centaines de sources de données, cette architecture peut vous aider à éviter d'avoir à faire des heures supplémentaires tard dans la nuit pour résoudre des problèmes.

Lors de la sélection d'un modèle, je regarde généralement trois points : le premier est de savoir si le débit peut correspondre à votre pic de données - comme un scénario de tempête lorsque tous les capteurs signalent en même temps ; la seconde est de savoir si le retard se situe dans la plage de tolérance de votre système mécanique ; le troisième est le coût d’exploitation et de maintenance. Kafka a trouvé un bon point d’équilibre dans ces dimensions.

Bien sûr, il n’existe pas de solution miracle. Cela nécessite que vous ayez un plan clair pour le flux de données, par exemple comment diviser les sujets (Sujet) et comment concevoir des partitions (Partition). C'est comme planifier l'itinéraire d'un tapis roulant pour une nouvelle usine : quelles données doivent être acheminées sur la voie rapide et lesquelles peuvent être consolidées pour le transport, vous devez y réfléchir à l'avance.

Parlons de l’expérience réelle de mise en œuvre. Lors du déploiement initial, l'équipe doit s'adapter à ce changement de logique « publication-abonnement » et ne plus insister sur les appels directs entre les services. Mais une fois qu'il démarre, la flexibilité du système est considérablement améliorée. Lorsqu'un service est mis à niveau, les autres services fonctionneront comme d'habitude ; lorsqu'un nouveau module d'analyse de données est ajouté, il vous suffit de le laisser s'abonner au flux de données concerné sans modifier le lien d'origine.

Le monde numérique des systèmes mécaniques est souvent invisible, mais il détermine si les mouvements des équipements physiques sont précis et fluides. Choisir une architecture de données appropriée, c'est comme équiper un mécanisme mécanique précis d'un système nerveux correspondant : il n'est peut-être pas directement visible, mais il rend la rotation de chaque engrenage plus sûre.

Créé en 2005,kpuissancea été dédié à un fabricant professionnel d'unités de mouvement compactes, dont le siège est à Dongguan, province du Guangdong, en Chine. Tirant parti des innovations en matière de technologie d'entraînement modulaire,kpuissanceintè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.kpuissancea 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.