CODEWITHSUNDEEP
springarchitecturecloudmicroservicescoupling
melpin
melpin

Reputation: 43

Microservice Coupling

I'm building a new application with microservice concepts, but I don't know how to communicate with another microservice without coupling. Here is my scenario.

I want to show a graphic bar about my sales but I have two microservices, the first one is the sales-service and the another one product-service. In this case I have to select the period I want to filter and then select the sales and after select the products from these sales, but I'm calling the product-service directly with REST and if my product-service going down fails every thing. What is the correct way to work in this scenario?

EDIT

Diagram of Architecture

This is the architecture with some services. The problem is that sale-service has to communicate with others services to get some informations.

We have a sales software in hundreds of client and this application recieves this data and we have a front-end that shows this informations. In this scenario, microservice is the best approatch?

I'm using Spring Cloud.

Upvotes: 3

Views: 972

Answers (5)

Vijay Parmar
Vijay Parmar

Reputation: 809

Microservice is best when you need scalability and flexibility ,

With your current architecture diagram ,i can understand that you are making synchronous call to recieve data hence sale service has to wait for data to come from all the service to get the full result hence more delay in the output.

Another observation is scalability of microservices which seems not being acheved right now ?

If you can make asyncronous call to microservices then you can imrpove performance and club the data once every service return the results desired.

Upvotes: 0

Brother
Brother

Reputation: 2210

The calls through REST call is a very good option if you need sync calls with return. If you can make a Async call, you could use a message architecture with RabbitMQ using Spring AMQP for example.

A good approach is when you are communicating with 3rd parties and other services, if you have a failover plan, so your service continue working.

The answer for this is to use a Circuit Breaker in you application.

Here are two examples:

  • Netflix Hystrix
  • CircuitBreaker (from Spring Retry)

I am currently working with the Spring Retry and is working as expected.

The idea is:

  • if a call to a external service is failing after some attempts, you return a default answer and lets the system recover before trying again.
  • After some time, you start calling the external service again (hopping now is working).

Here is an example in my Github where I implement the @CircuitBreaker annotation together with the @Recover.

spring-circuit-breaker-example

Upvotes: 1

Dinusha
Dinusha

Reputation: 716

Since you are using spring cloud, you and easily integrate with Hystrix circuit breaker for handle microsrvice failover scenarios.
use the hystrix commands for service break down. 

@HystrixCommand(fallbackMethod = "reliable")
  public List<String> readingList() {
    URI uri = URI.create("http://product-service/product");

    return this.restTemplate.getForObject(uri, String.class);
  }

  public String reliable() {
    return "no product available"; // or send empty array. Arrays.asList();
  }

Please find the example in,

https://spring.io/guides/gs/circuit-breaker/

Upvotes: 0

ootero
ootero

Reputation: 3475

Without going into the details of choosing between a monolithic app versus a Microservice architecture, what your diagram is missing a Registration and Discovery service such as Spring Cloud Netflix Eureka or Consul.

Services would register with Eureka then they get other services metadata (host, port service listen on) from Eureka.

A detailed tutorial could be found at Microservices Registration and Discovery using Spring Cloud, Eureka, Ribbon and Feign, a blog post I published a few moths ago.

Upvotes: 0

Robert Br&#228;utigam
Robert Br&#228;utigam

Reputation: 7744

The obvious answer if you don't know how to communicate without coupling is not to communicate then.

I really mean that. You should design your services in a way that does not require synchronous communication with other services to fulfill a business case. Doing otherwise, as you noted, leads to runtime coupling.

Obviously if you have a "product-service", that already suggests this is something pretty much every other service will need. You baked coupling into the architecture by cutting it up in a specific way.

Specifically in this case: the "sales" service should have all the data for the report, so it does not have to communicate. You might find that this data is actually not needed elsewhere, so there would be no real duplication of data.

Have a look at these guys: http://scs-architecture.org/. They have a lot of good ideas how (and why) to avoid such couplings, and how to design independent services, or at least only "offline" dependent ones.

Obviously this is not for everything. Most notably Netflix is doing coupling and "synchronous" calls, that's why they have all the cool frameworks for these sorts of things. But they also have a specific use-case, which might not be the same as yours.

Upvotes: 2

Related Questions