10

I'm new to micro-services, and I'm trying to take my project and turn it into A micro services based project. My problem is figuring out how each service communicates with each other.

First, I explored the REST style service, but if each service is based HTTP REST how do they "talk" to each other after all?

Then I tried to learn Spring Integration, but then it became even unclearer how should they communicate because now it came to my mind that maybe I need to use RabbitMQ to be the middleware between the front end and the micro services back end.

I also run into cloud and Docker technologies, so I guess each service should be on the cloud but still it doesn't make it clear how services communicate.

I'm using Java, Spring technologies.

I'll be happy if someone would give me a better picture how things should be.

Moshe Arad
  • 3,587
  • 4
  • 18
  • 33

5 Answers5

6

You are onto the right way. Exposing a service with a REST architecture is powerful and simple. Each microservice exposes some functionalities that can be invoked by others microservices. You can do this with SpingMVC and the annotation @RestController. To invoke REST API you may use the Spring class RestTemplate.

You probably also need a gateway that redirects requests to the right service. I suggest you to try the Netflix Cloud Stack:

  • Zuul. This is the entry point of your application. Every request is issued to it. It should orchestrate the whole ecosystem.
  • Eureka Client - Eureka Server. All of your microservices should somehow tell somebody that they are up and running and can accept requests. So you can use Eureka Server to accept registrations from your services and mark your microservices as Clients.
  • Ribbon. Another one important thing is the loadbalancing of the requests. With Ribbon you can do this easily.

If you are using Spring Boot you can setup this architecture quickly with some annotations.

You can find here a simple example: https://cloud.spring.io/spring-cloud-netflix/

Nano
  • 814
  • 2
  • 13
  • 30
4

I don't really like direct API calls from service A to service B or vice versa for two reasons. Firstly it create dependency between service A and B. Secondly it could easily create a spaghetti sort of messy relationships as the number of services grows. What I would like to see is a pub / sub pattern, e.g. service A publishes a message to the transportation layer (RabbitMQ is not a bad choice) and move on. The subscription and business logic to interpret the message are encapsulated nicely in service B. By doing that, service B does not need to know anything about service A at all and yet they can talk to each other nicely.

Gang Gao
  • 1,051
  • 8
  • 9
2

There is no standard for communication or transport mechanisms for microservices. In general, microservices communicate with each other using widely adopted lightweight protocols, such as HTTP and REST, or messaging protocols, such as JMS or AMQP. In specific cases, one might choose more optimized communication protocols, such as Thrift, ZeroMQ, Protocol Buffers, or Avro.

Communication between microservices can be designed either in synchronous (request-response) or asynchronous (fire and forget) styles. Both approaches have their own merits and constraints. It is not possible to develop a system with just one approach. A combination of both approaches is required based on the use cases.

You should choose ones which suits best to your projects depending on your use cases and requirements.

halil
  • 800
  • 16
  • 33
2

I have personally used an Eureka discovery service. This is basically the "master of puppets" of the microservices, if you will. Each microservice registers itself to a separate microservice (the discovery service) on startup. The discovery service hence knows the address and port of each microservice and each microservice can ask the discovery service which (other) microservices are registered. In addition, each microservice can simply ask the discovery service for information about another microservice. All communication (in my case) was done with REST, but this is a choice, as Spring Boot with the Eureka discovery service dependency promotes it.

With VERY little configuration you can get this whole framework to function.

This is based on the framework used by Netflix. I believe Eureka is even a netflix library for that matter.

Roel Strolenberg
  • 2,922
  • 1
  • 15
  • 29
0

Having microservices do synchronous communication with each other is a risk, the big issue is coupling, it means the services are now coupled to each other, if one of them fails it's dependents will now fully or partially disabled/crash, a better solution would be to use asynchronous communication for state changing operations.

You want to make a clear distinction between state changing operations and read operations (CQS Command Query Separation). For state changing operations you can use some kind of messaging infrastructure and go for fire and forget communication. For queries you would use Synchronous request response communication and could use an http API or just go directly to your data store.

If you are using messaging then you can also look at publish subscribe for raising events between services.

Another point to consider is (transactional) data sharing (as opposed to read only views) if you expose your internal state the reader might get the wrong state of your data, or the wrong version, and also will potentially lock your data?

Last but not least, try to do everything you can to keep your services autonomous (at least at the logical level).

Hope this makes sense.

Sean Farmar
  • 2,254
  • 13
  • 10