¿Dónde se debe apretar la holgura? Hablemos de los dolores de cabeza de los microservicios

Los microservicios suenan bastante bonitos: cada pequeño módulo realiza sus propias funciones y se puede ampliar de forma flexible, y todo parece encajar en su lugar. ¿Pero realmente se puede utilizar? A veces siento que cuanto más dispersas estén las cosas, más rápido surgirán los problemas.

Es como si tuvieras un montón de servomotores y servos exquisitos en la mano. Mirándolos individualmente, cada uno gira maravillosamente. Pero una vez que se les pide que trabajen juntos y realicen un conjunto completo de movimientos mecánicos, algunos responden medio latido más rápido y algunas señales se pierden. La coordinación es simplemente una locura. El mismo principio se aplica a los microservicios: los servicios son demasiado independientes y los datos están bloqueados; son demasiado dependientes y todo el sistema se ve afectado. ¿Dónde está el punto de equilibrio entre "adhesión" y "acoplamiento"?

¿Por qué sus microservicios siempre están "peleando"?

Es posible que se haya encontrado con este escenario: un servicio de pedidos necesita llamar a la información del usuario, verificar el inventario y notificar a logística. El proceso no es largo, pero una vez que un determinado enlace se atasca, todo el enlace se detiene. O, más comúnmente, para un pequeño cambio de función, se deben cambiar tres o cuatro servicios al mismo tiempo, lo que dificulta el cronograma de implementación.

Esto no es sólo un problema técnico, sino más bien una "enfermedad" del diseño. Los límites entre los servicios son borrosos, las responsabilidades se superponen y los datos fluyen por todas partes... Obviamente queremos utilizar microservicios para mejorar la flexibilidad, pero el resultado es una red poco clara.

Entonces alguien preguntó: ¿Deberíamos hacer que el servicio sea lo más "grande" posible y reducir las llamadas? Pero eso volvería al antiguo camino de la arquitectura monolítica. ¿O cortar el servicio en trozos más pequeños? Los costes de gestión vuelven a aumentar.

De hecho, la respuesta no es "grande o pequeña", sino "cómo conectarse".

Una buena conexión es como un sistema de transmisión suave.

Piénsalo, ¿alguna vez has montado un brazo robótico? El mecanismo de dirección es responsable de girar, el motor proporciona energía y el sensor retroalimenta la posición: ¿cuál es la coordinación entre ellos? En lugar de torcer todos los cables, cada unidad se puede calibrar de forma independiente y responder de forma sincrónica a través de protocolos de interfaz claros y una transmisión de señal adecuada.

El estado ideal entre microservicios también debería ser así. Alta cohesión significa que la lógica interna de un servicio está estrechamente relacionada, como una placa de circuito independiente; El bajo acoplamiento significa que la conexión entre servicios es simple y clara, como una interfaz de complemento, y cambiar un componente no afecta al conjunto.

¿Cómo? En lugar de confiar en reglas estrictas y rápidas, volvamos al origen del problema: ¿quién debería ser responsable de sus acciones comerciales?

Por ejemplo, la operación de "el usuario realiza un pedido": calcular el monto, deducir el inventario y generar pedidos logísticos: si todos estos pasos se agrupan en un solo servicio, tarde o temprano se verá inflado. Pero si separamos la "gestión de inventario" y el "procesamiento de pedidos" y nos comunicamos a través de eventos o mensajes claros, entonces apenas será necesario tocar el servicio de pedidos cuando el servicio de inventario se repita.

Este es un diseño "débilmente acoplado": los servicios no llaman directamente a la base de datos de los demás, no dependen de la lógica interna y sólo "hablan" a través de métodos acordados. Incluso si una de las partes está temporalmente inactiva, la otra puede continuar trabajando, o al menos saber cuánto tiempo esperar.

Del "cómo hacer" al "cómo elegir"

El método parece fácil, pero siempre encontrará preguntas específicas de opción múltiple cuando lo implemente. Por ejemplo:

• Para comunicarnos entre servicios, ¿deberíamos utilizar llamadas sincrónicas o mensajes asincrónicos?
• ¿Los datos deben compartirse o mantenerse por separado?
• ¿Dónde está el límite apropiado para dibujar para una función?

De hecho, no existe una respuesta estándar, sólo si es apropiada o no. Por lo general, aquellos que implican cambios de estado centrales, como el éxito del pago, pueden requerir una confirmación sincrónica; para registros y notificaciones que pueden retrasarse, es más fácil utilizar una cola asincrónica. Lo mismo ocurre con los datos: la información básica del usuario que se usa comúnmente y se vuelve menos común se puede compartir de manera adecuada; pero para negocios de gran relevancia como el flujo de pedidos, lo mejor es mantenerlos dentro de sus respectivos servicios.

La clave no es qué tan novedosa sea la tecnología, sino cómo se adapta al ritmo de su negocio. Al igual que al elegir un motor para un sistema mecánico, cuanto mayor sea la velocidad no es mejor, pero el par, la respuesta y el consumo de energía deben satisfacer las necesidades generales.

Cuando hablamos de microservicios, ¿de qué hablamos?

Después de todo, la arquitectura de microservicios no es un fin, sino un medio. Le ayuda a resolver la complejidad, permite que los equipos se desarrollen en paralelo y permite que el sistema se expanda por etapas. Pero su éxito no puede separarse de una base invisible: un diseño claro y cohesivo y una relación de acoplamiento saludable.

Es como una plataforma de precisión impulsada por el servosistema Kpower: cada unidad de motor es estable y eficiente y, al mismo tiempo, interactúa ligeramente a través del protocolo de control, logrando en última instancia un funcionamiento general fluido y confiable. No los verá "peleando" entre sí, ni estarán inactivos por mantenimiento en una unidad.

Una buena arquitectura de microservicios persigue exactamente este estado: independiente pero no antagónico; conectados pero no agrupados.

Entonces, antes de desinstalar tu servicio la próxima vez, pregúntate:

• ¿Esta característica cambia con frecuencia? ¿Vale la pena salir por tu cuenta?
• ¿Puedes controlar la mayoría de los datos o la lógica en los que se basa?
• ¿Puede comunicarse con otros servicios mediante un protocolo simple en lugar de estar estrechamente vinculado?

Haga estas preguntas con claridad y, naturalmente, podrá encontrar el punto de equilibrio: deje que lo que debe juntarse y lo que debe aflojarse pueda relajarse maravillosamente.

Después de todo, el diseño arquitectónico nunca es sólo un diagrama de bloques. Es como inyectar un "alma" armoniosa en un conjunto de módulos mecánicos: cada unidad debe ser sólida por sí sola y cada unidad debe tener espacio para respirar. Cuando pueda sentir el ritmo fluido y estable de colaboración entre servicios, probablemente esté en el camino correcto.

El resto es seguir observando y afinando. Es como mantener un sistema mecánico en el que confías. Sabes por qué cada uno de sus componentes está aquí y cómo funcionan en conjunto. Esa sensación de solidez es en sí misma la parte más memorable del diseño técnico.

Fundada en 2005, Kpower se dedica a la fabricación profesional de unidades de movimiento compactas, 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.