¿Deberían los servicios comunicarse directamente entre sí en una arquitectura de microservicio?

7

Tengo varios servicios web que forman una aplicación web. Los clientes pueden acceder a estos servicios a través de las llamadas de API REST.

¿Deberían estos servicios hablar directamente entre ellos? Si es así, ¿no sería eso lo que los une, lo que va en contra del concepto de los microservicios?

¿Debería el cliente llamarlos directamente uno tras otro para obtener los datos que necesita para cargar una página web en el cliente?

¿O debería tener otra capa encima de mis servicios, que maneje una solicitud del cliente, recupere los datos de esa solicitud y luego los envíe de vuelta al cliente?

    
pregunta cod3min3 09.01.2017 - 23:23

7 respuestas

12

Si desea que sus servicios se vean como en esta imagen, entonces sí: Noesquenopuedashacerlo,perolamayoríadelasvecestendráconsecuenciasnegativas.LacomunicaciónatravésdeRESTnodesvincularásignificativamentesusservicios.Cuandosemodificalainterfazdealgunosservicios,esprobablequetodoslosserviciosdependientesdebanmodificarseyvolveraimplementarse.Además,alredistribuirelservicio,deberácancelartodoslosserviciosdependientes,loquenoseconsideraunbuendiseñoparalosestándaresdealtadisponibilidad.

Alfinal,tendrásunaaplicacióndemicroserviciosqueesmáslentadeloqueseríaunaaplicaciónmonolíticaalternativa,¡peroconcasitodoslosmismosproblemas!

[email protected]

  
    

Sinembargo,enlapráctica,unoomásdesusmicroservicios(quizástodosellos)hablaránconalgúnalmacéndedatoscentralcomounabasededatosSQL.

  

Labasededatosdeintegraciónes antipattern conocida

Una solución mucho mejor es utilizar el patrón de publicación-suscripción para que la comunicación entre sus servicios sea asíncrona:

Porfavor,echeunvistazoalaformaenqueCQRS/ESimplementaestemétododecomunicación,GregYoungyotroschicos ofrece toneladas de buenos videos sobre el tema. Solo busca en Google la palabra clave "CQRS / ES". En este enfoque, cada servicio se convertirá en editor y suscriptor al mismo tiempo, permitiendo que los servicios estén mucho menos acoplados.

Aquí hay un buena serie de artículos sobre microservicios que arrojan luz sobre la controversia en torno al tema. Explicación muy detallada con bonitas ilustraciones.

    
respondido por el IlliakaillI 10.01.2017 - 16:38
7

Obtendrá muchas ideas muy buenas al leer lo que Udi Dahan tiene que decir sobre SOA .

  

Un servicio es la autoridad técnica para una capacidad comercial específica.   Cualquier dato o regla debe ser propiedad de un solo servicio.

     

Lo que esto significa es que incluso cuando los servicios se publican y se suscriben a los eventos de los demás, siempre sabemos cuál es la fuente autorizada de verdad para cada dato y regla.

     

Además, cuando observamos los servicios desde la perspectiva de las capacidades empresariales, lo que vemos es que muchas interfaces de usuario presentan información que pertenece a diferentes capacidades: el precio de un producto y si está disponible o no. Para que podamos cumplir con la definición de servicios anterior, esto nos lleva a comprender que dichas interfaces de usuario son en realidad un mashup, ya que cada servicio tiene el fragmento de la interfaz de usuario que se ocupa de sus datos particulares.

Específicamente con respecto a la composición de la UI, el artículo de Mauro Servienti sobre UI Composition es un buen comienzo punto. Vea también el video de Udi, disponible aquí .

  

¿Deberían estos servicios hablar directamente entre ellos? Si es así, ¿no sería eso lo que los une, lo que va en contra del concepto de los microservicios?

Si dos servicios intercambian mensajes entre sí, entonces obtendrás un poco de acoplamiento. La respuesta principal es que se unen a la API del otro servicio: el contrato que el servicio promete mantener estable incluso cuando sus aspectos internos estén cambiando.

Más allá de eso, las técnicas como descubrimiento de servicios pueden aliviar la dependencia de un proveedor de servicios específico, y los intermediarios de mensajes pueden desacoplar a los productores y consumidores (aún necesitan entender los mensajes de los demás y cómo interactuar con la API del intermediario de mensajes, no hay magia).

    
respondido por el VoiceOfUnreason 10.01.2017 - 07:40
5

Depende de lo que quieras decir con "directamente".

Según la arquitectura de microservicios, está perfectamente bien tener microservicios que invocan otros microservicios, ya sea en su propio servidor, o incluso en servidores externos, a través de alguna interfaz como REST.

Lo que no está bien, es que un microservicio invoque a otro mediante invocaciones de método directo; eso haría que ambos microservicios sean parte del mismo monolito.

    
respondido por el Mike Nakis 09.01.2017 - 23:37
4
  

¿Deberían estos servicios hablar directamente entre ellos? Si es así, ¿no sería eso lo que los une, lo que va en contra del concepto de los microservicios?

El acoplamiento no es una mala palabra. Cada aplicación ya tiene un cierto grado de acoplamiento; las aplicaciones que hablan con sus microservicios están ya acopladas a los microservicios, de lo contrario no funcionarían.

Lo que realmente buscas con los microservicios es acoplamiento suelto ; puede lograrlo simplemente haciendo que un microservicio interrogue al otro a través de su API pública o utilizando un bus de eventos.

En la práctica, sin embargo, uno o más de sus microservicios (quizás todos ellos) hablarán con algún almacén de datos central como una base de datos SQL. Dependiendo de cómo desee lograr su objetivo, es posible que simplemente tenga un microservicio que altere los datos de la base de datos de alguna manera, que el otro microservicio consultará para recoger el cambio.

    
respondido por el Robert Harvey 09.01.2017 - 23:34
2

Parece que cuando se habla de SOA y de la arquitectura en general, las personas quedan atrapadas en la semántica y la jerga. ¿Qué hace que un servicio sea "micro"? En última instancia, es un conjunto de características que, en cualquier "sistema de puntuación" que esté utilizando, claramente no hace que el servicio sea "no micro". ¿Qué fue lo que dijo la Corte Suprema de Justicia sobre la indecencia? "Lo sabré cuando lo vea".

Estoy seguro de que algunas personas dirán que esto no es una respuesta, pero luego se les escapa el punto. Las arquitecturas de microservicios están destinadas a evitar varios problemas, entre ellos el tema del "acoplamiento apretado". Por lo tanto, si termina creando una maraña de microservicios que dependen de demasiados detalles finos entre sí, habrá creado un acoplamiento estrecho que, ya sea que esté utilizando un bus de publicación / mensaje secundario o llamadas directas, destruye su capacidad para componer nuevas soluciones a partir de las piezas, reconfigurar piezas individuales sin desbaratar todo el sistema, etc. etc.

    
respondido por el Flickerthing dot com 11.01.2017 - 05:40
1
  

¿Debería el cliente llamarlos directamente uno tras otro para obtener los datos que necesita para cargar una página web en el cliente?

Depende; sin embargo, sugeriría proporcionar capacidades de uso directo al cliente y ocultar (encapsular) los detalles de cómo se ensamblan los resultados (por ejemplo, a través de múltiples microservicios).

Si hay demasiada lógica involucrada en la combinación de resultados de microservicios individuales por parte del cliente, esto puede causar que alguna lógica de negocios se introduzca en el cliente sin darse cuenta. También puede exponer más de su arquitectura interna al cliente de lo que quisiera, lo que dificultaría la refactorización posterior de los microservicios.

Por lo tanto, eso significa que con los microservicios, a veces es útil tener un microservicio de envoltura que proporcione al cliente un punto final con abstracciones útiles y que realice una coordinación de mayor nivel de otros microservicios (quizás ahora más internos).

(Además, los viajes de ida y vuelta al cliente son probablemente más caros que los de sus microservicios entre sí).

Si observa la dirección que está tomando GraphQL, por ejemplo, encontrará clientes que realizan consultas directamente relevantes a un punto final, que pueden o no implementarse como una colección de micrservicios. Como la arquitectura de los microservicios está oculta detrás de GraphQL, eso hace que la arquitectura sea más fácil de refactorizar y también más amigable para el cliente. Consulte, por ejemplo, enlace .

    
respondido por el Erik Eidt 10.01.2017 - 00:44
1

El propósito principal de los microservicios es hacer que su aplicación se acople de manera flexible. Por lo tanto, los servicios no se pueden llamar entre sí. De lo contrario, será acoplado de forma vinculada. Pero, ¿qué vamos a hacer si tenemos dos servicios que necesitamos compartir datos? La respuesta es Message Broker. Entonces, el servicio que obtiene datos del cliente puede compartir los datos con el intermediario central de mensajes, luego los servicios tienen que usarlos, pueden consumirlos, transformarlos y colocarlos en su propio almacenamiento de datos. Recomiendo Kafka porque puedes unir datos de diferentes temas sobre la marcha con Kafka Stream. PD. mejor separar sus microservicios por función.

    
respondido por el Panuwat Anawatmongkhon 11.01.2018 - 12:10

Lea otras preguntas en las etiquetas

Comentarios Recientes

Cuando tiene varias cuentas de desarrollador, se vuelve dependiente de ellas, idealmente los servicios creados por cada cuenta de desarrollador que tiene en su entorno. Una arquitectura de microservicios a menudo se describe mediante una serie de servicios que contribuyen a un servicio común pero no comparten un entorno de trabajo común. Entre los ejemplos de microservicios se incluye la Fábrica de Identidad Modular de Spring DevLabs que administra la autenticación, la Agencia de Seguridad de Spring y muchos más.... Lee mas