Tengo varios servicios web que forman una aplicación web. Los clientes pueden acceder a estos servicios a través de llamadas de API REST.
¿Deberían estos servicios poder comunicarse directamente entre ellos? Si es así, ¿no los haría pareja lo que va en contra del concepto de 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 maneja una solicitud del cliente, obtiene los datos para esa solicitud y luego la envía de vuelta al cliente?
architecture
rest
microservices
cod3min3
fuente
fuente
Respuestas:
Si desea que sus servicios se vean en esta imagen, entonces sí:
no es que no pueda hacerlo, pero la mayoría de las veces tendrá malas consecuencias. La comunicación a través de REST no desacoplará sus servicios de manera significativa. Cuando cambia la interfaz de algunos servicios, lo más probable es que todos los servicios dependientes tengan que cambiarse y volver a implementarse. Además, al volver a implementar el servicio, deberá cancelar todos los servicios dependientes, lo que no se considera un buen diseño para los estándares de alta disponibilidad.
Al final, tendrá una aplicación de microservicios que es más lenta que la aplicación alternativa de monolitos, ¡pero tiene casi los mismos problemas!
Tengo que estar en desacuerdo con @Robert Harvey
La base de datos de integración es un antipatrón bien conocido
Una solución mucho mejor es usar el patrón de publicación-suscripción para hacer que la comunicación entre sus servicios sea asíncrona:
Eche un vistazo a la forma CQRS / ES de implementar este método de comunicación, Greg Young y otros muchachos ofrecen toneladas de buenos videos sobre el tema. Simplemente busque 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 una buena serie de artículos sobre microservicios que arrojan luz sobre la controversia en torno al tema. Explicación muy detallada con bonitas ilustraciones.
fuente
Obtendrá muchas ideas muy buenas al leer lo que Udi Dahan tiene que decir sobre SOA .
Específicamente con respecto a la composición de la interfaz de usuario, el artículo de Mauro Servienti sobre la composición de la interfaz de usuario es un buen punto de partida. Vea también el video de Udi, disponible aquí .
Si dos servicios intercambian mensajes entre sí, obtendrá un poco de acoplamiento. La respuesta principal es que se acoplan a la API del otro servicio: el contrato que el servicio promete mantener estable incluso cuando sus componentes internos están cambiando.
Más allá de eso, las técnicas como el 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 )
fuente
Depende de lo que quieras decir con "directamente".
Está perfectamente bien, según la arquitectura de microservicios, tener microservicios que invoquen 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 utilizando invocaciones de métodos directos; eso haría que ambos microservicios fueran parte del mismo monolito.
fuente
Acoplamiento no es una mala palabra. Cada aplicación ya tiene un cierto grado de acoplamiento; las aplicaciones que hablan con sus microservicios ya están acopladas a los microservicios, de lo contrario no funcionarían.
Lo que realmente buscas con microservicios es acoplamiento flojo ; puede lograrlo simplemente haciendo que un microservicio interrogue al otro a través de su API pública o usando un bus de eventos.
En la práctica, sin embargo, uno o más de sus microservicios (quizás todos) hablarán con algún almacén de datos central como una base de datos SQL. Dependiendo de cómo desee lograr su objetivo, simplemente puede hacer que un microservicio altere los datos de la base de datos de alguna manera, que el otro microservicio consultará para recoger el cambio.
fuente
Parece que cuando se habla de SOA y 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é dijo la justicia de la corte suprema sobre la indecencia? "Lo sabré cuando lo vea".
Estoy seguro de que algunas personas dirán que esto no responde, pero luego se están perdiendo el punto. Las arquitecturas de microservicio están destinadas a evitar varios problemas, entre ellos el tema del "acoplamiento estrecho". Por lo tanto, si termina creando una maraña de microservicios que dependen de demasiados detalles entre sí, ha creado un acoplamiento estrecho que, ya sea que esté utilizando un bus de mensajes pub / sub o llamadas directas, destruye su capacidad para componer nuevas soluciones a partir de las piezas, reconfigurar piezas individuales sin derribar todo el sistema, etc.
fuente
Depende; sin embargo, sugeriría proporcionar capacidades directamente utilizables al cliente y ocultar (encapsular) los detalles de cómo se ensamblan los resultados (por ejemplo, a través de múltiples microservicios).
Si el cliente involucra demasiada lógica en la combinación de resultados de microservicios individuales, eso puede causar inadvertidamente que cierta lógica comercial se infiltre en el cliente. También puede exponer más de su arquitectura interna al cliente de lo que desea, lo que dificulta la refactorización posterior de los microservicios.
Entonces, eso significa que con los microservicios, a veces es útil tener un microservicio envoltorio que proporcione al cliente un punto final que tenga abstracciones útiles y que realice una coordinación de nivel superior 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 emiten consultas directamente relevantes a un punto final, que puede o no implementarse como una colección de microservicios. 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. Ver, por ejemplo, https://stackoverflow.com/a/38079681/471129 .
fuente
El objetivo principal de los microservicios es hacer que su aplicación se acople libremente. Por lo tanto, los servicios no pueden llamarse entre sí. De lo contrario, estará estrechamente acoplado. Pero, ¿qué haremos si tenemos dos servicios que necesitan compartir datos? La respuesta es Message Broker. Por lo tanto, el servicio que obtiene datos del cliente puede compartir los datos con el agente central de mensajes, luego los servicios tienen que usar esos datos para consumirlos, transformarlos y ponerlos 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.
fuente