Avatar von newyear
  • newyear

mehr als 1000 Beiträge seit 31.03.2015

Re: Vergesst die Daten nicht!

serroi schrieb am 08.12.2017 07:04:

Aus meiner Sicht macht das einen erheblichen Unterschied. Im Monolithen habe ich die Daten alle in einer Datenbank. Auswertungen, die über mehrere Entitäten gehen, sind einfach zu realisieren. Wenn Lager und Finanzbuchhaltung in einer DB zusammen sind, kann ich z.B. herausfinden, welches der Durchschnittspreis der Artikel im Lager ist.

Und damit man solche „interessanten“ Fragen einfach beantworten kann, muss die Finanzbuchhaltung mit dem Release lieder wieder warten, weil man bei dem Update natürlich den Shop runterfahren muss…

Die Probleme kennen wir alle. Wenn man wenig Onlineumsatz hat ist das natürlich die billige und pragmatische Lösung. Wer richtig E-Commerce betreiben möchten lernt da schnell die Grenzen kennen, oder eben den Wettbewerbsvorteil, den die Konkurrenz plötzlich hat…

Sind beide Themen als Microservices getrennt, muss ich erst die Artikel mit Lagerbestand suchen und dann den Finanzbuchhaltungs-Service nach deren Durchschnittspreis fragen. Das ist zum einen ein Performance-Problem und zum anderen werden auch wahnsinnig viele Daten plötzlich zwischen den Services übertragen.

Wieso die Performance anders ist erschließt sich mir nicht - und das Problem der Datenmenge sollte im eigenen Subnetz keines sein.

Abgesehen davon kann man mit Artikeldaten nicht mehr wirklich Traffic erzeugen. Aber ja, ich habe auch noch mit Leuten zu tun die 10.000 gleichzeitige Verbindungen noch als „viel“ empfinden.

Und bisher habe ich auch immer nur gelesen, dass Transaktionen über Webservices hinweg schwierig und aufwändig sind.

Wo braucht man da welche?

Z. B. bei einem ganz normalen Bestellvorgang: Bestellt der Kunde einen Artikel, soll sich der Lagerbestand reduzieren und gleichzeitig eine Rechnung geschrieben werden. Wird dies durch 2 Microservices abgebildet und tritt nun während des Vorgangs ein Fehler auf (Verbindung bricht ab, Kunde hat nicht genug Bonität, ...) möchte ich gerne ein Rollback durchführen, da ich sonst inkonsistente Zustände erhalte.

Schlechte Idee. Ich kenne Shops die so gebaut wurden, und dann Festellen mussten das Payment-Provider im täglichen Einsatz manchmal sehr lange Antwortzeiten haben, und das eine große Menge offener Transaktionen auch guten Datenbanken gar nicht gefällt:

„Pg will usually complete the same 10,000 transactions faster by doing them 5, 10 or 20 at a time than by doing them 500 at a time.“
https://wiki.postgresql.org/wiki/Number_Of_Database_Connections

Generell fallen Leute mit dem naiven Ansatz schnell auf die Nase und beschweren sich über die Datenbank, den Dienstleister oder versuchen sinnloserweise vertikal zu skalieren indem sie versuchen ein schlecht designtes System mit mehr RAM und CPU zum Laufen zu bekommen.

Es gibt natürlich Machanismen (Message-Queues, eigenes 2-Phase-Commit), mit denen man Transaktionen auch über mehrere Webservices hinweg erreichen kann, aber diese sind weder leicht zu implementieren noch performant (im Vergleich zu einer einfachen Datenbank-Transaktion).

Ich würde mal sagen das große E-Commerce-Anbieter eher Ahnung von Performanz haben als die kleinen Fische, bei denen dieser Aspekt selten eine Rolle spielt. Wenn man keine Performanz-Probleme hat, ist ein Monolith noch völlig in Ordnung und auch die billigere Lösung.

Bewerten
- +