The end of server management

RabbitMQ 101 : job scheduling, microservices communication, event-based data stream How to cook the rabbit?Quentin ADAM@waxzceClever Cloud

Immutable infraCall to action Liste de course1

Quentin ADAM from the Clever Cloud@waxzce on twitter github- soundcloud instagram .Who am I ?

My day to day work : Clever Cloud, the IT automation company

Keep your apps online. made with node.js, scala, java, ruby, php, python, go

And learn a lot of things about your code, apps, and good/bad design

Give back to the community

NEVER GONNA LET YOU DOWNclever-cloud.com

applications

More and more complex

Split applications?

Focus on specific stack for specific use?

Common case: php site with websockets, go to node?

Applications needs to communicates

Web dev first think : http

Unidirectional

No ACK

routing

auth

What do we need to share with others services?

events

Diffuse events to all services components where its need

Message broker

Message brokerJMS0MQRedisCeleryKafkaFiles + CronrabbitMQ

Advanced Message Queuing Protocolprotocol

Originally made by JP Morgan Bank (USA)AMQP

Now OASIS sectionAMQP

Many implementationsAMQP

rabbitmq

Is the well known implementation & made with erlangRabbit MQ

Erlang OTP

Speak almost all languages and platformRabbit MQ

Few concepts

Think as cluster name for sharing cluster nodes for multiples purposeVirtual host

Client pushing messagespublisher

Client getting messagesConsumer

Yeah, basically tcp + authconnections

logical connectionChannels

See this as INBOXexchanges

See this as WAY OUTQUEUES

And use a routing keyYou have to explicitly bind a queue on an exchange

Its an event, what we need to shareMessages

Headers / body

Wrap up

The different EXCHANGES

Perfect repartition with load balancing & routing key

Amqp.direct

Tell all messages to Anyone suscribeAmqp.fanout

Basically a FANOUT using routing key

Amqp.topic

Direct exchange using matching on HeadersAmqp.match

Listening one queue using many consumers

You can now describe your topology

ACK

no-ACK downside

Messaging lifecycle

Buffer by consumer

Durable & exclusiveQueue Params

Queue life cycle

Disk or RAM debateLots of messages in memory?

Request/reply pattern

enjoyTopology crash test

Example: Clever Cloud real time logExchange FanOut

Logs

Routing key = app idLogs from logstash, 1 message per line1 queue by WS, RK = appID, name = appid + autogen1 queue by WS, RK = appID, name = appid + autogen1 queue by WS, RK = appID, name = appid + autogen

Cluster way of life

Queue HA

federation

plugins

Stomp, mqtt, websockets

More than 5 years production historyIs it battle tested ?

Why its so cool

I can branch where I want

exampleEvolution of usages

Example: Clever Cloud real time log+ logs drainExchange FanOut

Logs

Routing key = app idLogs from logstash, 1 message per line1 queue by WS, RK = appID, name = appid + autogen1 queue by WS, RK = appID, name = appid + autogen1 queue by WS, RK = appID, name = appid + autogen1 durable queue by drain, using RK=appID & name = drain__1 durable queue by drain, using RK=appID & name = drain__1 durable queue by drain, using RK=appID & name = drain__1 durable queue by drain, using RK=appID & name = drain__

Run it with PHPhttps://github.com/php-amqplib/php-amqplib

Soon open source, new ACL add-on + pre-signed auth

Soon a regular add-on, just ask support to get beta accessYou can test it on Clever Cloud ;-)

Give clever-cloud.com a try Im @waxzce on twitter Thx for listening Clever Cloud gift coupon:phptour16