java - español - Comunicación entre dos microservicios

spring boot desde cero (4)

¿Has visto http://stytex.de/blog/2016/03/25/jhipster3-microservice-tutorial/ Parte 2: sección de comunicación entre servicios. Lo guiará a través de un ejemplo específico de cómo se logra

Estoy creando un proyecto con arquitectura de microservicios. Y creé dos microservicios.

Uno de ellos es para entidad de producto, el otro es para entidad de factura. Tienen sus propios puntos finales y están conectados con la puerta de enlace (estoy usando la arquitectura jhipster microservicios).

Los bill-ms deben tener acceso a la lista de productos. Me pregunto cómo puedo comunicarme entre esos dos. Tengo tres enfoques en mi mente:

Envíe una solicitud de bill-ms a la cola, como rabbitMQ, para obtener estos productos con estas identificaciones de product-ms (no sé qué es el cuello de botella de esto)
Enviar una solicitud a la puerta de enlace para el servicio del producto y obtener el producto de allí (estoy preocupado por la latencia debido al tamaño de datos entre ellos y de esta manera no estoy tocando la base de datos directamente, así que siempre dependo de la puerta de enlace)
Puedo duplicar los repositorios, servicios y entidades en bill-ms (es una manera fea, y creo que rompe la regla de ms-architecture y el mantenimiento es muy difícil)

Si tiene otros enfoques, le agradezco que me lo comparta.

Editar

Ahora sé cuál es el cuello de botella: decir que hay 3 instancias de bill-ms y ¿cómo decide rabbitMQ qué instancia responder? o ¿cómo debería decir a la cinta " darme la instancia gratuita de bill-ms para suscribirse a la solicitud de rabbitMQ " para el equilibrio de carga.

No estoy seguro de si lo que voy a responder es el correcto. Todavía estoy aprendiendo a mí mismo ... Pero puedo contarte cómo he implementado mis intentos de microservicios ...

Primero, comencé con microservicios basados en comunicación HTTP usando este blog . Esto funciona bien, pero el problema es que creas dependencias entre tus servicios. El servicio A necesita estar al tanto de un servicio B y necesita llamarlo directamente (a través del descubrimiento del servicio, etc. por supuesto). Esto es lo que generalmente está tratando de evitar al desarrollar microservicios.

Otro enfoque con el que he empezado últimamente es usar un message bus . En realidad, es la tercera opción que tocaste en tu pregunta.

Tengo un servicio A , que almacena personas (solo un ejemplo). Lo que hace el servicio cuando crea una nueva persona es: Envía un event en un bus RabbitMQ : personCreatedEvent . Si hay otros servicios interesados en eventos como este, pueden suscribirse a ellos. Estos servicios interesados conservan la información relevante en la que están interesados, en sus propios almacenes de datos.

Con este último enfoque, no existe realmente una dependencia entre sus servicios, porque no se comunican entre sí directamente. El servicio A no tiene conocimiento del servicio B , porque B solo envía eventos a RabbitMQ al servicio que le interese a estos eventos y viceversa.

Por supuesto, tiene duplicaciones entre las áreas de almacenamiento de datos sobre el servicio. Pero esto también puede ser rentable, por ejemplo, el servicio B no necesita usar el mismo esquema ni el mismo mecanismo de almacenamiento de datos que el servicio A. Solo almacena la información relevante de la forma más adecuada para este servicio.

Permítanme tratar de agregar más detalles a este escenario para enfatizar lo que puede o no calificar como un evento en el contexto de Producto y Biiling. El Billing-MS necesitaría hablar con Product-Ms solo en caso de que se realice un pedido. La colocación de un pedido sería principalmente para un MS separado, digamos Order-MS. Cuando se crea o coloca un pedido, contendrá información de Productos como artículos de línea.

La creación de un pedido se puede considerar como un evento. Cuando se produce un evento de creación de pedido, se puede enviar a una cola para el servicio de facturación. Cola debe implementarse como una cola de trabajo en RabbitMQ. De esta forma, varias instancias de Billing-MS pueden suscribirse a la misma cola pero será procesada por uno y solo un trabajador. No hay ninguna función de RIBBON en registrar un servicio como Worker to RabbitMQ. Cada instancia se registra en una cola y RabbitMQ decide RoundRobin, que instancia del servicio de facturación puede procesar este evento.

Obtener detalles de Productos en un Pedido para el Facturador-Ms debe ser una carga de llamada de Servicio-a-Servicio balanceada a través de Cinta (si eso es lo que está usando). Obtener detalles del producto no es realmente un evento, colocar una orden es, por lo tanto, la diferencia.

Además, Gateway debe usarse para exponer sus servicios perimetrales. Para llamadas de servicio a servicio, no sería ideal saltar a través del servicio de puerta de enlace.

Una opción es enviar una solicitud para facturar a microservicio utilizando su nombre registrado en el registro eureka.