Integrating Applications: the Reactive Way

Integrating Applications:
the Reactive Way
Nicola Ferraro
@ni_ferraro

Nicola Ferraro - JBCNConf Barcelona 2017
About Me
Follow me on twitter:
@ni_ferraro
Nicola Ferraro
Software Engineer at Red Hat
Working on Apache Camel, Fabric8,
JBoss Fuse, Fuse Integration
Services for Openshift

Agenda
● What does it mean to be reactive?
○ Reactive Programming
○ Reactive Systems
● Application Integration
○ Enterprise Integration Patterns
○ Apache Camel
● Demo
● Integration in Reactive Systems
○ Patterns
○ Future Challenges

What is Reactive Programming?
The goal of your
application is to:
“put a marble into
the bucket”
Phineas and Ferb
“Chain Reaction”
Disney

What is Reactive Programming?
You design all the
steps (map, flatMap,
filter, kicks and
punches) that lead to
putting a marble in
the bucket.
A fixed schema that is
activated only when a
marble is kicked in
(reactive).
A gameplay on Youtube
Phineas and Ferb “Chain Reaction”
Disney

reactive Programming Explained
merge(...)
stream1.map(e -> e.color(“#FF0”))
.zip(stream2, Bubble::of)
.merge(stream3)
.filter(Event::isAlmostRound)
.subscribe(bucket::put)
map(...)
filter(...)
zip(...)
?

Streams vs. Request/Response
Is reactive programming only about streams?
No, but even request/response patterns are internally mapped
as sequence of events (at event loop level).
And there’s flatMap.
// for each event, call a function
// and take the results in the stream
stream.flatMap(e -> compute(e))

How a “standard” application looks like?
Multiple “moving pieces”
(threads):
● Concurrency
● Resource contention
● Lock/Wait/Notify
● “One thread per request”
model
● “Thread migration” time
It is fun to play, but
inefficient!
Super Mario Bros 3
Nintendo

What’s wrong with “1 thread per request”?
At some point in the past (~2011), Node.js (it was single
threaded) was faster than many (multithreaded) Java web
servers! (according to some benchmarks… also on multi-core
machines!)
How the hell was this possible?!?!?
#reqs handled per second
Higher is better!

The reactor pattern (event loop)
A “Reactor”
The Simpsons
Event
Take
Execute
Handler
Reactor
And the multi-reactor
Multiple event loops, one two per physical core
(Vert.x)
leverage
asynchronous
I/O
1 thread event
per request
With no
concurrency
issues!

The Golden Rule
Don’t block the event loop!
● Thread.sleep(...)
● synchronized(...)
● statement.executeQuery()
● myLongWorkflow.execute()
● outputStream.write(...)
Blocking operations can be executed
in a external thread pool.
Do not sleep!
Do not block the reactor!
Is asynchronous IO always possible at OS level? https://lwn.net/Articles/724198/

What’s wrong with “1 thread per request”?
Performance comparison of
Tomcat (1 thread per request)
vs RxNetty (2015)
Reasons:
● Thread migration + context
switch
● Slower Garbage Collection
Details:
https://github.com/Netflix-Skunkworks/WSPerfLab
/blob/master/test-results/RxNetty_vs_Tomcat_Apr
il2015.pdf

Limits of “1 thread per request” model
How many concurrent requests you can handle?
1 thread requires 1 MiB of stack memory by default
10k connections ~= 10 GiB of stack memory (just for the
threads)
What about the C10m problem?
http://c10m.robertgraham.com/p/manifesto.html
The
C10k
problem

Reactive Programming vs. Reactive Systems
“Reactive: Readily responsive to a stimulus”, Merriam Webster
● Responsive (react to user requests):
○ Having rapid response times
● Resilient (react to failures)
○ Being responsive also in case of failures (e.g. replication, retry)
● Elastic (react to load)
○ No bottlenecks, can scale according to load
● Message driven (react to events/messages)
○ Communication based on asynchronous message passing, with location
transparency and backpressure
The reactive manifesto: http://www.reactivemanifesto.org/

Reactive “packages”
PROJECT REACTOR
(v. 5)
Toolkits for building Reactive Systems Reactive Programming Frameworks
Help me to classify them ...
streams
?

Integration
Nobody lives in isolation.
Integration is about:
● Communication (Messaging)
● Converting protocols
● Mapping Bounded Contexts
● Message Correlation
● Routing
● Flow Control
● ...

The integration platform
Apache Camel is a powerful
integration framework based on
enterprise integration patterns!
More than 200 components
Can connect to any platform The new logo (proposal)
by Zoran Regvart

Camel: the Components
ahc, ahc-ws, amqp, apns, asterisk, atmos, atmosphere-websocket, atom, avro, aws, azure, bam, barcode, base64,
beanio, beanstalk, bean-validator, bindy, blueprint, bonita, boon, box, braintree, cache, cassandraql, castor,
cdi, chronicle, chunk, cmis, cm-sms, coap, cometd, consul, context, core-osgi, core-xml, couchbase, couchdb,
crypto, csv, cxf, cxf-transport, digitalocean, disruptor, dns, docker, dozer, drill, dropbox, eclipse, ehcache,
ejb, elasticsearch, elasticsearch5, elsql, etcd, eventadmin, exec, facebook, fastjson, firebase, flatpack, flink,
fop, freemarker, ftp, ganglia, geocoder, git, github, google-calendar, google-drive, google-mail, google-pubsub,
gora, grape, groovy, groovy-dsl, grpc, gson, guava-eventbus, guice, hawtdb, hazelcast, hbase, hdfs, hdfs2,
headersmap, hessian, hipchat, hl7, http, http4, http-common, hystrix, ibatis, ical, ignite, infinispan, influxdb,
irc, ironmq, jackson, jacksonxml, jasypt, javaspace, jaxb, jbpm, jcache, jclouds, jcr, jdbc, jetty, jetty9,
jetty-common, jgroups, jibx, jing, jira, jms, jmx, johnzon, jolt, josql, jpa, jsch, jsonpath, jt400, juel,
jxpath, kafka, kestrel, krati, kubernetes, kura, ldap, leveldb, linkedin, lucene, lumberjack, lzf, mail, metrics,
milo, mina, mina2, mllp, mongodb, mongodb3, mongodb-gridfs, mqtt, msv, mustache, mvel, mybatis, nagios, nats,
netty, netty4, netty4-http, netty-http, ognl, olingo2, olingo4, openshift, openstack, opentracing, optaplanner,
paho, paxlogging, pdf, pgevent, printer, protobuf, pubnub, quartz, quartz2, quickfix, rabbitmq, reactive-streams,
reactor, restlet, rest-swagger, ribbon, rmi, routebox, rss, ruby, rx, rxjava2, salesforce, sap-netweaver, saxon,
scala, schematron, scr, script, servicenow, servlet, servletlistener, shiro, sip, sjms, sjms2, slack, smpp,
snakeyaml, snmp, soap, solr, spark, spark-rest, splunk, spring, spring-batch, spring-boot, spring-cloud,
spring-cloud-netflix, spring-dm, spring-integration, spring-javaconfig, spring-ldap, spring-redis,
spring-security, spring-web, spring-ws, sql, ssh, stax, stomp, stream, stringtemplate, swagger, swagger-java,
syslog, tagsoup, tarfile, telegram, test, test-blueprint, test-cdi, test-karaf, testng, test-spring, thrift,
tika, twilio, twitter, undertow, univocity-parsers, urlrewrite, velocity, vertx, weather, websocket, xmlbeans,
xmljson, xmlrpc, xmlsecurity, xmpp, xstream, yammer, zendesk, zipfile, zipkin, zookeeper, zookeeper-master …

Basic Usage
// Simple routing
from(“jms:queue/orders”)
.log(“Processing order: ${body}”)
.to(“http://myservice”)
.to(“smtp:localhost:25”);
Isn’t “.to()” close to “.map()”?
// A (not so) much complicated
// example
from(“hdfs:/home/nicola/data”)
.unmarshal().json() // json array
.split().body()
.choice()
.when(...)
.to(“jdbc:...”)
.otherwise()
.log(“Skipped ${body}”)

Camel: some EIPs
Fix out of order
messages
Aggregating results in
groups
from(“...”).resequence(header(“timestamp”))...
from(“...”).aggregate(header(“orderId”))...

Camel: some EIPs
Recipient list
Content Based Routing
from(“...”).recipientList(header(“recipient”))...
from(“...”).choice().when()...otherwise()

Camel: some EIPs
Hystrix
Others (important!):
● Redelivery Policy: setup number of redelivery attempts and delays
● Throttler: adjust message speed for slow consumers
● Service Call: integrate with an external service registry (consul, ribbon, kubernetes)
● Load Balancer: balance load to multiple endpoints using custom strategies
from(“...”)
.hystrix()
.to(“http://service”)
.onFallback()
.transform()...
Open and close the circuit to an external service
and provide fallback responses to the client.
S1 S2

Is Camel Reactive?
Camel 3.0 will have a fully reactive core.
Camel 2.20 is not fully reactive, but:
● Uses asynchronous processing by default (no 1 thread pr)
● Supports backpressure and throttling
● Has multiple components for asynchronous I/O
No event loops and reactors, but it’s fast (especially the
latest version)!

The goal: create a bigger reactive system
Integration in Reactive Systems
Browser
(Vert.x)
Microservice 1
(Vert.x)
EventBus Microservice 2
(Vert.x)
Resiliency, location
transparency
MS 1 MS 2
MS 3 MS 4
Another Reactive/Non-reactive Ecosystem
Integration
Microservice Integration
Microservice
Optional

Communication in Reactive Applications
Inside the JVM:
Reactive Streams
http://www.reactive-streams.org/
A specification for asynchronous stream processing with
non-blocking backpressure [?].
PROJECT REACTOR
JVM
Reactive Streams

Reactive Streams Visualized
public interface Publisher<T> {
public void subscribe(Subscriber<? super T> s);
}
public interface Subscriber<T> {
public void onSubscribe(Subscription s);
public void onNext(T t);
public void onError(Throwable t);
public void onComplete();
}
public interface Subscription {
public void request(long n);
public void cancel();
}
public interface Processor<T, R> extends Subscriber<T>,
Publisher<R> {
}
Just this 4 interfaces (and the rules to use them).
Java 9 Flow API: Flow.Publisher, Flow.Subscriber, Flow.Subscription, Flow.Processor

Demo
Use camel-reactive-streams to exchange data with a reactive
library (Vert.x → rx-java2 → Camel).
Use camel-netty-http to connect a Spring-Boot 2 (Spring 5)
WebFlux service.
Use camel-grpc to forward a stream to a remote service and
get the response stream back.
● https://github.com/nicolaferraro/reactive-demo (note: requires camel 2.20-snapshot)
PROJECT REACTOR

Demo: considerations
I’ve used the generic camel-reactive-streams component but
there’s also a specific connector for Vert.x (connects
directly to the Eventbus):
// Using the camel-vertx component
from(“vertx:raw-points”)
.to(“...”)
.to(“vertx:enhanced-points”);

Backpressure?
OP Normal Scenario
Normal operator or
boundary betweeen
reactive streams
OP
Too much water
(events)
SLOW
buffer full
pressure in the pipes (like with water!)
Backpressure
“Remember, you can’t put too much water in a nuclear reactor”, Saturday Night Live, 1984
buffer full
Backpressure

Backpressure in Reactive Streams
onSubscribe(sub)
subscribe()
request(1)
onNext(“m1”)
request(2)
onNext(“m2”)
onNext(“m3”)
Publisher
Subscriber

Limited Resources: microservices - no backpressure
Microservice 1
Microservice 2
Microservice 3
Microservice 4
Can’t process all events:
● Timeout
● HTTP 503
In req/resp mode,
you can do circuit
breaking.
In in-only
(streaming) mode,
you will retry
(increase load)

Limited Resources: microservices with backpressure
Microservice 1
Microservice 2
Microservice 4
Microservice 3You can buffer at the
source!
Flow control at
system level
backpressure
Less responsive, but you
can handle peaks
Later, you can scale out
“Microservice 4” to make
the system more
responsive

End-to-End Backpressure: In-Only Stream
Java / JS /
Python
Service 1
Java / JS /
Python
Service 2
backpressured
How???
RSocket
http://rsocket.io/
Application protocol providing reactive streams semantics.
Other solutions?? Designed for efficiency at low level
onNext
onError
onComplete

End-to-End Backpressure: In-Only Stream
This backpressure stuff is not new…

Back to TCP
TPC implements a sliding window protocol for flow control!
Java / JS /
Python
Java / JS /
Python
TCP / IP
data
ack + window size
You cannot send more data
than requested to a TCP
recipient!
TCP is backpressure aware!

Backpressure at Application Level: In-Only Stream
App 1
TCP
Local Backpressure:
do not write too much
App 2
TCP
Local Backpressure:
do not read if can’t process
backpressured
Application Level
Backpressure
Sliding window flow control
Can work also with higher level protocols
● HTTP
● Websocket
● SSE
● gRPC End-to-end backpressure

Backpressure: Stream → Camel
What in case of request/response messaging?
Reactive
Streams
Rx-Java Camel
from(“reactive-streams:events”)
.throttle(3).timePeriodMillis(10000)
.to(“http://dinosaurs.io/api/echo”);
Camel
Producer
External Servicebackpressure
from(“reactive-streams:events?maxInflightExchanges=20”)
.to(“http://dinosaurs.io/api/echo”);
No more than 20 concurrent reqsNo more than 3 reqs in 10 secs
In-Out

Backpressure: Camel → Stream
Camel
Consumer
Reactive
Streams
What happens when backpressure slows down Camel?
Reactor-CoreCamel
from(“jms:events”)
.routePolicy(maxExchangesPolicy)
.to(“reactive-streams:events”);
Message Source
backpressure
Camel will pause the consumer
in case of backpressure
Flux<Message>

Adding Elasticity: Load Balancer
canvas1
canvas2Camel Load Balancer:
from(“...”)
.loadBalance().sticky(canvasIdExpr())
.to(“endpoint1”, “endpoint2”)
Supports:
● Round robin, random, custom
● Failover
● Mixing with ServiceCall EIP (location transparency + load balancing) Works with any protocol:
HTTP, TCP, GRPC, ...
Streams or
RPC

Adding (a bit of) Location Transparency
192.168.0.22
service-1 service-2
Service Registry
● Consul
● Etcd
● Kubernetes
● Ribbon
Camel ServiceCall EIP:
from(“...”)
.serviceCall(“service-2”)
.to(“...”)

Adding Location Transparency and Resiliency
Reactive
Streams
Rx-Java Camel
Camel
Producer
Camel
Consumer
Messaging Broker
(your choice)
● JMS
● Kafka (anti-backpressure)
● AMQP
● MQTT
backpressure
Allows all kind of messaging patterns:
● P2P In-Only
● P2P In-Out
● Pub/Sub
Send messages to:
● Queues
● Topics
backpressure
If you have a fast-enough
messaging broker, you don’t have to
care a lot about backpressure when
writing (anti-backpressure)

@ni_ferraro
That’s all folks!

Integrating Applications: the Reactive Way

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Integrating Applications: the Reactive Way

Ähnlich wie Integrating Applications: the Reactive Way (20)

Mehr von Nicola Ferraro

Mehr von Nicola Ferraro (7)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Integrating Applications: the Reactive Way