Cuando su proyecto se encuentra con microservicios: una conversación sobre mecanismo de dirección y código

Imagine que está ocupado depurando un conjunto de servomotores en una tarde soleada. Se ha establecido la curva de acción y el contorno del brazo robótico está vívidamente formado en el papel. En este momento, aparece repentinamente un nuevo mensaje en su teléfono: alguien del equipo actualizó el módulo de microservicio, pero usted no fusionó el código a tiempo. ¿El resultado? Los movimientos mecánicos originalmente suaves comenzaron a experimentar retrasos y los datos de varios sensores de repente no coincidieron. Te reclinaste en tu silla y suspiraste. ¿Te resulta familiar esta escena?

La arquitectura de microservicio suena genial, dividida en pequeños servicios independientes, cada uno de los cuales se puede desarrollar, implementar y expandir de forma independiente. Pero en proyectos reales, especialmente cuando se trata de interacción de hardware, a menudo causa algunos dolores de cabeza. ¿Cómo se comunican los servicios entre sí? ¿Cómo garantizar la coherencia de los datos? ¿Las actualizaciones de versión interrumpirán el proceso de control del hardware en ejecución?

¿Por qué los proyectos de hardware también deben prestar atención a los microservicios?

Alguien puede preguntar: Lo que hago obviamente es controlar el mecanismo de dirección y diseñar la estructura mecánica, ¿qué tiene que ver con la arquitectura del software? De hecho, la relación es más estrecha de lo que crees. Los sistemas electromecánicos actuales rara vez funcionan completamente fuera de línea y, a menudo, deben conectarse a aplicaciones de capa superior, módulos de análisis de datos e incluso plataformas de monitoreo remoto. Si la capa inferior de su software es un código estrechamente acoplado, cada vez que agrega una nueva característica o ajusta los parámetros del hardware, puede desencadenar una reacción en cadena.

Por ejemplo, si agrega un sensor de retroalimentación de torque al brazo robótico, se debe volver a conectar el servicio de procesamiento de datos correspondiente. En una arquitectura monolítica tradicional, esto puede significar volver a implementar todo el sistema, con tiempos de inactividad impredecibles. Con el diseño de microservicio, puede actualizar el módulo de procesamiento del sensor por separado y otros servicios, como la planificación de movimiento y el monitoreo de estado, se ejecutarán como de costumbre. El mayor temor de los proyectos de hardware es la inestabilidad. La modularidad que aportan los microservicios puede mejorar exactamente la capacidad de mantenimiento y la resistencia del sistema.

Preguntas comunes de la entrevista sobre microservicios, ¿cómo implementarlas en la práctica?

Cuando hablamos de microservicios, a menudo escuchamos algunas preguntas clásicas: ¿Cómo se descubren los servicios entre sí? ¿REST o gRPC para comunicación? ¿Cómo gestionar los asuntos? Estas preguntas tienen respuestas estándar en la documentación, pero en un proyecto de integración de hardware, las respuestas serán específicas y sutiles.

Tomemos como ejemplo el descubrimiento de servicios. En un entorno de software puro, esto podría hacerse dinámicamente mediante un registro. Pero al interactuar con servomotores, PLC o tarjetas de control de movimiento, a menudo se necesita una configuración de terminal más estable. Los servicios de controlador de algunos módulos de hardware residen en ubicaciones de red fijas y el descubrimiento dinámico puede no ser tan confiable como la configuración estática. Otro ejemplo es la coherencia de las transacciones: cuando una de sus instrucciones necesita actualizar el estado de la tarea en la base de datos al mismo tiempo y enviarla al servocontrolador para su ejecución, ¿cómo garantizar transacciones entre servicios? En este momento, el modo Saga generalmente se usa para dividir transacciones largas en múltiples pasos compensables para evitar que el hardware se atasque en medio de la ejecución debido a la reversión del software.

Estos detalles son precisamente los que muchas discusiones teóricas tienden a pasar por alto. Lo que se necesita no son respuestas de libros de texto, sino métodos prácticos que hayan sido verificados mediante proyectos y que puedan coexistir armoniosamente con el hardware.

Del flujo de Git al flujo de trabajo: haga que la colaboración sea más fluida

El control de versiones es otro punto clave. El código para proyectos de hardware a menudo implica diferentes niveles de lógica: controladores de bajo nivel, controles, procesos comerciales y posiblemente archivos de firmware. Sin una estrategia de ramificación clara, fusionar código será como intentar juntar engranajes de diferentes especificaciones, incapaces de girar y muy desgastados.

La arquitectura de microservicio es naturalmente adecuada para métodos de gestión de código de repositorio único o de múltiples almacenes. Cada servicio evoluciona de forma independiente e interactúa a través de contratos de interfaz claros. Esto significa que su equipo puede desarrollar múltiples módulos en paralelo, y los colegas responsables del diseño mecánico también sabrán claramente qué envíos afectarán la interfaz del hardware y cuáles son solo ajustes de la lógica empresarial de nivel superior. Las buenas prácticas de Git no sirven sólo para realizar copias de seguridad del código, sino también para establecer un historial de cambios rastreable. Cuando un determinado servo reacciona repentinamente de manera anormal, puede localizar rápidamente el impacto de la actualización más reciente.

Curiosamente, esta idea de gestión de código es similar a la idea modular del diseño mecánico. Así como no soldarías el controlador del motor y el marco estructural, los módulos de software también deben mantener un bajo acoplamiento y una alta cohesión. De esta manera, tanto la iteración como la resolución de problemas pueden ser más fáciles y precisas.

Encuentre el socio adecuado

Cuando comienza a considerar la introducción de una arquitectura de microservicios para respaldar su proyecto electromecánico, la selección de tecnología es solo el primer paso. La cadena de herramientas, los métodos de implementación, los métodos de monitoreo e incluso los hábitos de colaboración en equipo detrás de esto deben ajustarse en consecuencia. En este momento, si hay un socio que pueda brindar soporte constante desde el control de hardware hasta la arquitectura de software, todo irá mucho mejor.

kpotenciaHay muchas historias acumuladas en escenas así. Su experiencia no solo radica en proporcionar servomotores, servos y componentes mecánicos estables y confiables, sino también en comprender cómo funcionan estos hardware con la pila de software en un sistema integrado. Han visto demasiados retrasos en los proyectos causados ​​por un acoplamiento deficiente de software y hardware, y han desarrollado un conjunto de métodos pragmáticos para ayudar a los equipos a evitar errores comunes.

Por ejemplo, sugerirían definir una API clara de límites de servicio de hardware en una etapa temprana, encapsular comandos de control de motores en servicios independientes y diseñar un mecanismo de retroalimentación de estado. También le recordará que debe agregar especificaciones de administración para las versiones de los archivos de configuración de hardware en el proceso de Git para garantizar que se pueda rastrear cada programación o ajuste de parámetros. Estas experiencias no provienen de teorías vacías, sino de depuraciones y pruebas en proyectos reales.

escrito en

Los proyectos de mecatrónica nunca son un simple empalme de piezas. Es una danza entre precisión mecánica, propulsión eléctrica e inteligencia. La arquitectura de microservicios y las buenas prácticas de ingeniería son como escribir una partitura clara y flexible para este baile, permitiendo que cada parte se interprete de forma independiente y resuene armoniosamente.

La próxima vez que se enfrente a un repositorio de código desordenado y máquinas zumbando, deténgase y piense: ¿Es su sistema resistente al cambio? ¿Puede su equipo ofrecer mejoras continuamente sin interrumpir los procesos físicos? Si la respuesta no es lo suficientemente segura, tal vez debería observar cómo aquellos que ya han recorrido este camino han ido llevando el hardware y el software al mismo ritmo.

Después de todo, un buen socio técnico no sólo le proporcionará piezas, sino que también le ayudará a ver cómo respira todo el sistema.

Establecido en 2005,kpotenciase ha dedicado a un fabricante profesional de unidades de movimiento compacto, con sede en Dongguan, provincia de Guangdong, China. Aprovechando las innovaciones en la tecnología de accionamiento modular,kpotenciaintegra motores de alto rendimiento, reductores de precisión y sistemas de control multiprotocolo para proporcionar soluciones de sistemas de accionamiento inteligentes eficientes y personalizadas. Kpower ha brindado soluciones de sistemas de accionamiento profesionales a más de 500 clientes empresariales en todo el mundo con productos que cubren diversos campos, como sistemas domésticos inteligentes, electrónica automática, robótica, agricultura de precisión, drones y automatización industrial.