http - conductor - microservicios orquestacion

Orquestando microservicios (7)

¿Cuál es el patrón estándar de orquestar microservicios?

Si un microservicio solo conoce su propio dominio, pero hay un flujo de datos que requiere que múltiples servicios interactúen de alguna manera, ¿cuál es la forma de hacerlo?

Digamos que tenemos algo como esto:

Facturación
Envío

Y por el bien del argumento, digamos que una vez que se ha enviado un pedido, se debe crear la factura.

En algún lugar, alguien presiona un botón en una GUI, "¡Ya terminé, hagamos esto!" En una arquitectura clásica de servicio monolítico, yo diría que hay un ESB manejando esto, o el servicio de envío tiene conocimiento del servicio de facturación y simplemente llama eso.

Pero, ¿cómo manejan las personas esto en este valiente mundo de microservicios?

Entiendo que esto podría considerarse altamente basado en la opinión. pero tiene un lado concreto, ya que no se supone que los microservicios hagan lo anterior. Por lo tanto, tiene que haber un "qué debería hacer por definición en su lugar", que no se basa en la opinión.

Disparar.

El libro Building Microservices describe en detalle los estilos mencionados por @RogerAlsing en su respuesta.

En la página 43 bajo Orquestación vs Coreografía, el libro dice:

A medida que comenzamos a modelar una lógica cada vez más compleja, tenemos que lidiar con el problema de administrar los procesos comerciales que se extienden a través de los límites de los servicios individuales. Y con microservicios, alcanzaremos este límite antes de lo habitual. [...] Cuando se trata de implementar este flujo, hay dos estilos de arquitectura que podríamos seguir. Con la orquestación, confiamos en un cerebro central para guiar e impulsar el proceso, al igual que el director de una orquesta. Con la coreografía, informamos a cada parte del sistema de su trabajo, y dejamos que resuelva los detalles, como bailarines que encuentran su camino y reaccionan a los demás a su alrededor en un ballet.

El libro luego procede a explicar los dos estilos. El estilo de orquestación corresponde más a la idea SOA de los servicios de orquestación / tareas , mientras que el estilo de coreografía corresponde a los tubos tontos y los puntos finales inteligentes mencionados en el artículo de Martin Fowler.

Estilo de orquestación

Bajo este estilo, el libro anterior menciona:

Pensemos cómo sería una solución de orquestación para este flujo. Aquí, probablemente lo más simple sería hacer que nuestro servicio al cliente actúe como el cerebro central. En la creación, se comunica con el banco de puntos de fidelidad, el servicio de correo electrónico y el servicio postal, [...] a través de una serie de llamadas de solicitud / respuesta. El servicio al cliente en sí mismo puede rastrear dónde se encuentra un cliente en este proceso. Puede verificar si se ha configurado la cuenta del cliente, o si se envió el correo electrónico o si se envió la publicación. Podemos tomar el diagrama de flujo [...] y modelarlo directamente en código. Incluso podríamos usar herramientas que implementen esto para nosotros, tal vez usando un motor de reglas apropiado. Existen herramientas comerciales para este propósito en forma de software de modelado de procesos de negocios. Suponiendo que usemos una solicitud / respuesta sincrónica, incluso podríamos saber si cada etapa ha funcionado [...] La desventaja de este enfoque de orquestación es que el servicio al cliente puede convertirse en una autoridad central de gobierno. Puede convertirse en el centro en medio de una web y en un punto central donde la lógica comienza a vivir. He visto que este enfoque da como resultado una pequeña cantidad de servicios inteligentes de "dios" que le dicen a los servicios anémicos basados en CRUD qué hacer.

Nota: Supongo que cuando el autor menciona herramientas se está refiriendo a algo como BPM (por ejemplo, Activity , Apache ODE , Camunda ). De hecho, el sitio web de patrones de flujo de trabajo tiene un conjunto impresionante de patrones para hacer este tipo de orquestación y también ofrece detalles de evaluación de diferentes herramientas de proveedores que ayudan a implementarlo de esta manera. Sin embargo, no creo que el autor sugiera que se requiere uno para usar una de estas herramientas para implementar este estilo de integración, se podrían usar otros marcos de orquestación livianos, por ejemplo, Spring Integration , Apache Camel o Mule ESB

Sin embargo, otros libros que he leído sobre el tema de Microservicios y, en general, la mayoría de los artículos que he encontrado en la web parecen desfavorecer este enfoque de la orquestación y, en cambio, sugieren usar el siguiente.

Estilo de coreografía

Bajo el estilo de coreografía, el autor dice:

Con un enfoque coreografiado, podríamos simplemente hacer que el servicio al cliente emita un evento de manera asincrónica, diciendo que el Cliente lo creó. El servicio de correo electrónico, el servicio postal y el banco de puntos de fidelidad simplemente se suscriben a estos eventos y reaccionan en consecuencia [...] Este enfoque es significativamente más desacoplado. Si se necesita algún otro servicio para llegar a la creación de un cliente, solo necesita suscribirse a los eventos y hacer su trabajo cuando sea necesario. La desventaja es que la vista explícita del proceso de negocio que vemos en [el flujo de trabajo] ahora solo se refleja implícitamente en nuestro sistema [...] Esto significa que se necesita trabajo adicional para garantizar que pueda monitorear y rastrear que las cosas correctas tienen sucedió Por ejemplo, ¿sabría si el banco de puntos de fidelidad tuvo un error y por alguna razón no configuró la cuenta correcta? Un enfoque que me gusta para lidiar con esto es construir un sistema de monitoreo que coincida explícitamente con la vista del proceso de negocios en [el flujo de trabajo], pero luego rastrea lo que cada uno de los servicios hace como entidades independientes, permitiéndole ver excepciones extrañas asignadas al flujo de proceso más explícito. El [diagrama de flujo] [...] no es la fuerza impulsora, sino solo una lente a través de la cual podemos ver cómo se comporta el sistema. En general, he descubierto que los sistemas que tienden más hacia el enfoque coreografiado están acoplados más libremente y son más flexibles y susceptibles de cambio. Sin embargo, debe hacer un trabajo adicional para monitorear y rastrear los procesos a través de los límites del sistema. He descubierto que las implementaciones más fuertemente orquestadas son extremadamente frágiles, con un mayor costo de cambio. Con eso en mente, prefiero encarecidamente apuntar a un sistema coreografiado, donde cada servicio sea lo suficientemente inteligente como para comprender su papel en todo el baile.

Nota: hasta el día de hoy todavía no estoy seguro de si la coreografía es solo otro nombre para la arquitectura controlada por eventos (EDA), pero si EDA es solo una forma de hacerlo, ¿cuáles son las otras formas? (Consulte también ¿Qué quiere decir con "Dirigido por eventos"? Y Los significados de la arquitectura basada en eventos ). También parece que cosas como CQRS e EvenSourcing resuenan mucho con este estilo arquitectónico, ¿verdad?

Ahora, después de esto viene la diversión. El libro Microservices no asume que los microservicios se implementarán con REST. De hecho, en la siguiente sección del libro proceden a considerar las soluciones basadas en RPC y SOA y finalmente REST. El punto importante aquí es que Microservices no implica REST.

Entonces, ¿qué pasa con HATEOAS?

Ahora, si queremos seguir el enfoque RESTful, no podemos ignorar a HATEOAS o Roy Fielding estará encantado de decir en su blog que nuestra solución no es realmente REST. Vea su publicación de blog sobre REST API. Debe ser impulsado por hipertexto :

Me frustra la cantidad de personas que llaman a cualquier interfaz basada en HTTP API REST. ¿Qué se debe hacer para dejar claro el estilo arquitectónico REST sobre la noción de que el hipertexto es una restricción? En otras palabras, si el motor del estado de la aplicación (y, por lo tanto, la API) no está siendo impulsado por el hipertexto, entonces no puede ser RESTful y no puede ser una API REST. Período. ¿Hay algún manual roto en algún lugar que deba repararse?

Entonces, como puede ver, Fielding piensa que sin HATEOAS no está realmente creando aplicaciones RESTful. Para el campo HATEOAS es el camino a seguir cuando se trata de orquestar servicios. Solo estoy aprendiendo todo esto, pero para mí HATEOAS no define claramente quién o cuál es la fuerza impulsora detrás de los enlaces. En una interfaz de usuario que podría ser el usuario, pero en las interacciones de computadora a computadora, supongo que eso debe hacerlo un servicio de nivel superior.

Según HATEOAS, el único enlace que el consumidor de API realmente necesita saber es el que inicia la comunicación con el servidor (por ejemplo, POST / pedido). A partir de este momento, REST va a conducir el flujo, porque en la respuesta de este punto final, el recurso devuelto contendrá los enlaces a los siguientes estados posibles. El consumidor de API luego decide qué enlace seguir y mueve la aplicación al siguiente estado.

A pesar de lo bueno que suena, el cliente aún necesita saber si el enlace debe PUBLICARSE, PONERSE, OBTENERSE, REPARARSE, etc. Y el cliente aún debe decidir qué carga útil pasar. El cliente aún necesita saber qué hacer si eso falla (reintentar, compensar, cancelar, etc.).

Soy bastante nuevo en todo esto, pero para mí, desde la perspectiva de HATEOA, este cliente o consumidor de API es un servicio de primer orden. Si lo pensamos desde la perspectiva de un ser humano, puede imaginarse a un usuario final en una página web, decidiendo qué enlaces seguir, pero aún así el programador de la página web tuvo que decidir qué método usar para invocar los enlaces, y qué carga útil para pasar. Entonces, en mi opinión, en una interacción de computadora a computadora, la computadora toma el papel del usuario final. Una vez más, esto es lo que llamamos un servicio de orquestaciones.

Supongo que podemos usar HATEOAS con orquestación o coreografía.

El patrón de puerta de enlace API

Chris Richardson sugirió otro patrón interesante, que también propuso lo que llamó un patrón de puerta de enlace API .

En una arquitectura monolítica, los clientes de la aplicación, como los navegadores web y las aplicaciones nativas, realizan solicitudes HTTP a través de un equilibrador de carga a una de N instancias idénticas de la aplicación. Pero en una arquitectura de microservicio, el monolito ha sido reemplazado por una colección de servicios. En consecuencia, una pregunta clave que debemos responder es con qué interactúan los clientes.

Un cliente de aplicaciones, como una aplicación móvil nativa, podría realizar solicitudes RESTful HTTP a los servicios individuales [...] En la superficie, esto podría parecer atractivo. Sin embargo, es probable que haya una discrepancia significativa en la granularidad entre las API de los servicios individuales y los datos requeridos por los clientes. Por ejemplo, mostrar una página web podría requerir llamadas a un gran número de servicios. Amazon.com, por ejemplo, describes cómo algunas páginas requieren llamadas a más de 100 servicios. Hacer tantas solicitudes, incluso a través de una conexión a Internet de alta velocidad, por no hablar de una red móvil de menor ancho de banda y mayor latencia, sería muy ineficiente y daría como resultado una mala experiencia del usuario.

Un enfoque mucho mejor es que los clientes hagan una pequeña cantidad de solicitudes por página, tal vez tan solo una, a través de Internet a un servidor front-end conocido como puerta de enlace API.

La puerta de enlace API se encuentra entre los clientes de la aplicación y los microservicios. Proporciona API que se adaptan al cliente. La puerta de enlace API proporciona una API de grano grueso para clientes móviles y una API de grano fino para clientes de escritorio que utilizan una red de alto rendimiento. En este ejemplo, los clientes de escritorio realizan múltiples solicitudes para recuperar información sobre un producto, mientras que un cliente móvil realiza una sola solicitud.

La puerta de enlace API maneja las solicitudes entrantes haciendo solicitudes a una cierta cantidad de microservicios a través de la LAN de alto rendimiento. Netflix, por ejemplo, describes cómo cada solicitud despliega en promedio seis servicios de back-end. En este ejemplo, las solicitudes detalladas de un cliente de escritorio simplemente se transmiten al servicio correspondiente, mientras que cada solicitud detallada de un cliente móvil se maneja agregando los resultados de llamar a múltiples servicios.

La puerta de enlace API no solo optimiza la comunicación entre los clientes y la aplicación, sino que también encapsula los detalles de los microservicios. Esto permite que los microservicios evolucionen sin afectar a los clientes. Por ejemplo, dos microservicios podrían fusionarse. Otro microservicio podría dividirse en dos o más servicios. Solo la puerta de enlace API debe actualizarse para reflejar estos cambios. Los clientes no se ven afectados.

Ahora que hemos visto cómo la puerta de enlace API media entre la aplicación y sus clientes, veamos cómo implementar la comunicación entre microservicios.

Esto suena bastante similar al estilo de orquestación mencionado anteriormente, solo que con una intención ligeramente diferente, en este caso parece tener que ver con el rendimiento y la simplificación de las interacciones.

Otras lecturas

Hay una gran serie de artículos publicados recientemente en el Blog de NGINX que recomiendo para profundizar en todos estos conceptos:

Entonces tienes dos servicios:

Servicio de micro factura
Micro servicio de envío

En la vida real, tendrías algo donde mantienes el estado del pedido. Llamémoslo servicio de pedidos. A continuación, tiene casos de uso de procesamiento de pedidos, que saben qué hacer cuando el pedido pasa de un estado a otro. Todos estos servicios contienen un cierto conjunto de datos, y ahora necesita algo más, que hace toda la coordinación. Esto podría ser:

Una simple GUI que conoce todos sus servicios e implementa los casos de uso ("Ya terminé" llama al servicio de envío)
Un motor de procesos de negocio, que espera un evento "He terminado". Este motor implementa los casos de uso y el flujo.
Un micro servicio de orquestación, digamos el servicio de procesamiento de pedidos en sí que conoce los casos de flujo / uso de su dominio
Cualquier otra cosa en la que aún no pensé

El punto principal con esto es que el control es externo. Esto se debe a que todos los componentes de su aplicación son bloques de construcción individuales, acoplados libremente. Si sus casos de uso cambian, debe modificar un componente en un lugar, que es el componente de orquestación. Si agrega un flujo de orden diferente, puede agregar fácilmente otro orquestador que no interfiera con el primero. El pensamiento del micro servicio no se trata solo de escalabilidad y de hacer API REST elegantes, sino también de una estructura clara, dependencias reducidas entre componentes y la reutilización de datos y funciones comunes que se comparten en toda su empresa.

HTH, Mark

Entonces, ¿en qué se diferencia la orquestación de microservicios de la orquestación de servicios SOA antiguos que no son "micro"? No mucho en absoluto.

Los microservicios generalmente se comunican mediante http (REST) o mensajes / eventos. La orquestación a menudo se asocia con plataformas de orquestación que le permiten crear una interacción programada entre servicios para automatizar los flujos de trabajo. En los viejos tiempos de SOA, estas plataformas usaban WS-BPEL. Las herramientas de hoy no usan BPEL. Ejemplos de productos de orquestación modernos: Netflix Conductor, Camunda, Zeebe, Azure Logic Apps, Baker.

Tenga en cuenta que la orquestación es un patrón compuesto que ofrece varias capacidades para crear composiciones complejas de servicios. Los microservicios se ven con mayor frecuencia como servicios que no deberían participar en composiciones complejas y más bien deberían ser más autónomos.

Puedo ver que se invoca un microservicio en un flujo de trabajo orquestado para realizar un procesamiento simple, pero no veo que un microservicio sea el servicio del orquestador, que a menudo usa mecanismos como compensación de transacciones y depósito de estado (deshidratación).

He escrito algunas publicaciones sobre este tema:

Quizás estas publicaciones también puedan ayudar:

Patrón de puerta de enlace API: API de curso detallado frente a API de grano fino

https://www.linkedin.com/pulse/api-gateway-pattern-ronen-hamias/ https://www.linkedin.com/pulse/successfulapi-ronen-hamias/

API de servicio de grano grueso frente a fino

Por definición, una operación de servicio de grano grueso tiene un alcance más amplio que un servicio de grano fino, aunque los términos son relativos. la complejidad de diseño aumentada de grano grueso pero puede reducir la cantidad de llamadas requeridas para completar una tarea. en la arquitectura de microservicios, el grano grueso puede residir en la capa API Gateway y orquestar varios microservicios para completar operaciones comerciales específicas. Las API de grano grueso deben diseñarse cuidadosamente para que involucren varios microservicios, ya que administrar diferentes dominios de experiencia tiene el riesgo de mezclar preocupaciones en una API única y romper las reglas descritas anteriormente. Las API de grano grueso pueden sugerir un nuevo nivel de granularidad para las funciones empresariales que, de lo contrario, no existirían. por ejemplo, el empleado contratado puede implicar dos llamadas de microservicios al sistema de recursos humanos para crear una identificación de empleado y otra llamada al sistema LDAP para crear una cuenta de usuario. alternativamente, el cliente puede haber realizado dos llamadas API específicas para lograr la misma tarea. mientras que el de grano grueso representa la cuenta de usuario de creación de casos de uso de negocios, el API de grano fino representa las capacidades involucradas en dicha tarea. Una API más detallada puede implicar diferentes tecnologías y protocolos de comunicación, mientras que los de grano grueso los resumen en un flujo unificado. Cuando diseñe un sistema, tenga en cuenta que, una vez más, no existe un enfoque de oro que resuelva todo y hay un intercambio para cada uno. Los de grano grueso son particularmente adecuados como servicios para ser consumidos en otros contextos de negocios, como otras aplicaciones, líneas de negocios o incluso por otras organizaciones a través de los propios límites de Enterprise (escenarios B2B típicos).

La respuesta a la pregunta original es el patrón SAGA.

Si el Estado necesita ser administrado, entonces el Abastecimiento de eventos con CQRS es la forma ideal de comunicación. De lo contrario, se puede utilizar un sistema de mensajería asincrónica (AMQP) para la comunicación entre microservicios.

De su pregunta, está claro que el ES con CQRS debe ser la combinación correcta. Si usa Java, eche un vistazo a Axon Framework. O cree una solución personalizada con Kafka o RabbitMQ.

Tratando de agregar los diferentes enfoques aquí.

Eventos de dominio

El enfoque dominante para esto parece ser el uso de eventos de dominio, donde cada servicio publica eventos relacionados con lo que sucedió y otros servicios pueden suscribirse a esos eventos. Esto parece ir de la mano con el concepto de puntos finales inteligentes, tuberías tontas que describe Martin Fowler aquí: http://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes

Apoderado

Otro enfoque que parece común es envolver el flujo de negocios en su propio servicio. Donde el proxy organiza la interacción entre los microservicios como se muestra en la siguiente imagen: