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

0 %
100 %
Information about HiScale REST - Architekturmuster für hochverfügbare und skalierbare...
Technology

Published on March 17, 2014

Author: axxessio

Source: slideshare.net

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".

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

Inhalt 2 » Begriffe » Service Unit » Service Area » Konzepte » Data Master-Slave » Information Aspects » Data Duplication » Polling (versus Messaging) » Chunking » GUI-Plugin » SST-Versionierung » Delta-Restore

Service Unit 3 » 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.

Service Unit Beispiele - Registration 4 » SU Registration – Eine vollständige Anwendung über welche sich der Nutzer registrieren kann. Registration

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

Service Area 6 » 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

Data Master Slave 7 » 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.

Information Aspects 8 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>

Dataduplication 9 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>

Polling zur Datenverteilung 10 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>

Chunking 11 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.

SA 12 Ein selbst implementierter Cache sorgt für optimales Antwortverhalten. DB AS SA SA SA Zugriff Cache Version: 2 Aspect: person, wohnadresse Version: 5 Aspect : person Version: 0 Aspect : 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

Schnittstellenversionierung 13 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

Schnittstellenversionierung mittels REST 14 Es gibt unterschiedliche Möglichkeiten zur Schnittstellen- versionierung in REST, die sehr kontrovers diskutiert werden. » Via URL, also http://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.

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

RDBMSRDBMSRDBMS # x Server# x Server# x Server# x Server AppServerAppServerAppServerAppServer Verteilung 16 Die weiteren Ausbaustufen ergeben sich dann von selbst. Registration Login RDBMS BillingShop SHP REG LOG BIL # x Server WebServer GUI Framework

GUI Pluginkonzept 17 » 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).

# 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 Communication Via REST Client PC Browser GUI Framework

Verfügbarkeit 19 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.

Verfügbarkeit - Setup 20 SA (Data Owner) SU SU SA (Data Reader) SU Prim SU Back HA Proxy 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.

Abfangen des Backup-Restore-Delta 21 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.

Delta-Restore mittels verteilter Aspekte 22 Die verteilten Daten 22 SA Registration SU SA Login SU SA Shop SU SA Billing SU REG 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

Unsere Standorte Niederlassung Köln Wilhelmstraße 3 51143 Köln Tel +49 22 03 – 91 22 0 Fax +49 22 03 – 91 22 23 Niederlassung Darmstadt Kasinostraße 60 64293 Darmstadt Tel +49 61 51 – 78 90 0 Fax +49 61 51 – 78 90 23 0 Hauptsitz Bonn Kurfürstenallee 5 53177 Bonn Tel +49 228 – 76 36 31 0 Fax +49 228 –76 36 31 3 Niederlassung Bern Frohbergweg 7 3012 Bern Tel +41 31 – 534 07 06 Fax +41 31 – 536 69 78 Consider IT done!

Add a comment

Related presentations

Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...

In this presentation we will describe our experience developing with a highly dyna...

Presentation to the LITA Forum 7th November 2014 Albuquerque, NM

Un recorrido por los cambios que nos generará el wearabletech en el futuro

Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...

Microsoft finally joins the smartwatch and fitness tracker game by introducing the...

Related pages

Software and Systems Architecture - innoQ

Check out our blog posts, podcasts, and talks on software architecture and development topics. Have fun browsing!
Read more

Software- und Systemarchitektur

... eine Entwicklungsmethode für skalierbare Web ... für die Entwicklung von verteilten und hochverfügbaren ... Architekturmuster für ...
Read more

Sessions | W-JAX

Vert.x ist ein auf Netty 4 und Hazelcast aufbauendes Framework für skalierbare, ... Für Geräte der Klasse 2 haben sich REST ... Architekturmuster für ...
Read more

AWS | Whitepaper

AWS bildet aufgrund der breiten Palette von skalierbaren Infrastrukturservices für die ... Architekturmuster zum ... hochverfügbaren, ...
Read more

Häufig gestellte Fragen - Amazon Web Services (AWS ...

Sie unterscheiden sich hinsichtlich des Umfangs der unterstützten Architekturmuster und ... automatisch den Rest. ... Server für die ...
Read more

| W-JAX

Vert.x ist ein auf Netty 4 und Hazelcast aufbauendes Framework für skalierbare, ... Für Geräte der Klasse 2 haben sich REST ... Architekturmuster für ...
Read more

Projekte und Profile it.projektwerk.com

... Cloud Subscription Management Aufgabe war die Entwicklung einer skalierbaren Cloud ... Das System ist hochverfügbar ... MVC Architekturmuster ...
Read more

Projekte und Profile it.projektwerk.com

... Betrieb des Rechenzentrums und dessen angebundenen Systeme • UHD für MS ... dem MVC Architekturmuster ... verschiedener REST ...
Read more