Communication between two microservices

Question

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:

1. 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)

2. 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)

3. 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

1. Now I know what the bottleneck is: say that there are 3 instance of bill-ms and how does rabbitMQ decide which instance to respond? or how should I say to ribbon "give me the free instance of bill-ms to subscribe to the request from rabbitMQ" for load balancing.

Answer 1

In general, you have two good options to communicate microservices and also several more to avoid as possible:

• Don't use shared db's
• Don't use FTP file sharing
• Don't use in-memory shared databases
• Don't use CSV or the kind

What to use:

• Option 1 (the best): Use a queue system to share messages, so if Microsoervice B needs some information from Microservice A, A will send a message to the queue and B will consume it. This is the most resilient solution as, if B is down, it will consume the message anyway when it recovers.
• Option 2: Use a RESTFul endpoint, you can call from A to inform B or from B to get information from A. The problem is that, if the receiver is down or failing, the request will break and you will desync. You need to implement a circuit-breaker then to avoid losing it.

You may find more information on how to communicate microservices properly in my article on Communicating microservices the proper way.

Answer 2

you can use below solution : Microservice A (i.e UAA-SERVICE), and Microservice B. Microservice B want to connect microservice A and call services with Feign client.

1)This code for Microservice B

@AuthorizedFeignClient(name = "UAA-SERVICE")

public interface UaaServiceClient {

@RequestMapping(method = RequestMethod.GET, path = "api/users")
public List<UserDTO> getUserList();

@RequestMapping(method = RequestMethod.PUT, path = "api/user-info")
public String updateUserInfo(@RequestBody UserDTO userDTO);

}

UAA-SERVICE : find this name with running Application Instances with registry.

2) In Microservice B (application.yml) Increase feign client connection Time Out------> feign: client: config: default:
connectTimeout: 10000 readTimeout: 50000 enter image description here Increase hystrix Thread time out-------->

hystrix: command: default: execution: isolation: thread: timeoutInMilliseconds: 60000 shareSecurityContext: true

enter image description here 3) add @EnableFeignClients in main @SpringBootApplication class.-------> This solution is working fine for me.

Answer 3

One option is sending a request to bill microservice using it's registred name on the eureka registry.

Answer 4

Let me try and add some more details to this scenario to stress what may or may not qualify as an event in the context of Product and Biiling. The Billing-MS would need to talk to Product-Ms only in case an Order is placed. Placing an Order would mostly be for a separate MS let's say Order-MS. When an order is created or placed, it will contain information of Products as line items.

Creation of an Order can be considered as an event. When Order creation event occurs, it can be pushed to a Queue for the Billing service. Queue should be implemented as a Work-queue in RabbitMQ. This way, multiple instances of the Billing-MS can subscribe to the same Queue but it'll be processed by one and only one Worker. There is no role of RIBBON in registering a service as a Worker to RabbitMQ. Each instance registers to a Queue and RabbitMQ decides RoundRobin which instance of Billing Service gets to process this event.

Getting details of Products in an Order for the Billing-Ms should be a Service-to-Service call load balanced via Ribbon (if that's what you are using). Getting Product details is not really an event, placing an Order is, hence the difference.

Also, Gateway should be used for exposing your Edge services. For Service-to-Service calls, it would not be ideal to hop via Gateway service.

Answer 5

Have you looked at http://stytex.de/blog/2016/03/25/jhipster3-microservice-tutorial/ Part 2: inter-service communication section. It walks you through a specific example of how it is achieved

Answer 6

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.