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.

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 :

  • 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

  • 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

    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), ie RabbitMQ or Apache Kafka.

    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

    链接地址: http://www.djcxy.com/p/34092.html

    上一篇: 哑管道智能端点

    下一篇: 微服务内部沟通