1. Microservice Architecture Mode Solution
Use the Scale Cube method to design the application architecture, and split the application services into a group of cooperating services according to their functions. Each service is responsible for a specific, related set of functions. Each service can have its own independent database, thus ensuring decoupling from other services.
1.1 Aggregator microservice design pattern
The aggregator calls multiple services to implement the functionality required by the application. It can be a simple web page that processes and displays the retrieved data. It can also be a higher-level composite microservice, which adds business logic to the retrieved data and then publishes it into a new microservice, which is in line with the DRY principle. Also, each service has its own cache and database. If the aggregator is a composite service, then it also has its own cache and database. Aggregators can scale independently along the X and Z axes.
1.2 Proxy microservice design pattern
This is a variant of the aggregator pattern. In this case, the client does not aggregate data, but calls different microservices according to the differences in business needs. A proxy can simply delegate requests, or it can do data transformation work.
1.3 Chained microservice design pattern
This pattern produces a merged response after receiving a request. In this case, service A communicates with service B after receiving the request, and similarly, service B communicates with service C. All services use synchronous messaging. The client will block until the entire chain of calls is complete. Therefore, the service call chain should not be too long to prevent the client from waiting for a long time.
1.4 Branch microservice design pattern
This pattern is an extension of the aggregator pattern, allowing simultaneous calls to two microservice chains
1.5 Data Sharing Microservice Design Pattern
Autonomy is one of the design principles of microservices, which means that microservices are full-stack services. But when refactoring an existing "monolithic application," SQL database denormalization can lead to data duplication and inconsistency. Therefore, this design pattern can be used in the transition stage of monolithic application to microservice architecture
1.6 Asynchronous messaging microservice design pattern
While the REST design pattern is very popular, it is synchronous and can cause blocking. Therefore, some microservice-based architectures may choose to use message queues instead of REST request/response