Microservices - IT-Anrechnungsstudiengänge | Open IT · 2019-10-23 · Microservices –vs– SOA...

Wir bilden Zukunft.

Microservices

Cloud Computing 1

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


Verschiedene Faktoren beeinflussen die

Entscheidung, ob es sich um einen Microservice

handelt

– Modularisierung

– Verteilte Kommunikation

– Refactoring

– Teamgröße

– Infrastruktur

– Ersetzbarkeit

– Transaktionen

Cloud Computing 5


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


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


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


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


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


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


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


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


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


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


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


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


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


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 PATTERN

Wie sieht das in Produktion aus?

Cloud Computing 29

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


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


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


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


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


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


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


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

Das Chaos verwalten

Cloud Computing 46

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.

RAFT

Der König ist tot, lang lebe der König

Cloud Computing 51

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


Selbstständig entscheidet ein Follower, Leader

werden zu wollen; er wird zum Candidate

Cloud Computing 55


Als Kandidaten wirbt er für eine Wahl zum

Leader, indem er andere Nodes über seine

Kandidatschaft informiert

Cloud Computing 56


In diesem einfachen Szenario gibt es keinen

weiteren Candidate, weshalb die beiden

anderen Follower für den vorhandenen stimmen

Cloud Computing 57


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


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


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


Es kann passieren, dass zwei Follower zu

Candidates werden und jeweils unterschiedliche

Follower zum Wählen auffordern

Cloud Computing 64


Im zweiten Schritt wird der jeweils andere

Follower um einen Vote gebeten

Cloud Computing 65


Da der zweite Follower bereits eine Stimme

abgegeben hat, verweigert er eine zweite

Cloud Computing 66


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


Es kommt zu einem Patt und es existieren

weiterhin zwei Candidates und zwei Follower

Cloud Computing 68


Der Vorgang beginnt erneut, indem ein

Candidate nach einer gewissen Zeit ihm

bekannte Follower um einen Vote bittet

Cloud Computing 69


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


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


Der verbleibende Candidate fragt nun um Votes

und teilt dabei mit, dass er für den Statusindex 3

wählt

Cloud Computing 72


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


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


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


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


Die dargestellten Protokolle lassen sich

diesbezüglich einordnen

Cloud Computing 81


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

Microservices - IT-Anrechnungsstudiengänge | Open IT · 2019-10-23 · Microservices –vs– SOA...

Documents

Transcript of Microservices - IT-Anrechnungsstudiengänge | Open IT · 2019-10-23 · Microservices –vs– SOA...