Date post: | 23-Jan-2018 |
Category: |
Technology |
Upload: | konrad-malawski |
View: | 309 times |
Download: | 0 times |
Building a Reactive System with Akka
Konrad Malawski (@ktosopl) - Akka Team Henrik Engström (@h3nk3) - Telemetry Team
O’Reilly Software Architecture Conference, NYC - April 2016
Free e-book and printed report.bit.ly/why-reactive
Covers what reactive actually is.Implementing in existing architectures.
Thoughts from the team that’s buildingreactive apps since more than 6 years.
• “TRADITIONAL” AND REACTIVE APPLICATIONS
• ACTOR MODEL AND DISTRIBUTED PROGRAMMING
• INTRODUCTION TO "BRACES"
• AKKA CLUSTERING AND PERSISTENCE
• AKKA STREAMS
• AKKA HTTP
• TESTING AKKA Actors / Streams / HTTP
• WHAT FEATURES ARE COMING SOON?
AGENDA
“TRADITIONAL” AND REACTIVE APPLICATIONS
IT IS 2017 AND WE STILL USE
• Synchronous local and remote calls • Single machine apps - scaling is an afterthought • Non resilient approaches
Result: brittle, slow, non-scalable applications
WHAT CAN WE DO ABOUT IT?Use message driven/asynchronous programming
PROBLEM SOLVED!?
REACTIVE MANIFESTO
http://www.reactivemanifesto.org/
• Created in September 2014, +18k signatures • Consists of four traits
• Responsive
• Resilient
• Elastic
• Message Driven
RESPONSIVE
RESILIENT
E L A S T I C
MESSAGE DRIVEN
Akka
Akka is the Enabler of Reactive Systems
• Individual entities, actors, that can contain state
• Communication done by message passing
• Lock-free concurrency
• Loosely coupled and distributable
• Fault tolerance via Supervision
Akka is a Toolkit
• A Toolkit, not a Framework
• Multitude modules and components – “pick-and-choose”
• Performance and distribution always a goal
• Resilient and asynchronous from its very core
ACTOR MODEL AND
DISTRIBUTED PROGRAMMING
What is an Actor?
• Behavior (processing) - An actor reacts on messages it receives
• State (storage) - An actor is shielded from the rest of the world - no need for synchronization!
• Communication - An actor interacts with other actors exclusively via messages
• "One actor is no actor" - they come in systems
Anatomy of an Akka Actor
Anatomy of an ActorSystem
INTRODUCTION TO BRACES
VOCABULARY
• Drone - autonomous, field-deployed UAV, sends metrics/position to backend system
• DroneShadow - backend “mirror” of field-deployed Drone,keeps metrics and represents drone in backend model
• Backend - single MicroService,backed by Akka Cluster for resilience/load-balancing
VOCABULARY
• Micro-service - has a single responsibility, it absolutely does not mean “one node”!
• Distributed Journal - backing datastore of the single service, often Cassandra, SQL or similar. Service should “own your data.”
HIGH-LEVEL ARCHITECTURE OVERVIEW
HIGH-LEVEL ARCHITECTURE OVERVIEW
AKKA ACTOR BASICS
LET’S CODE!
• Message passing (events are a kind of message)
• Distribution via Location Transparency
• Lock-free & simple Concurrency
• Very powerful abstraction underneath everything we’ll talk about
Akka Actors:
AKKA CLUSTERING AND PERSISTENCE
HIGH-LEVEL ARCHITECTURE OVERVIEW
LET’S CODE!
FAILURE SCENARIO: Node Failure
HIGH-LEVEL ARCHITECTURE OVERVIEW
FAILURE SCENARIO: State Recovery
(Akka Persistence)
http://developer.lightbend.com/docs/akka-commercial-addons/1.0.1/split-brain-resolver.html
//application.confakka.cluster.downing-provider-class="com.lightbend.akka.sbr.SplitBrainResolverProvider"
• Static Quorum - static, very predictable (like zk)
• Keep Majority - dynamic, supports dynamic growth
• Keep Oldest - keep “most stable” members
• Keep Referee - keep “precious side”
Split Brain / Failure Detection
http://developer.lightbend.com/docs/akka-commercial-addons/1.0.1/split-brain-resolver.html
• Simple timeout - known as “auto down”
• very naive,
• not really intended for real-world usage.
Naive Failure Detection
• Battle-tested Membership Protocol
• Powerful distribution mechanism
• Application aware Sharding
• Scale-out & Resilience
Akka Cluster:
• EventSourcing style persistence
• Pluggable Journals (Cassandra, SQL, Mongo, Dynamo, and more …)
• Trivial to plug in
• Enables CQRS-style architectures
• Powers AtLeastOnceDelivery
Akka Persistence:
AKKA STREAMS
Fast Publisher Slow Subscriber
Akka Streams - BackPressure
Subscriber usually has some kind of buffer.
Push model
Push model
Push model
Push model
What if the buffer overflows?
Push model
Use bounded buffer, drop messages + require re-sending
Push model
Kernel does this!Routers do this!
(TCP)
Use bounded buffer, drop messages + require re-sending
Push model
Increase buffer size… Well, while you have memory available!
Push model
Reactive Streams explained
Reactive Streams explained in 1 slide
Fast Publisher will send at-most 3 elements. This is pull-based-backpressure.
Reactive Streams: “dynamic push/pull”
JEP-266 – soon…!public final class Flow { private Flow() {} // uninstantiable
@FunctionalInterface public static interface Publisher<T> { public void subscribe(Subscriber<? super T> subscriber); }
public static interface Subscriber<T> { public void onSubscribe(Subscription subscription); public void onNext(T item); public void onError(Throwable throwable); public void onComplete(); }
public static interface Subscription { public void request(long n); public void cancel(); }
public static interface Processor<T,R> extends Subscriber<T>, Publisher<R> { }}
Reactive Streams: goals
1) Avoiding unbounded buffering across async boundaries
2)Inter-op interfaces between various libraries
Reactive Streams: goals1) Avoiding unbounded buffering across async boundaries
2)Inter-op interfaces between various libraries
Argh, implementing a correct RS Publisher or Subscriber is so hard!
1) Avoiding unbounded buffering across async boundaries
2)Inter-op interfaces between various libraries
Reactive Streams: goals
Argh, implementing a correct RS Publisher or Subscriber is so hard!
Reactive Streams: goals
Argh, implementing a correct RS Publisher or Subscriber is so hard!
You should be using Akka Streams instead!
1) Avoiding unbounded buffering across async boundaries
2)Inter-op interfaces between various libraries
HIGH-LEVEL ARCHITECTURE OVERVIEW
LET’S CODE!
• Fully Typed API
• Asynchronous Back-Pressure
• First impl. to pass Reactive Streams standard
• Reactive Streams coming to JDK9
• Powerful composable ScalaDSL and JavaDSL
• Open Materializer API (e.g. Intel GearPump)
Akka Streams:
AKKA HTTP
HIGH-LEVEL ARCHITECTURE OVERVIEW
A core feature not obvious to the untrained eye…!
Quiz time! TCP is a ______ protocol?
Akka HTTP
A core feature not obvious to the untrained eye…!
Quiz time! TCP is a STREAMING protocol!
Akka HTTP
Streaming in Akka HTTP
http://doc.akka.io/docs/akka/2.4.7/scala/stream/stream-customize.html#graphstage-scala “Framed entity streaming” https://github.com/akka/akka/pull/20778
HttpServer as a: Flow[HttpRequest, HttpResponse]
Streaming in Akka HTTP
http://doc.akka.io/docs/akka/2.4.7/scala/stream/stream-customize.html#graphstage-scala “Framed entity streaming” https://github.com/akka/akka/pull/20778
HttpServer as a: Flow[HttpRequest, HttpResponse]
HTTP Entity as a: Source[ByteString, _]
Streaming in Akka HTTP
http://doc.akka.io/docs/akka/2.4.7/scala/stream/stream-customize.html#graphstage-scala “Framed entity streaming” https://github.com/akka/akka/pull/20778
HttpServer as a: Flow[HttpRequest, HttpResponse]
HTTP Entity as a: Source[ByteString, _]
Websocket connection as a: Flow[ws.Message, ws.Message]
Streaming from Akka HTTP (Java) public static void main(String[] args) { final ActorSystem system = ActorSystem.create(); final Materializer materializer = ActorMaterializer.create(system); final Http http = Http.get(system);
final Source<Tweet, NotUsed> tweets = Source.repeat(new Tweet("Hello world"));
final Route tweetsRoute = path("tweets", () -> completeWithSource(tweets, Jackson.marshaller(), EntityStreamingSupport.json()) );
final Flow<HttpRequest, HttpResponse, NotUsed> handler = tweetsRoute.flow(system, materializer);
http.bindAndHandle(handler, ConnectHttp.toHost("localhost", 8080), materializer ); System.out.println("Running at http://localhost:8080");
}
LET’S CODE!
It’s turtles buffers all the way down!
Streaming from Akka HTTP
Streaming from Akka HTTP
Streaming from Akka HTTP
No demand from TCP=
No demand upstream=
Source won’t generate tweets
=> Bounded memory stream processing!
FAILURE SCENARIO 1
HIGH-LEVEL ARCHITECTURE OVERVIEW
HIGH-LEVEL ARCHITECTURE OVERVIEW
HIGH-LEVEL ARCHITECTURE OVERVIEW
FAILURE SCENARIO 2
HIGH-LEVEL ARCHITECTURE OVERVIEW
HIGH-LEVEL ARCHITECTURE OVERVIEW
HIGH-LEVEL ARCHITECTURE OVERVIEW
• “Streaming-first” HTTP Server
• Powerful composable ScalaDSL and JavaDSL
• Built completely on Akka Streams
• Trivially exposes TCP level flow control to Akka Streams as backpressure
• Simple inter-op with Actors, Futures, Streams
• HTTP/2 coming very soon
Akka HTTP:
TESTING ASYNCHRONOUS CODE WITH AKKA
TestKits and tools provided• Asynchronous is hard • Testing asynchonous code is hard
• We’ve prepared plenty tools to make it simple
TestKits and tools provided• Akka Actors - TestKit • Akka Streams - TestSource / TestSink
LET’S CODE!
• All major modules come with dedicated TestKit
• Actors, Streams, MultiJVM testing (!)
• Makes asynchronous code simpler to test
Akka Testing:
STREAMING INTEGRATION WITH “ALPAKKA”
Alpakka is a community driven project• Community of Akka Streams “Connectors”
• Akka Streams == Reactive Streams impl == everyone profits!
• Similar in goals to Apache Camel • “inter-op all the things!”
• We’ve prepared plenty tools to make it simple
Alpakka – a community for Stream connectors
http://developer.lightbend.com/docs/alpakka/current/
Alpakka – a community for Stream connectors
http://developer.lightbend.com/docs/alpakka/current/
Google Pub/Sub…
…
…
…
…
……
Alpakka – a community for Stream connectors
http://developer.lightbend.com/docs/alpakka/current/
Alpakka – a community for Stream connectors
http://developer.lightbend.com/docs/alpakka/current/
LET’S CODE!
• Vibrant community of Akka Streams developers
• Tens of integrations already, more coming as-we-speak
• All fully Streaming and Back-pressure Aware and s
Akka “Alpakka”:
MONITORING
MONITORING FEATURES (2017-04)• Akka Actors • Akka Remoting and Clustering • Lagom Circuit Breakers • Dispatchers / Thread Pools • Various backend integration (ES, StatsD, …) • Sandbox environment (EKG) for easy exploration
Datadog Integration
• Commercial monitoring
• Get the full picture about your applications in production
• Highly optimised, fine-tuned by core Lightbend teams
Lightbend Monitoring:
SUMMING UP
ARCHITECTURE
• Resilient & Elastic from the ground up • High-performance & Asynchronous all-the-way • Highly Self-Healing / Resilient • Well established API endpoints (HTTP/WS/SSE) • Highly reusable & composable code
• See Reactive Streams (j.u.c.Flow in JDK9)
CODE
• Full feature parity between Java & Scala DSL (always!) • Asynchronous all-the-way • Understandable and well-defined failure scenarios • Start local, go distributed with no or minimal changes • Highly reusable & composable code
• Brought to you by leaders of Reactive Streams
MONITORING
• Awesome monitoring of asynchronous code • Coming soon:
• Tracing across Actors, Futures, HTTP • Smart Cluster Sharding insights
WHAT FEATURES ARE COMING SOON?
Next steps for Akka
New Akka Remoting (benchmarked 1,000,000+ msg/s (!)), (built using Akka Streams, Aeron)
More integrations for Akka Streams stages, project Alpakka.
Akka Typed actively progressing (!).
Akka HTTP/2 Proof of Concept in progress. Akka HTTP as default backend of Play Framework.
Highly Available CRDTs with Akka Distributed Data.
We <3 contributions• Easy to contribute:
• https://github.com/akka/akka/issues?q=is%3Aissue+is%3Aopen+label%3Aeasy-to-contribute
• https://github.com/akka/akka/issues?q=is%3Aissue+is%3Aopen+label%3A%22nice-to-have+%28low-prio%29%22
• Akka: akka.io && github.com/akka • Reactive Streams: reactive-streams.org • Mailing list:
• https://groups.google.com/group/akka-user • Public chat rooms:
• http://gitter.im/akka/dev developing Akka • http://gitter.im/akka/akka using Akka
Lightbend booth / sponsor area
O’Reilly’s “Ask the Experts”
Henrik’s talk on Wednesday @ 4.50 pm…
Catch us here:Catch us here
EOF Q/A
Konrad Malawski (@ktosopl) - Akka Team Henrik Engström (@h3nk3) - Telemetry Team