Webdienst mit vielen Verbindungen

Question

Ich plane die Entwicklung eines Webdienstes, der sehr skalierbar sein muss, um viele gleichzeitige Verbindungen zu verarbeiten, wahrscheinlich Tausende. Der Dienst wird als API fungieren. Er muss sehr reaktionsschnell sein, eine Verzögerung von 3 Sekunden zwischen Anfrage und Antwort wird als zu viel angesehen.

Vielleicht könnte der Dienst auf viele interne Server verteilt werden, wobei ein Lastausgleichs-Gateway als Flussmanagement fungiert, damit die eigentliche Verarbeitung des Dienstes den Gateway-Server nicht in Anspruch nimmt. Ich erwäge die Verwendung von Amazon EC2, aber ich kann auch eine Reihe von internen Servern verwenden, solange ich eine gute Verwendung für sie finde. Die Datenbank wird wahrscheinlich MySQL sein (es sei denn, Sie haben eine bessere Idee).

Mir ist klar, dass die beste Lösung darin bestünde, einen eigenen Webserver zu entwickeln, aber das würde zu viel Zeit in Anspruch nehmen, und ich bezweifle, dass ich bessere Arbeit leisten kann als einige andere Webserver, die ich nicht kenne.

Außerdem überlege ich gerade, ob ich eine dauerhafte Verbindung herstellen soll oder nicht, aber ich werde mich wohl für Letzteres entscheiden.

Gibt es also Empfehlungen für eine gute, skalierbare Lösung?

Answer 1

Ich bin nicht der Meinung, dass die Entwicklung eines eigenen Webservers "die beste Lösung" ist. Verwenden Sie einen bestehenden. Sie sollten keinen eigenen Server schreiben müssen, nur um einen Webdienst bereitzustellen.

Sowohl .NET als auch Java EE bieten Möglichkeiten zur Erstellung und Bereitstellung von Webdiensten. Sie sagen nicht, für welche Sprache Sie sich entscheiden, aber sicherlich können Sie einen Webdienst in Java EE schreiben und ihn auf Tomcat bereitstellen, ohne einen eigenen Webserver schreiben zu müssen.

Was den Lastausgleich betrifft, F5 ist eine gute Hardware-Lösung, wenn Sie es sich leisten können.

Answer 2

Sie haben das Protokoll nicht erwähnt. Wenn Sie einen RESTful-Ansatz verwenden, ist dies ein sehr einfaches Stück Code zu schreiben. Wenn Sie einen SOAP-Ansatz verwenden, ist dies komplexer.

Apache + FastCGI wird dies tun, aber Ihr Dienst wird ein CGI-Programm sein. Sie werden in C oder C++ schreiben müssen, was unangenehm sein kann. Sie können Apache + mod_wsgi plus eines der Python-Frameworks verwenden; das ist zwar nicht so schnell, aber es wird sehr schnell sein und Sie müssen nicht viel Code schreiben.

Glassfish wird dies tun, und Sie können in Java schreiben.

Ein kommerzielles Produkt (wie JCAPS von Sun) kann dies leisten.

Es gibt zahlreiche Webdienst-Frameworks - es ist keine gute Idee, ein eigenes zu erfinden.

Editer Das Problem der "MaxClients".

Eine Webdienstanforderung sollte schnell sein - sie ist eine Ressource - man holt sie aus dem Cache oder der Datenbank und antwortet. Der begrenzende Faktor ist nicht MaxClients - es sind die Threads, die erfolgreich koexistieren können, und es ist die Socket-Aushandlung.

Wenn Ihre GET-Anfragen idempotent sind, können sie in Squid (oder einem anderen Reverse-Proxy-Server) zwischengespeichert werden. Sie können eine große Anzahl von diesen haben. Beachten Sie, dass die Verwendung eines Reverse-Proxy-Servers nichts mit Ihrem Webdienst zu tun hat per se Es hat jedoch alles mit dem Gesamtdurchsatz zu tun.

Answer 3

Amazon EC2 funktioniert gut, aber legen Sie Ihre Preisgestaltung nicht auf die $0,10-Instanzen fest - sie sind sehr leistungsschwach. Ich empfehle, mit mindestens c1.mediums zu beginnen. Ich verwende gerne nginx-Instanzen als Lastausgleich auf m1.small vor c1.medium Webserver-Instanzen (alle Anwendungen, die ich in letzter Zeit gebaut habe, sind CPU-gebunden und nicht speichergebunden).

3 Sekunden sind eine lange Zeit. Ich verwende normalerweise 200ms-400ms für ein Leistungsziel. Das hängt natürlich davon ab, wie zeitkritisch Ihre Anwendung ist und wie viel Arbeit erledigt werden muss.

Wenn wirklich 3 Sekunden Arbeit zu erledigen sind, können Sie wahrscheinlich ein Backend-Grid zur Vorverarbeitung der Daten einsetzen. Sie benötigen dann wahrscheinlich weniger Webserver, da diese meist vorgefertigte Daten zurückliefern.

Wenn ich an Ihrer Stelle wäre, würde ich einen Prototyp in der Sprache/Plattform erstellen, mit der ich mich am wohlsten fühle. Dann können Sie sich ein Bild davon machen, wohin Sie es bringen müssen.

Vergessen Sie nicht, dass es Zeit braucht, eine leistungsstarke Webanwendung zu entwickeln. Sie müssen programmieren, Benchmarks durchführen und wiederholen, um zu skalieren und die Antwortzeiten zu verringern.

Die Zahl der Fälle, in denen Sie einen eigenen Webserver schreiben müssen, ist sehr gering. Dies ist keiner von ihnen. Es gibt viele, aus denen man wählen kann. Ausgehend von einer Nix-basierten Plattform, können Sie Apache, nginx oder lighttpd verwenden. Es gibt noch eine ganze Reihe anderer, aber die werden typischerweise als App-Server verwendet (Tomcat, Zope, Mongrel usw.) und haben Apache/Nginx/Lighttpd/Squid als Proxy vor sich.

Ich habe nicht wirklich eine Plattform (Lösung) von der Stange für die Erstellung von Webanwendungen verwendet (ich nehme an, Sie meinen eine Art von Java- oder .Net-Stack). Ich kann Ihnen da nicht wirklich helfen. Die meisten Tools, mit denen ich arbeite (LAMP-ähnliches Zeug), sind komponentenbasiert und erlauben den Austausch von Komponenten in jedem Teil des Stacks. Es ist nicht ungewöhnlich, dass man aus einer Komponente herauswächst und sie durch eine andere ersetzen muss.

Zum Beispiel: kein Load Balancer -> Software Load Balancer -> Software Load Balancer, der puffern kann -> Hardware Load Balancer. Alle diese Varianten sind für unterschiedliche Größenordnungen kosteneffizient.