Cuando tu proyecto mecánico empieza a "trabajar en silos"

¿Recuerda la última vez que depuró ese sistema multieje? Se suponía que los tres servomotores estaban sincronizados como bailarines de ballet, pero en lugar de eso bailaban al ritmo de tres ritmos diferentes. Los cables estaban enredados como enredaderas y un pequeño cambio en cierto módulo obligó a reescribir todo el programa de control. En el laboratorio, a altas horas de la noche, mientras mira las luces indicadoras parpadeantes, es posible que se le haya pasado por la cabeza un pensamiento: ¿Cuánto menos preocupación habría si cada parte pudiera trabajar de forma independiente y colaborar de manera inteligente?

Este no es sólo tu problema. Desde líneas de montaje automatizadas hasta sofisticados sistemas de control del mecanismo de dirección, cuanto más complejos se vuelven los proyectos mecánicos, más difícil resulta para la arquitectura tradicional de "un solo cabello afectar a todo el cuerpo". Es como dirigir una banda donde todos los músicos comparten una partitura. Si cambias una nota, todos tienen que parar.

Como resultado, una idea llamada "plataforma de microservicios" entró silenciosamente en este campo. Puede considerarlo como asignar a cada función principal (como el control del motor, el cálculo de la trayectoria del movimiento y el monitoreo del estado) una “pequeña sala” dedicada y completamente funcional. Cada habitación tiene su propia fuente de alimentación, herramientas e instrucciones independientes. La información necesaria se transmite entre ellos a través de varios canales claros y fijos (generalmente interfaces API livianas), como "El motor A está en su lugar" y "La planificación de la ruta B está completa". Mientras se repara y mejora una habitación, otras habitaciones seguirán funcionando como de costumbre.

¿Suena esto un poco abstracto? Hablemos de algo específico

Pregunta: ¿Cuál es la diferencia entre esto y dividir un software grande en varios archivos pequeños? La diferencia es la "autonomía". La modularización tradicional es como un libro dividido en capítulos, pero el libro sigue siendo el mismo. Cada servicio en microservicios se parece más a un volumen independiente de una serie de novelas. Cada libro tiene su propio autor (equipo de desarrollo), escrito en el lenguaje (tecnología de programación) que domina e incluso se vende en diferentes librerías (servidores). Siempre que estén de acuerdo con los personajes clave y la interfaz de la trama (API), los lectores pueden seguir toda la serie sin problemas. Esto significa que puede usar el lenguaje más adecuado para escribir servicios de control para un determinado servo y usar otro lenguaje para procesar registros de datos sin interferir entre sí.

P: ¿Cuáles son los beneficios prácticos para mi proyecto mecánico? Imaginemos dos escenarios. La primera es la velocidad de iteración: es necesario mejorar la precisión de la retroalimentación del servo. Bajo la arquitectura de microservicio, solo necesita actualizar la pequeña sala del "servicio de control del servidor" y reemplazarla sin problemas después de la prueba. Todo el sistema no se apaga y otros servicios, como la administración de energía y el monitoreo de seguridad, continúan ejecutándose sin ningún conocimiento. El segundo es la tolerancia a fallos: si un servicio de procesamiento de datos de detección falla inesperadamente, la plataforma puede reiniciarlo automáticamente. En estos pocos segundos, el sistema podrá degradarse en funcionamiento, pero no quedará completamente paralizado como la arquitectura monolítica tradicional, dejando todo el brazo robótico congelado en el aire.

P: ¿Esto hará que el sistema sea más complejo y más difícil de integrar? El diseño del cableado inicial requiere nuevas ideas. Pero a la larga, reduce la complejidad. Cada servicio tiene una responsabilidad única y límites claros, al igual que cada herramienta en una caja de herramientas tiene una ranura fija, en lugar de que todas las herramientas estén soldadas en una gran pila. Al depurar, puede localizar con precisión si el "servicio de comunicación" o el "servicio de planificación de movimiento" son alarmantes. ¿Nueva característica? En lugar de modificar algo enorme, agregamos directamente una "habitación pequeña" independiente.

¿Cómo es una plataforma de microservicios confiable?

No debería ser un concepto académico, sino un verdadero "administrador comunitario". Esta ama de llaves es responsable de: asignar recursos a cada "sala de servicio", monitorear su salud, administrar las rutas de comunicación entre las habitaciones y construir rápidamente habitaciones nuevas e idénticas cuando sea necesario ampliarlas.

existirkpotenciaDesde nuestra perspectiva, una plataforma de este tipo no se copia directamente de los libros de texto de software. Tiene que comprender el "ritmo físico" del mundo mecánico. Por ejemplo, ¿puede la mensajería entre servicios cumplir los requisitos en tiempo real de los servomotores de alta velocidad? Cuando la plataforma programa recursos, ¿tiene en cuenta los picos de carga periódicos de determinados servicios de control? ¿Es lo suficientemente liviano como para implementarlo en dispositivos informáticos de vanguardia cerca de las máquinas herramienta de fábrica, en lugar de simplemente vivir en la nube?

Esto significa que el núcleo de la plataforma debe incorporar una comprensión de las redes sensibles al tiempo y los retrasos deterministas, e incluso puede ser compatible con varios protocolos de comunicación industrial. Las herramientas que proporciona deberían permitir a los programadores familiarizados con los diagramas de escalera y las tarjetas de control de movimiento gestionar estos "servicios" de forma relativamente natural, en lugar de obligarlos a convertirse en puros expertos en software.

Evita esas hermosas trampas

Hablar de arquitectura siempre es fascinante, pero siempre hay dificultades a la hora de implementarla. Por ejemplo, los "microservicios" no consisten en dividir todo en pedazos más pequeños. Una división excesiva aumentará la sobrecarga de comunicación. Es como configurar cada tornillo de una máquina como un servicio. El tráfico de red que conversa entre ellos puede estar más ocupado que trabajando. La clave es encontrar el “límite autónomo” de la funcionalidad: una unidad funcional que pueda implementarse y actualizarse de forma independiente y que tenga claras implicaciones comerciales.

Otro ejemplo es la coherencia de los datos. En un sistema monolítico, una transacción de base de datos puede manejarlo. Ahora bien, una acción puede abarcar varios servicios. ¿Cómo garantizar que todos los servicios relacionados tengan éxito o vuelvan al punto original? Esto requiere patrones de diseño más elaborados, como las transacciones distribuidas de Saga, en lugar de pretender que el problema no existe.

Y seguimiento. Cuando se ejecutan docenas de servicios, el método tradicional de "ver el registro general" es básicamente ineficaz. Necesita un panel unificado que pueda ver claramente el estado de la cadena de servicio de un vistazo y rastrear rápidamente dónde una solicitud se está desacelerando o experimentando errores. Esto es fundamental para una rápida resolución de problemas.

Entonces, ¿cómo comienza la historia?

Quizás no sea necesario pensar en reconstruir todo el vasto sistema de una vez. Puede comenzar con una función con límites claros y puntos débiles obvios. Por ejemplo, separe el módulo "administración de registros y alarmas" que cambia con frecuencia en el primer servicio. Experimente la sensación de desarrollo, implementación y expansión independientes. Luego puede haber un "Servicio de derechos de usuario" y luego un "Servicio de accionamiento de motor" específico.

Como construir Lego, pieza a pieza, conectados con interfaces bien definidas. Gradualmente sentirá la libertad: la libertad de selección de tecnología (los nuevos servicios pueden usar lenguajes más apropiados), la libertad de colaboración en equipo (los equipos pequeños se centran en servicios específicos) y la libertad de evolución del sistema.

En este proceso, una persona comokpotenciaLa plataforma tal como está concebida desempeña el papel de fundamento y administrador. Proporciona una forma estandarizada de ejecutar, conectar y monitorear estos bloques de servicios, de modo que no tenga que reinventar la rueda desde cero para lidiar con problemas de infraestructura tediosos pero críticos, como el descubrimiento de servicios, el equilibrio de carga y la recuperación de fallas.

En última instancia, se trata de hacer que la creación sea más fluida. Esto le permite a usted y a su equipo volver a concentrarse en la maquinaria misma (esos exquisitos diseños de transmisión, trayectorias eficientes, integración de hardware estable y confiable) en lugar de verse enredados en el atolladero del acoplamiento del sistema día y noche. Cuando cada parte pueda desempeñar sus funciones de manera constante e inteligente, la vitalidad de todo el proyecto naturalmente será diferente.

Esto no es sólo una actualización tecnológica, sino también una nueva forma de pensar acerca de cómo abordar la complejidad. Su proyecto merece este tipo de claridad y resiliencia.

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