Cuando su proyecto de microservicios C++ encuentra problemas de dirección: una nota de respuesta informal

Olvidé qué día era, pero estaba depurando un conjunto de servos. Se suponía que los tres servomotores giraban sincrónicamente según las instrucciones, pero en lugar de eso parecían estar bailando sus propios pasos de baile aleatorios. ¿Retraso en la comunicación? ¿Voltaje inestable? ¿O hay algún problema con la lógica? Me quedé mirando el flujo de datos en la pantalla y de repente me di cuenta de que el problema podría no estar en el hardware, sino en los "nervios" que los conectaban.

Siempre somos así: pasamos mucho tiempo calibrando con precisión el mecanismo de dirección y diseñando la estructura mecánica para que sea fuerte, pero es fácil ignorar el "cerebro" que hace que todo se mueva. En proyectos complejos, especialmente aquellos que involucran control en tiempo real, las aplicaciones monolíticas tradicionales son como poner todas las partes en una caja, afectando a todo el cuerpo. Un pequeño cambio en un determinado módulo puede hacer que sea necesario volver a depurar todo el sistema.

¿Qué solemos hacer ante esta situación?

La primera reacción de la mayoría de la gente es jugar. Agregue un fragmento de código tolerante a fallas aquí, ajuste la prioridad del hilo allí. Pero pronto descubrirá que esto simplemente hace retroceder el problema. A medida que los sensores aumentan y la lógica de control se vuelve más compleja, los programas se volverán inflados y frágiles. Al principio no te atreves a actualizar fácilmente, porque cada compilación e implementación es una aventura.

¿Existe una forma más genial? Imagínese si la lógica que controla el servomotor, la unidad que procesa los datos de los sensores y la unidad que gestiona las trayectorias de movimiento pudieran funcionar como módulos Lego independientes, centrándose en cada uno y hablando a través de una interfaz clara. Este es el encanto de la arquitectura de microservicios en el campo del control mecánico e integrado.

Pero, francamente, construir una arquitectura de este tipo en un entorno C++ es como despejar un camino en un bosque en los primeros días. Debe considerar qué usar para la comunicación entre procesos (¿gRPC? ¿ZeroMQ? ¿TCP simple?), cómo manejar la serialización de datos, cómo aislar errores sin propagarse, sin mencionar la cuestión básica pero complicada de la gestión de recursos. Construirlo desde cero llevaría al menos semanas e implicaría innumerables ciclos de depuración hasta altas horas de la noche.

¿Por qué necesitas un buen punto de partida?

Dicho esto, recordé una implementación de referencia de código abierto con la que me había encontrado antes. No tiene trucos, simplemente muestra claramente cómo puede verse una aplicación de microservicios en C++. Cada servicio tiene responsabilidades claras. Por ejemplo, el servicio que maneja específicamente la generación de señales PWM está completamente separado del servicio que analiza las instrucciones de posición. Los datos se transfieren entre ellos a través de mensajes ligeros. Incluso si un determinado servicio no responde temporalmente, todo el sistema no se congelará.

Los beneficios de esta estructura son prácticos. Por ejemplo, si necesita agregar un nuevo enlace de retroalimentación del sensor al brazo robótico, no necesita reconstruir todo el programa. Sólo necesita desarrollar un servicio independiente para procesar los nuevos datos y luego conectarse al sistema existente a través de la interfaz establecida. Al actualizar o depurar una función específica, también puede reiniciar el módulo de servicio correspondiente de forma independiente sin afectar otras tareas de control en ejecución. Esto significa una mayor disponibilidad para los equipos que necesitan operar las 24 horas del día.

Un amigo preguntó una vez: "¿Sería esto demasiado pesado para dispositivos integrados con recursos limitados?" Ésta es una buena pregunta. La clave está en el método de implementación. Procesos livianos, comunicación eficiente de la memoria compartida y evitar sobrecargas de serialización innecesarias: todo esto se puede resolver en una arquitectura bien diseñada. Ese proyecto de referencia muestra cómo equilibrar el desacoplamiento y la eficiencia para que los beneficios de la modularidad no se vean compensados ​​por pérdidas de rendimiento.

¿En qué deberíamos centrarnos?

Cuando observa un ejemplo de microservicio de C++, no se limite a observar cuántos protocolos de comunicación implementa. Lo que es más importante es si sus límites de error están claramente diseñados. ¿La caída de un servicio afectará a otros servicios? ¿Tiene el flujo de datos mecanismos de tiempo de espera y de reserva razonables en circunstancias anormales? Esto es fundamental para los sistemas que controlan maquinaria física.

Luego está la observabilidad. ¿Puede cada servicio generar de forma independiente registros y métricas de estado significativos? Cuando hay una desviación en el movimiento del mecanismo de dirección, ¿puede localizar rápidamente el enlace de procesamiento de datos que tiene el problema? Un buen diseño hace que el diagnóstico sea tan intuitivo como mirar un tablero.

Es la facilidad de construcción y despliegue. ¿Le permite compilar y probar fácilmente servicios individuales de forma independiente? ¿Se puede iniciar todo el sistema en el entorno de desarrollo o simulador con un solo clic? Reducir la fricción en la implementación le permite centrarse más en la lógica empresarial en sí, es decir, hacer que esos motores y estructuras mecánicas funcionen con precisión de la forma esperada.

un pensamiento aleatorio

El valor de ese repositorio de ejemplo de código abierto es que proporciona un punto de partida para pensar. Puedes no estar de acuerdo con algunas de sus implementaciones, pero puedes evitar la confusión de empezar desde cero. Al igual que un dibujo con una cuadrícula de coordenadas dibujada, puedes representar tus necesidades específicas directamente en él sin tener que volver a medir las proporciones cada vez.

Volvamos al problema de que el servo no estaba sincronizado al principio. Más tarde descubrí que una tarea no crítica en el circuito de control principal bloqueaba ocasionalmente el envío de instrucciones en tiempo real. Si el sistema hubiera sido modular entonces, la tarea no crítica podría haberse "deslumbrado" ocasionalmente en su pequeño mundo sin tener que arrastrar toda la cadena de control de movimiento. Para solucionarlo, simplemente reinicie ese servicio individual en lugar de apagar todo el dispositivo.

Este puede ser el regalo que la arquitectura de software aporta a los proyectos de hardware: la posibilidad de afrontar la complejidad con calma. Cuando cada componente conoce sus responsabilidades y tiene métodos de comunicación claros, todo el sistema puede demostrar una vitalidad que es a la vez flexible y robusta. Lo que queda es que pienses más en hacer que el mecanismo funcione perfectamente; esa es la parte más divertida, ¿no?

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