Reactive Programming: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(33 intermediate revisions by the same user not shown)
Line 4: Line 4:
* [[Java 9 Reactive Streams#Overview|Java 9 Reactive Streams]]
* [[Java 9 Reactive Streams#Overview|Java 9 Reactive Streams]]
* [[Stream Processing]]
* [[Stream Processing]]
* [[Universal Scalability Law]]
* [[Queueing Theory]]
* [[Reactive Support in the Spring Framework#Overview|Reactive Support in the Spring Framework]]


=Overview=
=Overview=
Line 9: Line 12:
The underlying principles of reactive applications inform overall system design.
The underlying principles of reactive applications inform overall system design.


Message-driven runtime.
Message-driven runtime. One of the key elements to reactive programming is being able to execute tasks asynchronously. Reactive runtimes use an event loop or a shared dispatcher infrastructure based on a thread pool. This allows sharing threads, which are expensive resources, among cheaper constructs: actors. It can be seen as a multiplexing technique. This approach allows for a pattern where we can afford to have one actor per a specific entity in the system, where entities can be quite large in number. <font color=darkgray>State synchronization issue.</font> Reactive applications must avoid blocking the event loop, thus making a specific thread (which can sometimes be the only thread in the system) unavailable. When a reactive application performs such an operation, the thread must be given back to the pool so it can be allocated to other "actors". In this context, blocking is not evil, but needs careful management. Reactive [[#Framework|frameworks]] deal with this issue by isolating the blocking behavior on a different thread pool, that is dedicated for such operations. This technique is called "sandboxing" or "bulkheading".


Programming model.
Programming model.


Resource utilization. Responsiveness is achieved by efficiently using the hardware. Better resource utilization is a component of scalability.
Resource utilization. Responsiveness is achieved by efficiently using the hardware, by using asynchronous APIs and programming techniques. Better resource utilization is a component of scalability.


Decoupling promotes scale-out, as various components can be scaled independently. Asynchronous communication is key to achieve decoupling. It separates the lifecycle of the request initiator from the lifecycle of the request target.
Decoupling promotes scale-out, as various components can be scaled independently. Asynchronous communication is key to achieve decoupling. It separates the lifecycle of the request initiator from the lifecycle of the request target.
Reactive streams.


Same reactive principles apply to the local (application) level of the system and to the distributed system, allowing composing a distributed system from reactive building blocks from bottom up.
Same reactive principles apply to the local (application) level of the system and to the distributed system, allowing composing a distributed system from reactive building blocks from bottom up.


In the academic world, "reactive" stands for "functional reactive programming" (FPR), or "functional reactive activation". This technique is very useful for reactive systems.
In the academic world, "reactive" stands for "functional reactive programming" (FPR), or "functional reactive activation". This technique is very useful for reactive systems.
Back-pressure. When the system uses synchronous API, it is "automatically" back-pressured by the blocking operations. With asynchronous APIs, we may be in the situation of performing the logic more intensely and overwhelm some other slower downstream parts of the application or systems. The back-pressure (or flow-control) mechanism helps with this. <font color=darkgray>TODO: https://doc.akka.io/docs/akka/2.4/scala/stream/stream-quickstart.html#back-pressure-in-action</font>
Actors - a task is usually achieved in messaging-based systems by sending a fire-and-forget message that we want to run a job. We can include in that message a flag that we want to be informed about the progress, and we're done on the sending side. Once the job completes, we'll get a message back with its results. Use of actors allow a "own your own data" pattern, which allow them to avoid concurrent access to mutable state.
::[[File:SynchronousVsAsynchronous.png]]
Scaling out - adding more machines. Scaling up - adding more powerful machines.
Reactive systems typically deal with failure by scaling out and replacing failed nodes with new healthy ones.
Reactive-oriented changes can be introduce in the code base using the [[Ivy Strangler Pattern#Overview|Ivy Pattern]].
=Reactive Streams=
An initiative around building concurrent and distributed systems that want to standardize an interop protocol around bounded-memory stream processing. It specifies a low-level interop protocol between various streaming libraries. Reactive streams have been incorporated in JDK [http://openjdk.java.net/jeps/266 JEP-266]. <font color=darkgray>TODO: https://medium.com/@viktorklang/reactive-streams-1-0-0-interview-faaca2c00bec</font>
=Streaming APIs=
Bounded-in-memory processing. We never use more of the data in memory than we actually need. Bounded-memory pipelines. Bounded buffers.
<font color=darkgray>TODO:
* https://dzone.com/articles/why-developers-should-bet-big-on-streaming.
* https://developer.twitter.com/en/docs/tutorials/consuming-streaming-data</font>


=Reactive System Tenets according to the Reactive Manifesto=
=Reactive System Tenets according to the Reactive Manifesto=
Line 34: Line 60:
* [[Lagom]]
* [[Lagom]]
* [[Play]]
* [[Play]]
* [[Netty]]
* [[Akka]]
* [[RxJava]]


=Companies=
=Companies=
Line 48: Line 77:
* http://www.reactive-streams.org
* http://www.reactive-streams.org
* RSocket - steaming message protocol with reactive extension/stream semantics https://github.com/rsocket/rsocket/blob/master/Motivations.md
* RSocket - steaming message protocol with reactive extension/stream semantics https://github.com/rsocket/rsocket/blob/master/Motivations.md
=Organizatorium=
* The benefits of reactive programming is that you can write code that reads closer to the business problem statement.

Latest revision as of 17:03, 10 December 2018

Internal

Overview

The underlying principles of reactive applications inform overall system design.

Message-driven runtime. One of the key elements to reactive programming is being able to execute tasks asynchronously. Reactive runtimes use an event loop or a shared dispatcher infrastructure based on a thread pool. This allows sharing threads, which are expensive resources, among cheaper constructs: actors. It can be seen as a multiplexing technique. This approach allows for a pattern where we can afford to have one actor per a specific entity in the system, where entities can be quite large in number. State synchronization issue. Reactive applications must avoid blocking the event loop, thus making a specific thread (which can sometimes be the only thread in the system) unavailable. When a reactive application performs such an operation, the thread must be given back to the pool so it can be allocated to other "actors". In this context, blocking is not evil, but needs careful management. Reactive frameworks deal with this issue by isolating the blocking behavior on a different thread pool, that is dedicated for such operations. This technique is called "sandboxing" or "bulkheading".

Programming model.

Resource utilization. Responsiveness is achieved by efficiently using the hardware, by using asynchronous APIs and programming techniques. Better resource utilization is a component of scalability.

Decoupling promotes scale-out, as various components can be scaled independently. Asynchronous communication is key to achieve decoupling. It separates the lifecycle of the request initiator from the lifecycle of the request target.

Same reactive principles apply to the local (application) level of the system and to the distributed system, allowing composing a distributed system from reactive building blocks from bottom up.

In the academic world, "reactive" stands for "functional reactive programming" (FPR), or "functional reactive activation". This technique is very useful for reactive systems.

Back-pressure. When the system uses synchronous API, it is "automatically" back-pressured by the blocking operations. With asynchronous APIs, we may be in the situation of performing the logic more intensely and overwhelm some other slower downstream parts of the application or systems. The back-pressure (or flow-control) mechanism helps with this. TODO: https://doc.akka.io/docs/akka/2.4/scala/stream/stream-quickstart.html#back-pressure-in-action


Actors - a task is usually achieved in messaging-based systems by sending a fire-and-forget message that we want to run a job. We can include in that message a flag that we want to be informed about the progress, and we're done on the sending side. Once the job completes, we'll get a message back with its results. Use of actors allow a "own your own data" pattern, which allow them to avoid concurrent access to mutable state.

SynchronousVsAsynchronous.png

Scaling out - adding more machines. Scaling up - adding more powerful machines.

Reactive systems typically deal with failure by scaling out and replacing failed nodes with new healthy ones.

Reactive-oriented changes can be introduce in the code base using the Ivy Pattern.

Reactive Streams

An initiative around building concurrent and distributed systems that want to standardize an interop protocol around bounded-memory stream processing. It specifies a low-level interop protocol between various streaming libraries. Reactive streams have been incorporated in JDK JEP-266. TODO: https://medium.com/@viktorklang/reactive-streams-1-0-0-interview-faaca2c00bec

Streaming APIs

Bounded-in-memory processing. We never use more of the data in memory than we actually need. Bounded-memory pipelines. Bounded buffers.

TODO:

Reactive System Tenets according to the Reactive Manifesto

  • Responsiveness refers to the capability of the system to be consistently responsive to the user and never fail; it refers to the value brought by such systems.
  • Resilience is the capability of the system to self-heal, and refers to form in which reactive systems are delivered.
  • Elasticity is the capability of the system to scale out and up/ in and down across physical and cloud infrastructure refers to form in which reactive systems are delivered.
  • Message-driven refers to the means used to implement reactive systems. A message-driven system is powered by means of asynchronous, non-blocking communication. This enables first and foremost isolation.

Frameworks

Companies

TODO

Organizatorium

  • The benefits of reactive programming is that you can write code that reads closer to the business problem statement.