I am creating a project with microservices architecture. And I created two microservices.
One of them is for product entity, the other is for bill entity. They have their own endpoints and they are connected together with the gateway (i am using jhipster microservices architecture).
The bill-ms should access to list of products. I'm wondering how I can communicate between those two ms. I have three approaches in my mind:
Send a request from bill-ms to queue - like rabbitMQ, to get these products with these ids from product-ms (I don't know what is bottleneck of this)
Send a request to gateway for product service and get the product from there (I'm worried about the latency because of the data size between them and in this way I'm not touching the database directly so I always depend on the gateway)
I can duplicate the repositories, services and entities in bill-ms (it's an ugly way, and I think it breaks the rule of ms-architecture and the maintenance is very difficult)
If you have any other approaches, I appreciate you to share it with me.
Edit
I'm not sure if what I am going to answer is thé right way. I'm still learning myself.. But I can tell you how I've implemented my microservices attempts..
First, I started with HTTP
communication based microservices using this blog. This works fine, but the problem is, that you create dependendies between your services. Service A needs to be aware of a service B and needs to call it directly (via service discovery etc of course). This is what you generally are trying to avoid when developing microservices.
Another approach that I've started with lately, is using a message bus
. It's actually the 3rd option that you touched in your question.
I have a service A, which stores persons (just an example). What the service does when it creates a new person is: It sends an event
on a RabbitMQ
bus: personCreatedEvent
.
If there are any other services interested in events like this, they can subcribe to them. These interested services keep the relevant information that they are interested in, in their own datastores.
With this last approach, there is not really a dependency between your services, because they don't communicate with each other directly. Service A is not aware of service B, because B just sends events to RabbitMQ
to whichever service is interested to these events and vice versa.
Of course, you have duplications between datastores over the service. But this can be profitable as well, e.g. service B doesn't need to use the same schema or data store mechanism as service A. It only stores the relevant information in the way that is best for this service.