microservices - it-anrechnungsstudiengänge | open it · 2019-10-23 · microservices –vs– soa...
TRANSCRIPT
Wir bilden Zukunft. Einleitung
Microservices sind ein Ansatz zur
Modularisierung, der der Philosophie von UNIX
folgt
– Ein Programm soll nur eine Aufgabe erfüllen, diese
aber präzise und gut
– Programme sollen miteinander interagieren können
– Eine universelle Schnittstelle zur Kommunikation soll
genutzt werden
• Bei UNIX sind dies Textstreams
Cloud Computing 2
Wir bilden Zukunft. Einleitung
Ziel ist es, ein großes System in verschiedene
kleine aufzuteilen
Microservices können mit verschiedenen
Technologien und auf Basis verschiedener
Plattformen implementiert werden
Sie können eigene Datenbanken und weitere
Services mitbringen
Sie sind selbstständige, in sich geschlossene
Prozesse
Sie kommunizieren über ein Netzwerk
– Z.B. über HTTP mit RESTful APIs
Cloud Computing 3
Wir bilden Zukunft. Definition
Eine genaue Definition für den Begriff
Microservice gibt es nicht
Denn impliziert der Name, dass die Größe
entscheidend ist
Ein Ansatz zur Definition wäre die Anzahl der
Codezeilen als Metrik zu nutzen. Allerdings
hängt dies stark von der Programmiersprache
ab. Zudem sind Microservices ein
Architekturmodell und sollten daher den
Architekturbetrachtungen statt
Programmiersprachenparametern folgen
Cloud Computing 4
Wir bilden Zukunft. Definition
Verschiedene Faktoren beeinflussen die
Entscheidung, ob es sich um einen Microservice
handelt
– Modularisierung
– Verteilte Kommunikation
– Refactoring
– Teamgröße
– Infrastruktur
– Ersetzbarkeit
– Transaktionen
Cloud Computing 5
Wir bilden Zukunft. Definition
Eine große Anwendung aufgeteilt in
verschiedene kleine interagierende Module
Kleine Einheiten eigenständiger Module können
einfacher nachvollzogen und implementiert
werden als große Anwendungen
Bei monolithischen Anwendungen steigt die
Komplexität über Zeit dramatisch an
– Microservices verteilen die Komplexität auf mehrere
Entitäten
Cloud Computing 6
Modularisierung
Kommunikation
Refactoring
Teamgröße
Infrastruktur
Ersetzbarkeit
Transaktionen
Wir bilden Zukunft. Definition
Da Microservices in verschiednen, einzelnen
Prozessen ausgeführt werden, benötigen sie
einen Weg zur Interprozesskommunikation
– Dazu nuten sie häufig RESTful APIs mit JSON
– Auch RPC/RMI oder SOAP wären eine Möglichkeit
Diese Art der Kommunikation erzeugt einen
großen Mehraufwand
– Sie ist zudem um ein vielfaches langsamer
– Höhere Fehleranfälligkeit ist ein weiteres Problem
In der Praxis funktionieren Microservice-
Systeme dennoch schnell und zuverlässig
Cloud Computing 7
Modularisierung
Kommunikation
Refactoring
Teamgröße
Infrastruktur
Ersetzbarkeit
Transaktionen
Wir bilden Zukunft. Definition
Die Grenzen der Implementierungen zwischen
Microservces bringen verschiedene
Schwierigkeiten mit sich
Im Falle einer Restrukturierung z.B. muss ggf.
Implementierung zwischen Microservices
verschoben werden
Die nicht unmittelbar sichtbaren Abhängigkeiten
bergen ein großes Fehlerpotential
Cloud Computing 8
Modularisierung
Kommunikation
Refactoring
Teamgröße
Infrastruktur
Ersetzbarkeit
Transaktionen
Wir bilden Zukunft. Definition
Die Einteilung des Entwicklungsaufwands in
Teams resultiert in einer Maximalgröße
Ein Team soll in der Lage sein, Änderungen
selbstständig vorzunehmen und in Produktion zu
bringen
Sind Microservices sehr klein, kann ein Team für
mehrere verantwortlich sein
Sind mehrere Teams für die Implementierung
eines Microservices zuständig, ist er zu groß
Cloud Computing 9
Modularisierung
Kommunikation
Refactoring
Teamgröße
Infrastruktur
Ersetzbarkeit
Transaktionen
Wir bilden Zukunft. Definition
Neben der reinen Entwicklung muss auch
Infrastruktur zum Testen, Integrieren und das
Deployment vorhanden sein
Jeder Schritt nach der Entwicklung sollte
automatisiert sein
Je größer Microservices werden, desto
schwieriger ist es, dies umzusetzen
Je kleiner sie sind, desto stabiler und schneller
funktioniert der automatische Prozess
Cloud Computing 10
Modularisierung
Kommunikation
Refactoring
Teamgröße
Infrastruktur
Ersetzbarkeit
Transaktionen
Wir bilden Zukunft. Definition
Ein Microservice muss so einfach ersetzbar sein
wie möglich
– Das passiert z.B., wenn Technologie veraltet oder die
Implementierung umfangreich verändert werden muss
Je kleiner ein Microservice ist, desto leichter
kann er ersetzt werden
– Und desto einfacher sind Abhängigkeiten zu
handhaben
Cloud Computing 11
Modularisierung
Kommunikation
Refactoring
Teamgröße
Infrastruktur
Ersetzbarkeit
Transaktionen
Wir bilden Zukunft. Definition
Auch in einem Microservice-Kontext muss in der
Regel das ACID-Prinzip erfüllt werden
Dabei werden Transaktionen über mehrere
Microservices hinweg gestartet und müssen
schließlich in einem konsistenten Gesamtsystem
resultieren
Verschiedene Ansätze und Tools für diese
Szenarien existieren
– Z.B. Two-Phase-Commits
Cloud Computing 12
Modularisierung
Kommunikation
Refactoring
Teamgröße
Infrastruktur
Ersetzbarkeit
Transaktionen
Wir bilden Zukunft. Definition – Zusammenfassung
Microservices sind
dedizierte
Implementierungseinheiten
Sie sollen genau eine
Aufgabe erfüllen
Zur Kommunikation sollte
ein fest definierter Weg
existieren
Ersetzbarkeit,
Transaktionsunterstützung
und die Teamgröße sind
weitere Einflussfaktoren
Cloud Computing 13
Wir bilden Zukunft. Beispiel
Die Abbildung zeigt exemplarisch eine
Microservices-Anwendung
Die Farbgebung deutet verschiedene
Aufgabengebiete an, die Höhe symbolisiert
unterschiedliche Skalierungsgrade
Cloud Computing 14
Wir bilden Zukunft. Beispiel
Jeder Microservice hat eine
Reihe von Bestandteilen, die
für den Betrieb wichtig sein
– Metriken
– Logging
– Healthchecks
– Einen Service-Endpunkt
– Integration in eine Service-
Registry
– Service Management
Cloud Computing 15
Wir bilden Zukunft. Definition
Es gibt verschiedene Gründe, warum
Unternehmen vermehrt Microservices zur
Implementierung von Anwendungen einsetzen
Das hat nicht nur technische Gründe; die
Struktur und die anders stattfindende
Entwicklung kann sich positiv auf die
Unternehmensziele auswirken
Cloud Computing 16
Modularisierung
Ersetzbarkeit
Time to Market
Skalierung
Technologiewahl
Continuous
Delivery
Wir bilden Zukunft. Definition
Das Modularisierungskonzept von Microservices
schafft unabhängige Anwendungsteile
Explizite Kommunikationsschnittstellen müssen
genutzt werden
– Das beugt leicht zu übersehenen Abhängigkeiten
größtenteils vor
Die gleiche Modularisierung kann auch in einem
Applikationsmonolithen erreicht werden, das
passiert allerdings äußerst selten
Cloud Computing 17
Modularisierung
Ersetzbarkeit
Time to Market
Skalierung
Technologiewahl
Continuous
Delivery
Wir bilden Zukunft. Definition
Microservices können leichter ersetzt werden
Wenn die explizite Schnittstelle zur
Kommunikation unverändert erhalten bleibt,
bemerken es nutzende Services nicht einmal
Das erlaubt auch, Teile des Gesamtsystems
auszutauschen, ohne den Rest zu beeinflussen
– Ein Aspekt, der bei monolithischen Systemen nicht
möglich ist
Cloud Computing 18
Modularisierung
Ersetzbarkeit
Time to Market
Skalierung
Technologiewahl
Continuous
Delivery
Wir bilden Zukunft. Definition
Microservices ermöglichen eine kürzere Time to
Market, Da Funktionalität in kleineren Teilen,
Schritt für Schritt in Produktion gebracht werden
kann
Eine Organissationsstruktur mit Cross
Functional Teams erlaubt es zudem,
Deployments ohne Abstimmung mit anderen
Teams durchzuführen
Das Konzept von Microservices skaliert mit dem
von agilem Projektmanagement
Cloud Computing 19
Modularisierung
Ersetzbarkeit
Time to Market
Skalierung
Technologiewahl
Continuous
Delivery
Wir bilden Zukunft. Definition
Ein weiterer Vorteil von vielen Systemen: jedes
einzelne kann auf die jeweiligen Bedürfnisse
angepasst skaliert werden
Das erlaubt besseres Reagieren auf spezifische
Skalierungsanforderungen vom Teil des
Systems
Weiterhin erlaubt das, die Infrastruktur erheblich
zu vereinfachen
Cloud Computing 20
Modularisierung
Ersetzbarkeit
Time to Market
Skalierung
Technologiewahl
Continuous
Delivery
Wir bilden Zukunft. Definition
Die strikte Trennung von Microservices erlaubt
es auch, verschiedene Technologien zu
Implementierung zu nutzen
Das erlaubt zum Beispiel Rolling Updates von
Technologien und vereinfacht
Technologiewechsel
Weiterhin können auch Technologien speziell
auf Anwendungsfälle abgestimmt werden
– Z.B. Anbindungen an Legacy-Systeme oder exotische
Datenbanken
Cloud Computing 21
Modularisierung
Ersetzbarkeit
Time to Market
Skalierung
Technologiewahl
Continuous
Delivery
Wir bilden Zukunft. Definition
Die Unabhängigkeit von Microservices erlaubt
es, die unabhängig voneinander in Produktion
zu bringen
Weiterhin ist das damit verbundene Risiko
gering, da im schlimmsten Fall nur ein kleiner
Teil des Systems ausfällt
– Blue/Green-Deployments und Containerisierung
erlauben darüber hinaus, das Risiko noch weiter zu
reduzieren
Cloud Computing 22
Modularisierung
Ersetzbarkeit
Time to Market
Skalierung
Technologiewahl
Continuous
Delivery
Wir bilden Zukunft. Vor- und Nachteile
Kategorie Monolith Microservices
Code Einzelne Codebase
für die gesamte
Anwendung
Verschiedene
Codebases, eine pro
Microservice
Verständlichkeit Oft schwer
nachvollziehbar über
Zeit
Bessere
Verständlichkeit und
Wartbarkeit
Deployment Big Bang-
Deployments mit
Scheduled
Downtimes
Komplizierte
Deployment-
Strukturen mit
besserer
Verfügbarkeit
Programmiersprache Eine
Programmiersprache
n
Programmiersprache
n
Skalierbarkeit Als ganzes Auf Services-Ebene Cloud Computing 23
Wir bilden Zukunft. Organisationsstruktur
Die Entscheidung zu Microservices hat auch
Einfluss auf die Organisationsstruktur des
Unternehmens
Nach Conway‘s Law, einer Gesetzmäßigkeit
postuliert von Melvin E. Conway, folgt die
Organisationsstruktur eines Unternehmens dem
Design seiner Systeme
– Oder anders herum?
Cloud Computing 24
Wir bilden Zukunft. Organisationsstruktur
Any organization that designs a system (defined
broadly) will produce a design whose structure is
a copy of the organization’s communication
structure
Für Unternehmen heißt das, dass die
vorhandene Kommunikationsstruktur geändert
werden können sollte, um erfolgreich
Microservices einzusetzen
Cloud Computing 25
Wir bilden Zukunft. Teamstruktur
In einem klassischen
Entwicklungsumfeld sind
Zuständigkeiten oft nach
technischen Aspekten
aufgeteilt
Änderungen seitens des
Kunden betreffen in der Regel
alle drei Bereiche
– Es entsteht Koordinationsaufwand
– Es kommt zu Verzögerungen
aufgrund von Prozessen und
Projektmanagement
Cloud Computing 26
Wir bilden Zukunft. Teamstruktur
Das Konzept von Microservices und die
entsprechende Teameinteilung wirkt sich positiv
auf die Produktentwicklung aus
In diesem Kontext wird auch von Cross
Functional Teams gesprochen
Cloud Computing 27
Wir bilden Zukunft. Microservices –vs– SOA
Bei Microservices handelt es sich nicht um eine
Service Oriented Architecture
– Bei dieser gibt es eine zentrale Integrationsstelle
– Entwicklung findet meist mit funktional eingeteilten
Teams statt
Cloud Computing 28
Wir bilden Zukunft. Deployment
Es gibt verschiedene Wege, wie Microservices
in Produktion bereitgestellt werden können
– Mehrere Services pro Host
– Service-Instanz pro Host
– Service-Instanz pro Container
Die Methode ist generell abhängig von
benötigten Ressourcen, Applikationsaufbau,
Anforderungen, …
Cloud Computing 30
Wir bilden Zukunft. Mehrere Services pro Host
Bei diesem Modell werden einer oder mehrere
Server physisch oder virtuell provisioniert
Auf diesem werden dann ein oder mehrere
Instanzen der Microservices ausgeführt
Klassisches Modell, Behandlung der Server als
Pets
Cloud Computing 31
Wir bilden Zukunft. Mehrere Services pro Host
Generell gibt es zwei Varianten dieses Modells
Getrennte Prozesse
– Es werden bspw. mehrere JEE-Anwendungen auf
mehreren Application Server-Instanzen ausgeführt
Geteilte Prozessgruppen
– Es werden bspw. mehrere JEE-Anwendungen auf der
selben Application Server-Instanz ausgeführt
Cloud Computing 32
Wir bilden Zukunft. Mehrere Services pro Host
Vorteile
– Ressourceneffizient
• Vor allem beim Teilen von App-Servern
– Deployment ist schnell
– Bootstrapping einer Anwendung ist schnell und simpel
• Auch wenn mehrere Prozesse gestartet werden müssen
Nachteile
– Wenig bis keine Isolation von Applikationen
– Spezifisches Monitoring komplizierter
– Keine gute Prozessisolation
– Operations-Team muss Details der Anwendung
kennen
Cloud Computing 33
Wir bilden Zukunft. Service-Instanz pro Host
Bei diesem Modell wird ein Service alleine pro
Host ausgeführt
In der Regel wird eine Anwendung dabei als
Abbild einer virtuellen Maschine gepackt und
deployed
Auch bei diesem Modell werden verschiedene
Werkzeuge zur Automatisierung genutzt, z.B.
Vagrant von Hashicorp
Cloud Computing 34
Wir bilden Zukunft. Service-Instanz pro Host
Vorteile
– Strikte Prozessisolation
– Begrenzte, aber dedizierte Ressourcen
– Black-Box-Charakter der VMs
Nachteile
– Ineffiziente Ressourcennutzung
– In der Regel langsames Deployment
• Betriebssystemstart, große Abbilder
– Overhead durch Betriebssystemverwaltung in der VM
Cloud Computing 35
Wir bilden Zukunft. Service-Instanz pro Host
Das vorherige Modell wird so angepasst, dass
Anwendungen in Containern ausgeführt werden
Container sind ein Virtualisierungsmechanisum
auf Betriebssystemebene
Für dieses Vorgehen wird die Anwendung als
Container gepackt und dann auf dem Host
ausgeführt
Cloud Computing 36
Wir bilden Zukunft. Service-Instanz pro Host
Vorteile
– Ähnlich zu denen des vorherigen Ansatzes
– Monitoring ist einfacher
– Bessere Steuerung über Container-APIs
– Schnelleres Bootstrapping
Nachteile
– Container haben oftmals Kinderkrankheiten
– Verwaltung der Container-Abbilder
– Falscher Eindruck von Sicherheit
Cloud Computing 37
Wir bilden Zukunft. Migration zu Microservices
Der Wechsel zu einem Microservices-System
involviert eine Menge an Planungs-,
Entwicklungs- und Verwaltungsaufwand
Generell kann eine Migration in drei Schritten
vorgenommen werden:
1. Anpassung des Deployments und der
Applikationsstruktur in Produktion
2. Neustrukturierung des Codes
3. Änderung der Datenstrukturen (Backing Services)
Cloud Computing 38
Wir bilden Zukunft. Migration zu Microservices
Lesen Sie dazu den formalisierten
Ansatz von Lecovitz/Terra/Valente in
Towards a Technique for Extracting
Microservices from Monolithic
Enterprise Systems (2016)
Cloud Computing 39
Wir bilden Zukunft. Service Discovery
Die Aufgabe von Service Discovery ist die
Sicherstellung, dass sich Microservices
gegenseitig finden können
In einem Netzwerk aus Diensten, verteilt über
mehrere Server/Regionen/Clouds/… muss eine
Kommunikation hergestellt werden
– Wie finde ich die Autorisierungsdienst?
Cloud Computing 40
Wir bilden Zukunft. Service Discovery
Eine naheliegende Möglichkeit wäre die Pflege
einer Datei mit Zuordnungen (z.B. Name zu
Adresse), die von Diensten ausgelesen wird
Allerdings hat dieser Ansatz gravierende
Nachteile
– Microservices kommen und gehen. Das liegt nicht nur
an Fehlern, sondern passiert auch bei neuen
Deployments
– Das Ziel von Microservices, Entkopplung, steht dem
entgegen
– Es ist schwierig, eine Übersicht über das
Gesamtnetzwerk zu erhalten
Cloud Computing 41
Wir bilden Zukunft. Service Discovery / Config. Mgmt.
Service Discovery ist mit dem Configuration
Management verwandt, allerdings scharf davon
zu trennen
– Configuration Management zielt auf Konsistenz ab;
eine spezifizierte Konfiguration soll auf einer Menge
von Servern sicher und konsistent bereitgestellt
werden
– Bei Service Discovery steht die Verfügbarkeit im
Vordergrund, es werden dafür Abstriche im Bereich
Konsistenz gemacht
Service Discovery ist die Grundlage für
Skalierung und Hochverfügbarkeit in einem
Microservices-System
Cloud Computing 42
Wir bilden Zukunft. Service Discovery-Systeme
Als Grundlage wird ein System benötigt, das
– IP-Adressen zu einer gegebenen eindeutigen Kennung
ermitteln kann
– Ports von Microservices zu einer gegebenen Kennung
ermitteln kann
– Auch mehrere Kombination dieser Datenpunkte
bereitstellen kann
– Einfach integrierbar in bestehende Anwendungen ist
– Gut skaliert werden kann
Welches System kennen Sie, das diese
Anforderungen erfüllt?
Cloud Computing 43
Wir bilden Zukunft. Service Discovery-Systeme
Als Grundlage wird ein System benötigt, das
– IP-Adressen zu einer gegebenen eindeutigen Kennung
ermitteln kann
– Ports von Microservices zu einer gegebenen Kennung
ermitteln kann
– Auch mehrere Kombination dieser Datenpunkte
bereitstellen kann
– Einfach integrierbar in bestehende Anwendungen ist
– Gut skaliert werden kann
Das Domain Name System (DNS)
Cloud Computing 44
Wir bilden Zukunft. Service Discovery-Systeme
DNS alleine reicht allerdings nicht aus, es muss
eine konstante Verwaltung und Anpassung
erfolgen
Daher wird es in der Regel mit einem speziellen
Service Discovery-System kombiniert
Cloud Computing 45
Wir bilden Zukunft. Consul
Consul ist ein Open Source-System, das für
Service Discovery (und auch Configuration
Management) genutzt werden kann
Best besteht aus vier Komponenten
– Service Discovery – Es können Dienste bereitgestellt
und erfragt werden (DNS oder RESTful HTTP API)
– Health Checking – Dienste können (automatisiert) auf
ihren Status überprüft werden
– Key-Value-Store – Konfiguration kann zentral
abgelegt werden
– Multi Datacenter – Consul unterstützt den Betrieb
über mehrere Rechenzentren/Clouds hinweg
Cloud Computing 47
Wir bilden Zukunft. Consul
Consul-Instanzen (Agents) werden auf jedem
System/Container ausgeführt
Die Agents werden in zwei Modi ausgeführt:
– Als Server sind sie verantwortlich für Leader Election,
Cluster- und Konfigurationsverwaltung
– Als Client registrieren sie Dienste, übermitteln
Statusdaten und fragen Daten des Clusters ab
Cloud Computing 48
Wir bilden Zukunft. Consul-Architektur
Beispielhafte Architektur eines Consul-Clusters
– Die Leaders sind die Verwalter (Consul Server)
– Consul Agents werden auf jedem Node ausgeführt
Cloud Computing 49
Wir bilden Zukunft. Multi Datacenter Mode
Wird Consul im Multi Datacenter Mode
ausgeführt, findet ein Austausch
zweischneidiges den Server-Agents über das
Internet statt
Cloud Computing 50
Wir bilden Zukunft. Leader Election
In einem verteilten System ist es für den Aspekt
der Konsistenz und der Koordination wichtig,
eine zentrale Entscheidungsinstanz zu haben
Daher wird einer der Server Agents als Leader
ausgewählt
Das dahinterstehende Verfahren wird als
Leader Election bezeichnet
Bei Consul wird Raft als Algorithmus verwendet
Cloud Computing 52
Wir bilden Zukunft. Raft
Raft ist ein simpler und effektiver Algorithmus
zum Treffen einer Entscheidung in einem
verteilten System (es ist ein Consensus
Algorithm)
Er basiert auf drei Rollen
– Leader, die eine Entscheidung gewonnen haben
– Followers, die einem Leader folgen
– Candidates, die Leader werden wollen
Die Grundidee ist, dass die Teilnehmer solange
füreinander stimmen, bis einer ein Leader
geworden ist
Cloud Computing 53
Wir bilden Zukunft. Raft Beispiel 1: Schritt 1
Beispielsweise soll eine Leader Election mit drei
Teilnehmern gezeigt werden
Im Ausgangsstadium befinden sich alle im
Follower-Status
Sie können kommunizieren, es fehlt ihnen
jegliche Information über einen Leader
Cloud Computing 54
Wir bilden Zukunft. Raft Beispiel 1: Schritt 2
Selbstständig entscheidet ein Follower, Leader
werden zu wollen; er wird zum Candidate
Cloud Computing 55
Wir bilden Zukunft. Raft Beispiel 1: Schritt 3
Als Kandidaten wirbt er für eine Wahl zum
Leader, indem er andere Nodes über seine
Kandidatschaft informiert
Cloud Computing 56
Wir bilden Zukunft. Raft Beispiel 1: Schritt 4
In diesem einfachen Szenario gibt es keinen
weiteren Candidate, weshalb die beiden
anderen Follower für den vorhandenen stimmen
Cloud Computing 57
Wir bilden Zukunft. Raft Beispiel 1: Schritt 5
Der Candidate ist damit zum Leader geworden
Alle drei Nodes sind sich über diesen Status
einig
Cloud Computing 58
Wir bilden Zukunft. Raft-Leader-Kommunikation
Der Leader sendet nun kontinuierlich
Informationen an seine Follower
Diese Log-Einträge dienen als Medium zur
Informationsübertragung, z.B. Konfiguration
oder Health-Daten
Cloud Computing 59
Wir bilden Zukunft. Raft-Leader-Heartbeats
Viel wichtiger als die Daten sind die ebenfalls
kontinuierlich gesendeten Lebenszeichen
(Heartbeats)
Damit teilt der Leader den Followern mit, dass er
noch existiert und den Lead weiterhin für sich
beansprucht
Cloud Computing 60
Wir bilden Zukunft. Raft Beispiel 1: Schritt 6
Es ist immer davon auszugehen, dass der
Leader versagt
– Heartbeats brechen ab
Kommt es zu dieser Situation, steht das Cluster
zunächst ohne Leader da
Cloud Computing 61
Wir bilden Zukunft. Raft Beispiel 1: Schritt 7
In diesem Fall beginnt die Leader Election von
vorne; einer der Follower entscheidet, Candidate
zu werden
Er fordert den verbleibenden Follower zum
Wählen auf und gewinnt, da einziger Candidate
Cloud Computing 62
Wir bilden Zukunft. Kompliziertere Situation
Der einfache Fall, dass nur ein Follower zum
Leader wird, tritt nur selten auf
Häufiger ist es so, dass mehrere Candidates
existieren und die Leader Election auch mehrere
Runden dauern kann
Cloud Computing 63
Wir bilden Zukunft. Raft Beispiel 2: Schritt 2
Es kann passieren, dass zwei Follower zu
Candidates werden und jeweils unterschiedliche
Follower zum Wählen auffordern
Cloud Computing 64
Wir bilden Zukunft. Raft Beispiel 2: Schritt 3
Im zweiten Schritt wird der jeweils andere
Follower um einen Vote gebeten
Cloud Computing 65
Wir bilden Zukunft. Raft Beispiel 2: Schritt 4
Da der zweite Follower bereits eine Stimme
abgegeben hat, verweigert er eine zweite
Cloud Computing 66
Wir bilden Zukunft. Raft Beispiel 2: Schritt 5
Auch die Candidates kontaktieren sich
untereinander, da sich den jeweils anderen als
einfachen Follower betrachten
Da Candidates automatisch für sich selbst
stimmen, ist auch hier keine Stimmabgabe
möglich
Cloud Computing 67
Wir bilden Zukunft. Raft Beispiel 2: Schritt 6
Es kommt zu einem Patt und es existieren
weiterhin zwei Candidates und zwei Follower
Cloud Computing 68
Wir bilden Zukunft. Raft Beispiel 2: Schritt 7
Der Vorgang beginnt erneut, indem ein
Candidate nach einer gewissen Zeit ihm
bekannte Follower um einen Vote bittet
Cloud Computing 69
Wir bilden Zukunft. Raft Beispiel 2: Schritt 8
Die beiden Follower wählen für den Candidate
Da es nur vier Nodes gibt, hat dieser nun die
Mehrheit und damit den Leader-Status
Cloud Computing 70
Wir bilden Zukunft. Raft Beispiel 2: Schritt 8
An dieser Stelle haben die Nodes
unterschiedliche Informationen über den
Cluster-Zustand, ausgedrückt durch die Indizes
– Blau befindet sich in Zustand 2, Rot/Grau in Zustand 3
Cloud Computing 71
Wir bilden Zukunft. Raft Beispiel 2: Schritt 9
Der verbleibende Candidate fragt nun um Votes
und teilt dabei mit, dass er für den Statusindex 3
wählt
Cloud Computing 72
Wir bilden Zukunft. Raft Beispiel 2: Schritt 10
Für den Index 3 gibt es aber bereits einen
Leader
Die Follower lohnen ab und teilen gleichzeitig
Informationen über den bereits gewählten
Leader mit
Cloud Computing 73
Wir bilden Zukunft. Raft Beispiel 2: Schritt 11
Da der verbleibende Candidate feststellt, dass
seine Informationen veraltet sind und es bereits
einen Leader gibt, akzeptiert er den Status ohne
weitere Wahlversuche
Cloud Computing 74
Wir bilden Zukunft. Gossip
Ein weiteres Protokoll, das in
einem Microservices-System
(und auch bei Consul) zum
Einsatz kommt, ist Gossip
Grundlage: ein Netzwerk an
Agenten mit eigenem Zustand
verteilt einen Gossip-Strom
– Nachricht: Quelle, Inhalt/Zustand,
Zeitstempel
– Nachrichten werden in einem
festen Takt periodisch an andere
Agenten versendet (Fanout)
Cloud Computing 75
Wir bilden Zukunft. Gossip
Virale Verbreitung
– Knoten, die mit dem Agenten in einer Gruppe sind,
bekommen auf jeden Fall eine Nachricht
– Die Top x% an Knoten, die dem Agenten eine
Nachricht schicken, bekommen eine Nachricht
Nachrichten, deren vertraut wird, werden in den
lokalen Zustand übernommen
– Die gleiche Nachricht wurde von mehreren Seiten
gehört
– Die Nachricht stammt von Knoten, denen der Agent
vertraut
– Es ist keine aktuellere Nachricht vorhanden
Cloud Computing 76
Wir bilden Zukunft. Gossip
Vorteile
– Keine zentralen Einheiten notwendig
– Fehlerhafte Partitionen in einem Netzwerk werden
umschifft, Kommunikation muss nicht verlässlich sein
Nachteile
– Der Zustand ist potenziell inkonsistent verteilt
(kovergiert aber mit der Zeit)
– Overhead durch redundante Nachrichten
Cloud Computing 77
Wir bilden Zukunft. Two Phase Commit
Ist strenge Konsistenz über alle Knoten
notwendig, so verbleibt das Two-Phase-Commit-
Protokoll (2PC)
Ein Transaktionskoordinator verteilt Änderungen
und aktiviert diese erst bei Zustimmung aller
– Ansonsten: Rollback
Cloud Computing 78
Wir bilden Zukunft. Two Phase Commit
Vorteil:
– Alle Knoten sind konsistent
Nachteile
– Zeitintensiv, da stets alle Knoten zustimmen müssen
– Das System funktioniert nicht mehr, sobald das
Netzwerk partitioniert ist, kann aber recovern
Cloud Computing 79
Wir bilden Zukunft. CAP Theorem
Für die Eigenschaften von zustandsbehafteten
verteilten Systemen wurde 2000 von E. Brewer
das sogenannte CAP Theorem entwickelt
– Mittlerweile wurde es formal bewiesen
Es gibt drei wesentliche Eigenschaften, von
denen ein verteiltes System nur zwei gleichzeitig
haben kann
Cloud Computing 80
Wir bilden Zukunft. CAP Theorem
Die dargestellten Protokolle lassen sich
diesbezüglich einordnen
Cloud Computing 81
Wir bilden Zukunft. CAP Theorem
In der Cloud ist davon auszugehen, dass es zu
Partitionen kommt
Damit ist die Entscheidung eigentlich binär
zwischen Konsistenz und Verfügbarkeit
Cloud Computing 82
Wir bilden Zukunft. Zusammenfassung
Microservices sind eine Architektur, die eine
Anwendung in kleine interagierende Teile
separiert
Um miteinander kommunizieren zu können,
kommt ein Service Discovery-Mechanismus zum
Einsatz
Services Discovery kann z.B. über DNS mit
Consul gelöst werden
Innerhalb eines Service Discovery-Systems
kommt z.B. ein Raft-Algorithmus zur Wahl eines
Verantwortlichen zum Einsatz
Cloud Computing 83