This series of articles index the "Response Spring's word Wizard"
Previously feed-responsive programming | Responsive flow
1.5 Responsive System 1.5.1 Response declaration
It's not hard to follow a "responsive" friend's search for an introduction to the "Responsive Manifesto," first:
This map embodies the wisdom and experience of many great gods, see the official website, the Chinese version of the official website, if you recognize the content of this declaration, you can also sign your name. Although these content multi-concept and less actual combat, let a person feel is reading the textbook, but the word of the daughter, sometimes see will have new experience and harvest.
This is also the code of conduct for new Age boyfriends:
- Responsive, to timely response, 24 hours online, not to answer the phone, reply time in 5 minutes or less;
- How to do responsive, the first to resilient, is to respond anyway. Even if you are playing lol, you have to answer the phone, even if you are speaking at the United Nations, then you have to set up "Sorry Baby, call you later" the automatic reply;
- Another point of doing responsive is elastic, which is to respond flexibly to the arrival of a large number of commands. What if there are too many imperial orders on the day of carriage? Sorry, does not exist, if the study does not three heads, then pulls a few friends to help;
- Imperial decree is passed through the asynchronous way (message driven), to flower shop call to order flowers, cake shop to order cakes, etc., do not forget the shopping cart "message queue" to deal with in a timely manner ~ These orders are a certain format and destination of the message , and then asynchronously waiting for the courier door.
Systems built in a responsive system are more flexible, loosely coupled and extensible. This makes them easier to develop and more embracing change. Respond in a timely manner to ensure a good user experience. System errors and anomalies are unavoidable, when the exception appears, to gracefully handle it, do not let it spread, or even reach the user's eyes.
The specific content of the declaration of the official web site is very detailed, not more than repeat.
From the ground up, it is not difficult to think of specific techniques to support the objectives of the Responsive Declaration:
- For example, today's more fiery cloud native and devops concepts and practices, as well as earlier automation operations, all help to make the system more elastic, but the system architecture of micro-service is also indispensable;
- The Hystrix-like fuse (circuit breaker) makes the system more resilient, because it can prevent the service anomaly in a controllable range in time, avoid avalanche, and the cloud-native application like Kubernetes can discover and reconstruct the abnormal service in the system in time;
- Message Queuing products like RABBITMQ and ACTIVEMQ help to build a message-driven system and play a role of decoupling, speed-up, broadcasting, and clipping.
- The message-driven system is advantageous to the elasticity and reliability, and the elasticity and reliability make the system response more timely.
- Wait a minute.
1.5.2 responsive programming and response system
A responsive manifesto is a set of architecture and design principles that a system that conforms to these principles can be thought of as a responsive system. and responsive system and responsive programming are different levels of content.
See some articles on the Internet in the introduction of Rxjava, reactor and other responsive programming technology, will use the response declaration to elicit the topic, a little bit of donkey lip to the mouth of the Horse (^_^). Responsive systems (or responsive declarations) and responsive programming are a couple of two terms that can easily be rubbed together (the last couple of easy-to-mix terms are "responsive programming RP" and "functional-responsive programming FRP", see 1.3.1 Lambda and functional), which are less relational than "Lei Feng" and "Leifeng Tower ", Java and JavaScript are so far away, but there is no inevitable causal relationship.
As the author of the Responsive Manifesto, Jonas Bonér and Viktor Klang explained the differences and linkages between responsive programming and responsive systems ("Linux China" has translated versions), which also read the four principles of the Responsive manifesto, which is worth learning. I've summed up some of the differences between the two:
1) The difference between tactics and strategy
Responsive programming is a subset of asynchronous programming, a paradigm that has a specific development library, focusing on the flow of information/data flow rather than the command-style control to drive the logic forward.
The Responsive Manifesto is a set of design principles, a way of thinking about system architecture and design in a distributed environment, a system that conforms to this architectural style.
2) The difference between event-driven and message-driven
Responsive programming-focusing on computation on a short-term data flow chain-tends to be event-driven, while responsive systems-focused on the elasticity and reliability of communication and collaboration through distributed systems-are message-driven.
The response declaration defines the difference between message-driven and event-driven:
A message is a piece of data that is sent to a definite destination. An event is a signal sent to a component that reaches a given state. In a message-driven system, an addressable recipient waits for a message to arrive and then responds to it, otherwise it remains dormant. In an event-driven system, the listener of the notification is bound to the message source so that it is called when the message is emitted. This means that an event-driven system is focused on the addressable event source while the message-driven system is focused on the addressable receiver.
3) The difference between the range of components and the system range
The "active scope" of responsive programming is within the component, a technology that manages the internal logic and data flow of a component or service, even if the flow of traffic from service B to service A is not a cross-service message delivery, just like in the 1.4.2 section, but is an API-based call.
A responsive system that emphasizes the exchange of information between components/services and provides a principle for dealing with the elasticity and reliability of distributed systems through a responsive manifesto, and therefore is distributed to the system-wide.
4) Differences in spatial decoupling capabilities
As the asynchronous invocation approach described earlier, event-driven, responsive programming focuses on decoupling in time, providing a more high-performance concurrency approach at the technical level. However, its scope limits its ease of decoupling in space.
The message-driven asynchrony makes the response system both decoupled in time and has the ability to decouple the space. The service room can not only realize distributed collaboration through message queue, but also can realize the elastic scaling of individual service according to the load, thus realizing the ability of elastic in the response declaration.
5) Summary
Responsive programming techniques are typically used to perform asynchronous, non-blocking processing of data flows in a single node or service. When there are multiple nodes, you need to carefully consider data consistency (consistency), cross-node communication (Cross-node Communication), coordination (coordination), versioning (versioning), The content of Orchestration (orchestration), error management (failure management), separation of concerns and responsibilities (concerns and responsibilities), and so on, are what the responsive system architecture considers.
Similarly, spring Webflux is a responsive programming framework for developing responsive applications, and spring cloud is not only a set of design principles that are tailored to the objectives and responsive systems of the microservices architecture in today's cloud-native environments, closer to the responsive manifesto.
It should be seen, however, that the demand for responsive, resilient, elastic and message driven of modern systems in the Responsive manifesto has made the call for responsive programming technology increasingly high, Obviously, responsive programming is one of the appropriate tools for building a responsive system. Especially with the reactive STREAMS specification , a top-level design that responds to a responsive manifesto, like reactor, RxJava, Vert.x, Spring Responsive programming techniques such as Webflux are bound to play a more and more important role in the response-type system.
The topic of the response system is relatively large, involving many ideas and techniques. This series of articles still focuses on the scope of responsive programming, and finally discusses the application of responsive programming in spring cloud.
(10) Responsive Manifesto, responsive system and responsive programming--response spring's Word Wizard