Design patterns for six micro-service architectures (RPM)

Original address: http://my.oschina.net/sourcecoding/blog/496068

Not long ago, Java Code Geeks published an article analyzing the pros and cons of monomer applications and microservices. Recently, the site published an article, providing six types of micro-service architecture design patterns.

Aggregator Micro-service design pattern

This is one of the most common and simplest design patterns, as shown in:

The aggregator invokes the functionality required by multiple services to implement the application. It can be a simple Web page that will retrieve the data to be processed for presentation. It can also be a higher-level combination of microservices, which adds business logic to the retrieved data and is further released into a new microservices, which conforms to the dry principle. In addition, each service has its own cache and database. If the aggregator is a composite service, it also has its own cache and database. The aggregator can be scaled independently along the X and Z axes.

Proxy microservices Design pattern

This is a variant of the aggregator pattern, as shown in:

In this case, the client does not aggregate the data, but calls different microservices depending on the difference in business requirements. The agent can simply delegate the request, or it can perform data conversion work.

Chain Micro Service Design pattern

This pattern produces a merged response after the request is received, as shown in the following:

In this case, service a receives the request and communicates with service B, similarly, service B communicates with service C. All services use synchronous message delivery. The client blocks until the entire chained call is complete. Therefore, the service call chain should not be too long to avoid the client waiting for a long time.

Branch MicroServices Design Patterns

This pattern is an extension of the aggregator pattern, allowing the simultaneous invocation of two microservices chains, as shown in:

Data sharing microservices Design Patterns

Autonomy is one of the design principles of microservices, which means that microservices are full-stack services. However, when refactoring an existing monolithic application (monolithic application), the SQL database de-normalization may result in data duplication and inconsistency. Therefore, this design pattern can be used in the transition phase of the monomer application to the MicroServices architecture, as shown in the following:

In this case, some microservices may share the cache and the database storage. However, this is only possible if there is a strong coupling relationship between the two services. This is an anti-pattern for new microservices-based applications.

Asynchronous messaging micro-service design pattern

While the rest design pattern is very popular, it is synchronous and can cause blocking. Therefore, some microservices-based architectures may choose to use Message Queuing instead of rest request/response, as shown in:

Original address: Http://www.infoq.com/cn/weifuwu

Design patterns for six micro-service architectures (RPM)