¿Por qué todo el mundo utiliza microservicios? ¿Es realmente tan útil?

Imagina que estás construyendo un robot complejo. Si todas las piezas están soldadas a una placa de circuito, una vez que un motor pequeño se estropea, es posible que tengas que desmontar toda la máquina y empezar de nuevo, lo que requiere mucho tiempo, trabajo y es fácil involucrar otras piezas intactas. Pero ¿qué pasa si cada articulación y cada sensor se forman independientemente en un pequeño módulo? Reemplazarlos es tan fácil como juntar bloques. Probablemente esta sea la razón por la que la arquitectura de microservicios ha cambiado silenciosamente muchas ideas de diseño de sistemas.

¿Cuál es el problema?

En el pasado, muchos programas eran como un gran bloque de hierro. Todas las funciones están abarrotadas y un movimiento afecta a todo el cuerpo. ¿Quieres actualizar una pequeña característica? Es necesario volver a implementar todo el sistema. ¿Un aumento repentino del tráfico? Sólo se puede ampliar en su conjunto, aunque sólo una pequeña parte necesite realmente recursos. Sin mencionar la selección técnica: una vez que se selecciona el marco, puede "bloquearse" en los próximos años y es difícil cambiar incluso una pequeña parte del mismo.

Es como si tuvieras un brazo robótico parecido a un pulpo con el mismo conjunto de motores y el mismo controlador para cada articulación. Se ve bien, pero cuando quieres flexibilizar tus muñecas y fortalecer tus codos, descubres que no tienes forma de empezar.

¿Qué diferencia aportan los microservicios?

El primer atractivo: la independencia.

Cada microservicio es como un volante independiente en la máquina, solo responsable de sus propias acciones: la administración de usuarios solo se encarga de la verificación del inicio de sesión y el servicio de pedidos solo se encarga del proceso de transacción. Se comunican entre sí a través de interfaces livianas, y quien las rompa las actualizará sin arrastrar a los demás. ¿Le gustaría reescribir uno de estos en un nuevo lenguaje de programación hoy? casual. Mientras pueda "saludar" a sus vecinos, otros servicios no sentirán ningún cambio.

La segunda característica: escalamiento elástico.

Cuando el número de visitas aumenta, en lugar de reemplazar toda la máquina por una más grande, sólo "añade músculo" a las partes que están bajo alta presión. Por ejemplo, si el servicio de pedidos está demasiado ocupado durante la temporada de promoción, implemente algunos microservicios de pedidos más; Si el módulo de retrato de usuario está inactivo, déjelo como está. La utilización de recursos es más refinada y los costos son más fáciles de controlar.

El tercer encanto: la libertad técnica.

Nadie estipula que todos los servicios deban desarrollarse con las mismas herramientas. Algunos son adecuados para una iteración rápida en Python y otros requieren que Java maneje una alta concurrencia. La base de datos también se puede seleccionar según demanda: esta usa MySQL, aquella usa MongoDB. Los equipos pueden elegir la pila de tecnología más conveniente para los servicios de los que son responsables, al igual que seleccionar el modelo de motor más apropiado para cada articulación de un brazo robótico, y ya no están limitados por "una talla única".

Entonces, ¿hay algún dolor de cabeza en esto?

Por supuesto que sí. Con tantos servicios, la coordinación se convierte en un desafío. En el pasado, se llamaba a una solicitud entre funciones internas, pero ahora puede abarcar varios servicios en la red. Esto provoca problemas de latencia, problemas de confiabilidad de la red y coherencia de los datos: el servicio A tiene éxito, pero el servicio B falla, ¿cómo revertirlo? El seguimiento y la depuración también se han vuelto más complicados. Es necesario tener un mapa de servicios claro para saber qué caminos han tomado las solicitudes.

Es como gestionar un escuadrón de robots. Es fantástico que cada miembro del equipo pueda trabajar de forma independiente, pero se necesita una buena cadena de mando, protocolos de comunicación claros y un mecanismo para que la misión general continúe si un miembro del equipo falla.

¿Qué es lo que realmente le importa a la gente cuando elige?

Algunas personas pueden preguntar: ¿Es necesario dividir el sistema en microservicios? no necesariamente. Si su negocio es simple y estable, una aplicación holística será más sencilla. Los microservicios son populares en escenarios en los que el negocio está cambiando, el tamaño del equipo se está expandiendo y se requiere prueba y error rápidos y una implementación independiente.

Lo que en realidad refleja es una especie de pensamiento: utilizar componentes modulares y reemplazables para construir un sistema flexible. Al igual que cuando hacemos diseño mecánico, no soldaremos todas las transmisiones al mismo chasis. Reservarás interfaces y estandarizarás protocolos para que cada unidad pueda operar de forma independiente y colaborativa.

¿En qué se parece esto extrañamente al diseño de hardware?

Las personas que hayan jugado con servos o servomotores pueden tener algo de experiencia. Un buen diseño modular no comprime todos los circuitos en una sola placa, sino que permite que la fuente de alimentación, el control y la detección formen módulos separados y los conecten a través de interfaces claras. De esta manera, al depurar el motor, el sensor no se quemará accidentalmente; Al actualizar el control, solo necesita reemplazar la placa central sin volver a cablear.

Lo mismo ocurre con la idea de los microservicios: "hardware" del software. Cada servicio es como un módulo de circuito con funciones claras y pines de entrada y salida (API) claros. La implementación interna se puede actualizar o incluso reemplazar continuamente. Mientras las definiciones de los pines permanezcan sin cambios, el sistema puede evolucionar sin problemas.

Entonces, ¿en qué escenas brilla realmente?

Cuando su empresa necesita lanzar rápidamente nuevas funciones y los ciclos de vida de las diferentes funciones varían mucho; cuando el tamaño del equipo crece y usted espera que varios grupos puedan desarrollar, probar y conectarse en línea de forma independiente; cuando el sistema necesita hacer frente a un tráfico desigual, y algunas partes están bajo gran presión y otras están inactivas, surgen las ventajas de los microservicios.

Descompone la "gran máquina" en "colaboración en equipos pequeños". Cada servicio se centra en una cosa y se comunica de forma estandarizada, pero el conjunto puede alcanzar objetivos complejos. Esto requiere un pensamiento de diseño inicial y un buen soporte de infraestructura, pero una vez que está en funcionamiento, la adaptabilidad y evolución del sistema tienden a ser mucho más rápidas.

Al igual que un dispositivo mecánico sofisticado, un sistema verdaderamente confiable y flexible suele estar compuesto por muchos módulos dedicados. Los microservicios son populares no porque sean perfectos, sino porque responden a una necesidad constante: cómo mantener los sistemas ágiles y resilientes en medio de los cambios. No es una solución milagrosa, sino un conjunto de herramientas de pensamiento que permiten iterar, reemplazar y actualizar el software como si fueran módulos de hardware. La próxima vez que diseñe un sistema, tal vez piense en ello: si lo considera un conjunto de unidades independientes que cooperan entre sí, ¿habrá nuevas posibilidades?

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.