Hallo Leute,

ich arbeite zur Zeit an einem Projekt, bei dem ich einen sehr CPU-lastigen Webservice anbieten möchte (was genau darf ich euch leider nicht sagen ). Das ist das erste Mal für mich, dass ich so ein großes System enwickel. Bisher habe ich nur kleinere Webseiten entwickelt und einen kleinen Medien-Server (Ubuntu) im Heimnetzwerk administriert. Da ich aber bei diesem neuen Projekt der einzige Entwickler bin, muss ich mich hier um alles Technische kümmern.

Folgende Eckdaten zum Service:

• wie schon gesagt sehr CPU-lastige Berechnungen
  
• Web Frontend mit Nutzerverwaltung
  
• RESTful Web API zum Austausch der Daten zwischen Webseite und Webservice
  
• Datenbank

Die Webseite würde ich als Single-Page-Website mit backbone.js, require.js und underscore.js (als Template Processor) umsetzen. Datenbank weiß ich noch nicht welche ich da nehme. Was bietet sich da an? MySQL? Vlt auch ne Datenbank die ich auch auf einem verteilen System laufen lassen kann, falls das mal notwendig wird? Für den Service hatte ich mir überlegt die einzelnen Systeme in Docker Container zu verpacken und das Ganze als Docker Swarm laufen zu lassen. Das hat den Vorteil das ich es schnell erweitern kann und das ganze Managing und Load-Balancing umsonst dazu bekomme. Ich würde es in folgende Container unterteilen:

• 1 x Web Server - würde ich mit node.js umsetzen (evtl. auch mehr als einer falls nötig)
  
• 1 x Datenbank
  
• N x Worker die meine Berechnungen durchführen
  
• (1 x Worker Manager - falls das Balancing von Docker nicht genau das macht was ich möchte, oder ich noch einen Dienst benötige, der meine Worker extra verwaltet)

Klingt das für euch soweit erstmal plausibel? Was würdet ihr anders machen? Hat vlt schon jmd Erfahrungen mit solchen großen Systemen?

MfG & Thx Bergmann

Moin Bergmann,

das schöne an der Entwicklung eines größeren verteilten Systems ist ja, dass man selbst bei der Konzeption in einem hochkarätigen Team mit großer Erfahrung garantiert früher oder später feststellt, dass viele getroffene Entscheidungen eigentlich gar nicht mal so gut sind.

Meiner Meinung nach, sind folgende Faktoren sehr wichtig für den Erfolg eines solchen Systems (Inspiration auch z.B. hier):

Erstklassiges Logging / Monitoring
Fehler in verteilten Systemen sind grundsätzlich schwieriger zu finden, als in einer single-threaded Desktopanwendung, in der man im Zweifel alles in Ruhe mit dem Debugger durchsteppen kann. Es ist empfehlenswert, von Anfang an sicher zu stellen, dass man jeden Request durch alle Services bis zum Ende Nachverfolgen kann. Hierzu empfiehlt es sich, für jeden Client-Request eine eindeutige ID zu generieren, die in allen Logs die als Folge aus diesem Request erzeugt werden mit ausgegeben wird.

Zusammen mit einem entsprechenden Logging Stack (z.B. dem ELK-Stack) oder im Zweifelsfall mit ein bisschen grep-Magie im Terminal (siehe Punkt 2), kann man so recht gut nachvollziehen, was im Fehlerfall überhaupt passiert ist.

Testing
Testing sollte heutzutage so selbstverständlich sein, dass ich es beim ersten Anlauf für diesen Beitrag fast vergessen hätte. Von Unittests über Integration- und End-To-End Tests (z.B. mit Selenium) haben Tests einen sehr großen Faktor auf die Codequalität. Erstens ist gut testbarer Code in fast allen Fällen auch tatsächlich besserer Code, zweitens verhindert man durch gezieltes Test driven development viele vermeidbare Bugs, die sonst erst viel später auffallen und erheblich schwieriger zu fixen sind.

Durch entsprechendes Tooling sollte man sich zwingen, die Test-Coverage möglichst maximal zu halten. Zwar ist die Coverage selbst keine 1:1 Metrik für die Qualität der Tests, jedoch gibt sie immerhin Anhaltspunkte.


Kein Overengineering
Es mag immer verlockend sein, eine Cassandra als Datenbank zu verwenden, falls man mal eben planet-scale skalieren muss. Oder MongoDB, weil NoSQL ja so schön einfach ist. Faktisch reicht für fast alle Anwendung eine gute alte relationale Datenbank. Zum Beispiel Postgres. Das kommt mit super Konsistenz und ist fast immer schnell genug.

Auch muss man nicht für jedes Projekt einen ELK-Stack ausrollen (auch wenn der wirklich sehr gut ist), aber man sollte wenigstens so entwickeln, es im Zweifel problemlos zu können.

Frontend
Wenn du Erfahrung mit backbone und underscore hast - nur zu, grundsätzlich sollte man mit allen Frameworks vergleichbare Ergebnisse erzielen können. Ich kann sonst z.B. React + Redux empfehlen. Aber das ist schon unglaublich Geschmackssache. Wenn man von Anfang an bundlen möchte, soll wohl auch Webpack momenten ganz gut sein. Habe ich aber noch nicht mit gearbeitet. Man kann für einen ersten Prototypen aber vermutlich auch auf Bundling verzichten.

Ich bin ein großer Vertreter von Typsicherheit. Daher würde ich zumindest darüber nachdenken, TypeScript zu verwenden. Mit Flow habe ich nicht die besten Erfahrungen gemacht.

Infrastruktur und Deployment
Docker ist schon eine der bahnbrechendsten Technologien der letzten Jahre. Großer Vorteil: Du kannst deine Services quasi überall laufen lassen. Egal ob bei AWS, GCE, Microsoft Azure, was auch immer. Weiterer Vorteil: du kannst im zweifelsfall einfach skalieren. Natürlich muss man sich hier am Anfang etwas einarbeiten.

Zum Verteilen von Containern auf verschiedene Hardware hat sich wohl Kubernetes etabliert. Kubernetes erleichtert auch viele Dinge die mit Netzwerkverbindungen zwischen unterschiedlichen Services zu tun haben. Das macht nämlich im allgemeinen alles keinen Spaß selbst zu machen. Außerdem bieten alle relevanten Clouddienstleister auch Hosting mit Kubernetes.

Datenbank
Wenn deine N Worker-Services (ggf. oft) auf eine geteilte Datenbank zugreifen müssen (ist jetzt aus deiner Frage so nicht ersichtlich), kann diese potenziell zum Flaschenhals werden. Hier muss man sich dann je nach Anwendungsfall eine schlaue Lösung überlegen.

Ansonsten ist deine Fragestellung nicht konkret genug, um direkte Empfehlungen aussprechen zu können. Darum habe ich mich weitestgehend auf Gemeinplätze versteift. Wenn du kannst, definiere und baue doch erstmal ein Minimum Viable Product, was erstmal einfach trennbare, aber wenige Services (vielleicht auch nur einen) hat. Dann kannst du besser erkennen, woran es hakt und hast noch nicht zu viel Zeit investiert und bist weit in die falsche Richtung losgerannt.

Gruß
Finn

Hallo Finn,

Danke für die vielen Infos, da war noch einiges dabei über das ich mir gar keine Gedanken gemacht habe.

Logging / Monitoring
Das mit der Request ID ist eine sehr gute Idee. Das werd ich so übernehmen. Die entsprechenden Log Ausgaben kann ich - soweit ich das gesehen hab - gleich mit Docker verwalten. Zum Durchsuchen der Ausgaben würde ich erst einmal auf einen Logging Stack verzichten, da das noch ein extra Service wäre den ich verwalten und pflegen müsste. Für den Anfang sollte ich mit ein wenig grep die Informationen bekommen, die ich benötige. Ich werd mit das mit dem Logging Stack trotzdem mal etwas genauer angucken, dann kann ich das System schon so auslegen, das ich den später ohne Probleme noch mit hinzufügen kann.

Testing
Ja Tests stehen außer Frage. Da ich ja auch beim Entwicklen das ein oder ander mal einen Einstiegspunkt mit entsprechenden Testdaten brauch um durch den Code zu debuggen war klar, dass ich den Code in einer Test Driven Umgebung implementieren werde.

Frontend
Dann werd ich denke ich wieder auf backbone und underscore setzen, da erspare ich mir die Einarbeitungszeit. TypeScript ist auch ne gute Idee, das wollte ich mir schon lange mal angucken. Das sollte mir auch einiges an Fehlersuche ersparen (es gab schon Fälle wo ich 2 Stunden nach den Bug gesucht habe der durch falsche Groß-/Kleinschreibung eines Buchstabens ausgelöst wurde )
Unit Test sind da auch kein Problem, das kann ich mit Jasmine ganz gut Umsetzen.

Infrastruktur und Deployment
Ich kenn Kubernetes nicht, hab mir das aber mal kurz angeguckt. Das sollte - soweit ich das jetzt sehe - das selbe wie ein Docker Swarm sein. Einen einfachen Docker Swarm hatte ich bei mir zu Hause schon ausprobiert, das lief eigentlich ganz gut. Es gibt dann auch entsprechende Dienste wie Microsoft Azure oder Amazone Web Services auf die ich meinen Docker Swarm auslagern könnte.

Datenbank
Ich hab bis jetzt sehr wenig Erfahrung mit Datenbanken gemacht, deshalb weiß ich auch nicht genau wie ich die skalieren muss, aber nach deiner Beschreibung denke ich das eine normale relationale Datenbank für mich ausreichend ist. Die Worker müssen sich nur den Datensatz aus der Datenbank holen, machen dann ihre intensiven Berechnungen und schreiben das Ergebnis dann zurück in die Datenbank. Der Zugriff auf die Datenbank hält sich also in Grenzen.

MfG Bergmann.

Bergmann89 hat folgendes geschrieben :

Datenbank weiß ich noch nicht welche ich da nehme. Was bietet sich da an? MySQL?

Insbesondere wenn es ein kommerzielles Projekt ist, MariaDB, aber auch sonst bietet sich diese Lösung an. Das ist die freie Alternative zu MySQL (ist daraus entstanden).
Mit MaxScale als Gateway und Galera-Cluster-Unterstützung (zur Replikation) hast du Hochverfügbarkeit, Sicherheit, Skalierbarkeit usw. schon direkt dabei. Fällt ein Node aus, wird er automatisch aus dem Cluster entfernt usw.

Schön ist dabei, dass du dich darum nicht in deinem Server selbst kümmern musst. Die Datenbank muss nur entsprechend eingerichtet werden. Gut, das "nur" war jetzt untertrieben.

Bergmann89 hat folgendes geschrieben :

Hallo Finn, Danke für die vielen Infos, da war noch einiges dabei über das ich mir gar keine Gedanken gemacht habe.

Gerne, gerne

Bergmann89 hat folgendes geschrieben :

Logging / Monitoring Die entsprechenden Log Ausgaben kann ich - soweit ich das gesehen hab - gleich mit Docker verwalten.

Ja, kann man am Anfang theoretisch natürlich so machen. Spätestens jedoch, wenn man dann Benachrichtigungen haben möchte, wenn irgendwo ungewöhnlich viele Fehlermeldungen auftreten hört es dann leider auf.

Bergmann89 hat folgendes geschrieben :

Testing Unit Test sind da auch kein Problem, das kann ich mit Jasmine ganz gut Umsetzen.

Mit Jasmine habe ich soweit auch ganz gute Erfahrung gemacht. Etwas besser (aber syntaktisch quasi identisch) fand ich Mocha + Chai + Istanbul, momentan arbeite ich viel mit Jest. Der Vorteil an Jest ist, dass die Coverage Reports vernünftig mit TypeScript funktionieren. Das habe ich so sonst noch nicht erlebt (soll aber mit Istanbul auch irgendwie gehen).

Bergmann89 hat folgendes geschrieben :

Was würdet ihr anders machen?

Ich würde weder Node.js noch Ubuntu einsetzen wollen, weil ich beides für nicht sonderlich stabil für langfristige Entwicklung halte. Ansonsten hänge ich mich hier einfach mal beobachtend dran.
Vielleicht kann ich mal Sinnvolleres beitragen.

@jaenicke: Hab mich jetzt mal in mariadb eingearbeitet. Funktioniert ganz gut und arbeitet auch super mit MySQL Workbench zusammen. Werd ich denke ich so in meiner Produktiv Umgebung einsetzen

@Finn: Stimmt, an entsprechende Benachrichtigungen habe ich bis jetzt auch noch nicht gedacht. Vlt bau ich's lieber doch gleich mit ein
Ich hab bis jetzt nur mit Jasmin gearbeitet, aber so wie es sich anhört ist Jest auch mal einen Blick wert.

@hydemarie: Was würdest du denn nehmen?

Bergmann89 hat folgendes geschrieben :

Was würdest du denn nehmen?

Hängt davon ab.

• Programmiersprache: Wenn der Webserver nicht viel mehr machen soll als eine Website, deren Logik komplett im Client hängt (Geschmackssache, ob man unbedingt erzwingen will, dass die Besucher JavaScript aktivieren...), mit einer MySQL-Datenbank zu verbinden, ist Node.js sicherlich sozusagen Overkill. Da würde ich was Schlankes in C oder, wenn's schnell gehen muss, Python oder Perl (je nach stilistischer Vorliebe) empfehlen - gerade auch, weil JavaScript ein moving target ist. Dein Node.js-Code von heute wird in zwei Jahren nicht mehr reibungslos laufen, nehme ich an. (Von npm und seinen Abhängigkeiten, die gern mal über Nacht nicht mehr funktionieren, möchte ich da nicht anfangen, das Problem gibt es in Python, Perl, ... auch.)
  
• Betriebssystem: vielleicht irgendwas, was nicht wegen "innovativer Funktionen" wie systemd plötzlich komische Dinge macht und den Benutzer nicht mit Werbung belästigt.

Aber: Dein Projekt, deine Regeln.

Guten Morgen,

@WebServer: Falls du meinst einen komplett eigenen WebServer in C zu schreiben, dann halte ich das für ein bisschen größenwahnsinnig (egal wie klein der Use Case ist). Ein entsprechendes Modul in C, was vom Web Server geladen wird kann ich mir schon eher vorstellen. Trotzdem ist die Entwicklungszeit dafür zu lang. Ich wollte für den Web Server eine Sprache nutzen, die mir viele Sachen schon abnimmt. Javascript (bsw. Node.js) hab ich mir deshalb ausgesucht, weil ich dann server- und clientseitig dieselbe Sprache nutzen kann. Aber anscheinend setzt der Großteil der Community hier wirklich mehr auf Python als auf Node.js (klick mich).
Über Javascript im Browser kann man sich jetzt streiten, aber die Otto-Normal-User (welche den Großteil meines Web Services ausmachen) haben Javascript aktiviert (ist ja auf manchen Seiten auch nicht mehr weg zu denken). Ich hab bis jetzt nur Erfahrungen mit Single-Page-Webseiten (die Javascript vorraussetzen) gemacht. Vlt sollte ich mich im Vorfeld auch nochmal mit anderen Möglichkeiten beschäftigen.

@OS: Ja, das leidige Thema systemd. Hier gehen die Meinungen ja sehr stark auseinander. Ich selbst habe noch keine schlechten Erfahrungen mit systemd gemacht und komm auch so relativ gut damit klar. Trotzdem scheint der Großteil der Community trotzdem auf Debian zu setzen (klick mich). Ich hatte zwar erst Ubuntu im Blick, aber mit Debian komm ich auch super zu Recht.

Kurz gesagt: an meiner Entscheidung Debian als OS zu nutzen halte ich fest. Das mit dem Javascript überleg ich mir nochmal, bzw. schau ich mich nochmal nach Alternativen um, die für mich in Frage kommen würden.

MfG Bergmann

Dass viele Leute ein bestimmtes Produkt einsetzen, sagt über dessen Qualität oft erschreckend wenig aus. Dies gilt auch für Betriebssysteme.
Wie groß irgendeine Community ist, sagt ja noch nicht viel darüber aus, wie hoch die Praxistauglichkeit in deinem Anwendungsfall ist.

Bergmann89 hat folgendes geschrieben :

@jaenicke: Hab mich jetzt mal in mariadb eingearbeitet. Funktioniert ganz gut und arbeitet auch super mit MySQL Workbench zusammen. Werd ich denke ich so in meiner Produktiv Umgebung einsetzen

Ich habe auch zuerst die Workbench weiter benutzt, aber mittlerweile bin ich bei HeidiSQL gelandet. Das kann einiges mehr und ist schneller.
Insbesondere einfach mal so einen Dump über das Kontextmenü zu erstellen, der auch schön aussieht, ist echt was wert...

Für Debug zwecke klingt das in der Tat besser, aber ich find den ER-Designer im Workbench mega. Vlt mach ich das Schema erstmal im Workbench und probier dann mal HeidiSQL (lustiger Name ) aus.

Das stimmt, der ist echt gut. So etwas hat HeidiSQL nicht.

Hallo Leute,

dieses Wochenende ist mir noch eine Frage/Problem eingefallen bei dem ich gern nochmal eure Meinung wissen würde. Und zwar wird mein Projekt ein kommerzielles Projekt. Der Nutzer muss also für gewisse Dienste bezahlen. Bei den ganzen Zahlungen, Rechnungserstellung, Steuern usw. muss man ja viel beachten, dass alles seine Richtigkeit hat. Deshalb wollte ich fragen ob es da vlt schon ein fertiges Modul für node.js gibt, das mir da ein wenig Arbeit abnimmt. Kennt einer von euch so ein Modul, oder wie würdet ihr das realisieren?

MfG Bergmann.

- Nachträglich durch die Entwickler-Ecke gelöscht -

Ja das hab ich auch schon gemerkt. Die Frage zielte eig mehr daruf ab mit welchem ihr schon gute/schlechte Erfahrungen gemacht habt pder ob (und wie) ihr das komplett ohnen node lösen würdet.

- Nachträglich durch die Entwickler-Ecke gelöscht -

Ja die Dienste kenn ich alle. Ich sucher aber ein Module/API die mir mehrere dieser Dienste (PaySafe, Paypal, VISA, MasterCard, ...) über eine API zur Verfügung stellt und mir (wenn möglich) auch das Erstellen der Rechnungen (+Steuern usw.) abnimmt.

- Nachträglich durch die Entwickler-Ecke gelöscht -

Moin,

ich habe mal kurz eine bestehende Anwendung mit PayOne betreut. Das fand man dann irgendwann zu teuer und wir sind dann zu PayPal Plus gewechselt. Von der Implementierung her fand ich das eigentlich ganz angenehm und man kann Überweisung, Lastschrift, Kreditkarte und Rechnungskauf, sowie natürlich PayPal anbieten. Die Gebühren waren eigentlich auch akzeptabel. Der Vorteil von PayOne ist hier höchstens, dass sie noch erheblich mehr Zahlungsmöglichkeiten (z.B. Sofort, GiroPay, Klarna...) anbieten können.

Die Paypal REST API ist gut dokumentiert und man kann damit ungefähr alles machen, was man sich vorstellen kann (inkl. Ratenzahlung, Rückerstattungen, etc.). Wenn du oft einfache Anwendungsfälle hast, könnte ich mir vorstellen, dass auch Paypal Express oder ggf. Braintree für dich geeignet sind. In den Segmenten in denen ich bisher gearbeitet habe, waren Kreditkarte, Paypal und Vorkasse immer die beliebtesten Zahlungsmethoden. Das kann aber natürlich je nach Zielgruppe stark variieren. Paypal strahlt natürlich eine unendliche Seriösität aus.

Was du auf keinen Fall möchtest, ist selbst in die Nähe von Kundendaten wie Kreditkartennummern oder Bankverbindungen zu kommen. Erstens gibt es da gesetzliche Auflagen, zweitens macht man sich keine Freude, wenn man dann mal eine Sicherheitslücke hat. Daher ist die Entscheidung einen Zahlungsanbieter zu nutzen, sehr richtig und wichtig.

Zum anderen Teil der Frage: um deine Buchhaltung und Steuern kommst du eh nicht herum, da hilft dir dann auch dein Zahlungsanbieter nicht wirklich - einen Kontoauszug kriegst du da natürlich.

Gruß
Finn