12 principios del diseño de microservicios

Cuando los servomotores se encuentran con los microservicios: ¿por qué los diseños mecánicos tradicionales se vuelven engorrosos?

Imagina que estás montando un brazo robótico complejo. Cada articulación está controlada por un servomotor o servo, que es responsable de la posición, la velocidad y el par precisos. Todo está diseñado con rigor y precisión, al menos sobre el papel. Pero cuando comienzas a depurar, surgen problemas: un ajuste de parámetros del motor requiere recompilar todo el programa de control; una pequeña falla en el sensor hace que todo el sistema se apague; desea actualizar uno de los módulos, pero descubre que está estrechamente acoplado con otros cinco o seis módulos.

¿Te suena familiar? Es como intentar tallar una escultura detallada en una roca. Cada movimiento del cuchillo puede provocar una fragmentación inesperada. En el ámbito de la maquinaria y la automatización, a menudo caemos en el dilema de esta "arquitectura monolítica": el sistema es enorme, rígido y afecta a todo el cuerpo. Cambiar una pieza puede significar rediseñar la mitad de la máquina.

¿Por qué sucede esto? Tal vez sea porque estamos acostumbrados a ideas de diseño verticales e integradas. Empaquetamos todas las funciones (control de movimiento, procesamiento lógico, protocolos de comunicación) en un bloque compacto de código o módulo de hardware. Solía ​​ser eficiente, pero cuando los proyectos se vuelven complejos y los requisitos se repiten rápidamente, esta estructura se convierte en una carga.

¿Existe alguna manera de construir nuestro sistema de control como si fueran bloques de construcción? ¿Dejar que cada servomotor o unidad de ejecución sea como un pequeño equipo independiente, cada uno realizando sus propias tareas y pudiendo comunicarse fácilmente?

Iluminación a partir de microservicios: desmantelar los sistemas mecánicos en “células inteligentes”

Esto puede parecer un poco cruzado, pero veamos un concepto candente en el mundo del software: los microservicios. En pocas palabras, divide una aplicación grande en una serie de pequeños servicios. Cada servicio se centra en una cosa y se comunica de forma ligera. Puede desarrollar, implementar y ampliar cualquiera de ellos de forma independiente sin afectar al conjunto.

¿Qué tal si incorporamos esto a nuestros proyectos de control mecánico y de motores? Imagínese esto: ya no tiene un cerebro central que controle los doce motores articulares. En cambio, a cada servomotor (o a cada grupo de motores que trabajan juntos) se le asigna una "unidad de toma de decisiones" dedicada y liviana. Esta unidad solo es responsable de este motor: leer la retroalimentación del codificador, realizar el control de circuito cerrado PID y administrar su protección de temperatura. Le dice a sus vecinos a través de un protocolo claro (como bus CAN o EtherCAT): "Mi posición está en su lugar y el par es normal", o "Necesito reducir la velocidad y la carga aumenta repentinamente".

Esta es la encarnación de la idea de diseño de "microservicio" a nivel de hardware e integrado.kpotenciaDespués de explorar profundamente este concepto, se perfeccionó e implementó un conjunto de "12 principios de diseño de microservicios" adecuados para proyectos de mecatrónica. No es un producto ya hecho, sino un conjunto de filosofía de diseño y patrones de construcción que ayudan a dividir ese "monolito" en "células inteligentes" que trabajan en coordinación.

¿Qué puntos débiles específicos resuelve?

• Los cambios ya no dan miedo: ¿Quiere optimizar el algoritmo de respuesta de un determinado servo? Solo necesita actualizar ese pequeño servicio sin tocar todo el programa principal, lo que reduce en gran medida el riesgo de pruebas y regresión.
• Los fracasos son aislados en lugar de difusos: Una lectura anormal de un sensor sólo afectará al servicio local al que pertenece. Otras partes del sistema pueden degradarse o suspenderse de forma segura, en lugar de colapsar por completo.
• La selección de tecnología puede ser más flexible: El servicio responsable de la comunicación puede utilizar un idioma y el servicio responsable de la planificación del movimiento puede utilizar otro. Puede elegir las herramientas y el conjunto de tecnología más adecuados para cada módulo pequeño.
• La expansión se vuelve natural: ¿Necesita agregar un módulo de reconocimiento visual para guiar el brazo robótico? Simplemente agregue un nuevo "bloque de construcción" de servicio que siga las mismas reglas de comunicación sin tener que refactorizar la base.

De la filosofía a la práctica: ¿Cómo implementar los 12 principios?

Estos 12 principios van desde la delimitación de límites y la implementación independiente hasta la tolerancia a fallas y el monitoreo. Hablemos de algunos de los más intuitivos.

Por ejemplo, "responsabilidad única". Esto requiere que cada microservicio (correspondiente a nuestro proyecto, que puede ser cada unidad de control de motor y cada módulo de gestión IO) haga solo una cosa. Al igual que un buen mecanismo de dirección, su responsabilidad es girar con precisión al ángulo especificado y mantenerlo. No se debe calcular la trayectoria de todo el camino al mismo tiempo. Los límites claros de responsabilidad son el punto de partida de la fiabilidad.

Otro ejemplo es la "gestión de datos descentralizada". Los sistemas tradicionales pueden almacenar todos los datos (parámetros del motor, registros de posición, registros de alarmas) en una base de datos central. Consejos de diseño de microservicios: deje que cada servicio administre sus propios datos. El servicio de control de motores mantiene sus propios parámetros de calibración y registros de operación; el servicio de comunicación gestiona su propia cola de mensajes. Esto reduce los puntos únicos de falla y evita la expansión y el acoplamiento infinitos de estructuras de datos.

Algunas personas pueden preguntar: "Con más servicios, ¿no será la comunicación más complicada y más lenta?" Ésta es una buena pregunta. Esto lleva al principio de “puntos finales inteligentes y tuberías tontas”. La tubería de comunicación (bus o red) debe mantenerse simple y confiable, responsable únicamente de transmitir datos. Toda la "inteligencia" (como la validación de datos, la lógica empresarial) debe colocarse en los servicios en ambos extremos de la comunicación. Esto significa que debe diseñar cuidadosamente el protocolo de interfaz entre servicios para que sea lo suficientemente claro y estable.kpotencia, proporciona una gran cantidad de patrones y prácticas de interfaz probados para equilibrar la libertad y la complejidad aquí.

También existe el "diseño tolerante a fallos". En los sistemas distribuidos, las fallas son la norma. Pueden ocurrir fallas en el servicio, demoras en la comunicación e inconsistencia temporal de los datos. Nuestros diseños se anticipan a esto. Por ejemplo, cuando un servicio de control de motores no responde temporalmente, ¿qué debe hacer el servicio de planificación de rutas aguas arriba? ¿Deberías esperar, intentarlo de nuevo o cambiar al modo seguro? Definir estas políticas desde el principio hace que el sistema sea más resiliente.

Un viaje, no una panacea

La introducción de este pensamiento de diseño basado en microservicios no persigue una moda técnica. Es esencialmente una respuesta al problema de la complejidad. Cuando el proyecto al que se enfrenta ya no es una simple plataforma de tres ejes, sino un sistema de automatización que necesita coordinar docenas de actuadores, interactuar con múltiples dispositivos y tiene necesidades en evolución, naturalmente sentirá las limitaciones de la arquitectura tradicional.

kpotenciaEl marco "12 principios del diseño de microservicios" está diseñado para ayudar a los ingenieros y líderes de proyectos a comenzar este viaje sin problemas. Proporciona una hoja de ruta, una lista de patrones de diseño y una guía para evitar obstáculos, en lugar de una especificación obligatoria. Puede comenzar con un módulo pequeño y probarlo, como funciones de registro o alarma como servicio, para experimentar el aislamiento y la flexibilidad de implementación que brinda.

En última instancia, el objetivo no es hacer que el sistema sea "más distribuido", sino hacerlo más adaptable al cambio, más fácil de entender y más robusto y confiable. Al igual que un conjunto de piezas mecánicas modulares bien diseñadas, cada pieza es estándar y resistente, pero cuando se combinan, pueden completar una danza extremadamente compleja.

Al comenzar su próximo proyecto de mecatrónica, tal vez pregúntese: ¿estamos diseñando una roca pesada o un conjunto de ladrillos LEGO que se pueden reconfigurar y actualizar en cualquier momento? Las diferentes respuestas pueden definir el futuro de todo el proyecto.

Fundada en 2005, Kpower se dedica a la fabricación profesional de unidades de movimiento compactas, con sede en Dongguan, provincia de Guangdong, China. Aprovechando las innovaciones en tecnología de accionamiento modular, Kpower integra 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.