Vi skal bruge en Message Broker eller en anden form for Event Streaming platform (BUS), her på H5. Formålet er at det skal være den første vores IoT enhed(er) kontakter og generelt kommunikere med. Der findes flere forskellige værktøjer som kan bruges, så her er en liste og den som jeg anbefaler til H5.
| Egenskab | Apache Kafka | Redis (med Redis Streams) | Mosquitto | RabbitMQ (Anbefalet) |
|---|---|---|---|---|
| Protokol | Egen protokol | Egen protokol | MQTT | AMQP 0-9-1, MQTT, STOMP |
| Beskedleveringsgaranti | Mindst én gang, præcis én gang | Mindst én gang | Mindst én gang, QoS niveauer | Mindst én gang, præcis én gang |
| Skalerbarhed | Meget skalerbar (distribueret som standard) | Skalerbar, men ikke distribueret som standard | Begrænset skalerbarhed | Moderat skalerbar (understøtter clustering) |
| Brugsscenarie | Realtime streaming og big data pipelines | Realtime-opgaver, letvægts streaming | IoT-messaging og letvægtskommunikation | Generel messaging |
| Persistens | Ja | Valgfrit (kan konfigureres) | Valgfrit (kræver specifik konfiguration) | Ja |
| Brugervenlighed | Middel (kræver opsætning og administration) | Nem (minimal opsætning) | Nem (letvægtsbroker) | Nem til Middel (omfattende dokumentation) |
| Ideel til | Big Data og Event Streaming | Letvægts messaging og task-køer | IoT og letvægtsenheder | Generel messaging, køer, IoT |
RabbitMQ er det bedste af begge verdener inden for IoT og Big Data, fordi det kombinerer pålidelig messaging og fleksibilitet med nem opsætning og understøttelse af flere protokoller som AMQP, MQTT, og STOMP.
Det er helt op til jer, hvilket værktøj i bruger, I skal bare kunne argumentere for hvorfor I vælger netop det værktøj til opgaven - resten af pensum tager udgangspunkt i RabbitMQ!
RabbitMQ står for Rabbit (hurtig) message-queueing. Vi bruger den blandt andet på H5, da den er velegnet til at arbejde med IoT enheder og Embedded systemer! RabbitMQ er som sagt hurtigt men også meget pålidelig, hvilket gør at den håndtere selv store datamængder rigtig godt! På siden her vil vi dykke ned i hvordan RabbitMQ er bygget op, hvorfor det er så hurtigt, samt de funktioner som gør den passer godt på IoT og Big Data! Her er en kort introduktion inden I begynder at læse - https://www.youtube.com/watch?v=NQ3fZtyXji0 | https://www.rabbitmq.com/ | https://www.youtube.com/watch?v=bfVddTJNiAw&pp=ygUPcmFiYml0bXEgZG90bmV0
RabbitMQ bygger på AMQ Protokollen, mere specifikt AMQP 0-9-1, som gør at vi har en masse funktioner fra start, her er en kort liste af de vigtigste.
Meddelelsesbaseret kommunikation
I stedet for at vi har direkte forbindelse mellem enhed og server eller enhed og client, har vi en Broker som fungerer som mellemmand mellem afsender og modtager. Dette gør kommunikationen mere fleksibel og pålidelig, da brokeren kan håndtere forskellige kommunikationsmønstre
Pålidelig levering
AMQP understøtter funktioner som meddelelses bekræftelse og automatisk genlevering, hvis en besked ikke bliver modtaget korrekt. Den fungerer altså også som en buffer, der kan gemme beskeder midlertidigt, hvis modtageren ikke er tilgængelig.
Routing og køstyring: AMQP har indbygget routing igennem exhanges, som gør at vi kan kontrollere hvordan vores data distribueres igennem queues
Interoperabilitet
AMQP er en standardprotokol, kan den bruges på tværs af forskellige platforme og programmeringssprog.
Skalering og løskobling Løskobling i AMQP betyder, at producenter og forbrugere ikke er direkte afhængige af hinanden, da de kommunikerer gennem en message broker som RabbitMQ. Producenter sender beskeder til en exchange, som router dem til køer baseret på routing keys og regler. Dette muliggør asynkron kommunikation, hvor systemerne kan skalere uafhængigt, og beskeder sikres levering, selv hvis en forbruger er offline. Dette gør AMQP ideelt til distribuerede og skalerbare systemer.
En publisher sender data til vores broker og den har kontrol over hvor det bliver sendt hen, hvilket betyder at publisher og consumer, ikke er direkte forbundet og derfor løskoblet!
Konkrete koncepter under AMQP
Nu har vi et overblik over hvorfor AMQP er en velegnet protokol for et hurtigt og skalerende message system, men lad os tage fat i nogle af de konkrete teknologier og hoved koncepter som er en del af AMQP.
Virtual Host (vhost): En vhost er en logisk container inden i en broker, der bruges til at adskille applikationer, som deler samme RabbitMQ-instans. For eksempel kan en vhost bruges til at opdele miljøer som udvikling og produktion. Ressourcer som køer, exchanges og brugere er isolerede inden for en vhost, så brugere kun har adgang til de ressourcer, der hører til deres vhost.
Connection: En connection er en fysisk netværksforbindelse (TCP) mellem applikationen (producent/forbruger) og brokeren. Hvis klienten afbryder forbindelsen, eller der opstår en fejl, lukkes forbindelsen.
Channel: En channel er en virtuel forbindelse inden i en connection. Den genbruger den samme TCP-forbindelse og undgår behovet for at oprette en ny. Når beskeder sendes eller modtages, sker det via en channel, og der kan være flere channels i én connection.
Exchange: En exchange håndterer routing-reglerne for beskeder og sørger for, at de når de korrekte køer. Beskeder rutes baseret på regler som direct (point-to-point), topic (mønstre), fanout (broadcast) eller headers. For at en kø kan modtage beskeder, skal den være bundet til mindst én exchange.
Queue: En queue er en opbevaringsplads for beskeder, som venter på at blive behandlet. Køer findes inde i brokeren.
Binding: En binding er en virtuel forbindelse mellem en exchange og en queue. Den sikrer, at beskeder fra en exchange kan flyde videre til den tilknyttede queue.
Her ser vi et komplet billede af de centrale elementer beskrevet ovenfor omkring AMQP
Vi kan starter vores Docker container med følgende Docker compose.yaml-fil
services:
H5:
image: rabbitmq:management
ports:
- "5672:5672" # RabbitMQ port med amqp-protokol
- "15672:15672" # RabbitMQ management UI
- "1883:1883" # MQTT port
environment:
RABBITMQ_DEFAULT_USER: admin
RABBITMQ_DEFAULT_PASS: admin
Her starter vi RabbitMQ op med 3 porte.
"15672:15672" som vi bruger til vores webdashboard som kommer standart med rabbitmq.
"5672:5672" som er den standart AMQP port, hvor vi senere kan subscribe på beskederne herfra og dermed bruge dem i vores backend og database
"1883:1883" vi tilføjer også porten for MQTT - dette er et rabbitmq plugin som gør at den både kan bruge AMQP og MQTT. En del enheder supportere begge, men lige præcis vores Arduino Opla gør ikke som standart eller gennem et større supporteret bibliotek. Derfor skal den have mulighed for at sende det over MQTT i stedet, dette er heller ikke et problem i de fleste af vores use-cases da MQTT er mindre tung end AMQP og derfor passer bedre til vores MKR1010 boards. Vi kan stadig drage fordel af funktionerne i RabbitMQ, såsom exhanges og queues
<aside> 🚫
Hvis I for en fejl med at port 1883 allerede er i brug, har jeres maskine nok allerede en lokal mosquitto kørende. Den kan i stoppe med følgende guide!
</aside>
For en sikkerhedsskyld se om det faktisk er mosquitto som optager porten
sudo lsof -i :1883
Hvis følgende bliver skrevet ud, så har I en lokal version af mosquitto
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mosquitto 125056 mosquitto 5u IPv4 1006750 0t0 TCP localhost:1883 (LISTEN)
mosquitto 125056 mosquitto 6u IPv6 1006751 0t0 TCP ip6-localhost:1883 (LISTEN)
Stop den nuværende mosquitto service
sudo systemctl stop mosquitto
Sørg for at det ikke starter op ved en genstart
sudo systemctl disable mosquitto
<aside> <img src="notion://custom_emoji/78111fd7-5d55-4196-af1c-1918b8dd24a0/1aedab5c-a237-80a7-87d3-007ace1044da" alt="notion://custom_emoji/78111fd7-5d55-4196-af1c-1918b8dd24a0/1aedab5c-a237-80a7-87d3-007ace1044da" width="40px" />
Hvis man vil sende data til RabbitMQ fra en Arduino enhed, skal man tilføje MQTT protokollen til RabbitMQ. Her gør vi det ud fra at det kører i Docker!
</aside>
For at tilgå ens container er det nemmest at bruge vores VSCode udvidelse med Docker
Når man trykker på inspect, for man en lang json fil - her burde der gerne være et “Name” - i det her eksempel er det "Name": "/docker-H5-1". Det kan vi bruge til at tilgå vores Container med følgende kommando
docker exec -it docker-H5-1 /bin/bash
Herfra burde I være inde og se jeres ID fra Docker - root@44205edfe1fb:/#
Nu kan vi skrive følgende kommando for at tilføje MQTT
rabbitmq-plugins enable rabbitmq_mqtt
Så genstarter vi vores RabbitMQ-Server for at være sikker på at ændringerne kommer med!
rabbitmqctl stop
rabbitmq-server &
For at tjekke, hvilke plugins der er installeret eller aktiveret på rabbitMQ kan man bruge følgende
rabbitmq-plugins list
Her burde følgende linje være der
[E*] rabbitmq_mqtt 4.0.7
Hvis der er fejl, kan det være nødvendigt at genstarte ens container med følgende kode
docker restart docker-H5-1