Building Reactive Systems with Akka (in Java 8 or Scala)

Building
Reactive Systems
with Akka
Jonas Bonér
Typesafe
CTO & co-founder
Twitter: @jboner

The rules of the game
have changed

3
Apps in the 60s-90s
were written for
Apps today
are written for

3
Apps in the 60s-90s
were written for
Apps today
are written for
Single machines

3
Apps in the 60s-90s
were written for
Apps today
are written for
Single machines Clusters of machines

3
Apps in the 60s-90s
were written for
Apps today
are written for
Single core processors

3
Apps in the 60s-90s
were written for
Apps today
are written for
Single core processors Multicore processors

3
Apps in the 60s-90s
were written for
Apps today
are written for
Expensive RAM

3
Apps in the 60s-90s
were written for
Apps today
are written for
Expensive RAM Cheap RAM

3
Apps in the 60s-90s
were written for
Apps today
are written for
Expensive disk

3
Apps in the 60s-90s
were written for
Apps today
are written for
Expensive disk Cheap disk

3
Apps in the 60s-90s
were written for
Apps today
are written for
Slow networks

3
Apps in the 60s-90s
were written for
Apps today
are written for
Slow networks Fast networks

3
Apps in the 60s-90s
were written for
Apps today
are written for
Few concurrent users

3
Apps in the 60s-90s
were written for
Apps today
are written for
Few concurrent users Lots of concurrent users

3
Apps in the 60s-90s
were written for
Apps today
are written for
Small data sets

3
Apps in the 60s-90s
were written for
Apps today
are written for
Small data sets Large data sets

3
Apps in the 60s-90s
were written for
Apps today
are written for
Latency in seconds

3
Apps in the 60s-90s
were written for
Apps today
are written for
Latency in seconds Latency in milliseconds

Reactive applications share four traits
Reactive
Applications
5

Reactive applications enrich the user
experience with low latency response.

Responsive
• Real-time, engaging, rich and collaborative
• Create an open and ongoing dialog with users
• More efficient workflow; inspires a feeling of connectedness
• Fully Reactive enabling push instead of pull
7
“The move to these technologies is already paying off.
Response times are down for processor intensive code–such as image
and PDF generation–by around 75%.”
Brian Pugh, VP of Engineering, Lucid Software

Reactive applications react to
changes in the world around them.

Message-Driven
• Loosely coupled architecture, easier to extend, maintain, evolve
• Asynchronous and non-blocking
• Concurrent by design, immutable state
• Lower latency and higher throughput
9
“Clearly, the goal is to do these operations concurrently and
non-blocking, so that entire blocks of seats or sections are not locked.
We’re able to find and allocate seats under load in less than 20ms
without trying very hard to achieve it.”
Andrew Headrick, Platform Architect, Ticketfly

11
The Actor Model
A computational model that embodies:

11
The Actor Model
✓ Processing

11
The Actor Model
✓ Processing
✓ Storage

11
The Actor Model
✓ Processing
✓ Storage
✓ Communication

✓ Processing
✓ Storage
✓ Communication
Supports 3 axioms—when an Actor receives a message it can:
11
The Actor Model

✓ Processing
✓ Storage
✓ Communication
1. Create new Actors
11
The Actor Model

✓ Processing
✓ Storage
✓ Communication
2. Send messages to Actors it knows
11
The Actor Model

✓ Processing
✓ Storage
✓ Communication
2. Send messages to Actors it knows
3. Designate how it should handle the next message it receives
11
The Actor Model

The essence of an actor
from Akka’s perspective
0. DEFINE
1. CREATE
2. SEND
3. BECOME
4. SUPERVISE
12

public class Greeting implements Serializable {
public final String who;
public Greeting(String who) { this.who = who; }
}
!
public class Greeter extends AbstractActor {{
receive(ReceiveBuilder.
match(Greeting.class, m -> {
println(“Hello " + m.who);
}).
matchAny(unknown -> {
println(“Unknown message " + unknown);
}).build());
}}
0. DEFINE
X

}
!
}).
}).build());
}}
0. DEFINE
X
Define the message(s) the Actor
should be able to respond to

}
!
}).
}).build());
}}
0. DEFINE
X
Define the Actor class

}
!
}).
}).build());
}}
0. DEFINE
X
Define the Actor’s behavior

1. CREATE
ActorSystem system = ActorSystem.create("MySystem");
!
ActorRef greeter =
system.actorOf(Props.create(Greeter.class), “greeter");

1. CREATE
Create an Actor system
!
ActorRef greeter =

1. CREATE
Actor configuration
!
ActorRef greeter =

1. CREATE
Actor configuration
!
ActorRef greeter =
Give it a name

1. CREATE
!
ActorRef greeter =
Give it a name
Create the Actor
Actor configuration

1. CREATE
!
ActorRef greeter =
Give it a name
You get an ActorRef back
Create the Actor
Actor configuration

0. DEFINE
case class Greeting(who: String)
!
class GreetingActor extends Actor with ActorLogging {
def receive = {
13
case Greeting(who) => log.info(s"Hello ${who}")
}
}

0. DEFINE
13
!
def receive = {
}
}

0. DEFINE
13
!
def receive = {
}
}
Define the Actor’s behavior

1. CREATE
!
def receive = {
case Greeting(who) => log.info("Hello " + who)
}
}
!
val system = ActorSystem("MySystem")
val greeter = system.actorOf(Props[GreetingActor], name = "greeter")

1. CREATE
!
def receive = {
}
}
!

1. CREATE
!
def receive = {
case Greeting(who) => log.info("Hello " }
Actor configuration
+ who)
}
!

1. CREATE
!
def receive = {
}
}
!
Give it a name
Actor configuration

1. CREATE
!
def receive = {
Actor configuration
+ who)
}
!
Give it a name
Create the Actor

1. CREATE
!
def receive = {
Actor configuration
+ who)
}
!
Give it a name
You get an ActorRef bCarcekate the Actor

Actors can form hierarchies
Guardian System Actor

system.actorOf(Props.create(Foo.class), “Foo”);

Foo
system.actorOf(Props.create(Foo.class), “Foo”);

Foo
context().actorOf(Props.create(A.class), “A”);

A
Foo
context().actorOf(Props.create(A.class), “A”);

A
Foo Bar
B
C
B
E
A
D
C

system.actorOf(Props[Foo], “Foo”)

Foo
system.actorOf(Props[Foo], “Foo”)

Foo
context.actorOf(Props[A], “A”)

A
Foo
context.actorOf(Props[A], “A”)

Name resolution—like a file-system
A
Foo Bar
B
C
B
E
A
D
C

A
Foo Bar
B
C
B
E
A
D
C
/Foo

A
Foo Bar
B
C
B
E
A
D
C
/Foo
/Foo/A

A
Foo Bar
B
C
B
E
A
D
C
/Foo
/Foo/A
/Foo/A/B

A
Foo Bar
B
C
B
E
A
D
C
/Foo
/Foo/A
/Foo/A/B
/Foo/A/D

2. SEND
X
greeter.tell(new Greeting("Charlie Parker”), sender);

2. SEND
X
Send the message asynchronously

2. SEND
X
Pass in the sender ActorRef

Bring it together
X
}
}).
}).build());
}
}}
!
ActorRef greeter = system.actorOf(Props.create(Greeter.class), “greeter");
greeter.tell(new Greeting(“Charlie Parker”));

2. SEND
17
!
def receive = {
case Greeting(who) => log.info(s”Hello ${who}")
}
}
!
greeter ! Greeting("Charlie Parker")

2. SEND
17
!
def receive = {
}
}
!

Bring it together
18
!
def receive = {
}
}
!

DEMO TIME A simple game of ping pong

3. BECOME
X
public class Greeter extends AbstractActor {
public Greeter {
}).
matchEquals(“stop" -> {
!!!! }).build();
}
}

3. BECOME
X
public Greeter {
}).
!!!! }).build();
}
}
context().become(ReceiveBuilder.

3. BECOME
X
public Greeter {
}).
!!!! }).build();
}
}
Change the behavior

3. BECOME
X
public Greeter {
}).
!!!! }).build();
}
}
Change the behavior
println(“Go Away!”);

3. BECOME
X
public Greeter {
}).
!!!! }).build();
}
}
Change the behavior
println(“Go Away!”);
}).build());

3. BECOME
19
def receive = happy
!
val happy: Receive = {
case Angry => context become angry
}
!
val angry: Receive = {
case Greeting(_) => log.info("Go away!")
case Happy => context become happy
}
}

3. BECOME
19
def receive = happy
!
val happy: Receive = {
case Angry => context become angry
}
!
val angry: Receive = {
case Greeting(_) => log.info("Go away!")
case Happy => context become happy
}
}
Redefine the behavior

Reactive applications are architected
to handle failure at all levels.

Resilient
• Failure is embraced as a natural state in the app lifecycle
• Resilience is a first-class construct
• Failure is detected, isolated, and managed
• Applications self heal
21
“The Typesafe Reactive Platform helps us maintain a very
aggressive development and deployment cycle, all in a fail-forward manner.
It’s now the default choice for developing all new services.”
Peter Hausel, VP Engineering, Gawker Media

Think Vending Machine
Coffee
Programmer Machine

Coffee
Inserts coins
Programmer Machine

Coffee
Inserts coins
Add more coins
Programmer Machine

Coffee
Inserts coins
Add more coins
Programmer Machine
Gets coffee

Coffee
Inserts coins
Out of coffee beans error
Programmer Machine

Coffee
Inserts coins
OutW of corfofeen begans error
Programmer Machine

Coffee
Inserts coins
Out of
coffee beans
error
Programmer Machine

Service
Guy
Coffee
Inserts coins
Out of
coffee beans
error
Programmer Machine

Service
Guy
Coffee
Inserts coins
Out of
coffee beans
error
Programmer Machine
Adds
more
beans

Service
Guy
Coffee
Inserts coins
Programmer Machine
Gets coffee
Out of
coffee beans
error
Adds
more
beans

The Right Way
Request
Client Service

The Right Way
Request
Client Service
Response

The Right Way
Request
Validation Error
Client Service
Response

The Right Way
Request
Validation Error
Client Service
Response
Application
Error

The Right Way
Supervisor
Request
Validation Error
Client Service
Response
Application
Error

The Right Way
Supervisor
Request
Validation Error
Client Service
Response
Application
Error
Manages
Failure

Use Bulkheads
• Isolate the failure
• Compartmentalize
• Manage failure locally
• Avoid cascading failures

Supervisor hierarchies
A
Foo Bar
B
C
B
E
A
D
C
Automatic and mandatory supervision

4. SUPERVISE
X
Every single actor has a default supervisor strategy.
Which is usually sufficient.
But it can be overridden.
class Supervisor extends UntypedActor {
private SupervisorStrategy strategy = new OneForOneStrategy(
10, Duration.create(1, TimeUnit.MINUTES),
DeciderBuilder.
match(ArithmeticException.class, e -> resume()).
match(NullPointerException.class, e -> restart()).
matchAny( e -> escalate()).
build());
!
@Override public SupervisorStrategy supervisorStrategy() {
return strategy;
}

4. SUPERVISE
X
class Supervisor extends UntypedActor {
private SupervisorStrategy strategy = new OneForOneStrategy(
10, Duration.create(1, TimeUnit.MINUTES),
DeciderBuilder.
match(ArithmeticException.class, e -> resume()).
match(NullPointerException.class, e -> restart()).
matchAny( e -> escalate()).
build());
!
@Override public SupervisorStrategy supervisorStrategy() {
return strategy;
}
ActorRef worker = context.actorOf(
Props.create(Worker.class), "worker");
public void onReceive(Object i) throws Exception {
…
}
}

Monitor through Death Watch
X
public class WatchActor extends AbstractActor {
final ActorRef child = context().actorOf(Props.empty(), "child");
!
public WatchActor() {
context().watch(child);
match(Terminated.class,
t -> t.actor().equals(child),
t -> {
… // handle termination
}).build()
);
}
}

X
!
t -> {
}).build()
);
}
}
Create a child actor

X
!
t -> {
}).build()
);
}
}
Watch it

X
!
t -> {
}).build()
);
}
}
Watch it
Handle termination message

4. SUPERVISE
29
Every single actor has a default
supervisor strategy.

4. SUPERVISE
29
Every single actor has a default
supervisor strategy.
class Supervisor extends Actor {
override val supervisorStrategy =
OneForOneStrategy(maxNrOfRetries = 10, withinTimeRange = 1 minute) {
case _: ArithmeticException => Resume
case _: NullPointerException => Restart
case _: Exception => Escalate
}
!
val worker = context.actorOf(Props[Worker], name = "worker")
!
def receive = {

4. SUPERVISE
29
class Supervisor extends Actor {
override val supervisorStrategy =
OneForOneStrategy(maxNrOfRetries = 10, withinTimeRange = 1 minute) {
case _: ArithmeticException => Resume
case _: NullPointerException => Restart
case _: Exception => Escalate
}
!
val worker = context.actorOf(Props[Worker], name = "worker")
!
def receive = {
case n: Int => worker forward n
}
}
!

Cleanup & (Re)initialization
30
class Worker extends Actor {
...
override def preRestart(
reason: Throwable, message: Option[Any]) {
... // clean up before restart
}
override def postRestart(reason: Throwable) {
... // init after restart
}
}

31
class Watcher extends Actor {
val child = context.actorOf(Props.empty, "child")
context.watch(child)
!
def receive = {
case Terminated(`child`) => … // handle child termination
}
}

31
!
def receive = {
}
}

31
Watch it
!
def receive = {
}
}

31
Watch it
Handle termination message
!
def receive = {
}
}

Reactive applications scale up
and down to meet demand.

Elastic
• Elasticity and Scalability to embrace the Cloud
• Adaptive Scale on Demand
• Clustered servers support joining and leaving of nodes
• More cost-efficient utilization of hardware
33
“Our traffic can increase by as much as 100x for 15 minutes each day.
Until a couple of years ago, noon was a stressful time.
Nowadays, it’s usually a non-event.”
Eric Bowman, VP Architecture, Gilt Groupe

34
Essentially the same thing

35
We need to
1. Minimize Contention
2. Maximize Locality of Reference

Fully event-driven apps are a necessity
X
Amdahl’s Law will hunt you down

Define a router
ActorRef router = context().actorOf(
new RoundRobinPool(5).props(Props.create(Worker.class)),
“router”)
X

Define a router
37
val router = context.actorOf(
RoundRobinPool(5).props(Props[Worker])), “router”)

…or from config
38
akka.actor.deployment {
/service/router {
router = round-robin-pool
resizer {
lower-bound = 12
upper-bound = 15
}
}
}

Turn on clustering
39
akka {
actor {
provider = "akka.cluster.ClusterActorRefProvider"
...
}
cluster {
seed-nodes = [
“akka.tcp://ClusterSystem@127.0.0.1:2551",
“akka.tcp://ClusterSystem@127.0.0.1:2552"
]
auto-down = off
}
}

Use clustered routers
40
akka.actor.deployment
{
/service/master
{
router
=
consistent-‐hashing-‐pool
nr-‐of-‐instances
=
100
!
cluster
{
enabled
=
on
max-nr-of-instances-per-node = 3
allow-‐local-‐routees
=
on
use-‐role
=
compute
}
}
}

Use clustered routers
40
Or perhaps use an
AdaptiveLoadBalancingPool
akka.actor.deployment
{
/service/master
{
router
=
consistent-‐hashing-‐pool
nr-‐of-‐instances
=
100
!
cluster
{
enabled
=
on
max-nr-of-instances-per-node = 3
allow-‐local-‐routees
=
on
use-‐role
=
compute
}
}
}

Use clustered pub-sub
41
class Subscriber extends Actor {
val mediator =
DistributedPubSubExtension(context.system).mediator
mediator ! Subscribe(“content”, self)
def receive = { … }
}

Use clustered pub-sub
41
class Publisher extends Actor {
val mediator =
DistributedPubSubExtension(context.system).mediator
def receive = {
case in: String =>
mediator ! Publish("content", in.toUpperCase)
}
}

• Cluster Membership
• Cluster Pub/Sub
• Cluster Leader
• Clustered Singleton
• Cluster Roles
• Cluster Sharding
42
Other Akka Cluster features

• Supports two different models:
• Command Sourcing
• Event Sourcing
• Great for implementing
• durable actors
• replication
• CQRS etc.
• Messages persisted to Journal and replayed on restart
43
Use Akka Persistence

X
Command Sourcing Event Sourcing

X
write-ahead-log

X
write-ahead-log derive events from a command

X
same behavior during recovery
as normal operation

X
as normal operation
only state-changing behavior
during recovery

X
as normal operation
during recovery
persisted before validation

X
as normal operation
during recovery
persisted before validation events cannot fail

X
as normal operation
during recovery
allows retroactive changes to
the business logic

X
as normal operation
during recovery
the business logic
fixing the business logic will not
affect persisted events

X
as normal operation
during recovery
the business logic
naming: represent intent,
imperative

X
as normal operation
during recovery
the business logic
naming: represent intent,
imperative
naming: things that have
completed, verbs in past tense

Domain Events
• Things that have completed, facts
• Immutable
• Verbs in past tense
Akka
Persistence
Webinar
• CustomerRelocated
• CargoShipped
• InvoiceSent
“State transitions are an important part of our problem
space and should be modeled within our domain.”
Greg Young, 2008

Life beyond Distributed Transactions:
an Apostate’s Opinion
Position Paper by Pat Helland
http://www-‐db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf
“In general, application developers simply do not implement
large scalable applications assuming distributed transactions.”
Pat Helland
Akka
Persistence
Webinar

Consistency boundary
• An Actor is can define an Aggregate Root
• Each containing one or more Entities
• Aggregate Root is the Transactional Boundary
• Strong consistency within an Aggregate
• Eventual consistency between Aggregates
• No limit to scalability
Akka
Persistence
Webinar

DEMO TIME Persist a game of ping pong

Typesafe Activator
http://typesafe.com/platform/getstarted

• Purely asynchronous and non-blocking
web frameworks
• No container required, no inherent
bottlenecks in session management
48
Typesafe Reactive Platform
• Actors are asynchronous and
communicate via message passing
• Supervision and clustering in support of
fault tolerance
• Asynchronous and immutable
programming constructs
• Composable abstractions enabling
simpler concurrency and parallelism

Reactive is being adopted across
a wide range of industries.

50
Finance Internet/Social Media Mfg/Hardware Government Retail

Building Reactive Systems with Akka (in Java 8 or Scala)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (17)

Ähnlich wie Building Reactive Systems with Akka (in Java 8 or Scala)

Ähnlich wie Building Reactive Systems with Akka (in Java 8 or Scala) (20)

Mehr von Jonas Bonér

Mehr von Jonas Bonér (11)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Building Reactive Systems with Akka (in Java 8 or Scala)