CODEWITHSUNDEEP
microservices
Zeina
Zeina

Reputation: 257

Microservice internal communication

I've been reading up on Microservice Architecture But I still can't understand the inter-microservices communication mechanism.
In many articles they said that microservices are usually exposed over a RESTful API. But when you search the internet you always see implementations based on messaging and events for the backend communications.

So I'm confused, Is REST API a standard for all the microservices or we can see microservices without a REST endpoints.

Upvotes: 12

Views: 8724

Answers (4)

skjagini
skjagini

Reputation: 3217

REST is universally supported, its accepted on all languages, if all your backend services are running in the same location you may not see much different in throughput.

Anyhow its a good idea to invest and learn gRPC or Thrift as mentioned above, you could convert all your internal services to gRPC for example (supported on most languages) and do a conversion between gRPC and REST at your Universal Gateway.

There are two approaches to internal architecture, CQRS vs Plain REST calls. The eventing/messaging is an example of CQRS, where you can separate read/write side operations and all write side operations can be implements through eventing for better scalability and throughput.

Upvotes: 3

techagrammer
techagrammer

Reputation: 1306

For your problem , first lets understand the ways in which one service interacts with each other , lets create two service order service and customer service :

  1. One service need some data from other service to process its requests, eg: lets say you want to place an order , so from ui you must hit http request to order service (which can be rest , or have a api gateway in between n that use some other protocol like protobu ) to call order service for placing an order , now assume order service needs to check the validity of the customer , so order service needs to call customer service in sync — most probably you will hit rest or create a protobuf or have a persistent websocket between the service and then after response from customer service , order service move ahead.

In this case sync communication needs to be imitated , one direct approach is rest or protobuff , or imitate it through messaging

  1. Based on one service events , you want to update other service : in this generally the preferred style is messaging bus , where one service emits out event and multiple other services have a listener on the messaging bus and react accordingly . Eg : lets say on update of customer name in customer service , you want to update the cached name of the customer in order service , in this when name is updated in customer service , it emits customer name updated event , order service subscribe to it , then react to it

Your third question is , is it possible to have service with no rest endpoint ::: yes its possible , but every service needs to be reachable . So use rest or other form is needed

Above mentioned link : microservices.io is very good , go through it once again

Upvotes: 8

Constantin Galbenu
Constantin Galbenu

Reputation: 17693

One of the benefits of using microservices (if not the biggest) is that it eliminates any long-term commitment to a technology stack. When developing a new service you can pick a new technology stack. Similarly, when making major changes to an existing service you can rewrite it using a new technology stack.

So, you can choose whatever communication mechanism you want as long as it does not prevent you changing the technology stack. REST over HTTP is a good choice because it hides the technologies used by the microservice to generate the responses in a request-response synchronous style. Message-based communications are also a good fit because the messages could also hide the technologies used to produce them (as long as you don't use the builtin serialization of the producer programming language), i.e. RabbitMQ or Apache Kafka.

Upvotes: 2

Kanishk
Kanishk

Reputation: 431

REST is not the only style available for microservice-to-microservice (aka inter-process communication/IPC) but it is the most popular IPC technology used by applications based on microservices-styled architecture. There are other technologies like Apache Thrift and gRPC which can serve the same purpose. Essentially all of these technologies are industry-grade implementations of RPC (Remote Procedure Call).

I highly recommend you to read this link by Microservices Expert - Chris Richardson

Upvotes: 2

Related Questions