Entwickler-Ecke
Sonstiges (Web-Entwicklung) - Konzept meines eigenen Webservices
Bergmann89 - Di 27.06.17 19:05
Titel: Konzept meines eigenen Webservices
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 :P ). 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
FinnO - Di 27.06.17 21:48
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 [
https://twitter.com/smartrevolution/status/788046770567864320]):
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 [
https://www.elastic.co/webinars/introduction-elk-stack]-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
Bergmann89 - Mi 28.06.17 09:26
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 :motz:)
Unit Test sind da auch kein Problem, das kann ich mit
Jasmine [
https://jasmine.github.io/] 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.
jaenicke - Mi 28.06.17 10:04
 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. ;-)
FinnO - Mi 28.06.17 19:22
| 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.
Mit Jasmine habe ich soweit auch ganz gute Erfahrung gemacht. Etwas besser (aber syntaktisch quasi identisch) fand ich
Mocha + Chai [
https://mochajs.org/] +
Istanbul [
https://github.com/gotwarlost/istanbul], momentan arbeite ich viel mit
Jest [
https://facebook.github.io/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).
hydemarie - Do 29.06.17 23:00
| 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.
Bergmann89 - Do 29.06.17 23:48
@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 :D
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? :?!?:
hydemarie - Do 29.06.17 23:58
| 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 [https://twitter.com/systemdsucks] und den Benutzer nicht mit Werbung belästigt [https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1701068].
Aber: Dein Projekt, deine Regeln. :)
Bergmann89 - Fr 30.06.17 09:37
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 [
https://www.slant.co/topics/1565/~server-side-programming-languages]).
Ü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 [
https://www.slant.co/topics/2078/~linux-distributions-for-servers]). 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
hydemarie - Fr 30.06.17 09:40
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.
jaenicke - Fr 30.06.17 11:04
| 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...
Bergmann89 - Fr 30.06.17 12:06
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 :lol: ) aus.
jaenicke - Fr 30.06.17 20:48
Das stimmt, der ist echt gut. So etwas hat HeidiSQL nicht.
Bergmann89 - Mo 17.07.17 11:31
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.
Delete - Mo 17.07.17 11:45
- Nachträglich durch die Entwickler-Ecke gelöscht -
Bergmann89 - Mo 17.07.17 12:20
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.
Delete - Mo 17.07.17 12:32
- Nachträglich durch die Entwickler-Ecke gelöscht -
Bergmann89 - Mo 17.07.17 12:47
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.
Delete - Mo 17.07.17 13:23
- Nachträglich durch die Entwickler-Ecke gelöscht -
FinnO - Mo 17.07.17 22:44
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 [
https://developers.braintreepayments.com/] 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
Delete - Di 18.07.17 05:52
- Nachträglich durch die Entwickler-Ecke gelöscht -
Bergmann89 - Di 18.07.17 09:23
Guten Morgen,
Danke für die Infos. Paypal Plus (bzw. für's erste Paypal Express) sollte für mich erstmal ausreichend sein. Vlt noch PaySafe als Alternative (ich fnd PaySafe auch ne gute Sache).
Wegen den Rechnungen sollte ich mich vlt nochma beim Steuerberater informieren, auf was genau man da achten muss. Bei dem Ganzen rechtlichen Kram hab ich null Ahnung :?
MfG Bergmann.
jaenicke - Di 18.07.17 17:46
| Bergmann89 hat folgendes geschrieben : |
| Wegen den Rechnungen sollte ich mich vlt nochma beim Steuerberater informieren, auf was genau man da achten muss. Bei dem Ganzen rechtlichen Kram hab ich null Ahnung :? |
Ich würde die Steuererklärung vom Steuerberater machen lassen, wenn man dafür nicht groß genug ist um eigene Mitarbeiter für solche Sachen zu haben (oder sich damit sehr gut auskennt). Denn die Wahrscheinlichkeit, dass du etwas falsch machst oder zu viel Steuern bezahlst, ist relativ hoch.
(Ich sehe auch privat, dass da viele zu viel zahlen, z.B. weil sie die Steuererklärung manuell machen, sprich die Tipps von Elster nicht sehen, und viele Sachen gar nicht ausfüllen. Einfaches Beispiel: haushaltsnahe Dienstleistungen...)
Bergmann89 - Do 20.07.17 12:38
Ja, das is klar. Selber würde ich mir das nicht zutrauen. Aber ich denke das es da doch noch die ein oder andere Sache gibt, die ich beachten muss. Rechnugs-Erstellung machen wir ja dann in dem System. Die Rechnungen bekommt dann der Steuerberater um seinen Part zu erledigen. Das sind dann so kleine Detailfragen, wie: Was genau muss auf die Rechnung drauf? Usw...
Bergmann89 - Do 03.08.17 20:47
Hey Leute,
ich hab da mal noch ne Frage bzw. ein Problem: Ich mach grad das Design von der Datenbank und meinen Workern, die dann die eigentliche Berechung durchführen. Ich habe ein Tabelle in der die Jobs für die Worker liegen. Jeder aktive Worker holt sich dort einen Job raus und bearbeitet ihn. Sollte der Woker jetzt hart beendet werden (Kill, Fehler im Worker, ...) dann würde der Job den der Worker gerade bearbeitet im aktuellen Zustand fest hängen, weil ich beim harten Beenden des Workers nicht sicherstellen kann, das der Job in der Datenbank wieder auf 'waiting' gesetzt wird. Bietet MariaDB (bzw. MySQL) eine Möglichkeit das zu umgehen. So nach dem Motto: "Wenn die Connection weg fliegt Update mal den Datensatz"?
MfG & Thx Bergmann.
FinnO - Do 03.08.17 21:26
Moin,
es gibt zwei Probleme in der Programmierung verteilter Systeme [
https://twitter.com/mathiasverraes/status/632260618599403520?lang=en]:
2. Exactly once delivery
1. Guaranteed order of delivery
2. Exactly once delivery
Je nachdem, wie lange deine Jobs laufen, bzw. wie teuer es für dich ist, einen Job (ungewollt) zweimal abzuarbeiten, musst du dir eine Strategie überlegen, nach der du deine Jobs auslöst.
Möglich ist zum Beispiel folgendes Vorgehen:
1. Du startest einen Job. In der Datenbank speicherst du, welcher Worker welchen Job ausführt. Dabei musst du dafür sorgen, dass das Speichern in der Datenbank über eine Transaktion garantiert an das Starten des Jobs gekoppelt ist. Das heißt, dass du sowohl die Transaktion erst committen darfst, wenn der Job gestartet wurde, andererseits aber auch den Job abbrechen solltest, wenn die Transaktion fehlschlägt.
2. Wenn der Job erfolgreich abgearbeitet wurde, markierst du dies erneut in der Datenbank. Wird der Job nicht erfolgreich beendet, oder ist die Datenbank vom Worker aus nicht erreichbar, oder andere Katastrophen treten auf, bleibt diese Markierung aus. Nach einem gewissen Timeout kannst du den Job neu starten. Oder verwerfen. Dann kann es natürlich (wenigstens theoretisch) passieren, dass der Job zweimal gestartet wird.
3. Eine ähnliche Logik kannst du für den Fall bauen, dass du einen Absturz des Workers detektierst (wie auch immer). Dann kannst du den entsprechenden Job in der Datenbank finden und wieder in den Ausgangszustand versetzen.
Nach harter Arbeit und elender Quälerei hast du dann eine Art Job-Queue mit MySQL gebaut. Du kannst natürlich auch die Job-Queue des Clouddienstleisters deines Vertrauens verwenden (z.B.
AWS-SQS [
https://aws.amazon.com/sqs/?nc1=h_ls]). Da hast du dann gleich eine saubere und zuverlässige Lösung, die alle wesentlichen Anwendungsfälle abdecken sollte.
Bergmann89 - Do 03.08.17 21:40
Ja sowas in der Art hab ich mir auch überlegt, aber ich dachte vlt gibts da ne schönere Lösung :?
Extra Cloud Dienste kommen für mich erstmal nicht in Frage.
Bergmann89 - Do 03.08.17 22:42
RabbitMQ klingt ganz gut. Da gibts auch schon entsprechende Docker Images und beim ersten Blick auf die Tutorials machen die genau das was ich brauch. Entsprechende Schnittstellen für JavaScript (also node.js) und Objective-C (das sollte sich leicht nach C++ portieren lassen) gibt es ja auch schon. Ich guck mir das die Tage mal genauer an. Danke :) :zustimm:
Bergmann89 - Mi 18.10.17 20:39
Hallo,
ich mach mir gerade Gedanken darüber wie ich die REST-Api möglichst sicher gestalten kann. Folgende Ideen dazu:
- HTTPS (das sollte Grundvoraussetung sein :P )
- Anmeldung des Users: Das Passwort des Users bekommt vor der Übertragung zum Server (Anmeldung/Registierung) etwas Salz und wird gehasht (um ein Secret zu erzeugen). Das Secret wird serverseitig nochmal mit bcrypt verarbeitet und kann dann in der Datenbank gespeichert werden.
- Authentifizierung: Der User vereinbart nach erfolgreicher Anmeldung einen Session Key mit dem Server. Dieser Session Key wird genutzt um Requests zum Server mit HMAC zu sichern.
Fragen:
- Wie sicher ich die Registrierung ab, das man diese möglichst nicht maschinell durchführen kann?
- Wie umgehe ich am besten DoS Attacken?
Macht das soweit Sinn? Hab ich was vergessen?
MfG Bergmann89.
FinnO - Mi 18.10.17 20:53
Moin,
wenn nicht richtig gute Business-Gründe dagegen sprechen, würde ich vermeiden wollen irgendetwas zu programmieren, was in die Richtung von Security geht. Man kann gut externe Dienste (z.B.
https://auth0.com/ - kostenlos bis 7k Nutzer) nutzen, oder soetwas wie googles firebase auth verwenden.
https://firebase.google.com/docs/auth/
Wenn eine große Bandbreite von OAUTH Providern nicht nötig ist, (z.B. wenn davon ausgegangen werden kann, dass alle deiner Nutzer GitHub accounts haben), kann man auch einfach nur einen individuellen Provider selbst implementieren:
https://developer.github.com/v3/guides/basics-of-authentication/
Dann muss man sich auch um DoS und Registrierung keine Gedanken machen.
Gruß
Finn
Bergmann89 - Mi 18.10.17 21:35
Firebase klingt nicht schlecht, das guck ich mir morgen mal genauer an. Ich möchte das der User so wenig wie möglich Aufwand in anderen Systemen hat. Er soll sich auf meinem Service einfach registrieren/anmelden und fertig. Mit Firebase kann ich das ja alles im Hintergrund machen, sodass der User davon nichts mit bekommt, soweit ich das jetzt auf den ersten Blick richtig gesehen hab.
Bergmann89 - Do 19.10.17 18:49
So, ich hab mich eben mal durch die Firebase Doku gearbeitet. Wennn ich das richtig verstanden habe, dann ist Firebase mein Backend und ich bau nur das Frontend drum rum. Das kommt für mich aber nicht in Frage, das ich ein sehr spezielles Backend habe (hier sollen einige Berechnungen ausgeführt werden). Das Backend soll eine REST Api zur Verfügung stellen, die dann vom Fronend genutzt wird.
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2024 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!