Microservices

Was ist ein Microservice?

• Kleine Services, die genau eine Geschäftsfunktion implementieren
• Jeder Service ist unabhängig von den anderen Services (Programmiersprache, Datenbank, Technologie-Stack)
• Jeder Service kann unabhängig von den restlichen Services in Produktion gebracht werden

Microservice-Typen

Microservices unterscheiden sich neben der eingesetzten Technologien auch in ihrer Kommunikation untereinander

• HTTP
• TCP
• UDP
• Websocket
• XMPP
• AMQP
• etc.

Wer benutzt Microservices?

• Netflix
• Amazon
• Soundcloud
• Ebay
• Google
• Spotify

Zitat von Melvin Conway, 1968

Welchen Vorteil bringt eine Microservice-Architektur?

• Starke Abgrenzung zwischen den Modulen
• Unabhängige Deployments
• Technische Vielfalt
• Flexiblere Skalierbarkeit

Welchen Nachteil bringt eine Microservice-Architektur mit?

• Höherer Kommunikationsaufwand (menschlich und technisch)
• Konsistenz nicht gegeben
• Deployment-Aufwand

Was braucht man für den Einsatz von Microservices?

• Continuous Delivery
• Devops
• Design for failure
• Monitoring

Beispiel

Mittelanträge im Hackerspace Bremen e.V.

Problematik

Mittelanträge im Hackerspace Bremen e.V.

Lösung im Verein

• Jedes Mitglied kann einen Mittelantrag für ein Projekt, Gerätschaft o.ä. stellen
• Monatliche Ausschüttung der Überschüsse auf Mittelanträge
• Abstimmung wie Mittel verteilt werden (Jedes Mitglied 3 Stimmen)

Berechnung zur Mittelverteilung

1. Sortiere Mittelanträge nach Stimmen
   • Wenn Projekt mit meisten Stimmen die verfügbaren Mittel komplett nutzen kann, erhält es diese
   • Ansonsten erhält es die Hälfte der verfügbaren Mittel
2. Wiederhole den letzten Schritt für den nächsten Antrag

Besonderheiten:
• Mittelantrag "Sammelfach" blockiert alle Mittelanträge mit weniger Stimmen
• Mehrere Mittelanträge haben gleich viel Stimmen

Was ist Vert.x?

Reactive

Polyglot

• Java
• JavaScript
• Groovy
• Ruby
• Ceylon

Asynchron

• Prozess wird nicht blockiert
• Ermöglicht, dass der Thread beim Warten auf ein Ergebnis, andere Aufgaben erledigen kann

Event-basiert

• Ermöglicht Entkopplung der Module

Skalierbar

• Über mehrere Server
• Durch Cluster-Manager

Modular

• Vert.x selber ist modular aufgebaut
• Der Core ist nur 650kB groß
• Komplett Open-Source: github.com/vert-x3

Flexibel

• Kann zusammen mit anderen Frameworks verwendet werden
• .. oder alleine

Vert.x Grundlagen

Verticle

• Basiskomponente in Vert.x

public class MyVerticle extends AbstractVerticle {

    public void start() {
        System.out.println("Hello World");
    }
}

Worker Verticle

• Worker können blockierende Aufrufe enthalten
• Werden in einem Thread-Pool ausgeführt

Eventbus

• "Nervensystem" von Vert.x
• Über den Event-Bus können Verticle miteinander kommunizieren
• Nachrichten werden an eine Adresse gesendet
• Verticles können sich für Adressen registrieren
• Verschiedene Nachrichten-Kommunikation:
  • Publish/Subscribe
  • Point to point
  • Request-Response

Nachrichten empfangen

Nachrichten können über Handler empfangen werden:

vertx.eventBus().consumer("uni.bremen", message -> {
    System.out.println("I have received a message: " + message.body());
});

public class MyVerticle extends AbstractVerticle 
        implements Handler<Message<JsonObject>>{

    public void start() {
        vertx.eventBus().consumer("uni.bremen", this);
    }

    @Override
    public void handle(Message<JsonObject> message) {
        System.out.println("I have received a message: " + message.body());

        message.reply("Got it");
    }    
}

Nachrichten senden

• Nachrichten können mittels send & publish versendet werden
• Mit publish wird die Nachricht an jeden horchenden Handler gesendet
• Mit send wird die Nachricht an einen horchenden Handler gesendet
• Antworten können nur durch die Nutzung von send erhalten werden

Publish und Send

this.vertx.eventBus().publish("uni.bremen","ONOC ftw");
						
this.vertx.eventBus().send("berechne", "5+4", asyncResult -> {
    log.info("Ergebnis" + asyncResult.result().body().toString())
});

Cluster-fähiger Eventbus

• Vert.x hat kein eigenes Cluster-System
• Verschiedene Cluster-Lösungen nutzbar
  • Hazelcast
  • JGroups
  • Zookeeper
• Vorteil: Höhere Skalierbarkeit

Event-Bus Bridges

• Der Event-Bus kann über sogenannte "Bridges" an andere Systeme angebunden werden
• Websocket-Bridge
• TCP-Bridge
• Vert.x 2 Bridge
• AMQP-Bridge in Version 3.3
• Eigene Implementierung

Verteilte Daten

• Es ist möglich Daten in gemeinsam genutzte Datenbereiche (Shared Maps) zu legen
  • Local shared Maps
  • Cluster-wide asynchronous maps
• Locks um bestimmte Bereiche zeitweise zu sperren
• Counter

Web

• Vert.x bietet eigenes Web-Modul
• Low-level

vertx.createHttpServer().requestHandler(request -> {
    HttpServerResponse response = request.response();
    response.putHeader("content-type", "text/plain");
    response.end("Hello World!");
});

server.listen(8080);

Mittelanträge: Lösung mit Microservices in Vert.x

Möglicher Aufbau einer Microservice-Architektur

Code

siehe Beispiel-Projekt auf Github: github.com/HackerspaceBremen/mittelvergabe-vertx

Umbau "Open Space Notifier"

Aktuell

• Der Open Space Notifier läuft auf dem PaaS-Dienst Google App Engine
• Nutzung bis zu einem gewissen Maße kostenlos
• Einschränkungen: DataStore, Caching, Taskqueues, usw.
• Architektur: Simple Drei-Schichten-Architektur mit HTML & JSP im Frontend

Läuft doch! Warum umbauen?

• Anbindung Sensoren nicht optimal
• Erweiterung der Anwendung ist für andere Entwickler nicht unbedingt einfach
• Nutzung für andere Spaces unattraktiv

Also: Umbau auf Microservices

• Geräte:
  • Mehrere Raspberry-Pi im Cluster nutzen
• Loadbalancer:
  • Nginx zur "Lastverteilung"
• Umgebung:
  • Microservices laufen in Docker Containern
  • In einem Docker Swarm CLuster
• Das wird eine super Spielwiese

Vorteile

• Bessere Anbindung der Sensoren
• Unterschiedliche Programmiersprachen mögliche
• Verschiedene Technologie-Stacks möglich
• Anbindung an andere Projekte, wie Arduino Videogame

Nachteile

• Kommunikation
  • zwischen Microservices muss dokumentiert sein
  • zwischen Entwicklern

Herausforderungen

• Logging
• Deployment über Weboberfläche
• Einarbeitung in nginx und Docker Swarm