¿Deben los microservicios hablar entre ellos?

Estoy diseñando una aplicación usando Micro-Servicios y no estoy seguro del mejor mecanismo para recolectar datos de múltiples servicios.

Creo que hay dos opciones:

• Integre un mecanismo de comunicación 'entre servicios' que permita que los servicios hablen directamente. API Gateway llamaría a un servicio individual, que luego llama a otros servicios para recopilar datos, antes de devolver la respuesta consolidada a API Gateway. La API luego devuelve la respuesta a la persona que llama. (Esto tendría que ser llamadas síncronas cuando la llamada al servicio B requiere la respuesta del servicio A. IE Separate Person and Address Services).
• Haga que API Gateway llame a cada servicio directamente y consolide los datos dentro de la API antes de devolver la respuesta.

Me estoy inclinando hacia la segunda opción, ya que hacer que los servicios se comuniquen entre sí introduciría el acoplamiento, en cuyo caso también podría diseñar una aplicación monolítica. Sin embargo, hay algunas desventajas serias que puedo pensar fuera de mi cabeza con esta opción:

• Hacer que la API ejecute varias llamadas a múltiples servicios aumenta la carga en el servidor de la API, especialmente cuando algunas de esas llamadas se están bloqueando.

• Este método significaría que la API debe ser "consciente" de lo que la aplicación está tratando de hacer (IE Logic tendría que programarse en la API para manejar las llamadas de los servicios, y luego consolidar los datos), en lugar de simplemente actuar como un "punto final" tonto para los microservicios.

Me gustaría saber cuál es el enfoque estándar para este problema y si hay otra tercera opción que me falta.

En general, aconsejaría que los microservicios no se comuniquen sincrónicamente, el gran problema es el acoplamiento, significa que los servicios ahora están acoplados entre sí, si uno de ellos falla, el segundo ahora es total o parcialmente disfuncional.

Yo haría una distinción clara entre las operaciones de cambio de estado y las operaciones de lectura ( Separación de consulta de comando CQS ). Para las operaciones de cambio de estado, usaría algún tipo de infraestructura de mensajería e iría a disparar y olvidar. Para consultas, usaría la comunicación de respuesta de solicitud síncrona y podría usar una API http o simplemente ir directamente a su almacén de datos.

Si está utilizando la mensajería, también puede mirar la suscripción de publicación para generar eventos entre servicios.

Otro punto a considerar es el intercambio de datos (transaccionales) (en oposición a las vistas de solo lectura) si expone su estado interno, el lector podría obtener el estado incorrecto de sus datos o la versión incorrecta, y también podría bloquear sus datos.

Por último, pero no menos importante, intente hacer todo lo posible para mantener sus servicios autónomos (al menos a nivel lógico).

Espero que esto tenga sentido.

Depende de por qué necesita esos datos. Si es por UI, está perfectamente bien. Además, es como debería ser. Chris Richardson tiene una buena explicación de ese concepto , y Sam Newman tiene un gran artículo sobre un concepto muy similar llamado Backends for Frontends .

Pero si lo necesita para algo de lógica, es probable que los límites de servicio sean incorrectos.

Hay varias características que el sentido común nos dice que nuestros servicios deberían poseer . Son:

1. Bajo acoplamiento. Si realiza algunos cambios en el servicio A, no desea que afecten al servicio B.
2. Alta cohesión. Si necesita implementar alguna función, desea que se vea afectada la menor cantidad posible de servicios.
3. Alta autonomía. Si algún servicio falla, no desea que todo el sistema esté inactivo.
4. Granularidad correcta. No desea que sus servicios sean demasiado habladores, ya que su red es más compleja de lo que podría pensar.
5. Los servicios deben comunicarse a través de eventos. No desea que su servicio se conozca entre sí, ya que reduce la capacidad de mantenimiento. Piense en lo que sucede si necesita agregar un nuevo servicio.
6. Datos descentralizados. Un servicio no debe compartir la forma en que se almacena la información. Al igual que un buen objeto, expone el comportamiento, no los datos.
7. Servicio de coreografía sobre orquestación.

Para lograr esto, trate los límites de su servicio como capacidades comerciales . Un proceso formal de identificación de límites de servicio se ve así:

1. Identificar límites de nivel superior. Me gusta pensar en ellos como pasos que su organización debe seguir para lograr su objetivo comercial, para obtener su valor comercial. Puede la idea de los pasos básicos a través de echar un vistazo a la cadena de valor de Porter .
2. Dentro de cada servicio, profundiza. Identifique las unidades autónomas para niños con sus propias responsabilidades.
3. Cuidado con la forma en que se comunican. Los servicios correctos se comunican principalmente a través de eventos. Piensa en tu estructura organizacional. La comunicación dentro de ellos es bastante intensa, aunque generalmente se exponen algunos eventos externos.

Un ejemplo de aplicación de este enfoque podría ser de algún interés.

Me inclinaría hacia el segundo enfoque también de forma predeterminada, aunque tal vez no en su "puerta de enlace API", pero consideraría completamente razonable crear un nuevo microservicio cuyo único propósito era organizar las solicitudes a otros microservicios y representar los datos en un formulario de nivel superior. En una arquitectura de microservicios, me inclinaría a que los microservicios "base" se comuniquen directamente entre sí.

Para hacer esto un poco menos subjetivo, digamos que un servicio depende de otro si el primero requiere datos o servicios del segundo, directa o indirectamente . En términos matemáticos, queremos que esta relación sea un orden parcial y no un pedido anticipado . En forma de diagrama, si trazó su diagrama de dependencia, debería obtener un diagrama de Hassey no tener ningún ciclo (dirigido). (En un diagrama de Hasse, los bordes se dirigen implícitamente de menor a mayor). Como guía adicional, desea que las rutas de arriba a abajo sean generalmente más cortas. Esto significa que desea depender más directamente de las cosas de forma predeterminada. Las razones son que esto minimiza la cantidad de cosas que pueden salir mal para cualquier solicitud en particular, minimiza los gastos generales y reduce la complejidad. Entonces, en el caso "ideal" de esta métrica, el diagrama de Hasse tendría solo dos niveles. Por supuesto, hay muchas razones por las que es posible que desee introducir servicios intermedios como el almacenamiento en caché, la consolidación, el equilibrio de carga, la gestión de fallas.

Para profundizar en su segunda preocupación de que la API Gateway sea "inteligente", un patrón que está ganando terreno ahora con marcos como Falcor y Relay / GraphQL es hacer solicitudes más especificaciones de qué hacer para que la "API Gateway" pueda genéricamente ejecutar esas especificaciones sin tener que saber qué GetTimelineimplica. En cambio, recibiría una solicitud como "solicitar esta información de usuario del servicio de usuario y obtener estas publicaciones del servicio de correos" o lo que sea.

Sospecho que su necesidad de servicios para "llamarse" entre sí indica que está procediendo con un sistema que no ha sido bien diseñado, ya que esta necesidad de microservicios para "llamarse" entre sí es una forma de acoplamiento que rara vez aparece cuando Los microservicios están diseñados adecuadamente.

¿Puede explicar más sobre el problema que está tratando de resolver? ¿En inglés simple?