The concept of "reactive programming"

Most of the content below is translated.

REACTIVE programming?

What is reactive programming?

To understand the motivations behind the reactive--from the programming paradigm, it is important to understand the challenges that developers and companies have not faced ten years ago.

There are two major aspects of game change:

• Hardware improvements
• Internet

Why things is different now?

(compared with the 2005 and 2014 growth of the special users: 1 billion to 2.95 billion; the growth of Facebook users: 5.5 million to 1.3 billion; Twitter has no, 0 to 270 million users)

Times have changed, and now a website needs to deal with the entire Internet traffic ten years ago. It is easy to discover that software is becoming more and more important for everyday life. It is also easy to see that some of the previous paradigms are no longer applicable to the present, and not to the future.

The four reactive principles

Reactive applications is built on four guiding principles.

• The goal is a responsive program.
• A responsive program must be both scalable and resilent.responsiveness to leave scalability and resilence is impossible to achieve
• A message-driven architecture is the Scalale, resilent, and ultimately the basis for responsive systems

Let's understand each of these principles at the top and understand why they are integral to developing a software that works for today's environment.

Responsive

What do we say when we say that a program is "responsive"?

A responsive system is quick to react to all users-under blue skies and grey skies-in order to ensure a consistently pos Itive user experience.

A responsive system is a quick response to all users – no matter if it's cloudy and sunny – to ensure an always-positive user experience.

The "fast" and "integrable" user experience under various conditions, such as an external system problem or a surge in traffic, relies on the two traits of reactive application: resilence, and scalability. A message-driven architecture provides the basis for a responsive system.

Why is message-driven architecture so important for responsiveness?

The world is asynchronous.

If you have a cup of coffee now, you will find that the sugar and cream are gone.

One approach is to:

• Start Cooking Coffee
• Go to the store to buy sugar and milk?
• Go home
• Everything's up, start drinking coffee.
• Enjoy life

Another approach is to:

• Go to the store and buy sugar and cream.
• Go home
• Brewed Coffee
• Wait for the coffee to boil.
• Endure caffeine shortages
• Collapse

As you can see, a message-driven architecture provides you with an asynchronous boundary (asynchronous boundary) that frees you from time and space. In the remainder of this article we will continue to delve into the concept of asynchronous boundaries. (This example is very good, but I do not see this example is related to the message-driven)

consistency at Walmart Canada consistency to Canada Amazon

This consistency is not the same as the consistency of the distributed system ... ）

Before joining Typesafe, I was the technical leader for the play and Scala team that built Amazon Canada's new e-commerce platform.

Our goal is to provide a consistent and positive user experience, regardless of:

• No matter what type of physical device is used to access walmart.ca, do not set it as a desktop, tablet or mobile device
• Current peak traffic, whether it's due to a surge, or a durable
• A major infrastructure is not available, such as an entire data center.

The response time and overall user experience must be consistent, regardless of whether the above situation occurs. Consistency is critical to your site, because right now, this is your brand. A bad user experience is hard to forget or ignore, whether it happens online or in a line store.

Responsive retail at Gilt

Gilt's responsive retail. The consistency of the e-commerce sector (the importance) does not happen. Like gilt, gilt is a flash-shopping site that has a spike in traffic every day at noon when they release sales on the day.

Let me consider the user experience of the next Flash shopping site. If you visited gilt,12:01 at 11:58 and visited it again. Then you want two visits to have a positive experience, whether it's gilt at 12:01 and the traffic bursts.

Gilt offers an always-active, responsive user experience, and it's all done through reactive. Learn about Gilt's migration to the Scala-based microservices architecture (scala-based microservices architecture) Through this ReadWrite interview with Eric Bowman of Gilt.

Resilient

Most of the programs are designed and developed for "sunny days", but things can go bad. Every few days there will be reports that a major application is unavailable, or because the hacker's attack caused the service to be unavailable, data loss, or damage to the store reputation.

A Resilient system applies proper design and architecture principles in order to ensure responsiveness under grey skies as well as blue.

A resilient system employs a number of design and architecture principles that make it responsive, regardless of external conditions.

Both Java and the JVM are used to seamlessly program an application to multiple operating systems, and, similarly, 201x years of inter-connected applications are about the combination, connectivity, and security of the app hierarchy. (Note: This sentence is a bit around ...) Ignore, look at the bottom)

Today's programs are mostly assembled from a number of other programs, and are integrated through Web service and other network protocols. Now an application may depend on a large number of other services--10,20 or more, and the services it relies on are outside of its own trusted firewall (trust firewall). It may also be providing services to a large number of external users-including people and other systems.

Given the complexity of integration, how many developers:

• Analyze and model all external dependencies
• Combine the ideal response time for each service into a document, perform performance testing-at peak and normal-to fully assess initial expectations
• Encode all expectations, failure scenarios, and other non-functional requirements into the core logic of the system
• Analyze and test the impact of failure scenarios for each service
• Analyze each externally dependent security to identify whether the integration of this external dependency poses the greatest security risk to the system

Resiliency is one of the weakest links of even to the most sophisticated application, but resilency as an afterthought will soon end. Modern procedures must be resilent at its core to keep the responsive in the real-world environment, not just in the ideal situation. Performance, durability, and security are all aspects of resilency. Your app must be resilent at all levels.

Message-driven Resiliency

The beauty of building apps on a message-driven kernel is that you naturally get a lot of valuable building blocks.

Isolation Isolation is required for a self-healing (self-heal) system. When isolation is used properly, we can separate different types of work based on factors such as the risk of failure, different performance, CPU and memory usage, and so on. The failure of a isolation component does not affect the responsiveness of the entire system and gives the system of failure a chance to be cured.

Location Transparency position transparency allows us to communicate with different processes on different cluster nodes just like in-process communication with the same VM.

a dedicated separate error channel a well-designed separation of erroneous information channels allows us to redirect error signals to other places, rather than throwing them back at the caller. ( Note: This action should be typed in the event stream of Akka, which allows certain failed messages to be subscribed so that not only the component that is currently calling a failed component can know that it has failed, but that all related components can understand the situation, Make it easy for them to respond)

These factors help us consolidate robust error handling and fault tolerance into our systems. The implementation of Akka's supervisor hierarchies shows this.

These core building blocks provided by the message-driven architecture help resiliency, and thus help responsiveness--not only in an ideal situation, but also in a variety of scenarios that are not ideal, real-world situations.

The million dollar resiliency mistake

Let's see what the Knight Capital Group experienced during the 2012 software failure (software glitch experienced by Knight). In a software upgrade, another dormant, integrated program is inadvertently awakened, and the volume is started to zoom in.

What happened in the next 45 minutes was a nightmare.

The automated trading system of Knight Capital floods the wrong trade with NASDAQ (NOTE: NASDAQ), allowing the company to enter a position that costs $ billions of. After that, the company spent $440 million to reverse the situation. In this failure, Knight Capital can not stop the water-like wrong trade, Nasdaq had to end the Knight capital to stop all this. Knight Capital's stock fell 63% a day, almost unable to survive as a company, only to wait for its shares to regain some value after being taken over by some investors.

The system of Knight Capital is high-performance, but not resilent. High performance but no resilience makes the problem magnified, as Knight Capital finds. They don't even have a stop switch to make their system stop trading when there are serious problems, so when it's really a problem, their automated trading system exhausts the entire company's capital within 45 minutes.

This is the result of designing and developing programs that can only be used for "sunny days". Today, software is a key component of our private life and business. If we do not design and prepare for the "cloudy" situation, then even if this situation only exists in less than one hours, it will also cause us huge losses.

Scalable

Resililency and scalability hands, together to build always responsive procedures.

A scalable system is easily upgraded on demand in order to ensure responsiveness under Varioius load conditions.

An extensible system can easily be upgraded when faced with different workloads to ensure respnsiveness

Anyone who sells something on the internet knows the truth: your biggest traffic is when you sell the most stuff. Unless the sudden increase in traffic is due to deliberate hacking, it is a good thing to expect a sudden increase in traffic. In a burst of traffic, people are willing to pay you.

So how to deal with this sudden increase in traffic, or a long but large amount of traffic growth.

First choose your paradigm (paradigm) and then choose the language and tools that embrace this paradigm. In many cases, developers simply choose the language and framework .... Once you've chosen a tool, it's hard to change it back. So, just like you're dealing with any major investment, make these decisions. If your technology choice is based on some principles and analysis, then you are one step ahead.

thread-based Limitations to concurrencylack of thread-based concurrency

A critical technology choice is the concurrency model of the framework. At a higher level, there are two concurrency models:

• Traditional thread-based concurrency model, based on call stacks and shared memory
• Message-driven concurrency

Some popular MVC frameworks, such as rails, are CAI threads. Typical features of this type of framework include:

• Shared mutable State
• One thread per request
• Concurrent access to mutable states-variables and object instances-are managed using locks and other complex synchronization structures

These features, combined with dynamic types, interpreted languages such as Ruby, can quickly reach the upper limit of performance and extensibility. You can think of all the languages that are essentially scripting languages.

Out or up?

Let's consider the different ways to extend an application.

Scaling up is about maximizing the resources that take advantage of a cpu/server, usually by purchasing a more powerful, dedicated, and expensive machine.

Scaling out is about distributing the computation to a cluster of inexpensive commdity machines. This is more cost-effective, but if your system is based on the concept of time and space (note: "Time-based" can assume that the program's actions are synchronous, need to block, wait, "space-based" can be considered based on a process internal memory sharing, such as non-threading shared variables) , it is very difficult to scale out. As we mentioned earlier, a message-driven architecture provides the asynchronous boundary (asynchronous boundary) required to decouple from time and space, providing the ability to scale out (scaled out on demand) as needed. This ability is also called elasticity. Scaling up is about using existing resources more efficiently, and elasticity is about adding new resources as needed when the system needs to change. The ability to "scale out and on demand" is the ultimate goal of reactive programming in terms of extensibility.

Reactive applications are difficult to build on a thread-based framework, and think about how difficult it is to put a program based on mutable states, threads, and locks out. Developers need to take advantage not only of the multicore on a single machine, but also the power of a computer cluster at some point. Sharing mutable states also makes scale up difficult, even if not impossible. Anyone who has tried to manipulate the mutable state of two thread sharing can understand how complex it is to ensure thread safety, and can also understand the performance penalty of the extra effort required to ensure thread safety.

Message-driven

A message-driven architecture is the foundation of a reactive application. A message-driven program can be event-driven (Event-driven), actor-based (actor-based), or a combination of both.

An event-driven system is event-based and these events are monitored by one or more listeners. This differs from the imperative programming, so the caller does not need to block to wait for the response of the invoked routine. Events are not directed at specific addresses, but are monitored, and we will discuss their implications in more depth.

Actor-based concurrency is an extension of the messaging architecture in which messages can span thread boundaries or be passed to another actor's mailbox (mailbox) on different physical machines, in an actor-based concurrency schema. This makes Elasticity--scale out on demand--possible, because actors can be distributed throughout the network, but can still communicate as they do in the same VM.

The difference between a message and an event is that the message has a direction, and the event is just "happening" and there is no direction. The message has a clear purpose, and the event can be monitored by one or more listeners.

Let's dive into the next event-driven and message-based concurrency.

Evnt-driven concurrency

Typical programs develop with the style of the command-a linear sequence of commands-and are based on the call stack. The main function of the call stack is to trace the caller of the routine (routine, which is supposed to be a function) , execute the invoked routine while blocking the caller, return the control flow to the caller when execution is complete, and returns the value of the execution result (or no return)

Event-driven programs do not focus on the call stack, but instead focus on triggering events. Events can be encoded into messages, placed in queues, and monitored by one or more listeners. The big difference between event-driven and imperative is that the caller is not blocked and does not have to occupy a thread while waiting for a response (caller does not block and holds onto a thread while waiting for a response). The event loop itself can be single-threaded, but it can still be implemented concurrently, because the routine can be called at the same time (sometimes a single-threaded) event loop to process a new request (note: Because the call to the routine is made non-blocking, Event-loop is not blocked). It is no longer blocking a request, waiting for it to be processed, and now the caller's identity can be passed along with the request message itself so that (if the invoked routine chooses to do so) the caller can be called back, passing the response on the callback (the caller can called back with a Response).

The main result of choosing an event-driven architecture is that they can encounter a phenomenon called Callback Hell (callback Hell) http://callbackhell.com. Callback hell occurs because the recipient of the message is an anonymous function rather than an addressable recipient (addressable recipients). The usual solution is to focus only on syntactic-aka, the Pyramid of doom- This ignores the difficulty of deriving and debugging subsequent events arising from the event expressed in the code.

actor-based concurrency

Actor-based programs are centered on asynchronous message passing between multiple actors.

An actor is made up of the following attributes:

• Mailbox for receiving messages
• The logic of the actor, which relies on pattern matching (pattern matching) to determine how the actor handles different types of messages
• The state of the isolation, isolated state, rather than the status of the share. Use the state of isolation to store the context between requests.

Like event-driven concurrency, actor-based concurrency bypasses the call stack and shifts to lightweight messaging. Actors can return and send messages, and even pass messages to themselves. A message can be passed to its own message, allowing it to process other messages in the queue before ending a long-running request. One great benefit of actor-based concurrency is that it can have not only the benefits of event-driven concurrency, but it also makes it easier to cross network boundaries and avoids callback hell because messages are directed to the actor. This is a powerful concept that helps to construct highly scalable programs that are easy to design, implement, and maintain. Regardless of "space" and "time", or the deep nesting of callback functions, you just need to consider the flow of messages between actors.

The main benefit of another actor-based architecture is decoupling between components. Callers do not have to block their threads waiting for a response, so callers can quickly move on to other work. The invoked routine, encapsulated in an actor, simply responds to the caller in the required reply. This opens up a number of possibilities, such as distribution routines (routines) into a cluster, because no more call stacks are coupled to a single memory, and the actor model can make the deployment of a topology (topology) a virtual configuration and no longer be encoded in the program.

Akka is a part of the actor-based toolkit and runtime-typesafe reactive platform, used to construct concurrent, distributed, fault-tolerant, actor-based programs that run on the JVM. There are other Akka features that are used to construct reactive application, such as supervisor hierarchies for Rsilience, and the ability to distribute work to achieve extensibility. In-depth research on Akka is beyond the scope of this article, but I highly recommend visiting let it Crash blog for more information about Akka.

I also highly recommend reading Benjamin ERB's diploma thesis,concurrent programming for Scalable WEB architectures, which is used for reference in this section.

Conclusion

The above describes the surface of today's software development, and leads us to recognize why reactive programming is not just a trend, but a paradigm that software developers now need to learn. Regardless of the language and tools you choose, prioritizing scalability and resilient to achieve responsiveness is the only way to meet the needs of your users. Every year, this becomes more important.

Want to learn by hand? Download Typesafe Activator and start building your reactive applications today. (Advertising ...) )

Here's another article

• Reactive

  is readily responsive to a stimulus

  • React to Events (Event-driven)
  • React to load (scalable)
  • React to failures (resilient)
  • React to users (responsive)

• Event-driven

  Systems is composed from loosely coupled event handlers.

  • Events can be handled asynchronously, without blocking.
• Scalable

  An application is scalable if it's able to being expanded according to its
  Usage.

  • Scale up: make use of parallelism in multi-core systems
  • Scale out: Make use of multiple server nodes

  Important for Scalability:minimize gkfx mutable state.
  Important for scale out:location transparency, resilience.

• Resilient

  An application are resilient if it can recover quickly from failures.
  Failures can be:

  • Software failures
  • Hardware failures
  • Connection Failures

  Typically, resilience cannot is added as an afterthought; It needs to be
  Part of the design from the beginning.
  Needed:

  • Loose coupling
  • Strong encapsulation of State
  • Pervasive supervisor Hierarchies
• Responsive

  An application are responsive if it provides rich, real-time interaction with
  Its users even under load and in the presence of failures.
  Responsive applications can be built on an event-driven, scalable, and
  Resilient architecture. Still need careful attention to algorithms, system design, back-pressure, and many other details.

The concept of "reactive programming"