Shulou(Shulou.com)06/02 Report--

This article focuses on "how to use the fuse pattern of common architectural design patterns". Interested friends may wish to take a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to use the fuse pattern of common architectural design patterns.

Fuse

The fault problem should be taken into account in the design of distributed system. At present, micro-services have been widely used, and most of these services rely on other remote services. Remote services may not be able to respond in time because of network, application load and other reasons. In most cases, these problems should be solved by retrying.

But there are also extreme cases, such as service downgrade or complete failure of the service itself. In this case, there is no point in continuing to try again. So fuse mode can come in handy.

Fuse

The figure above shows the implementation of the fuse pattern. When service 1 learns that there is a continuous failure / timeout when invoking service 2, service 1 does not retry, but skips calling service 2 and returns the response immediately.

There are some popular open source libraries, such as Netflix's Hystrix, that can be used to implement this pattern very easily.

If you are using an API gateway or a sidecar proxy such as Envoy, it can be implemented at the agent level itself.

Note: it is important to have sufficient logging and alerts when the fuse is turned on to track requests received during this period and to make this information known to the operations team.

You can also implement fuses in a half-open case to continue to serve customers who can tolerate service degradation.

When to use this mode

When a service relies on another remote service and is likely to fail in some cases

When a service has a strong dependency (for example, a master data service).

When not to use this mode

Fuses may incur overhead when you are dealing with local dependencies.

Command and query responsibility isolation (CQRS)

CQRS is a very useful schema for modern applications that use data storage. Its principle is to separate the read (query) and write / update (command) operations in the data store.

Suppose you are building an application that needs to store data in a MySQL/PostgreSQL database. As we all know, when writing data to a data store, an operation takes several steps, such as validation, model, and persistence, so a typical write / update operation takes longer than a simple read operation.

When you use a single data store to perform both read and write operations, and the traffic is high, you may begin to experience performance problems.

In this case, the CQRS mode can be useful. The CQRS mode recommends the use of separate data stores for read and write operations.

CQRS

Note: most PaaS databases now provide the ability to create read replication (Google Cloud SQL, Azure SQL DB, Amazon RDS, etc.) for data stores, which makes it easier to implement CQRS.

If you are dealing with private databases, many enterprise databases also provide this feature.

Note: nowadays, some people also like to use fast, high-performance NoSQL databases, such as MongoDB and Elasticsearch, for read replication.

When to use this mode

When you are considering extending an application that expects a lot of reading and writing.

When you want to adjust the performance of read and write operations separately

When your read operation can accept near real-time or final consistency

When not to use this mode

When you are building a regular CRUD application, there is not always a lot of reading and writing.

Event traceability (Event Sourcing)

Event traceability is an interesting design pattern in which the sequence of domain events is stored as a log, and the aggregate view of the log shows the current state of the application.

This pattern is commonly used in systems that cannot withstand data storage locks and requires maintenance of audit and history of events, such as hotel / conference / seat reservation applications.

Trace the source of the event

For example, a hotel room reservation system in which users need to book or cancel reservations. Here, you need to store reservations and cancellations as a series of events. Before each reservation, the aggregate view shows the available rooms by looking at the event log.

Note: most cloud service providers support messaging services, such as Google Pub/Sub, Azure Service Bus, AWS SQS, etc. These services, combined with powerful consistent data storage, can be used to implement this pattern.

When to use this mode

When the regular CRUD operation can not meet the demand very well.

It is usually suitable for seat reservation systems, such as buses, trains, conferences, cinemas, etc., or e-commerce systems composed of shopping cart operation, payment and other events.

When powerful auditing and event playback are needed to create the current and past state of the application.

When not to use this mode

When regular CRUD operations are sufficient to meet the needs of users.

At this point, I believe you have a deeper understanding of "how to use the fuse pattern of common architectural design patterns". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.