Lorsque votre système serveur commence à « devenir gênant » : une histoire sur l'API REST des microservices

Avez-vous déjà rencontré cette situation ? Un matin, le bras robotique de l'atelier, âgé de trois ans, est soudainement devenu lent. Il bougeait toujours, mais sa réponse était toujours un demi-temps plus lente, comme s'il ne s'était pas réveillé. La coordination entre plusieurs servos a également commencé à montrer un léger désalignement. Bien que cela n’ait pas affecté le fonctionnement global, la précision des pièces traitées était un peu mauvaise.

Le problème ne vient souvent pas du matériel lui-même

Nous avons passé beaucoup de temps à vérifier le moteur, les capteurs, la structure de la transmission – tout allait bien. Mais le problème demeure. Il a été découvert plus tard que la communication interne du logiciel de contrôle en coulisses commençait à connaître des retards. L'échange de données entre les différents modules fonctionnels est comme une ancienne plaque tournante du transport, bloquée dans des endroits invisibles.

Il s'agit en fait d'un phénomène très typique. De nombreux systèmes mécaniques et d'automatisation fonctionnent bien au début, mais à mesure que les fonctions augmentent et que la quantité de données augmente, l'efficacité de la transmission interne des informations diminue progressivement. Surtout lorsque le système doit gérer une collaboration multi-axes, un retour en temps réel et un ajustement dynamique, les logiciels d'architecture monolithique traditionnels deviennent souvent un goulot d'étranglement.

À ce stade, vous devrez peut-être changer d’avis et examiner le problème.

Microservices et API REST : diviser les grands systèmes en petites équipes flexibles

Imaginez si chaque unité mécanique de l'atelier était comme une petite équipe indépendante avec une entente tacite. Les responsables de la saisie se concentrent uniquement sur la saisie, ceux responsables de la rotation se concentrent uniquement sur la rotation et ceux responsables du positionnement se concentrent sur le positionnement. Ils disposent chacun de leur propre « cerveau » (services), mais ils communiquent entre eux à tout moment grâce à un langage simple et standard (API REST).

L’avantage le plus direct de cette démarche est la flexibilité. Si une certaine unité doit être améliorée ou entretenue, cela n'affectera pas le fonctionnement normal des autres unités. C'est comme changer de musicien dans le groupe et la musique peut continuer. La maintenabilité du système est grandement améliorée.

C'est la clarté. Chaque service a des limites de responsabilité claires. Quand quelque chose ne va pas, vous savez à qui vous adresser. Lors du débogage, vous pouvez également être plus concentré et tout votre corps ne sera pas affecté par une seule chose.

Troisièmement, il y a l’évolutivité. Un jour, vous devrez ajouter un module d'inspection visuelle ou connecter un nouveau tableau de bord de données, c'est comme ajouter un nouveau rôle à l'équipe existante - utilisez simplement le même langage de communication (API) pour vous connecter, il n'est pas nécessaire de renverser et de recommencer.

Mais le « démantèlement » n’est pas l’objectif, mais plutôt une « meilleure collaboration ».

Lorsque beaucoup de gens entendent « microservices », ils pensent que plus le logiciel est défectueux, mieux c'est. Pas vraiment. La base de la séparation devrait être les limites naturelles des fonctions commerciales. Pour les systèmes de contrôle mécanique, il peut s'agir des domaines essentiels du « contrôle de mouvement », de la « surveillance de l'état », de la « logique de processus » et de la « persistance des données ».

Après la séparation, la clé est de savoir comment les laisser communiquer de manière efficace et fiable. C’est le problème que les API REST sont conçues pour résoudre.

Une bonne conception d’API, c’est un peu comme développer un protocole de communication efficace pour l’équipe. cela devrait:

• Intuitif et facile à comprendre：看到接口地址和方法，能猜出它是干什么的。 par exemple/api/moteur/statutUtilisé pour obtenir l'état du moteur,POST /api/tâcheUtilisé pour émettre de nouvelles tâches.
• Stable et cohérent: Il se comporte de la même manière aujourd'hui et demain. Le format des données renvoyées et la signification du code d'erreur restent unifiés, offrant ainsi une tranquillité d'esprit à l'appelant.
• Ne transmettez que les informations nécessaires: Ni plus, ni moins, juste ce qu'il faut pour répondre aux besoins de collaboration. Évitez de déplacer de grandes quantités de données redondantes entre les services, ce qui augmenterait la charge du réseau et les coûts d'analyse.
• Avoir une bonne « tolérance aux pannes »: Le réseau se déconnecte occasionnellement et un certain service ne répond temporairement plus. Une bonne conception d'API peut aider le système à se dégrader progressivement ou à récupérer rapidement au lieu de planter directement.

Du concept à la pratique : quelques réflexions spécifiques incontournables

Sur quoi devrions-nous nous concentrer lors de la construction d’un tel système ?

Premièrement, la granularité des services. La commande de chaque moteur doit-elle être transformée en un service indépendant, ou la commande de mouvement d'un axe entier doit-elle être utilisée comme un service ? Cela nécessite des compromis. S'il est trop détaillé, la complexité de la gestion augmentera ; s’il est trop grossier, les avantages des microservices seront perdus. Notre expérience consiste à partir des capacités métier de base et à trouver des unités fonctionnelles relativement indépendantes et autonomes.

Deuxièmement, la fiabilité de la communication. Dans les environnements industriels, les réseaux ne sont pas toujours parfaits. Les appels API peuvent échouer. Par conséquent, en plus de concevoir un mécanisme de nouvelle tentative, il est parfois également nécessaire d'introduire une file d'attente de messages asynchrone pour éviter la perte d'instructions importantes. S'assurer que « livré au moins une fois » est essentiel pour contrôler les instructions.

Troisièmement, la surveillance et la perspicacité. Une fois le système démonté, comment savoir si l’ensemble du système est sain ? Un mécanisme unifié de journalisation, de surveillance et de suivi des liens est requis. Lorsqu'un certain délai de traitement d'une pièce expire, vous pouvez rapidement retracer le service (tel que le service de planification de trajectoire) qui répond lentement, au lieu de vérifier aveuglément tout le matériel.

Quatrièmement, sécuriser les frontières. Chaque service a sa propre entrée et des politiques de sécurité détaillées. Qui a accès à l’interface de contrôle de mouvement ? Qui peut seulement lire le statut ? La gestion des autorisations d'API basées sur les rôles n'est pas facultative dans les systèmes industriels, mais indispensable.

Il ne s’agit pas simplement d’un changement dans l’architecture logicielle

À un niveau plus profond, l’adoption de microservices et d’une API REST claire change réellement la façon dont le système évolue. Cela transforme votre système d'automatisation en briques Lego qui peuvent être combinées, remplacées et mises à niveau en fonction des besoins de l'entreprise. Aujourd’hui, vous pouvez vous concentrer sur l’usinage de précision, les services de contrôle de mouvement en sont donc le cœur ; demain, vous devrez peut-être ajouter une maintenance prédictive Big Data, il vous suffira alors d'améliorer les services de collecte et d'analyse de données, et le flux de contrôle d'origine n'aura pas besoin d'être modifié de manière significative.

Ce type de flexibilité présente une valeur cachée et énorme pour les environnements de fabrication qui nécessitent un fonctionnement à long terme et une adaptation continue aux nouveaux processus et aux nouveaux produits. Cela réduit la dette technique et le risque de changements futurs.

existerkpuissance, nous sommes profondément impliqués dans les applications intégrées de servomoteurs, d’appareils à gouverner et de divers systèmes mécaniques. Nous avons constaté trop de goulots d'étranglement à un stade avancé, causés par des limitations architecturales logicielles. C'est précisément parce que nous comprenons les caractéristiques physiques et la logique de contrôle des systèmes mécaniques que nous accordons plus d'attention à la construction d'un squelette de communication « solide et flexible » au niveau logiciel.

Une bonne technologie ne devrait pas donner l’impression aux gens que c’est compliqué. Tout comme un ensemble d'excellentes API REST de microservices, ce qui est finalement présenté aux utilisateurs est une expérience de contrôle plus fluide, un rythme de production plus stable et une capacité d'expansion plus tranquille. Lorsque l'équipement de l'atelier semble avoir une « entente tacite », il y aura naturellement moins de problèmes.

Tout commence par une conception claire de la manière de « dialoguer ».

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. 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.