Scene description

In the microservice architecture, each microservice is responsible for its own database, and microservice A is not allowed to directly connect to microservice B’s database for operation.

Now there are two micro services, one is the order service, one is the user service.

There is a requirement for data reporting: generate an order report with user information.

This requires retrieving the data from the two services for connection summary.

How do you build this data reporting service?

Solution 1 Directly connects to the database

Directly connect the order service, user service database, obtain the required data, after getting processing can be.

Very simple, but with obvious problems.

The first is to break the principle of micro services mentioned above, directly to connect to other people’s database, too rude.

A more serious problem is what if the database table structure of the order service and the user service changes?

Reporting services have to change along with it, too sensitive.

Scheme 2 Data aggregation

Instead of connecting directly to the data, the REST API interfaces of the two services are called to get the desired data.

The problem of the previous scheme is solved, but the biggest problem of this method is poor performance.

The reporting service needs the latest data and accesses these two services frequently. As the data size increases, the performance of all three services decreases.

Scheme 3: Pull data in batches

Set up your own database for the reporting service, using a timing program to batch pull data from the databases of the two services and store it in your own database.

We solved the problem of the last solution and got a significant performance improvement, but we seem to have reverted to the problem of the first solution, breaking the principles of microservices and being extremely sensitive to changes in the data table structure.

The advantage is that having your own database is much more convenient and has better performance.

Scheme 4 Event push model

In order services, or user services, the data table comes back, generates an event, publishes it to a messaging system (such as Kafka), reports the service’s subscription to the topic, and writes the received data to its own database.

Benefits:

  • Loosely coupled, there is no call relationship between business services and reporting services, either at the business interface layer or the database layer.

  • Data consistency is good, quasi-real-time, business service data table immediately send event messages, reporting services can be quickly consumed.

  • Good performance. With the increase of data throughput, the reporting service can increase workers to process events and provide processing capacity.

  • Scalability allows for additional data processing requirements, such as real-time analysis, and more business system data may be analyzed rather than just order reporting, when the new service only needs to send its data change events to the messaging system.

Write in the last

Welcome to pay attention to my public number [calm as code], massive Java related articles, learning materials will be updated in it, sorting out the data will be placed in it.

If you think it’s written well, click a “like” and add a follow! Point attention, do not get lost, continue to update!!