Cuando su sistema de servidor comienza a "hablar": desentrañando los mitos de las API y los microservicios

¿Recuerdas la escena en la que depuraste el brazo robótico la última vez? Esa tarde, miraste los parámetros de salto en el panel de control y de repente te diste cuenta de que la transmisión de cada comando era en realidad como un diálogo preciso. Ahora, cuando hablamos de sistemas de control modernos, este enfoque "conversacional" se está dividiendo silenciosamente en dos escuelas: API y microservicios. Parecen similares, pero desempeñan funciones muy diferentes en el funcionamiento real.

La pregunta es: ¿realmente necesitamos distinguir entre los dos?

Imagínese esto. Diseñas un conjunto de brazos robóticos de seis ejes. Los servos de cada articulación necesitan recibir instrucciones, retroalimentación del estado y coordinar acciones. Si todas las funciones están empaquetadas en un enorme paquete de instrucciones, una vez que es necesario ajustar un determinado enlace, como la mejora de la precisión de la rotación de la muñeca, debe suspender todo el sistema, volver a compilarlo, probarlo e implementarlo. ¿Te resulta familiar esta escena?

Es como utilizar un conjunto fijo de moldes para producir todas las piezas, con una flexibilidad limitada. El dilema que enfrentan muchos equipos es: ¿Qué arquitectura de "diálogo" debería elegirse para que el sistema sea más inteligente y tolerante?

Desmentir mitos: las API no son microservicios y los microservicios son inseparables de las API

Hagamos una analogía simple. API se parece más a un diagrama de cableado estándar, que define cómo conectar el enchufe y cómo transmitir la señal. Los microservicios desmantelan toda la caja de alimentación en módulos independientes: uno para iluminación, otro para motores y otro para sensores. Cada módulo puede funcionar por sí solo y comunicarse con otros módulos a través de interfaces estándar (API).

En el mundo del servocontrol, esta distinción se vuelve concreta. Por ejemplo,kpotenciaDespués de que el sistema de mecanismo de dirección inteligente adopta una arquitectura de microservicio, el monitoreo de temperatura, la retroalimentación de posición y el ajuste de torque se han convertido en servicios independientes. Cuando la carga aumenta repentinamente, el módulo de temperatura puede hacer sonar una alarma individualmente sin interrumpir todo el proceso de control. Este diseño hace que el mantenimiento sea tan intuitivo como el reemplazo de piezas modulares.

¿Por qué esta arquitectura es digna de atención?

Estuve conversando con un líder de proyecto la semana pasada y mencionó un fenómeno interesante: desde que el sistema de control pasó de una única API a una combinación de microservicios, la cantidad de tiempos de inactividad inesperados del sistema se ha reducido en casi un 70 %. "Es como pasar de un circuito en serie a un circuito en paralelo", describió. "Si una bombilla se rompe, las otras luces permanecen encendidas".

Hay varios beneficios prácticos detrás de esto:

• La actualización local no afecta la situación global.: ¿Quiere optimizar el algoritmo PID? Simplemente actualice el servicio del algoritmo de control sin tocar el módulo de planificación de trayectoria de movimiento.
• Las averías se aíslan en "habitaciones pequeñas": Cuando hay un problema con el servicio de comunicación, el servicio de grabación de datos aún puede continuar guardando los datos normales anteriores.
• Las pilas de tecnología se pueden mezclar y combinar: C++ se utiliza para la parte de control en tiempo real y Python se utiliza para el panel de datos; se puede seleccionar la herramienta más adecuada para cada servicio.

¿Cómo elegir?

Esta no es una pregunta de uno u otro. La mayoría de las veces son complementarios. Al igual que cuando se diseña un sistema de transmisión, no solo necesita una interfaz de acoplamiento estándar (API), sino que también debe considerar convertir la conducción, el frenado y la detección en unidades independientes (microservicios).

Varios escenarios prácticos pueden ayudarle a juzgar:

• Si el modelo de su dispositivo es fijo y el ciclo de iteración de la función es largo, una API bien diseñada puede ser suficiente.
• Pero si está desarrollando una plataforma que necesita agregar funciones con frecuencia o conectarse a una variedad de dispositivos de terceros, la arquitectura de microservicio puede brindarle más flexibilidad.

Una vez, un cliente compartió su proceso de transformación: inicialmente, se usaba una única API para administrar toda la línea de ensamblaje, y cada vez que se agregaba o eliminaba una estación de trabajo, se requería una prueba completa. Posteriormente, se adoptó el diseño de microservicios y cada estación de trabajo se convirtió en un servicio independiente. Agregar una nueva estación de inspección visual fue como insertar una nueva tarjeta en la ranura de expansión: se puede integrar en el sistema existente después de configurar la interfaz de comunicación (API).

Las sutilezas al aterrizar.

Por supuesto, cualquier arquitectura tiene un precio. Las características distribuidas que aportan los microservicios requieren consideraciones de coherencia de datos y planificación de red más detalladas. Esto es como cambiar de una lubricación centralizada a un suministro de aceite independiente para cada articulación: hay más puntos de mantenimiento, pero el impacto de las fallas locales es menor.

En la implementación real, los equipos a menudo comienzan a realizar pruebas piloto desde funciones centrales. Por ejemplo, primero divida el control del motor y la retroalimentación de estado en dos servicios para experimentar el proceso de implementación y escalado independientes. Este tipo de transformación gradual suele ser más suave que una reconstrucción única.

Volver a la pregunta original

Por lo tanto, la diferencia entre API y microservicios es esencialmente un plan diferente para el "método de diálogo" del sistema. Uno tiende a desarrollar protocolos de comunicación unificados y completos, mientras que el otro se centra en crear unidades funcionales flexibles y reemplazables.

En el mundo del control de máquinas y servomotores, esta elección afecta el funcionamiento diario del sistema. Determina si cuando un sensor de repente se queda "en silencio", si toda la línea de producción se detiene y espera, o si otros módulos continúan completando acciones ejecutables; también determina cuándo se desea mejorar la precisión de un determinado equipo, si se cierra toda la línea para realizar actualizaciones a altas horas de la noche o si se reemplaza un pequeño módulo durante la pausa del almuerzo.

Una buena arquitectura debe ser como un sistema de transmisión bien diseñado: cada componente tiene una función clara, las conexiones son suaves y confiables, e incluso si es necesario reemplazar engranajes individuales, todo el sistema aún puede mantener el ritmo de operación. Y ésta puede ser la confiabilidad que realmente buscamos detrás de nuestras elecciones tecnológicas.

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.