Verteilte Systeme: Web Services

Transkript

1 Wegweiser Verteilte Systeme: Web Services Einführung 1

2 SOA Service Oriented Architecture Frontend Business Logik Persistenz Service Consumer Service Provider Div. Design Prinzipien Lose Kopplung Abstraktion Wiederverwendbarkeit Zustandslosigkeit Web Services Einführung 2

3 SOAP Entstanden 1999 XML basiert HTTP typisch als Transport, aber nicht erforderlich Struktur: Envelope, Header, Body WSDL als Beschreibungssprache (tot: UDDI) Einführung 3

4 SOAP Nachrichtenaufbau SOAP Envelope SOAP Header Headers <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockprice> <m:stockname>ibm</m:stockname> </m:getstockprice> </soap:body> </soap:envelope> SOAP Body XML Content SOAPFault <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockpriceresponse> <m:price>34.5</m:price> </m:getstockpriceresponse> </soap:body> </soap:envelope> Einführung 4

5 WSDL Quelle: W3C Einführung 5

6 Beispiel: SoapUI Einführung 6

7 SOA mit REST -> ROA REST (REpresentational State Transfer) Erdacht 2000 von Roy Fielding als Doktorarbeit Stark an HTTP gebunden, URL adressierbar Response Encodings: XML, JSON, HTML, andere denkbar Zustandslos, CRUD Einführung 7

8 HTTP Methoden bei REST Primitive GET POST PUT PATCH DELETE HEAD OPTIONS Bedeutung Ressource lesen, ohne Status zu verändern Ressource anlegen und sonstige Operationen Ressource anlegen/ändern Teilweise Änderung einer Ressource Ressource löschen Metadaten zu einer Ressource erfragen Methoden zum Ressourcenzugriff abfragen Einführung 8

9 REST Beispiel Einführung 9

10 REST Encoding JSON, XML, YAML, HTML oder beliebig { id :23, nachname : Magschok, vorname : Georg, alter :23} <?xml version="1.0" encoding="utf-8" standalone="yes"?> <person id= 23"> <alter>23</alter> <vorname>georg</vorname> <nachname>magschok</nachname> </person> Chunking Compression Multipart Einführung 10

11 Beispiel: Enunciate Einführung 11

12 REST in MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON }) public class GreetingService public Response message() { } } } return new Response("Hi public Response lowercase(final Request message) { return new Response(message.getValue().toLowerCase()); Einführung 12

13 REST: WADL Einführung 13

14 HATEOAS & RMM Rest Maturity Model (Leonard Richardson) Quelle: Martin Fowler HATEOAS (Hypermedia as the Engine of Application State): Dynamische Ressource Links, weg von der statischen Interfacedefinition Einführung 14

15 Andere Mechanismen zur verteilten Kommunikation RPC DCOM CORBA RMI XML-RPC DCE RMI-IIOP Thrift Einführung 15

16 Wegweiser Scaling: wie kriegen wir die Cloud groß genug? Einführung 16

17 Scaling Dimensionen Scaling Storage Netzwerk Processing Filesystem DB RAM Einführung 17

18 Wegweiser DB Scaling Einführung 18

19 Umgang mit Relationalen DBMSs Siehe Einführung Scale-Up Scale-Out Normalisierung + De-Normalisierung! Sharding Dimensionen: Storage Zugriffe/Performance technische DB-Optimierung (z.b. Indizes, Caching) Einführung 19

20 Zoo an Alternativen aka NoSQL In Memory DBs: SAP HANA; memcached, extremedb Caches: memcached, redis Key-Value Stores: redis, Amazon Dynamo, Apache Cassandra Dokumenten DBs: Riak, CouchDB, MongoDB Graph DBs: InfoGrid, Neo4j Object DBs: ZopeDB, Gemstone Einführung 20

21 NoSQL: Häufige Eigenschaften Nomen est Omen keine SQL basierte Abfrage => aber bewegt sich in die Richtung Verzicht auf striktes ACID Eventual Consistent Einfache Skalierbarkeit durch Daten Verteilung / Sharding => siehe Consistent Hashing. Spezialisierter Use-Case Keine oder weniger strikte Schema Einführung 21

22 Apache Open Source, Ursprünglich Entwickelt von Facebook Viele Konzepte von Amazons Dynamo (der Core Entwickler von Cassandra hatte vorher Dynamo mitentwickelt) und Google BigTable Kommerzieller Support von DataStax Einführung 22

23 Cassandra Konzepte (1) Peer-to-Peer Modell - kein Master => Gossip Protokoll Automatische Replikation / Verteilung => Consistent Hashing Multi-Datacenter Support Tuneable Consistency Modell (per Operation) read repair Konflikt Auflösung Hohe Performance => r/w skaliert weitestgehend linear mit Anzahl der Knoten Hohe Verfügbarkeit => definierbarer Replikationsfaktor, Hinted Handoff Einführung 23

24 Cassandra Konzepte (2) Key-Value++ / Column Based Cassandra Query Language (CQL) Lightweight Transactions => PAXOS Map/Reduce support => Integration in Hadoop Einführung 24

25 Cassandra Tuneable Consistency Replikationsfaktor wird festgelegt Quorum = GanzZahligAbgerundet(Replikationsfaktor / 2 + 1) Verschiedene Konsistenzlevel (pro Operation wählbar) Konflikt Auflösung via Timestamp neuster gewinnt Lesend (Auswahl): ONE: Antwort des nächsten Knotens Quorum: Antwort mit aktuellstem Zeitstempel aus Quorum Knoten Local Quorum: wie Quorum aber nur aus einem Rechenzentrum ALL: Antwort mit aktuellstem Zeitstempel nach Abfrage aller Replika- Knoten Einführung 25

26 Cassandra Tuneable Consistency Schreibend (Auswahl): Any: Der Schreibzugriff muss persistiert sein (eventuell Lesen nicht möglich wenn die zuständigen Knoten nicht verfügbar => Hinted Handoff) ONE: Der Schreibzugriff muss einem zuständigen Knoten persistiert sein (ist danach lesbar) Quorum: der Schreibzugriff muss bei Quorum Knoten erfolgreich sein Local Quorum: wie Quorum nur 1 RZ All: der Schreibzugriff muss bei allen Replika-Knoten erfolgreich sein Publikumsfrage Beispiele für verschiedene Lese Schreibszenarien Einführung 26

27 Cassandra Datenmodell Bestimmt den zuständigen Knoten => Consistent Hashing Keyspace (=>Datenbank) Column Family (=>Tabelle ) Row Column Row Key: Row Key: Row Name:Value Name:Value Name:Value Der Inhalt der Row liegt linear auf der Platte Einführung 27

28 Cassandra Datenmodell Beispiele Keyspace: StudiDB Column Family: Student 123: Vorname:Paul Nachname: Muster Note:1plus 124: Vorname:Lisa create keyspace StudiDB; use StudiDB; create column family Student; set Student [ 123 ][ Vorname ] = paul set Student [ 123 ][ Nachname ] = Muster set Student [ 123 ][ Note ] = 1plus set Student [ 124 ][ Vorname ] = Lisa get Student[ 123 ] =>(colum-vorname, value=paul, timestamp=34324) =>(column-nachname=muster, timestamp=132423) =>(column get Student where note= 1plus Secondary Index muss gesetzt sein Einführung 28

29 Cassandra Randbedingungen Colums können hinten oder vorne hinzugefügt werden => implizite zeitliche Sortierreihenfolge möglich Löschen von Colums erzeugen Tombstones => z.b: Queues sind ein Anti-Pattern Schreibzugriffe schneller als Lesen (disk commit log => Memtable => DataFile (Sorted Strings Table) & SSTableIndex & Bloomfilter) Vorsicht bei secondary Indexen auf Columns Die Rows sind verteilt gespeichert Niedrige Kardinalität (viele Duplikate) von Vorteil Level:ANY Level:ONE Bei Hoher Kardinalität (und sehr kleine ausgeprägte Selektivität) zu hoher overhead => unnötige Anfragen an alle Knoten im Cluster Einführung 29