Eine erholsame Kommunikation zwischen lokalen Anwendungen ist eine gute Idee?

StackOverflow https://stackoverflow.com/questions/4002545

Frage

Ich frage mich, ob es eine gute Idee ist, lokale Anwendungen (auf demselben Server) vollständig über die Restful API miteinander kommunizieren zu lassen?

Ich weiß, dass dies keine Seltenheit ist, da wir bereits Anwendungen wie CouchDB haben, die HTTP REST für die Kommunikation verwenden, sogar mit lokalen Anwendungen.

Aber ich möchte es auf eine höhere Ebene bringen, indem ich Anwendungen erstelle, die wie Module für eine größere Anwendung funktionieren, die auch ein Modul für eine andere Anwendung sein könnten und so weiter.Mit anderen Worten: Es wird viele lokale Anwendungen/Module geben, die mit der Restful API kommunizieren.

Auf diese Weise könnten diese Anwendungen/Module in jeder beliebigen Sprache vorliegen und über die Leitung zwischen Servern kommunizieren.

Aber ich habe einige Fragen:

  • Ist das eine gute Idee?
  • Wird die Datenübertragung zwischen ihnen langsam sein?
  • Wenn ich das mache, muss jede Anwendung/jedes Modul ein HTTP-Server sein, oder?Wenn meine Anwendung also 100 Anwendungen/Module verwendet, muss jedes davon ein lokaler HTTP-Webserver sein, der jeweils auf einem anderen Port läuft (http://localhost:81, http://localhost:82, http://localhost:83 und so weiter), oder?
  • Gibt es Best Practices/Fallstricke, die ich kennen sollte?
War es hilfreich?

Lösung

  • Ist das eine gute Idee?

Sicher, vielleicht.

  • Wird die Datenübertragung zwischen ihnen langsam sein?

Jawohl!Aber im Vergleich zu was?Im Vergleich zu nativen, internen Anrufen wird es auf jeden Fall eiskalt sein.Im Vergleich zu anderen Netzwerk-APIs ist es nicht unbedingt langsamer.

  • Wenn ich dies mache, muss jede Anwendung/jedes Modul ein HTTP -Server sein, oder?Wenn meine Anwendung 100 Anwendungen/Module verwendet, muss ich 100 lokale HTTP -Webserver aufweisen und jeweils mit einem anderen Port ausführen (http: // localhost: 81,,http://localhost:82, http://localhost:83 und so weiter)?

Nein, es gibt keinen Grund, jedem Modul einen Port zuzuweisen.Es gibt alle möglichen Möglichkeiten, dies zu tun.

  • Gibt es Best Practices/Gotchas, die ich wissen sollte?

Das gelingt nur, wenn die Leistungen, über die Sie sprechen, groß genug sind.Dabei muss es sich um große, sperrige Dienste handeln, bei denen sich die Kosten für einen Anruf lohnen.Bei jeder Transaktion fallen Verbindungskosten, Datenübertragungskosten und Datenmarshallingkosten an.Sie möchten also, dass diese Transaktionen so selten wie möglich sind und dass die Nutzlast so groß wie möglich ist, um den größtmöglichen Nutzen zu erzielen.

Reden Sie tatsächlich von der Verwendung der REST-Architektur oder vom einfachen Hin- und Hersenden von Daten über HTTP?(Das sind verschiedene Dinge) REST verursacht seine eigenen Kosten, einschließlich eingebetteter Verknüpfungen, allgegenwärtiger und allgemeiner Datentypen usw.

Schließlich müssen Sie dies möglicherweise einfach nicht tun.Es könnte durchaus „irgendwie cool“ sein, ein „nice to have“, „sieht auf der Tafel gut aus“, aber wenn Sie es wirklich nicht brauchen, dann tun Sie es nicht.Befolgen Sie einfach die bewährten Methoden zur Isolierung Ihrer internen Dienste, sodass Sie, falls Sie sich später dazu entschließen, so etwas zu tun, einfach die für die Verwaltung der Kommunikation usw. erforderliche Klebeschicht anbringen können.Das Hinzufügen einer Remote-Verteilung erhöht das Risiko, die Komplexität und verringert die Leistung (Skalierung! = Leistung), daher sollte es überhaupt einen guten Grund dafür geben.

Das ist wohl die „beste Praxis“ von allen.

Bearbeiten – Antwort auf Kommentar:

Sie meinen also, ich führe einen Webserver aus, der alle eingehenden Anfragen bearbeitet?Aber dann sind die Module keine eigenständigen Anwendungen, die den gesamten Zweck besiegen.Ich möchte, dass jeder der Module in der Lage ist, alleine zu laufen.

Nein, es macht den Zweck nicht zunichte.

Das ist der Deal.

Nehmen wir an, Sie haben drei Dienste.

Auf den ersten Blick kann man mit Fug und Recht sagen, dass es sich um drei verschiedene Dienste handelt, die auf drei verschiedenen Computern auf drei verschiedenen Webservern laufen.

Aber die Wahrheit ist, dass diese alle auf demSELBEN Computer, auf demSELBEN Webserver laufen können, bis hin zur (um es auf die Spitze zu treiben) exakt gleichen Logik.

Mit HTTP können Sie alle möglichen Dinge abbilden.HTTP selbst ist ein Abstraktionsmechanismus.

Als Kunde ist für Sie nur die zu verwendende URL und die zu sendende Nutzlast wichtig.Mit welcher Maschine es letztendlich kommuniziert oder welchen tatsächlichen Code es ausführt, ist nicht das Problem des Clients.

Auf Architekturebene haben Sie eine Art der Abstraktion und Modularisierung erreicht.Mit den URLs können Sie Ihr System in dem von Ihnen gewünschten LOGISCHEN Layout organisieren.Die PHYSISCHE Implementierung unterscheidet sich von der logischen Sicht.

Diese drei Dienste können auf einem einzigen Computer ausgeführt werden, der von einem einzelnen Prozess bedient wird.Andererseits können sie 1000 Maschinen darstellen.Wie viele Maschinen reagieren Ihrer Meinung nach auf „www.google.com“?

Sie können alle drei Dienste problemlos auf einem einzigen Computer hosten, ohne Code außer dem Webserver selbst weiterzugeben.Dies erleichtert die Verlagerung eines Dienstes von seiner ursprünglichen Maschine auf eine andere Maschine.

Der Hostname ist die einfachste Möglichkeit, einen Dienst einer Maschine zuzuordnen.Jeder moderne Webserver kann eine beliebige Anzahl unterschiedlicher Hosts bedienen.Jeder „virtuelle Host“ kann eine beliebige Anzahl einzelner Dienstendpunkte innerhalb des Namensraums dieses Hosts bedienen.Auf der „Host“-Ebene ist es trivial, Code bei Bedarf von einem Computer auf einen anderen zu verschieben.

Sie sollten die Möglichkeiten eines modernen Webservers genauer erkunden, um beliebige Anfragen an die tatsächliche Logik auf dem Server weiterzuleiten.Sie werden feststellen, dass sie sehr flexibel sind.

Andere Tipps

Ist das eine gute Idee?

Ja. Es ist die ganze Zeit gemacht. So funktionieren zum Beispiel alle Datenbankserver. Linux ist voller Client/Server -Anwendungen, die über TCP/IP kommunizieren.

Wird die Datenübertragung zwischen ihnen langsam sein?

Nr. TCP/IP verwendet verwendet localhost Als kurzer Schnitt, um das tatsächliche Netzwerk-E/A-Netzwerk zu sparen.

Das HTTP -Protokoll ist nicht das Beste für engagierte Verbindungen, aber einfach und gut unterstützt.

Wenn ich dies mache, muss jede Anwendung/jedes Modul ein HTTP -Server sein, oder?

Nicht unbedingt. Einige Module können Clients sein und keinen Server haben.

Wenn meine Anwendung also 100 Anwendungen/Module verwendet, muss jeder davon ein lokaler HTTP -Webserver sein, der jeweils auf einem anderen Port ausgeführt wird (http: // localhost: 81,, http: // localhost: 82, http: // localhost: 83 Und so weiter) richtig?

Ja. So funktioniert es.

Gibt es Best Practices/Gotchas, die ich wissen sollte?

Nicht "Hardcode" -Portnummern "Hardcode".

Verwenden Sie nicht die "privilegierten" Portnummern (unter 1024).

Verwenden Sie eine WSGI -Bibliothek und Sie werden alle Ihre Module zu WSGI -Anwendungen machen. Sie können dann einen trivialen 2-Zeilen-HTTP-Server verwenden, um Ihr Modul zu wickeln.

Lesen Sie dies. http://docs.python.org/library/wsgiref.html#examples

Ich glaube, dass dies eine gute Idee ist, um erholsame Lösungen für die Integration von Anwendungen zu verwenden, und es ist eine gute Idee und bekannte ähnliche Ansichten bei einer anderen Frage.

Um ehrlich zu sein, glaube ich nicht, dass Sie 100 Server für 100 Anwendungen benötigen, vielleicht nur 100 Ports auf demselben Server verwenden.

Außerdem bietet Ihnen eine rastful -Schnittstelle die Flexibilität, die Server zu erweitern und den Lastausgleich zu aktivieren, wenn Sie das Potenzial haben möchten, bis auf riesig zu werden.

Nein - es ist keine gute Idee, wenn Sie keinen guten Grund haben. Es ist eine gute Idee, den Code Ihrer Anwendung zu entfernen, damit er zu einem späteren Zeitpunkt "ausgeruht" werden kann, wenn Sie ihn brauchen. (Oder unabhängig von der Leistungsverbesserung ist als notwendig.) Die erhöhte Komplexität der Bereitstellung von "serverbasierten Ebenen" ist ein guter Grund, dies nicht zu tun. Ich würde vorschlagen:

  • Schreiben Sie eine gut strukturierte Anwendung mit gutem, sauberem Code.
  • Testen Sie es mit erwarteten Produktionsbelastungen
  • Bei Bedarf - Refactor in Schichten, die Server sind - aber .....

Ein besserer Ansatz besteht darin, die gesamte Anwendung zu laden. Wenn Sie so etwas wie Schienen ohne Status auf dem App -Server tun, sollte es kein Problem sein, mehrere Instanzen parallel auszuführen.

Wenn Sie nach Komplexität suchen - ignorieren Sie meine Antwort. :-)

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top