2

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.

Community
  • 1
  • 1
melpin
  • 33
  • 2
  • 6
  • It really depends how the services are designed. Could you paste some diagram of architecture? How services communicates each other? – comprex May 08 '17 at 14:46
  • 1
    Have the sales service own the data it needs without going to the products service. Then you don't need the call. – tom redfern May 08 '17 at 14:48
  • @comprex I added the diagram in the question. The microservices communicates with REST. – melpin May 08 '17 at 15:31
  • Do you use an event-driven architecture? – Constantin Galbenu May 09 '17 at 06:28
  • @ConstantinGALBENU No, I'm not using. – melpin May 09 '17 at 12:07
  • Then, in order to avoid `cascade failure` of microservices, you should replicate periodically the required data from one microservice to others, possible using an anti-corruption layer (if you use the DDD approach). BTW, coupling will always exists in any system, the idea is to minimize the impact when one microservice is not responsive anymore – Constantin Galbenu May 09 '17 at 12:53
  • @ConstantinGALBENU you mean something like I have an AMQP queue and recieve a sale and with the sale I have a product, but I don't need all information about the product, so, I just get the useful information I need to generate the graphic and save into the sale-service database? And when I need I already have the data on the same place and don't need to call product-service. – melpin May 09 '17 at 14:59
  • Yes. You replicate only what you need. – Constantin Galbenu May 09 '17 at 15:01
  • For example, we have more then 1500 clients using our software, each one have more or less 45000 products. In this case I will have to replicate some things from the products, but it is not so much data to replicate? And I have to replicate other things from sales or there is some solution for this amout of data? – melpin May 09 '17 at 18:07

5 Answers5

2

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.

Robert Bräutigam
  • 7,514
  • 1
  • 20
  • 38
  • Do you mean that I can have a AMQP and get just the useful information for each service? I have others services that is used by others, like customer. I described my application scenario in the question. Do you think that microservice is not the best approatch for me? – melpin May 08 '17 at 15:34
  • No, I mean it could work, but you'll have to design your architecture around business cases (sales, search, feedback, etc.), instead of "entities" (customer, product, etc.). With that, you could avoid needing information from other services, regardless of communication technology. – Robert Bräutigam May 08 '17 at 15:39
  • I tried to do that. I designed my architecture around business cases more or less, for example, in sale-service I have a lot of things relationed but in my case it's hard to think in the best design because it's a drougstore/pharmacy ERP and we have a lot of things that needs data from customers, sales, payments and other things. Is it possible use microservice concepts for ERP or it's not the best thing to use because there are things related like sales and shopping with products? – melpin May 08 '17 at 18:02
  • You can try to decouple the data ingestion from 3rd party systems. So instead of calling some product management system whenever you need some data about a product, you can let each service manage their data ingestion/synchronization separately from the business logic. It's hard to tell what would fit your exact use-case, but there are other ways than chain-calling through multiple layers of services. – Robert Bräutigam May 08 '17 at 18:06
1

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

Brother
  • 2,150
  • 1
  • 20
  • 24
0

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.

ootero
  • 3,235
  • 2
  • 16
  • 22
  • I already have eureka, zuul and others things related with Spring Cloud. I did that diagram just to illustrate my services and its coupling. – melpin May 08 '17 at 20:07
0

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/

Dinusha
  • 696
  • 1
  • 14
  • 27
0

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.

Vijay Parmar
  • 795
  • 4
  • 13