Diseño impulsado por dominios y microservicios.

Cuando su sistema de servidor comienza a "enojarse": hablemos de controladores de dominio y microservicios

Imagínese esto: su línea de producción está funcionando a toda velocidad y, de repente, un servo comienza a vibrar y luego todo el brazo robótico comienza a balancearse como si estuviera borracho. Después de verificar durante mucho tiempo, descubrí que el código en cierto módulo de control estaba "peleando": la lógica de monitoreo de temperatura y la trayectoria del movimiento estaban en desacuerdo entre sí, y nadie sintió que fueran más importantes. ¿Te resulta familiar esta escena?

El problema a menudo no está en el hardware.

La primera reacción de muchas personas es: "¿El motor está roto? ¡Reemplácelo!". Pero si lo desarmas con frecuencia, encontrarás que los devanados están intactos y el codificador está normal. El verdadero quid de la cuestión reside en la confusa lógica del software. La arquitectura monolítica tradicional es como guardar todas las herramientas en un cajón: destornilladores, llaves inglesas y cinta adhesiva están todos mezclados y hay que rebuscar entre ellos cada vez que se encuentra algo. Cuanto más complejo sea el sistema, más desordenado estará este cajón, hasta que un día se atasque por completo.

Diseño basado en dominios: proporcione a cada herramienta una caja de herramientas dedicada

El concepto central del diseño basado en dominios (DDD) es en realidad muy práctico: dejar que personas con conocimientos se encarguen de los asuntos profesionales. Por ejemplo, el módulo de control de temperatura solo se preocupa por la disipación de calor y la protección contra el sobrecalentamiento. No necesita conocer los detalles de la trayectoria del movimiento; el módulo de calibración de posición se centra en la compensación de precisión y no necesita preocuparse por las fluctuaciones de voltaje. Es como tener una caja de herramientas dedicada para la línea de producción: la caja del electricista, la caja del maquinista y la caja del programador están divididas en categorías y cada una realiza sus propias funciones.

¿Qué pasa con los microservicios? Puede pensar que cada caja de herramientas tiene su propio administrador. Los administradores se pasan mensajes entre sí a través de interfaces estandarizadas: "Mi temperatura ha alcanzado el valor crítico, ¿pueden reducir la velocidad?" "Recibido, la curva de aceleración ha sido ajustada." No hay reuniones largas, ni procesos de aprobación complicados, solo colaboración eficiente punto a punto.

¿Qué diferencia real puede aportar esta combinación?

Hubo un caso: el retraso de respuesta de un conjunto de manipuladores de seis ejes era originalmente de unos 50 ms, pero ocasionalmente saltaba a 200 ms. Después de la transformación, el control de cada eje se convirtió en un microservicio independiente y el retraso se mantuvo estable en 20 ms. Aún mejor es que cuando es necesario actualizar el módulo de reconocimiento visual, solo es necesario reemplazar una de las "cajas de herramientas", sin necesidad de apagar toda la línea durante tres días para realizar pruebas de compatibilidad.

"¿Pero será más difícil de gestionar si se divide en cantidades demasiado finas?" alguien preguntó.

¡Buena pregunta! Esto implica el arte de trazar límites. DDD aboga por definir territorios a través de "contextos delimitados", tal como dividir las áreas de taller en una fábrica. El control de la transmisión mecánica es un contexto, el procesamiento de señales es otro e interactúan a través de protocolos claros.kpotenciaLa práctica ha demostrado que una división razonable de los límites puede hacer que el sistema sea como ladrillos de Lego, independiente y fácil de reorganizar.

Varios puntos de observación a la hora de elegir un plan.

Mire la estructura del equipo. Si su equipo de hardware y su equipo de software generalmente dependen de los gritos para comunicarse, entonces es posible que sea necesario combinar los microservicios con un proceso de comunicación; Si el propio equipo colabora estrechamente, el progreso será más fluido.

Mire la frecuencia de los cambios. Los módulos de parámetros que a menudo deben ajustarse (como el control de presión para adaptarse a diferentes materiales) son adecuados para servicios independientes; mientras que aquellos factores subyacentes que no han cambiado durante diez años puede resultar más económico permanecer en una sola entidad.

Piense en los requisitos de tolerancia a fallos. Un cliente dijo una vez: "Preferiría que una determinada función fuera más lenta que hacer que toda la línea de producción se paralizara". El aislamiento de los microservicios muestra aquí su valor: si hay un problema con un determinado servicio, es como un ajuste temporal de una determinada estación en la línea de montaje, mientras que otras estaciones continúan funcionando como de costumbre.

Sabiduría progresiva al aterrizar

No es necesario reinventar la rueda de la noche a la mañana. Puede comenzar con los módulos que causan la mayoría de los problemas, como el programa de calibración del servomotor que debe depurarse cada semana. Extráigalo a un servicio independiente y utilice una interfaz clara para hablar con el sistema principal. Después de tres meses, es posible que descubra que el tiempo de depuración se ha reducido de medio día a una hora.

Luego abordará aquellas funciones que afectan a todo el cuerpo, como la lógica de sincronización y coordinación que involucra múltiples sensores. Después de ser independiente, puede reescribirlo en un lenguaje más adecuado (como C ++ para requisitos elevados en tiempo real, Go para lógica empresarial compleja) sin preocuparse por afectar otros módulos.

Retos y respuestas inevitables

Los sistemas distribuidos introducen nuevos problemas, como la latencia de la red. Pero en entornos industriales, las implementaciones localizadas y las redes dedicadas pueden aliviar esto. Otro desafío es la coherencia de los datos: cuando varios servicios necesitan compartir estado,kpotenciaEl modelo de seguimiento de eventos se utiliza a menudo: cada cambio de estado se registra como un evento y los servicios se suscriben según demanda, al igual que el registro del flujo de órdenes de trabajo en la línea de producción, que se puede rastrear en cualquier momento.

En última instancia, la esencia de la arquitectura tecnológica es gestionar la complejidad. El diseño basado en dominio le ayuda a aclarar los límites lógicos y los microservicios proporcionan medios de aislamiento físico. Su combinación no es una solución milagrosa, sino que es como equipar maquinaria de precisión con una solución de mantenimiento modular: actualizarla y reemplazarla dondequiera que vaya sin tener que ir a la guerra cada vez.

La próxima vez que vea una anomalía en el equipo, también podría preguntar: "¿Está cansado el hardware o el software está 'luchando'?" Quizás cambiar la forma de pensar y organizar la estructura del código pueda hacer que la máquina vuelva a funcionar sin problemas. Después de todo, lograr que sistemas complejos sigan funcionando de manera confiable siempre ha sido una danza entre el arte y la tecnología.

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.