Your SlideShare is downloading. ×
0
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Resilient Microservices
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Resilient Microservices

958

Published on

Oliver Wronka, Principal Architect/ Project Manager bei axxessio, befasst sich in dieser Präsentation mit dem Thema „Architekturmuster für hochverfügbare, fehlertolerante (resilient) und skalierbare …

Oliver Wronka, Principal Architect/ Project Manager bei axxessio, befasst sich in dieser Präsentation mit dem Thema „Architekturmuster für hochverfügbare, fehlertolerante (resilient) und skalierbare Microservices".

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
958
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
15
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Architekturmuster für hochverfügbare, fehlertolerante und – skalierbare REST-Architekturen OLIVER WRONKA 31. MÄRZ 2014 Resilient Microservices
  • 2. Inhalt 2 » Begriffe » Micro Service Unit » Micro Service Area » Konzepte » Data Master-Slave » Information Aspects » Data Duplication » Polling (versus Messaging) » Chunking » GUI-Plugin » SST-Versionierung » Delta-Restore
  • 3. Micro Service Unit 3 » Ein Micro Service deckt Teile eines fachlichen Anforderungskatalogs ab. » Durch mehrere Micro Services des gleichen Typs wird eine horizontale Skalierung erreicht. » Basierend auf einem 3 Tier Ansatz können Micro Services in unterschiedlichen Ausprägungen erscheinen, z. B.: » GUI – Logik – Persistenz (vollständige Anwendung) » Logik – Persistenz (Service) » Batch » usw.
  • 4. Micro Service Beispiele - Registration 4 » MS Registration – Eine vollständige Anwendung über welche sich der Nutzer registrieren kann. Registration
  • 5. Micro Service Beispiele - Login 5 » MS Login – Eine Anwendung, über welche sich der Nutzer einloggen kann. Nutzt in dieser Ausprägung die Stammdaten der MS Registration online. Login Registration
  • 6. Micro Service Area 6 » Mehrere MS unterschiedlicher Ausprägung werden zusammengefasst, um die geforderte Funktionalität vollständig abzubilden. » Mehrere MS der gleichen Ausprägung werden zusammengefasst um die geforderte Skalierung zu erreichen. MSA-Billing SMSU Billing Service SMSU Billing Service SMSU Billing Service SMSU Billing Batch SMSU Billing Batch
  • 7. Data Master Slave 7 » Ressourcen im Sinn von REST (also Kunde, Rechnung etc.) leben (read / write) nur in einem MS. » Zu Skalierungszwecken können andere MS diese Ressourcen jedoch kopieren und lesend darauf zugreifen.
  • 8. Information Aspects 8 Aufteilung der Daten in Aspekte lässt eine feingranulare Verteilung zu. » Daten werde in Aspekte unterteilt, z. B. Account, Person, Adresse oder Bankverbindung. » Diese Aspekte können zwischen den MSAs 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 code="MR" /> <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> <bankaccount1> <owner>Oliver Wronka</owner> <iban>DE#######################</iban> <bic>COLS#####XXX</bic> </bankaccount> </customer> 1: Anmerkung des Autors – Sicherheitsrelevante Daten müssen eigentlich contentverschlüsselt übertragen werden. Der Einfachheit halber ist dies hier nicht der Fall. :
  • 9. 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 MS 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>
  • 10. 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. » Die Version des Kunden wird mit jeder Änderung eines Aspects erhöht. <?xml version="1.0"?> <customer> <version>7</version> <id>1234</id> <account> ... </account> <person type="NATURAL"> ... </person> <addresses> <address type="HOME"> ... </address> <address type="BILL"> ... </address> </addresses> <bankaccount> ... </bankaccount> </customer>
  • 11. 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.
  • 12. 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
  • 13. Schnittstellenversionierung 13 Für echten 24x7 Betrieb müssen die Schnittstellen versioniert werden. » Es können mehrere Versionen einer MSU 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 MSU MSU Disp Service v1 Service v2 DBS Conf v1 v2 Fassade v1 Fassade v2
  • 14. 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-Prinzipien /1.0/customers eigentlich eine andere Ressource ist als /1.1/customers, dies ist jedoch nicht immer der Fall.
  • 15. 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
  • 16. 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
  • 17. GUI Pluginkonzept 17 » Es gibt einen übergeordneten GUI-Framework, der die GUI der einzelnen MSU einbettet. » Initial startet dieser mit dem Login. » Bei einem client side Framework werden die darunter liegenden Services der einzelnen MSU mittels REST angesprochen. » Die GUIs der einzelnen MSU werden auch in der MSA gehostet. Verantwortung bleibt beim Team, es entsteht kein GUI-Moloch (devide and conquer).
  • 18. # 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
  • 19. 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 MSUs gezielt genutzt. » Da zwischen den MSUs ausschließlich REST (http) gesprochen wird kann HA Proxy einfach eingesetzt werden. » Je MSA wird eine MSU zum primären Datareader ernannt. Es wird eine weitere MSU zum Backup ernannt. Diese lauscht mittels Heartbeat beim Primary. Ist dieser nicht mehr erreichbar, so übernimmt die Backup MSU den Datentransfer.
  • 20. Verfügbarkeit - Setup 20 MSA (Data Owner) MSU MSU MSA (Data Reader) MSU Prim MSU Back HA Proxy Heartbeat » Ein HA Proxy wird zur Lastverteilung vor die MSUs der MSA Data Owner geschaltet. » Dieser verteilt die Anfragen im Round Robbin Verfahren. » MSU Back lauscht per Heartbeat bei MSU Prim. » Kann MSU Back diese nicht erreichen, so übernimmt MSU Back das Polling. » Ist MSU Prim wieder erreichbar, so stoppt MSU Back das Polling.
  • 21. 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 MSA 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.
  • 22. Delta-Restore mittels verteilter Aspekte 22 Die verteilten Daten 22 MSA Registration MSU MSA Login MSU MSA Shop MSU MSA Billing MSU 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
  • 23. axxessio Consider IT done!23

×