Cuando tu proyecto está estancado en el debate de "microservicios o monolito"

Imagínese: la reunión del equipo ha entrado en la tercera hora, la pizarra está llena de cuadros y flechas, se ha bebido el café, pero el debate sobre arquitectura no ha cesado: "¡Los microservicios son más flexibles!" "¡Pero el despliegue monolítico es más sencillo!" En este momento, ¿quiere simplemente algo que realmente pueda moverse, en lugar de quedarse en debates teóricos?

A menudo pensamos que la selección de tecnología es una cuestión puramente de software, pero cuando realmente comienzas a construir productos, encontrarás que los actuadores en el mundo físico, como servos precisos y servomotores confiables, suelen ser las manos que hacen que las ideas se hagan realidad. No importa qué arquitectura se utilice en el backend, lo que el usuario final siente es si la parte mecánica es fluida y si la respuesta es oportuna.

¿Por qué el rendimiento del hardware debería influir en sus decisiones de software?

Alguien me preguntó: "Usamos microservicios en el backend. ¿Debería dividirse la parte de control del motor también en módulos independientes?" De hecho, no es necesario copiarlo mecánicamente. La arquitectura del software resuelve problemas de escalabilidad y mantenibilidad, mientras que la selección del hardware se centra en la precisión, el par y la velocidad de respuesta. Por ejemplo, si diseña un dispositivo de visualización automatizado, el software se puede actualizar de forma iterativa con frecuencia, pero el mecanismo de dirección interno es preciso la primera vez: no tiene posibilidad de "actualización en caliente".

kpotenciaSe descubrió un fenómeno interesante al abordar este tipo de proyectos: muchos equipos pasan mucho tiempo debatiendo la arquitectura del software, pero por defecto "siempre habrá una manera" en la parte del hardware. El resultado suele ser un sistema bellamente diseñado, pero la experiencia general se ve comprometida debido a la falta de precisión de los actuadores mecánicos.

Entonces, ¿cómo salir de este ciclo?

Piense claramente qué acciones desea primero y luego analice qué estructura se necesita.

Por ejemplo, si crea un dispositivo de visualización interactivo:

• ¿Necesita un ajuste rápido de ángulo pequeño? Entonces la velocidad de reacción es la clave.
• ¿Necesitas levantar una cierta cantidad de peso sin problemas? Que el par y la estabilidad son más importantes
• ¿Necesita funcionar continuamente durante mucho tiempo? Se debe priorizar la durabilidad y la disipación de calor.

Estos determinan qué motor elegir y también afectan indirectamente el diseño del software de la parte de control. Un motor que requiere un alto control en tiempo real puede ser más adecuado para un acoplamiento estrecho con el controlador; Para escenarios que requieren alta precisión pero no requisitos extremos en tiempo real, un enfoque de microservicio a través de llamadas API puede ser más sencillo.

Respuestas a preguntas frecuentes

"Tenemos un presupuesto limitado. ¿Deberíamos conformarnos primero con motores baratos y actualizarlos después?" Esto es un poco como construir un edificio alto con andamios endebles: un reemplazo posterior a menudo significa rediseñar la estructura.kpotenciaUna vez, los ingenieros ayudaron a un equipo a planificar: originalmente planearon usar motores de bajo costo para verificar la idea primero, pero la prueba encontró que el error de precisión hizo que todo el sistema de retroalimentación no pudiera calibrarse. Posteriormente, se volvió a seleccionar el modelo, lo que aumentó el costo inicial en un 15%, pero ahorró al menos dos meses de reajuste del sistema.

"Bajo la arquitectura de microservicios, ¿cómo debería diseñarse la parte de control de hardware?" No es necesario tener microservicios por el bien de los "microservicios". Trate la parte que interactúa directamente con el hardware como un límite de servicio independiente y defina la interfaz en función de las características de respuesta del hardware. Si un motor requiere una respuesta de milisegundos, no permita que pase por demasiadas capas de servicio. La arquitectura sirve a objetivos, no al revés.

Detalles invisibles, resultados visibles

El año pasado, un equipo creó un sistema de demostración de almacenamiento inteligente. La arquitectura del software era elegante y hermosa. Sin embargo, durante la demostración in situ, el servo de manejo siempre vibró ligeramente en posiciones clave. El problema no es la lógica del software, sino la falta de estabilidad del motor a bajas velocidades. Posteriormente cambiaron a un modelo más adecuado para escenarios de baja velocidad y el problema desapareció.

Este tipo de cosas no es infrecuente. Se dedica mucho tiempo a diseñar divisiones de servicios, bases de datos y definiciones de interfaces perfectas, pero la sensación más intuitiva para los usuarios suele ser si el brazo robótico es suave, si la plataforma giratoria es silenciosa y si el posicionamiento es preciso.

Entonces, la próxima vez que tengas una reunión...

Cuando la discusión caiga en el ciclo de "qué arquitectura es mejor", intente cambiar la pregunta: "¿Qué movimiento físico queremos lograr? ¿Qué tan rápido, preciso y poderoso debe ser este movimiento?"

La respuesta suele ser mucho más clara. La arquitectura del software se puede ajustar y reconstruir continuamente, pero una vez que se integra el hardware, el costo de reemplazo es mucho mayor. Primero ancle los indicadores centrales del hardware y luego deje que la arquitectura del software los iguale, y no al revés.

Las buenas decisiones técnicas no consisten en elegir una respuesta “correcta”, sino en dejar que cada parte haga lo que mejor sabe hacer. El motor es responsable de la ejecución precisa, el software es responsable de la programación flexible y su equipo es responsable de crear valor; de esta manera, no importa si el backend es un microservicio o un monolito, el front-end presenta a los usuarios una experiencia fluida y confiable.

En última instancia, a los usuarios no les importa qué tan detallado sea su servicio, solo les importa que el producto funcione como se espera. El paso que hace realidad las expectativas comienza a menudo con un motor adecuado.

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.