HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

23
Architekturmuster für hochverfügbare und skalierbare REST-Architekturen OLIVER WRONKA MÄRZ 2014 HiScale REST

description

Oliver Wronka, Principal Architect/ Project Manager bei axxessio, befasst sich in dieser Präsentation mit dem Thema „Architekturmuster für hochverfügbare und skalierbare REST-Architekturen".

Transcript of HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

Page 1: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

OLIVER WRONKA

MÄRZ 2014

HiScale REST

Page 2: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

2

Inhalt

» Begriffe» Service Unit» Service Area

» Konzepte» Data Master-Slave» Information Aspects» Data Duplication» Polling (versus Messaging)» Chunking» GUI-Plugin» SST-Versionierung» Delta-Restore

Page 3: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

3

Service Unit

» Eine Service Unit deckt Teile eines fachlichen Anforderungskatalogs ab.

» Durch mehrere Service Units des gleichen Typs wird eine horizontale Skalierung erreicht.

» Basierend auf einem 3 Tier Ansatz können Service Units in unterschiedlichen Ausprägungen erscheinen, z. B.:» GUI – Logik – Persistenz (vollständige Anwendung)» Logik – Persistenz (Service)» Batch» usw.

Page 4: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

4

Service Unit Beispiele - Registration

» SU Registration – Eine vollständige Anwendung über welche sich der Nutzer registrieren kann.

Registration

Page 5: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

Service Unit Beispiele - Login

5

» SU Login – Eine Anwendung, über welche sich der Nutzer einloggen kann. Nutzt in dieser Ausprägung die Stammdaten der SU Registration online.

Login

Registration

Page 6: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

6

Service Area

» Mehrere SU unterschiedlicher Ausprägung werden zusammengefasst, um die geforderte Funktionalität vollständig abzubilden.

» Mehrere SU der gleichen Ausprägung werden zusammengefasst um die geforderte Skalierung zu erreichen.

SA-Billing

SSU Billing

Service

SSU Billing

Service

SSU Billing

Service

SSU Billing Batch

SSU Billing Batch

Page 7: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

7

Data Master Slave

» Ressourcen im Sinn von REST (also Kunde, Rechnung etc.) leben (read / write) nur in einer SA.

» Zu Skalierungszwecken können andere SA diese Ressourcen jedoch kopieren und lesend darauf zugreifen.

Page 8: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

8

Information Aspects

Aufteilung der Daten in Aspekte lässte eine feingranulare Verteilung zu.

» Daten werde in Aspekte unterteilt, z. B. Account, Person, Adresse oder Bankverbindung.

» Diese Aspekte können zwischen den SAs gezielt verteilt werden.

<?xml version="1.0"?><customer> <id>1234</id> <account> <login>owronka</login> <pwdhash>2fc16e07...<pwdhash> <salt>b295d117135...</salt> </account> <person type="natural"> <salutation>MR</salutation> <firstname>Oliver</firstname> <lastname>Wronka</lastname> </person> <addresses> <address type="home"> <street>Rheinweg 86</street> <zip>53129</zip> <city>Bonn</city> </address> <address type="bill"> <street>Kurfürstenallee 5</street> <zip>53177</zip> <city>Bonn</city> </address> </addresses> <bankaccount> <owner>Oliver Wronka</owner> <iban>DE89370400440532073000</iban> <bic>COLSDE55XXX</bic> </bankaccount></customer>

Page 9: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

9

Dataduplication

Redundante Datenhaltung sorgt für minimale Kopplung

» Zu Zwecken der Skalierbarkeit aber auch zur getrennten Entwicklung durch eigenständige Teams werden die Daten je SA teilweise redundant vorgehalten.

Login

Registration Billing

Shop

http://axxessio.com/customers/1?aspects=~account<id>1234</id><account>...</account>

Datenfluß

http://axxessio.com/customers/1?aspects=~person~address.home<id>1234</id><person type="natural">...</person><addresses> <address type=“home"> ... </address></addresses>

http://axxessio.com/customers/1?aspects=~person~address.bill~bankaccount<id>1234</id><person type="natural">...</person><addresses> <address type="bill"> ... </address></addresses><bankaccount>...</bankaccount>

Page 10: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

10

Polling zur Datenverteilung

Versionierung der Aspekte sorgt für optimierte Verteilung

» Die Daten werden versioniert um Anfragen der Umsysteme besser Cachen zu können.

» Jede Änderung an einem Information Aspect führt einfach zu einer neuen, höheren Version des Aspekts.

» Die Version des Kunden wird mir jeder Änderung eines Aspects erhöht.

<?xml version="1.0"?><customer> <version>7</version> <id>1234</id> <account> <version>1</version> ... </account> <person type="natural"> <version>1</version> ... </person> <addresses> <address type="home"> <version>3</version> ... </address> <address type="bill"> <version>2</version> ... </address> </addresses> <bankaccount> <version>1</version> ... </bankaccount></customer>

Page 11: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

11

Chunking

Zur performanteren Übertragung werden die Datensätze zu Chunks zusammengefasst.

» Die Datensätze mit den darin enthaltenen Informationsaspekten werden nicht einzeln übertragen sondern in Chunks zu mehreren Datensätzen.

» Der Client pollt zyklisch z. B. alle 10s.» Der Server liefert einen Chunk aus. Hierbei gibt es eine

definierte Obergrenze, z. B. 100 Datensätze.» Liegen mehr als 100 Datensätze beim Server vor, so

signalisiert er dies in der Antwort.» Der Client wartet keine weiteren 10s sondern ruft sofort

den nächsten Chunk ab.

Page 12: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

12

SA

Ein selbst implementierter Cache sorgt für optimales Antwortverhalten.

DB AS

SA

SA

SA

Zugriff

Cache

Version: 2Aspect: person, wohnadresse

Version: 5Aspect : person

Version: 0Aspect : person, rechnungsadresse, billing

Die Clients rufen zyklisch die Schnittstelle auf. Hierbei teilt er mit, welche Version er selbst bereits kennt. Hierbei wird das REST-Protokoll verwendet:

http://{server}.{port}/customers?version=### Optional können die Aspekte mit übergeben werden:

/customers?version=###&aspects=~person~address.home

Page 13: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

13

Schnittstellenversionierung

Für echten 24x7 Betrieb müssen die Schnittstellen versioniert werden.

» Es können mehrere Versionen einer SU zeitgleich betrieben werden.

» Der aufrufende Client teilt mit, welche Version er benötigt.» Vorteil: Versionen können zur Laufzeit außer Betrieb oder Live

gesetzt werden ohne Downtime.

Zugriff

SU

SU

Disp

Service v1

Service v2

DBS

Conf

v1

v2

Fassade v1

Fassade v2

Page 14: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

14

Schnittstellenversionierung mittels REST

Es gibt unterschiedliche Möglichkeiten zur Schnittstellen-versionierung in REST, die sehr kontrovers diskutiert werden.

» Via URL, alsohttp://axxessio.com/1.0/customers...

» oder aber als Header1

content-type: application/vnd.appidv1+xml

1: Der Autor empfiehlt dieses Vorgehen sofern es die eingesetzten Produkte und Bibliotheken erlauben. Der Grund hierfür ist, dass basierend auf den REST-Priinzipien /1.0/customers eigentlich eine andere Ressource ist als /1.1/customers, dies ist jedoch nicht immer der Fall.

Page 15: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

Server (HW oder VM)

AppServerAppServerAppServerAppServer

Verteilung (minimal)

15

Die grundlegenden Architekturmuster werden schon in der kleinsten Ausbaustufe strikt beibehalten.

Registration Login

RDBMS

BillingShop

SHP REG LOG BIL

Server (HW oder VM)WebServer

GUI Framework

Page 16: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

16

RDBMSRDBMSRDBMS

# x Server# x Server# x Server# x Server

AppServerAppServerAppServerAppServer

Verteilung

Die weiteren Ausbaustufen ergeben sich dann von selbst.

Registration Login

RDBMS

BillingShop

SHP REG LOG BIL

# x ServerWebServer

GUI Framework

Page 17: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

17

GUI Pluginkonzept

» Es gibt einen übergeordneten GUI-Framework, der die GUI der einzelnen SAs einbettet.

» Initial startet dieser mit dem Login.» Bei einem client side Framework werden die darunter

liegenden Services der einzelnen SAs mittels REST angesprochen.

» Die GUIs der einzelnen SAs werden auch in der SA gehostet. Verantwortung bleibt beim Team, es entsteht kein GUI-Moloch (devide and conquer).

Page 18: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

# x Server# x Server# x Server# x Server

AppServerAppServerAppServerAppServer

Die weiteren Ausbaustufen ergeben sich dann von selbst.

Registration Login BillingShop

# x Server

WebServer

GUI Framework

Upload

CommunicationVia REST

Client PCBrowser

GUI Framework

Page 19: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

19

Verfügbarkeit

Eine hohe Verfügbarkeit ist konzeptionell mittels frei verfügbarer Software einfach umzusetzen.

» Um die Verfügbarkeit zu erhöhen wird die mehrfache Ausprägung von SUs gezielt genutzt.

» Da zwischen den SUs ausschließlich REST (http) gesprochen wird kann HA Proxy einfach eingesetzt werden.

» Je SA wird eine SU zum primären Datareader ernannt. Es wird eine weitere SU zum Backup ernannt. Diese lauscht mittels Heartbeat beim Primary. Ist dieser nicht mehr erreichbar, so übernimmt die Backup SU den Datentransfer.

Page 20: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

20

Verfügbarkeit - Setup

SA (Data Owner)

SU

SU

SA (Data Reader)

SUPrim

SUBack

HAProxy Heartbeat

» Ein HA Proxy wird zur Lastverteilung vor die SUs der SA Data Owner geschaltet.

» Dieser verteilt die Anfragen im Round Robbin Verfahren.

» SU Back lauscht per Heartbeat bei SU Prim.

» Kann SU Back diese nicht erreichen, so übernimmt SU Back das Polling.

» Ist SU Prim wieder erreichbar, so stoppt SU Back das Polling.

Page 21: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

21

Abfangen des Backup-Restore-Delta

Dieses Konzept kann sogar inhärente Schwächen eines Datenbankbackups abfangen.

» Auch wenn eine Datenbank täglich gesichert wird so ist doch ein Datenverlust von bis zu 24h möglich.

» Die hier aufgezeigte, redundante Datenhaltung kann das Delta wieder ausgleichen. Voraussetzung: Die DB der jeweiligen SA laufen jeweils in dedizierten Umgebungen.

» Aber: Sollte nicht auf alle Daten angewendet werden. Primär sollten nur Stammdaten auf diese Weise behandelt werden.

» Der Ansatz basiert darauf, dass die umliegenden Clientsysteme insgesamt alle Informationsaspekte haben, wenn auch verteilt.

Page 22: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

22

Delta-Restore mittels verteilter Aspekte

Die verteilten Daten

22

SA Registration

SU

SA Login

SU

SA Shop

SU

SA Billing

SUREG

Mittels Backup wurde Kunde bis

Version 4711 zurückgesichert

http://axxessio.com/customers? version=4711&apects=~account

http://axxessio.com/customers? version=4711&apects=~billing~address.bill

http://axxessio.com/customers? version=4711&apects=~person~address.home

Datenfluss

Page 23: HiScale REST - Architekturmuster für hochverfügbare und skalierbare REST-Architekturen

Unsere Standorte

Niederlassung Köln

Wilhelmstraße 351143 KölnTel +49 22 03 – 91 22 0Fax +49 22 03 – 91 22 23

Niederlassung Darmstadt

Kasinostraße 6064293 DarmstadtTel +49 61 51 – 78 90 0Fax +49 61 51 – 78 90 23 0

Hauptsitz Bonn

Kurfürstenallee 553177 BonnTel +49 228 – 76 36 31 0Fax +49 228 –76 36 31 3

Niederlassung Bern

Frohbergweg 73012 BernTel +41 31 – 534 07 06Fax +41 31 – 536 69 78

Consider IT done!