Microservice-Alarmanlage gegen steigende Einbruchszahlen

Inhaltsverzeichnis

In den vergangenen Monaten hat das Buzzword "Microservices" zunehmend an Bedeutung (Google Trends) gewonnen. Der Artikel veranschaulicht anhand der Entwicklung einer Alarmanlage den praktischen Nutzen der damit verbundenen Architektur.

Gemeinhin versteht man unter Microservices den architektonischen Gegenentwurf zum klassischen Softwaremonolithen, der sämtliche Komponenten einer Anwendung unter einem Artefakt ausliefert. Setzt sich die Anwendung hingegen aus einer Menge unabhängiger Softwarebausteine zusammen, die sich getrennt voneinander entwickeln, versionieren und ausliefern lassen, spricht man von einer Microservice-Architektur.

Die Alarmanlage der beiden Autoren basiert ausschließlich auf Open-Source-Software. Die theoretischen Grundlagen zu Microservices sind im Artikel "Microservices im Zusammenspiel mit Continuous Delivery" beschrieben.

Durch die Aufteilung der Alarmanlage in kleine Komponenten, die zum Beispiel auf einem Raspberry Pi laufen, ist eine hohe Flexibilität zur Zusammenstellung und Erweiterung des gerade benötigten Systems gegeben. Deshalb ist sie in jedem Haushalt einsetzbar, um sich effektiv gegen Einbrüche zu schützen.

Aus welchen Microservices besteht das System?

Das System besteht aus vier Microservice-Typen, die unabhängig voneinander entwickelt und ausgeliefert werden:

• Detektoren sind für das Erkennen von Alarmzuständen verantwortlich. Die Implementierung von jedem Detector-Service kann dabei ganz unterschiedlich ausfallen. Beispielsweise lässt sich ein Alarm auslösen, indem Infrarot-Sensoren eine Bewegung erkennen oder wenn Erschütterungssensoren ein Rütteln an Türen und Fenstern feststellen. Hier sind noch viele weitere Erkennungsmechanismen möglich.
• Handler sind genauso wie Detektoren unabhängige Services, die für die Verarbeitung erkannter Störungen (durch die Detektoren) zuständig sind. Das kann zum Beispiel die Aktivierung einer Sirene auf dem Dach sein, ein Mail-Versand oder einfach nur ein ein Wiedergabegerät, das den Einbrecher bittet, das Haus wieder zu verlassen, und ihn informiert, dass die Polizei informiert wurde.
• Konsolen sind für das Ein- und Ausschalten der Alarmanlage zuständig. Das ist ansonsten nur über die Weboberfläche des Masters möglich.
• Der Master oder auch Dispatcher wird für die Koordination zwischen Detektoren und Handlern eingesetzt und ist ebenfalls komplett unabhängig von den anderen Komponenten implementiert. Empfängt der Master ein Signal von einem Detektor, leitet er es an die entsprechend konfigurierten Handler weiter, damit diese die gewünschte Aktion durchführen. Zusätzlich wird über den Master ein Web-Interface bereitgestellt, das die Konfiguration sowie das Ein- und Ausschalten des Systems ermöglicht.

Die entkoppelten Services kommunizieren mittels einfachem JSON über HTTP miteinander und tauschen so Daten aus. Folgende Grafik zeigt eine Service-Komposition am Beispiel einer Wohnung:

Die Dreizimmerwohnung ist in jedem Raum mit einem Infrarot-Detektor ausgestattet. Als Alarm-Signale sind ein Mail- und Sirenen-Handler vorhanden. Der Master in Raum 2 sorgt für die Verwaltung der Komponenten. Die Bewohner können über das Smartphone auf den Master zugreifen und sehen so den Zustand der Alarmanlage:

Master-, Infrarot-, Sirenen- sowie Mail-Service sind bereits implementiert und können als Grundlage für die erste eigene Alarmanlage dienen. Zusätzlich existieren zum Testen noch weitere Mock-Services, die in der Systemübersicht beschrieben sind. Das System ist so aufgebaut, dass es jederzeit erweiterbar ist und sich neue Microservices mit zusätzlichen Funktionen hinzufügen lassen. Da es sich um Open-Source-Software handelt, kann jeder das Ökosystem erweitern.