messaging for the cloud and microservices

Messaging for the Cloud and Microservices

Rob Davies2015

RED HAT | Fabric8 Rocks!2

Rob Davies

• Director of Middleware Engineering for xPaaS

• Over 20 years experience of developing large scale solutions for telcos and finance

• Creator of ActiveMQ and ServiceMix• Committer on open source projects,

including fabric8, Apache Camel and other stuff …


All singing, all dancing scalable messaging for the

cloud

AND …

Messaging for Microservices


Why do we use messaging ?

• Robustness to change• Time independence• Hide latency• Event driven• Platform and language

independenceBroker

Message in

Message out after enrichment by Process B

Process C

Process B

Process AQueue:Foo

Queue:Bar


Traditional Enterprise Message brokers

• Designed to support many different messaging patterns

• highly available• Support clustering• Support store and

forward• But – are usually

very static in nature


Core Messaging Patterns …


Requestor

Core Message Pattern: Request/Reply

Service


Producer

Core Message Pattern: Queue

Consumer

Consumer

Consumer


Core Message Pattern: Publish/Subscribe

Consumer

Consumer

Consumer

Producer


Message Channels and Filters


Message Routing: Selectors

Producer Destination

ConsumerColor = red

ConsumerColor =

blue


Message Routing: Destination Wildcards

• * matches a subject• > matches sub-tree

Topic:BAR.BEER.WHITE

Topic:BAR.WINE.WHITE

Producer

ConsumerTopic:BAR.WINE.WHITE

ConsumerTopic:BAR.BEER.WHITE

ConsumerTopic:BAR.*.WHITE

ConsumerTopic:BAR.>


Message Groups

Producer

Consumer

Consumer

Consumer

Queue:Prices

Message message = session.createTextMessage(“Hi DWP”);message.setStringProperty("JMSXGroupID", ”JavaRocks");producer.send(message);


Scaling Messaging – the traditional way …


Client Scaling:

Message Bus


Broker Scaling:

Message BusMessage throughput requirement exceeds broker capacity


Broker Scaling:

Message Bus Message Bus


Broker Scaling:



Broker Scaling:


Message BusMessage Bus


Broker Scaling: Problems


Message BusMessage Bus• Diminished

returns • Focused

Overload• Stranded

Capacity


How do we scale Messaging for the Cloud ?


Requirements for Messaging as a Service

• Needs to support many thousands of clients• Flexible, brokers need to be spun up and down,

based on demand• Client connections may need to be multiplexed,

to decrease the load on individual message brokers

• Popular messaging protocols support• Flexible routing needs to be supported


What contenders are already out there ?


ActiveMQHornetQ

RabbitMQProprietary Enterprise

Messaging


Apache Kafka

• Publish/Subscribe messaging – rethought as a distributed commit log

• Designed for fast data ingestion of logs• Scalable – designed to allow a single cluster to act as a

messaging platform, allowing for elastic expansion with no downtime

• Messages are persisted to disk, and replicated to prevent data loss

• Allows partitioning of data streams across cluster of machines

• Created at Linkedin – donated to the ASF


Apache Kafka Architecture

ZooKeeper BrokerBrokerBroker Broker

Producer Producer

Consumer Consumer


Apache Kafka Performance

https://cwiki.apache.org/confluence/display/KAFKA/Kafka+papers+and+presentations

From: Kafka: A distributed Messaging System for log processing, Jun Rao


Apache Kafka – Differences with a Message Broker

• Distributed commit log – broker maintains no state• Niche – so works really well for a particular set of use

cases• Proprietary • Written in Scala• Consumers have to maintain state


Kubernetes Helps


Fabric8 MQ – not a message broker – but a scalable messaging system

Many concurrent connections, one out

FlexibleProtocols

Mul

tiple

xConnections

Vert.x Core

Embedded Camel,Integration with APIMan

OpenWire,STOMPMQTTAMQPWebSockets – all done asynchronously

Scaling ConnectionsNOT a problem

Destination Sharding


Fabric8 MQ Independently scalable:

Node

Pod

ActiveMQ Broker

AMQ Replication Controller

Node

Pod

ActiveMQ Broker

Node

Pod

ActiveMQ Broker

Fabric8MQ Replication Controller

Vert.xVert.x

Vert.x

MultiplexerMultiplexer

MultiplexerFabric8MQ

Vert.xVert.x

Vert.x



Vert.xVert.x

Vert.x




Fabric8 MQ Message Flow:

Protocol Conversion

Camel Routing

API Management Multiplexer

Destination Sharding

Broker Control


Qpid Dispatch Router

BrokerBrokerBroker Broker

Producer ProducerConsumer Consumer

Router Router Router Router

AMQP 1.0


Multiplexing

• Brokers performs better the lower the number of connections – less contention

• IoT applications have long lived connections, but small amount of traffic

• All configurable – you can decide how fine or coarse grained you want multiplexing

• Dispatch Router does this automatically


Destination Sharding: Benefits

• There is an overhead associated with a Destination – restrict the number of Destinations per Broker to improve performance

• Co-locate producers and consumers of a Destination to the same broker reduces latency and improves overall performance

• Increased scalability for your messaging solution

• Dispatch Router does this automatically


Red Hat Messaging – how we plan to tackle messaging for

the cloud …


What we have today Separate clients tied to

broker- specific protocols

Limitedintegration between brokers& overlapping capabilities

MRG-M (Apache Qpid C++ broker)•AMQP, high performance, routing, HA•No longer sold but actively supported

M. MQ 6.x (Apache ActiveMQ 5.x Java broker)

• Multi-protocol JMS-oriented broker• Large user community, rich feature set

EAP HornetQ JMS Messaging Broker (HornetQ GitHub project)•Multi-protocol JMS-oriented broker•JMS 2.0, best-in-class SpecJMS performance

MRG-M 3.1

A-MQ6.x

HornetQ EAP6


Clients

A-MQ

Where we’re going

• Consolidate to a single messaging product, known as A-MQ

• Consists of three components: Broker, Interconnect & Clients

• Developed in open, community-based, upstream projects and

leveraging open, standards-based protocols

Broker

Interconnect


Where we’re going

M. MQ Broker• Full-featured, high-performance, multi-protocol

enterprise broker• HA through replication and failover

M. MQ Interconnect Router• Large-scale, secure, reliable, and manageable

messaging networks• Use with or without broker. HA through redundant

routing.

M. MQ Clients• Ubiquitous, standards-based messaging clients for all

common platforms and programming languagesA-MQA-MQ

Broker

Interconnect

Clients


Where we’re going

• AMQP (Advanced Message Queuing Protocol)

• Rich semantics, multiplexing, flow control, extensible

• International standard – ISO/IEC ISO 19464

• MQTT (Message Queuing Telemetry Transport)

• Lightweight “first mile” telemetry• OASIS Standard; International

standardization in progress

• STOMP (Simple Text-Oriented Messaging Protocol)

• WebSocket encapsulationA-MQ

Broker

Interconnect

Clients


Messaging for Microservices


Reliable, Fast Communication between Services


Functional Decomposition


Micromessaging

• Whilst external services should often be http – internal services do not need to be.

• Using a messaging system can improve performance and scalability

• Standards are important – immutable infrastructure leads to disposable infrastructure. Apply that all assets in your design.


Micromessaging: inter-service communications

Broker

Service AService A

Service AService C

Service AService B

Service AService F

Service AService E

Service AService Drequest

reply

subscribe

subscribe

publishpublish


Micromessaging: Control Plane

BrokerController

Service AService F

Service AService A

subscribe

subscribe

publish

{Start Processing}

{Stop Processing}


Micromessaging: Stream Processing

Brokerpublish

Event ListenerSMS

Event Listener

Event ListenerHTTP Post





SMTP

publish

publish

EventProcessing

Engine


Micromessaging anti-patterns

• Any pattern that is transactional in nature

e.g. Transactional Client• Any pattern that relies on Message Persistence

Durable Subscriber, Guaranteed Delivery• Any pattern where the message system inspects, or

selectively routes messages Message Filter, Content Based Routing, Content Enricher


Micromessaging: what to use ?

Qpid Dispatch Router


Demo:Variance

Collector

Compare Interprocess communication:HTTP vs Messaging


Standard Deviation Processor:

public void process(Exchange exchange) throws Exception {

String message = exchange.getIn().getBody(String.class); ObjectMapper objectMapper = new ObjectMapper();

TypeFactory typeFactory = objectMapper.getTypeFactory();

List<Double> values = objectMapper.readValue(message, typeFactory.constructCollectionType(List.class, Double.class));

SummaryStatistics summaryStatistics = new SummaryStatistics();

List<Double> list = new ObjectMapper().readValue(message, List.class); for (Double value : list) { summaryStatistics.addValue(value); } String stdDev = Double.toString(summaryStatistics.getStandardDeviation()); exchange.getOut().setBody(stdDev);}


Standard Deviation Route:

@ContextName("stddevCamel")public class StdDevHTTP extends RouteBuilder {

@Inject StdDevProcessor processor;

@Override public void configure() throws Exception { from("jetty:http://0.0.0.0:8183/std-dev").doTry() .process(processor) .doCatch(Throwable.class) .setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500)) .setBody(constant("{\"error\" : \"Service failed\"}")) .end(); }}


HTTP Calculator

@Override

public void configure() throws Exception { onException(Throwable.class).maximumRedeliveries(-1).delay(5000); from("direct:start") .multicast() .parallelProcessing().timeout(10000).to(stdDevService, varianceService) .end().setHeader("name", constant("HTTP")).to(collectorService);

}


HTTP Calculator

@Inject

@Uri("netty4-http:http://{{service:collector-http:localhost:8184}}/results/http")private Endpoint collectorService;

@Inject@Uri("netty4-http:http://{{service:variance-http:localhost:8182}}/variance")private Endpoint varianceService;

@Inject@Uri("netty4-http:http://{{service:std-dev-http:localhost:8183}}/std-dev")private Endpoint stdDevService


Messaging Calculator

Endpoint jmsSender = getContext().getEndpoint("jms:topic:" + CALCULATION_TOPIC + "?preserveMessageQos=true" + "&replyTo=" + RESULT_QUEUE +"&replyToType=Exclusive" + "&asyncConsumer=true" + "&asyncStartListener=true" + "&concurrentConsumers=10");


Messaging Calculator

from("jms:queue:”+RESULT_QUEUE).aggregate(header(CORRELATION_HEADER), new AggregationStrategy() { @Override public Exchange aggregate(Exchange oldExchange, Exchange newExchange) { if (oldExchange == null) { return newExchange; }

String oldBody = oldExchange.getIn().getBody(String.class); String newBody = newExchange.getIn().getBody(String.class); oldExchange.getIn().setBody(oldBody + "+" + newBody); return oldExchange; }}).completionSize(NUMBER_OF_SERVICES).completionTimeout(2000) .setHeader("name", constant("MSG")).to(collectorService);


The Collector:

@ContextName("collectorCamel")public class CollectorHTTP extends RouteBuilder {

@Override public void configure() throws Exception { getContext().addRoutePolicyFactory(new MetricsRoutePolicyFactory());

from("jetty:http://0.0.0.0:8184/results/http”).setId("HTTP");

from("jetty:http://0.0.0.0:8184/results/msg”).setId("MSG"); }}


Links:Links:

http://camel.apache.orghttp://camel.apache.orghttp://fabric8.iohttp://fabric8.iohttps://github.com/rajdavies/microservices-https://github.com/rajdavies/microservices-examplesexamples

messaging for the cloud and microservices

Software