Cómo funcionan juntos los microservicios – Linux.com

Este artículo apareció originalmente en el blog de capacitación y certificación de la Fundación Linux. El autor es Marco Fioretti. Si está interesado en obtener más información sobre los microservicios, considere algunos de nuestros cursos de capacitación gratuitos, que incluyen Introducción a las tecnologías de infraestructura en la nube, Creación de plataformas de microservicios con TARS y Actores de WebAssembly: de la nube al perímetro. Los microservicios permiten a los desarrolladores de software diseñar aplicaciones basadas en Internet altamente escalables y altamente tolerantes a fallas. Pero, ¿cómo se comunican realmente los microservicios de una plataforma? ¿Cómo coordinan sus actividades o saben con quién trabajar en primer lugar? Aquí presentamos las principales respuestas a estas preguntas y sus principales características y desventajas. Antes de profundizar en este tema, primero debe leer las partes anteriores de esta serie: Microservicios: definición y aplicaciones principales, API en microservicios e Introducción a la seguridad de microservicios.

Acoplamiento cercano, orquestación y coreografía.

Si cada microservicio puede y debe comunicarse directamente con todos sus microservicios asociados sin intermediarios, tenemos lo que se conoce como acoplamiento estrecho. El resultado puede ser muy eficiente, pero hace que todos los microservicios sean más complejos y difíciles de cambiar o escalar. Además, si uno de los microservicios se rompe, todo se rompe. La primera forma de superar estas desventajas del acoplamiento estrecho es tener un controlador central para todos, o al menos algunos, de los microservicios de una plataforma, haciéndolos funcionar en sincronía, como el director de una orquesta. En esta orquestación, también llamada patrón de solicitud/respuesta, es el director quien hace las solicitudes, recibe sus respuestas y luego decide qué hacer a continuación; es decir, ya sea para realizar más solicitudes a otros microservicios o para compartir los resultados de ese trabajo con usuarios externos o aplicaciones cliente. El enfoque complementario a la orquestación es la arquitectura descentralizada llamada coreografía. Este consta de múltiples microservicios que funcionan de forma independiente, cada uno con sus propias responsabilidades, pero como bailarines en un mismo ballet. En la coreografía, la coordinación tiene lugar sin supervisión central a través de mensajes que fluyen entre múltiples microservicios según reglas comunes predefinidas. Esta mensajería, además de determinar qué microservicios están disponibles y cómo comunicarse con ellos, se realiza a través de buses de eventos. Estos son componentes de software con API bien definidas para suscribirse y darse de baja de eventos y para publicar eventos. Estos buses de eventos se pueden implementar de diversas formas para intercambiar mensajes utilizando estándares como XML, SOAP o Lenguaje de descripción de servicios web (WSDL). Cuando un microservicio envía un mensaje en un bus, todos los microservicios que se han suscrito para escuchar en el bus de eventos correspondiente lo ven y saben si deben responderlo de forma asincrónica, individualmente y sin ningún orden en particular. En esta arquitectura basada en eventos, un desarrollador solo necesita codificar los comandos de suscripción para los buses de eventos en los que generar o esperar eventos en un microservicio para interactuar con el resto de la plataforma.

¿Orquestación o coreografía? Depende de

Las dos formas más populares de coordinar microservicios son la coreografía y la orquestación, cuya diferencia fundamental es dónde colocan el control: uno lo distribuye a los microservicios del mismo nivel que se comunican de forma asíncrona, el otro a un líder central que mantiene a todos los demás al tanto. Cuál es mejor depende de las características, las necesidades y los patrones de uso del mundo real de cada plataforma, con quizás solo dos reglas que se aplican en todos los casos. En primer lugar, casi siempre se debe evitar el acoplamiento estrecho real, ya que contradice la idea misma de los microservicios. El bajo acoplamiento con la comunicación asíncrona encaja mucho mejor con las ventajas fundamentales de los microservicios, a saber, el despliegue independiente y la máxima escalabilidad. Sin embargo, el mundo real es un poco más complejo, así que digamos algunas palabras más sobre los pros y los contras de cada enfoque. En términos de orquestación, quizás el principal inconveniente es que el control centralizado es a menudo, si no sinónimo, al menos un atajo a un único punto de falla. Una desventaja mucho más común de la orquestación es que, a menos que la conectividad sea real, el rendimiento puede verse afectado de manera más o menos impredecible, ya que los microservicios y un conductor pueden residir en diferentes servidores o nubes, solo conectados a través de la Internet pública excelente. En otro nivel, cuando se trata de orquestación, prácticamente cualquier adición de microservicios o cambios en sus flujos de trabajo pueden requerir cambios en muchas partes de la plataforma, no solo en el conductor. Lo mismo se aplica a las fallas: cuando un microservicio orquestado falla, generalmente ocurren efectos en cascada: por ejemplo, otros microservicios esperan recibir comandos solo porque el conductor está esperando temporalmente las respuestas del fallido. En el lado positivo, precisamente porque la «cadena de mando» y las comunicaciones están bien definidas y no son realmente flexibles, será relativamente fácil averiguar qué se rompió dónde. Por la misma razón, la orquestación facilita la prueba de diferentes funciones de forma independiente. En consecuencia, la orquestación puede ser el camino a seguir siempre que los flujos de comunicación dentro de una plataforma basada en microservicios estén bien definidos y sean relativamente estables. En muchos otros casos, la coreografía puede proporcionar el mejor equilibrio entre la independencia de los microservicios individuales, la eficiencia general y la facilidad de desarrollo. Con la coreografía, un servicio solo necesita emitir eventos, es decir, notificaciones de que algo sucedió (por ejemplo, se recibió una solicitud de inicio de sesión), y todos sus microservicios posteriores solo necesitan reaccionar ante ellos de forma autónoma. Por lo tanto, cambiar un microservicio no afecta a los que están aguas arriba. Incluso agregar o eliminar microservicios es más fácil que con la orquestación. La desventaja de esta moneda es que, al menos cuando se hace sin precauciones, hay más oportunidades de que las cosas salgan mal, en más lugares y de maneras que son más difíciles de predecir, probar o depurar. Lanzar mensajes a Internet, confiando en que todo está bien, pero sin ninguna forma de saber que todos sus destinatarios lo recibieron y todos pudieron responder correctamente, puede dificultar mucho la vida de los integradores de sistemas.

Conclusión

Ciertos flujos de trabajo son inherentemente altamente sincrónicos y predecibles. Otros no lo son. Esto significa que muchas plataformas de microservicios del mundo real podrían, y probablemente deberían, combinar ambos enfoques para obtener la mejor combinación de rendimiento y resistencia a fallas o picos. Debido a que los picos de carga temporales, que pueden administrarse mejor coreográficamente, pueden ocurrir solo en ciertas partes de una plataforma, y ​​las interrupciones trascendentales, para las cuales una orquestación más estricta podría ser más segura, solo en otros (por ejemplo, productos de clientes finales, versus pedidos al mismo Buy productos a granel para reponer stock). Para los arquitectos de sistemas, quizás lo peor que podría pasar es diseñar una arquitectura que sea orquestación o coreografía sin ser realmente conscientes (quizás porque solo están transfiriendo una plataforma monolítica ya existente a los microservicios) a la que pertenece. Por lo tanto, hay sorpresas desagradables cuando algo sale mal o los nuevos requisitos resultan mucho más difíciles de diseñar o probar de lo esperado. Lo que lleva a la segunda de las dos reglas generales anteriores: ni siquiera comience a elegir entre orquestar o coreografiar sus microservicios hasta que tenga la mejor estimación posible de sus cargas y necesidades de comunicación en el mundo real.