Solución:
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 más allá de los límites de los servicios individuales. Y con los microservicios, alcanzaremos este límite antes de lo habitual. […] Cuando se trata de implementar realmente este flujo, hay dos estilos de arquitectura que podemos 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 si todos los bailarines encontraran su camino y reaccionaran a los demás en un ballet.
Luego, el libro procede a explicar los dos estilos. El estilo de orquestación corresponde más a la idea SOA de 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 en cómo sería una solución de orquestación para este flujo. En este caso, probablemente lo más sencillo sería que nuestro servicio de atención al cliente actuara como el cerebro central. En el momento de la creación, habla 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 de atención al cliente en sí mismo puede realizar un seguimiento de dónde se encuentra un cliente en este proceso. Puede comprobar si se ha configurado la cuenta del cliente, si se ha enviado el correo electrónico o si se ha entregado la publicación. Llegamos a tomar el diagrama de flujo […] y modelarlo directamente en código. Incluso podríamos usar herramientas que implementen esto para nosotros, quizás usando un motor de reglas apropiado. Existen herramientas comerciales para este mismo propósito en forma de software de modelado de procesos comerciales. Suponiendo que usamos 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 de gobierno central. Puede convertirse en el eje en medio de una red 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.
Sin embargo, otros libros que he leído sobre el tema de los microservicios y, en general, la mayoría de los artículos que he encontrado en la web parecen desaprobar este enfoque de orquestación y, en cambio, sugieren usar el siguiente.
Estilo de coreografía
Bajo estilo de coreografía el autor dice:
Con un enfoque coreografiado, podríamos simplemente hacer que el servicio al cliente emitiera un evento de manera asincrónica, diciendo que el cliente 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 está significativamente más desacoplado. Si algún otro servicio necesitaba 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 visión explícita del proceso empresarial que vemos en
[the workflow] ahora solo se refleja implícitamente en nuestro sistema […]
Esto significa que se necesita trabajo adicional para garantizar que pueda monitorear y rastrear que hayan sucedido las cosas correctas. 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 empresarial en [the workflow], pero luego rastrea lo que hace cada uno de los servicios como entidades independientes, lo que le permite ver excepciones extrañas asignadas al flujo de proceso más explícito. los [flowchart]
[…] no es la fuerza impulsora, sino solo una lente a través de la cual podemos ver cómo se está comportando el sistema. En general, he descubierto que los sistemas que tienden más hacia el enfoque coreografiado están más débilmente acoplados y son más flexibles y susceptibles de cambio. Sin embargo, necesita hacer un trabajo adicional para monitorear y rastrear los procesos a través de los límites del sistema. He descubierto que la mayoría de las implementaciones 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 impulsada 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 “impulsada por eventos”? Y Los significados de la arquitectura impulsada por eventos). Además, parece que cosas como CQRS y EventSourcing resuenan mucho con este estilo arquitectónico, ¿verdad?
Ahora, después de esto viene la diversión. El libro de Microservicios no asume que los microservicios se vayan a implementar con REST. De hecho, en la siguiente sección del libro, proceden a considerar las soluciones basadas en RPC y SOA y finalmente a REST. Un punto importante aquí es que Microservicios no implica REST.
Entonces, ¿qué pasa con HATEOAS?(Hypermedia como motor del estado de la aplicación)
Ahora, si queremos seguir el enfoque RESTful, no podemos ignorar a HATEOAS o Roy Fielding estará muy complacido de decir en su blog que nuestra solución no es realmente REST. Vea la publicación de su blog sobre REST API Must be Hypertext Driven:
Me frustra la cantidad de personas que llaman a cualquier interfaz basada en HTTP una API REST. ¿Qué se debe hacer para que el estilo arquitectónico REST quede claro 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 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 arreglarse?
Entonces, como puede ver, Fielding piensa que sin HATEOAS no está realmente construyendo aplicaciones RESTful. Para Fielding, HATEOAS es el camino a seguir cuando se trata de orquestar servicios. Estoy aprendiendo todo esto, pero para mí, HATEOAS no define claramente quién o qué es la fuerza impulsora detrás de seguir los enlaces. En una interfaz de usuario que podría ser el usuario, pero en interacciones de computadora a computadora, supongo que eso debe ser realizado por un servicio de nivel superior.
Según HATEOAS, el único enlace que el consumidor de API realmente necesita conocer es el que inicia la comunicación con el servidor (por ejemplo, POST / pedido). A partir de este punto, REST llevará a cabo el flujo, porque, en la respuesta de este punto final, el recurso devuelto contendrá los enlaces a los siguientes estados posibles. Luego, el consumidor de API decide qué enlace seguir y mueve la aplicación al siguiente estado.
A pesar de lo genial que suena, el cliente aún necesita saber si el enlace debe ser PUBLICADO, PUTADO, OBTENIDO, PATCHADO, etc. Y el cliente aún necesita decidir qué carga útil pasar. El cliente aún debe 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 alto nivel. Si lo pensamos desde la perspectiva de un 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 utilizar para invocar los enlaces, y qué carga útil pasar. Entonces, a mi punto, en una interacción de computadora a computadora, la computadora asume el papel del usuario final. Una vez más, esto es lo que llamamos servicio de orquestaciones.
Supongo que podemos usar HATEOAS con orquestación o coreografía.
El patrón API Gateway
Otro patrón interesante es sugerido por Chris Richardson, quien 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 las 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, un key La pregunta que debemos responder es ¿con qué interactúan los clientes?
Un cliente de aplicación, como una aplicación móvil nativa, podría realizar solicitudes HTTP RESTful a los servicios individuales […] A primera vista, esto puede parecer atractivo. Sin embargo, es probable que exista 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 una gran cantidad de servicios. Amazon.com, por ejemplo, describe 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, y mucho menos una red móvil de menor ancho de banda y mayor latencia, sería muy ineficiente y resultaría en una mala experiencia del usuario.
Un enfoque mucho mejor es que los clientes realicen una pequeña cantidad de solicitudes por página, quizás tan solo una, a través de Internet a un servidor de aplicaciones para el usuario 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 general a los clientes móviles y una API más detallada a los clientes de escritorio que utilizan una red de alto rendimiento. En este ejemplo, los clientes de escritorio realizan varias 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 realizando solicitudes a una cierta cantidad de microservicios a través de la LAN de alto rendimiento. Netflix, por ejemplo, describe cómo cada solicitud se expande a un promedio de seis servicios de backend. En este ejemplo, las solicitudes detalladas de un cliente de escritorio simplemente se envían mediante proxy al servicio correspondiente, mientras que cada solicitud de grano grueso 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, se pueden fusionar dos microservicios. Otro microservicio podría dividirse en dos o más servicios. Solo es necesario actualizar la puerta de enlace de la API 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 que se trata de rendimiento y simplificación de interacciones.
Intentando 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 sobre lo que ha sucedido y otros servicios pueden suscribirse a esos eventos. Esto parece ir de la mano con el concepto de terminales inteligentes, tubos tontos 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 orquesta la interacción entre los microservicios como se muestra en la siguiente imagen:
.
Otros patrones de la composición
Esta página contiene varios patrones de composición.
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 mensajería / eventos. La orquestación a menudo se asocia con plataformas de orquestación que le permiten crear una interacción por script entre servicios para automatizar los flujos de trabajo. En los viejos tiempos de SOA, estas plataformas usaban WS-BPEL. Las herramientas actuales no utilizan 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 más a menudo como servicios que no deberían participar en composiciones complejas y más bien 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 de orquestador, que a menudo usa mecanismos como transacciones de compensación y repositorio de estado (deshidratación).