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í 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 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 mismo propósito en forma de software de modelado de procesos comerciales. 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 de gobierno central. Puede convertirse en el centro en el 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 , Actividad , 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 los microservicios y, en general, la mayoría de los artículos que he encontrado en la web parecen desfavorecer este enfoque de 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 visión 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 negocio 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 encontrado que los sistemas que tienden más hacia el enfoque coreografiado están acoplados de manera más flexible 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 ). 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 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. Un punto importante aquí es que Microservices no implica REST.
Entonces, ¿qué pasa con HATEOAS? (Hypermedia como el motor del estado de la aplicación)
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. Ver su publicación de blog sobre REST API debe ser impulsado por hipertexto :
Me siento frustrado por 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 Fielding, 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 un servicio de nivel superior debe hacerlo.
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 llevará a cabo el flujo, porque, en respuesta a este punto final, el recurso devuelto contendrá los enlaces a los siguientes estados posibles. 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 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 imaginar 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, 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 microservicios, 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 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, 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 única solicitud.
La puerta de enlace API maneja las solicitudes entrantes haciendo solicitudes a cierto número de microservicios a través de la LAN de alto rendimiento. Netflix, por ejemplo,
describe
cómo cada solicitud se 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 ser todo sobre el rendimiento y la simplificación de las interacciones.
.