diferencia entre microservicios y resto api

¿Cuál es la diferencia entre microservicios y API REST? hablemos

Imagina que estás construyendo un robot. Cada articulación requiere un servo independiente para controlar la rotación, y estos servos deben coordinarse entre sí para transmitir señales. En ese momento, alguien le sugirió: ¿Qué tal si coloca todos los circuitos de control en una caja y los cablea de manera uniforme? ¿O deberíamos equipar a cada servo con un pequeño controlador inteligente, dejarles realizar sus respectivas tareas y luego comunicarse de una manera simple y universal?

¿Te suena esta pregunta? De hecho, en el mundo del software esta confusión ocurre todos los días. Así es, estamos hablando de las palabras "microservicios" y "API REST" que a menudo se confunden. Muchas personas no entienden la diferencia entre ellos e incluso piensan que son lo mismo. ¿El resultado? Al diseñar el sistema, siempre siento que algo anda mal y mantenerlo más tarde me parece como desentrañar un desastre.

Entonces, charlemos informalmente hoy y eliminemos esto del camino. No te preocupes por la terminología, solo hablaremos en lengua vernácula.

Primero descúbrelo: ¿quiénes son?

Usemos una analogía. Entras en un gran restaurante. Si esta tienda tiene una arquitectura de "microservicio", el chef se puede dividir en varios grupos independientes: el grupo de embutidos solo se centra en ensaladas, el grupo de barbacoa se centra en la barbacoa y el grupo de postres se centra en la elaboración de tartas. Cada equipo tiene su propio espacio de cocina, herramientas y flujos de trabajo dedicados, y se comunican las necesidades entre sí a través de una hoja de papel estándar, como un formulario de pedido. Este "sistema de notas en papel" es como una API REST.

¿Ves el camino? Los microservicios son una idea arquitectónica: dividen una aplicación grande en muchos servicios pequeños que se ejecutan de forma independiente y se centran en funciones específicas, como esos grupos en un restaurante con una clara división del trabajo. Cada servicio se ocupa de su propio negocio y puede desarrollarse, implementarse e incluso reiniciarse de forma independiente sin afectar a otras partes. La API REST es un protocolo de comunicación, una "forma de hablar" basada en HTTP acordada entre servicios, al igual que la nota de pedido en formato estándar.

En pocas palabras, los microservicios son una estructura de equipo de "divide y vencerás", y la API REST es el "lenguaje de comunicación" común dentro del equipo. Puede utilizar la API REST para conectar microservicios, pero la API REST también se puede utilizar en otras arquitecturas. No es exclusivo de los microservicios.

Entonces ¿por qué separarse? ¿Cuál es el beneficio?

Quizás quieras preguntar: ¿no sería bueno tener una aplicación “grande monolítica” que empaquete todo el código en un mismo paquete? ¿Por qué tomarse la molestia de dividirlo?

Piensa en tu robot. Si toda la lógica de control está comprimida en una placa base, una vez que desee actualizar una determinada articulación, es posible que deba detener todo el robot, reescribirlo, probarlo y luego implementarlo. Sin mencionar los problemas, los riesgos también son altos. Pero si utiliza un microcontrolador independiente (microservicio) para cada articulación (módulo funcional), la situación cambia. Puede actualizar la lógica de agarre del manipulador de forma independiente sin afectar en absoluto el módulo de movimiento del chasis. Todo el sistema se vuelve más flexible y robusto.

"Pero", murmurará alguien, "si los servicios se dividen, ¿cómo podrán comunicarse entre sí de forma fiable?" Esto se remonta a lo que llamamos "lenguaje de comunicación". La razón por la que REST API es popular es que es simple y universal, como el mandarín en el mundo de Internet. Utiliza las acciones comunes del protocolo HTTP: GET (obtener), POST (crear), PUT (actualizar), DELETE (eliminar) para transmitir intenciones. Cuando el servicio A necesita datos, envía una solicitud HTTP claramente formateada al servicio B, y el servicio B devuelve un paquete de datos en un formato estándar (normalmente JSON). Claro y fácil de usar para desarrolladores.

¿Cómo los utilizamos?

existirkpotencia, hemos estado expuestos a muchos escenarios de integración. Por ejemplo, hay un proyecto que requiere que el sistema de control central programe de manera flexible docenas de tipos diferentes de servomotores y, al mismo tiempo, proporcione información sobre el estado en tiempo real. El plan inicial era escribir toda la lógica de control en un programa gigante. ¿Cuál fue el resultado? Cada vez que se añadía un nuevo modelo de motor, el código temblaba y los ciclos de prueba eran dolorosamente largos.

Más tarde, cambié a la arquitectura de microservicios. Dividimos las funciones de control de motores, monitoreo de estado, diagnóstico de fallas e inicio de sesión en pequeños servicios independientes. Cada servicio se centra en hacer bien una cosa. ¿Cómo se hablan entre ellos? Esto se logra a través de una API REST bien diseñada y claramente documentada. Por ejemplo, si el servicio de monitoreo de estado desea conocer el torque en tiempo real del motor número 3, envía una solicitud GET /api/motors/3/torque al servicio de control del motor e inmediatamente obtiene una cadena de datos clara. ¿Actualizar diagnósticos? Mientras el servicio de diagnóstico esté habilitado, todo lo demás se ejecutará como de costumbre.

Este modelo acelera las iteraciones y reduce el acoplamiento entre equipos. El colega responsable del control motor puede concentrarse en su trabajo. Siempre que cumpla con el "contrato de comunicación" API acordado de antemano, no teme afectar otros módulos.

¿A qué debes prestar atención al elegir?

Entonces, si estás pensando en estructurar tu propio proyecto, no te limites a mirar palabras de moda. Pregúntate:

• ¿Su sistema es complejo? ¿Algunas piezas se ampliarán o cambiarán con frecuencia en el futuro? (Si es así, la independencia de una arquitectura de microservicios puede ser una ventaja).
• ¿Cómo es la estructura de tu equipo? ¿Es adecuado que varios equipos pequeños desarrollen diferentes módulos en paralelo?
• ¿Cómo necesitan los servicios comunicarse entre sí? ¿Qué tan altos son los requisitos de confiabilidad y tiempo real? (La API REST es una opción común, pero no la única; a veces una cola de mensajes u otro protocolo es más adecuado).

No existe una respuesta única para todos. Al igual que elegir un servo para un robot, depende de los requisitos de carga, precisión y velocidad de respuesta. Los microservicios y la API REST son una poderosa combinación de herramientas, pero solo si se comprenden sus respectivas funciones se pueden utilizar sin problemas.

Después de todo, la tecnología tiene un propósito. En última instancia, el objetivo de una arquitectura clara y una comunicación eficiente es hacer que el sistema sea más robusto y más fácil de mantener. Al igual que una estructura mecánica precisa, cada componente funciona adecuadamente y se coordina para generar potencia precisa. existirkpotenciaCreemos que desmantelando las cosas claramente y luego conectándolas de la manera más común, a menudo podemos avanzar de manera más constante y más lejos. Espero que este intercambio informal pueda ayudarte a aclarar tus próximos pasos.

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.