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 la lógica más y más compleja, tenemos que lidiar con el problema de la gestión de los procesos de negocio que se extienden a través de la límite de los servicios individuales. Y con microservicios, vamos a golpear este límite antes de lo habitual. [...] When it comes to actually implementando este flujo, hay dos estilos de arquitectura que podríamos seguir. Con la orquestación, dependemos de un cerebro central para guiar y conducir el proceso, al igual que el director de una orquesta. Con coreografía, informamos a cada parte del sistema de su trabajo, y lo dejamos resolver los detalles, como bailarines que encuentran su camino y reaccionando a otros a su alrededor en un ballet.

El libro entonces procede a explicar los dos estilos. El estilo de orquestación corresponde más a la idea SOA de orchestration/task services, mientras que el estilo coreográfico corresponde a los dumb pipes y smart endpoints mencionados en el artículo de Martin Fowler.

Estilo de orquestación

Bajo este estilo, el libro anterior menciona:

Pensemos en cómo se vería una solución de orquestación este flujo. Aquí, probablemente lo más simple sería tener nuestro servicio al cliente actúa como el cerebro central. En creación, habla al banco de puntos de fidelidad, servicio de correo electrónico y servicio postal [...], a través de una serie de llamadas de solicitud / respuesta. El el servicio al cliente en sí puede rastrear dónde se encuentra un cliente en este proceso. Se puede comprobar para ver si la cuenta del cliente se ha establecido arriba, o el correo electrónico enviado, o el correo entregado. Tenemos que tomar el diagrama de flujo [...] y modélalo directamente en código. Incluso podríamos usar herramientas que implementa esto para nosotros, tal vez utilizando un adecuado motor de reglas. Existen herramientas comerciales para este propósito en la forma de software de modelado de procesos de negocio. Suponiendo que usemos síncronos solicitud / respuesta, incluso podríamos saber si cada etapa ha funcionado [...] La desventaja de este enfoque de orquestación es que el cliente el servicio puede convertirse en una autoridad de gobierno central. Puede convertirse en el centro en medio de una red, y un punto central donde la lógica empieza a vivir. He visto que este enfoque resulta en un pequeño número de smart "dios" servicios diciéndole a los servicios basados en CRUD anémicos qué hacer.

Nota: Supongo que cuando el autor menciona herramientas se está refiriendo a algo como BPM (por ejemplo, Actividad, ODA Apache, Camunda ). De hecho, el Sitio web de Patrones de flujo de trabajo tiene un impresionante conjunto 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. No creo que el autor implica que se requiere el uso de una de estas herramientas para implementar este estilo de integración, aunque 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 desaprovechar este enfoque de orquestación y en su lugar sugerir el uso de la siguiente una.

Estilo de Coreografía

Bajo el estilo coreográfico el autor dice:

Con un enfoque coreografiado, podríamos tener al cliente servicio emitir un evento de una manera asincrónica, diciendo Cliente crear. El servicio de correo electrónico, el servicio postal y el banco de puntos de fidelidad entonces solo suscríbase a estos eventos y reaccione en consecuencia [...] Este enfoque está significativamente más disociado. Si algunos otro servicio necesario para llegar a la creación de un cliente, simplemente necesita suscribirse a los eventos y hacer su trabajo cuando sea necesario. El 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 han sucedido. Por ejemplo, ¿podrías saber si el banco de puntos de fidelidad tenía un error y por alguna razón no configurar la cuenta correcta? Un enfoque que me gusta lidiando con esto es construir un sistema de monitoreo que coincida explícitamente con la vista de el proceso de negocio en [el flujo de trabajo], pero luego rastrea lo que cada uno de los servicios hace como entidades independientes, lo que le permite ver impar excepciones asignadas al flujo de proceso más explícito. El [diagrama de flujo] [...] isn't the driving force, but just one lens through que podemos ver cómo se está comportando el sistema. En general, he encontrado que los sistemas que tienden más hacia el enfoque coreografiado son mas acoplados libremente, y son más flexibles y susceptibles de cambio. Lo haces necesidad de hacer trabajo adicional para monitorear y rastrear los procesos en todo el sistema límites, sin embargo. He encontrado más fuertemente orquestado las implementaciones deben ser extremadamente frágiles, con un mayor costo de cambio. Con eso en mente, prefiero apuntar a una coreografía sistema, donde cada servicio es lo suficientemente inteligente como para comprender su papel en todo el baile.

Nota: Hasta el día de hoy todavía no estoy seguro si coreografía es solo otro nombre paraarquitectura impulsada por eventos (EDA), pero si EDA es solo una forma de hacerlo, ¿cuáles son las otras formas? (Véase también ¿Qué quiere decir con "Impulsado por eventos"? y Los Significados de la Arquitectura Impulsada por Eventos). También parece que cosas como CQRS y EvenSourcing 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 implementarán con RESTO. De hecho, en la siguiente sección del libro se procede a considerar las soluciones basadas en RPC y SOA y, finalmente, DESCANSAR. El punto importante aquí es que los microservicios no implican DESCANSO.

Entonces, ¿Qué Hay De HATEOAS?

Ahora, si queremos seguir el enfoque RESTful, no podemos ignorar a HATEOAS o a Roy Fielding le complacerá mucho decir en su blog que nuestra solución no es realmente DESCANSAR. Ver su entrada de blog en REST API Debe ser Hipertexto Impulsado:

Me estoy frustrando por el número de personas que llaman a cualquier basado en HTTP interfaz de una API REST. Lo que hay que hacer para hacer el RESTO estilo arquitectónico claro en la noción de que el hipertexto es un restricción? En otras palabras, si el motor del estado de aplicación (y por lo tanto, la API) no está siendo impulsada por hipertexto, entonces no puede ser RESTful y no puede ser una API REST. Periodo. ¿Hay algún manual roto ¿algún lugar que necesite ser arreglado?

Así, como puedes ver, Fielding piensa que sin HATEOAS no estás 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 realmente los enlaces. En una interfaz de usuario que podría ser el usuario, pero en las interacciones de computadora a computadora, supongo que necesita ser hecho por un servicio de nivel superior.

Según HATEOAS, el único enlace el consumidor de API realmente necesita saber es el que inicia la comunicación con el servidor (por ejemplo, POST /order). A partir de este punto, 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. A continuación, el consumidor de la API decide qué enlace seguir y mueve la aplicación al siguiente estado.

A pesar de lo genial que suena, el cliente todavía necesita saber si el enlace debe ser publicado, PUTed, GETed, Parcheado, etc. Y el cliente todavía tiene que decidir qué carga útil pasar. El cliente todavía tiene que ser consciente de qué hacer si eso falla (reintentar, compensar, cancelar, etc.).

Soy bastante nuevo en todo esto, pero para mí, desde la perspectiva de HATEOAs, este cliente o consumidor API es un servicio de alto pedido. Si lo pensamos desde la perspectiva de un humano, podemos imaginar 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 pasar. Así que, para mi punto, 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 API Gateway

Otro patrón interesante es sugerido por Chris Richardson quien también propuso lo que él llamó un Patrón de Puerta de enlace API .

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

Un cliente de aplicación, como una aplicación móvil nativa, podría hacer Peticiones HTTP RESTful a los servicios individuales [...] En la superficie esto puede parecer atractivo. Sin embargo, es probable que haya un desajuste significativo en granularidad entre las API del individuo servicios y datos requeridos por los clientes. Por ejemplo, mostrando uno la página web podría requerir llamadas a un gran número de servicios. Amazon.com, por ejemplo, describe cómo algunos las páginas requieren llamadas a más de 100 servicios. Hacer que muchas solicitudes, incluso a través de internet de alta velocidad conexión, y mucho menos un ancho de banda más bajo, red móvil de mayor latencia, sería muy ineficiente y resultaría en una mala experiencia de usuario.

Un enfoque mucho mejor es que los clientes hagan un pequeño número de solicitudes por página, tal vez tan pocas como una, a través de Internet a un servidor front-end conocido como API gateway.

La API gateway se encuentra entre los clientes de la aplicación y el microservicios. Proporciona API que se adaptan al cliente. El Puerta de enlace de API proporciona una API de grano grueso a los clientes móviles y un API más fina para clientes de escritorio que utilizan un alto rendimiento red. En este ejemplo, los clientes de escritorio realizan varias solicitudes para recuperar información sobre un producto, donde como cliente móvil hace una sola solicitud.

La puerta de enlace de API maneja las solicitudes entrantes realizando solicitudes a algunos número de microservicios en la LAN de alto rendimiento. Netflix, para ejemplo, describe cómo cada solicitud ventiladores hacia fuera a en promedio seis servicios de backend. En este por ejemplo, las solicitudes detalladas de un cliente de escritorio son simplemente el servicio correspondiente, mientras que cada uno de grano grueso la solicitud de un cliente móvil se maneja agregando los resultados de llamando a múltiples servicios.

La API gateway no solo optimiza la comunicación entre los clientes y la aplicación, pero también encapsula los detalles de la microservicios. Esto permite que los microservicios evolucionen sin impactando a los clientes. Por ejemplo, dos microservicios podrían ser fusionar. Otro microservicio puede particionarse en dos o más Servicio. Solo la puerta de enlace de API debe actualizarse para reflejar estos cambio. Los clientes no se ven afectados.

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

Esto suena bastante similar a la el estilo de orquestación mencionado anteriormente, solo que con una intención ligeramente diferente, en este caso parece ser todo sobre la interpretación y la simplificación de las interacciones.

Otras lecturas

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

• Introducción a los microservicios
• Creación de microservicios: Uso de una API Puerta de enlace
• Creación de Microservicios: IPC en una arquitectura de Microservicios
• Descubrimiento de servicios en una arquitectura de Microservicios
• Gestión de Datos Basada en Eventos para Microservicios
• Elegir una Estrategia de Implementación de Microservicios
• Refactorización de un Monolito en Microservicios