Organizations with deep roots in different fields are trying to discover similar software building patterns. The hope is that these systems will be more robust, resilient, flexible, and better able to meet the needs of modernity.

Application requirements have changed dramatically in recent years, and schema changes have come with them. Just a few years ago, a large application typically had dozens of servers, second-level response times, hours of maintenance, and gigabytes of data. Today, applications are deployed on a variety of devices, from mobile devices to cloud clusters running thousands of multi-core processors. Users expect millisecond response times and services that are 100% up and running (ready to go). The data is measured in PB. Yesterday’s software architecture is simply not enough for today’s needs.

We believe that you need an architectural design solution that covers the entire system, and the various aspects that must be addressed in the design have been clarified. We need the system to have the following characteristics: Responsive, Resilient, Elastic, and Message Driven. We call such a System a Reactive System.

Reactive systems are more flexible, loosely coupled and scalable. This makes them easier to develop and adapt. They are also more tolerant of systemic failure, and when failure does occur, their response is tactful rather than chaotic. Reactive system is highly responsive and provides users with efficient interactive feedback.

Characteristics of reactive systems: Immediate responsiveness: Whenever possible, the system will respond in a timely manner. Instant response is the cornerstone of usability and utility, but more importantly, instant response means that problems can be quickly detected and dealt with effectively. Just-in-time systems focus on providing fast and consistent response times, establishing reliable feedback ceilings to provide consistent quality of service. This consistent behavior, in turn, simplifies error handling, builds end-user trust, and encourages further user interaction with the system.

Resilience: The system remains responsive in the event of failure. This isn’t just true for highly available, mission-critical systems — any system that isn’t resilient will lose its responsiveness after a failure. Resilience is achieved through replication, containment, isolation, and delegation. The spread of failure is contained within each component, isolated from other components, ensuring that a failure in one part of the system does not compromise the entire system and can be recovered independently. The recovery of each component is delegated to another (external) component, and replication can be used if necessary to ensure high availability. The client of the component is no longer responsible for handling component failures.

Resilience: The system remains responsive to changing workloads. A reactive system can respond to changes in the rate of inputs (loads) by, for example, increasing or decreasing the resources allocated to service those inputs (loads). This means that there are no points of contention and central bottlenecks in the design, allowing components to be sharded or copied and inputs (loads) to be distributed between them. Reactive systems can support both predictive and reactive scaling algorithms by providing relevant real-time performance indicators. These systems can be cost-effective and flexible on both conventional hardware and software platforms.

Message-driven: Reactive systems rely on asynchronous messaging to ensure clear boundaries between loosely coupled, isolated, and transparently located components. This boundary also provides a means of delegating failures as messages. With explicit messaging, load management, resilience, and flow control can be achieved by shaping and monitoring message flow queues in the system and applying backpressure when necessary. Using location-transparent messaging as a means of communication makes it possible to manage failures using the same structural components and semantics across clusters or within a single host. Non-blocking communication allows the receiver to consume resources only when active, thereby reducing system overhead.

A large system consists of several smaller systems, so the overall utility depends on the reactant properties of their components. This means that reactive systems apply design principles that allow these properties to work at all levels of scale and to be composable. The world’s largest systems rely on architectures based on these attributes and serve the needs of billions of people every day. Now is the time to consciously apply these design principles from the beginning of the system design, rather than rediscovering them every time.

From: www.reactivemanifesto.org/zh-CN