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ß, das ist keine ungewöhnliche Sache, denn wir haben bereits Anwendungen wie CouchDB, 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 erzeuge, die wie Module für eine größere Anwendung funktionieren, die auch ein Modul für eine andere Anwendung sein könnte, und so weiter. Mit anderen Worten, es wird viele lokale Anwendungen / Module geben, die mit Restful API kommunizieren.
Auf diese Weise könnten diese Anwendungen / Module in jeder Sprache sein und sie könnten über die Verbindung zwischen Servern kommunizieren.
Aber ich habe einige Fragen:
Sicher, vielleicht.
Ja! Aber verglichen mit was? Im Vergleich zu nativen, internen Anrufen, absolut - es wird glazial sein. Im Vergleich zu einer anderen Netzwerk-API, nicht unbedingt langsamer.
Nein, kein Grund, einen Port pro Modul zuzuweisen. Alle möglichen Arten, dies zu tun.
Das wird nur gelingen, wenn die Dienste, über die Sie sprechen, grob genug sind. Diese müssen große, schwarze kastenförmige Dienste sein, die die Kosten, sie als lohnend zu bezeichnen, ausmachen. Bei jeder Transaktion fallen Verbindungskosten, Datenübertragungskosten und Kosten für das Daten-Marshalling an. Daher möchten Sie, dass diese Transaktionen so selten wie möglich sind und dass die Nutzlast so groß wie möglich sein soll, um den besten Nutzen zu erzielen.
Sprechen Sie eigentlich über die REST-Architektur oder schicken Sie einfach Dinge über HTTP hin und her? (Dies sind verschiedene Dinge) REST hat seine eigenen Kosten, enthält eingebettete Verknüpfungen, ubiquitäre und allgemeine Datentypen usw.
Schließlich müssen Sie dies möglicherweise nicht tun. Es könnte gut "irgendwie cool" sein, ein "nice to have", "sieht gut aus auf der Tafel", aber wenn es wirklich nicht gebraucht wird, dann tu es nicht. Befolgen Sie einfach die bewährten Verfahren zum Isolieren Ihrer internen Dienste. Sollten Sie sich später entscheiden, können Sie einfach die zum Verwalten der Kommunikation usw. erforderliche Klebeschicht einfügen. Durch das Hinzufügen einer Remote-Verteilung erhöht sich das Risiko, die Komplexität und die Leistung (Skalierung) ! = Leistung), also sollte es einen guten Grund geben, es überhaupt zu tun.
Das ist wohl die "beste Praxis" von allen.
Bearbeiten - Antwort auf Kommentar:
Also meinst du, ich betreibe einen Webserver, der alle eingehenden Anfragen bearbeiten? Aber dann Die Module sind nicht eigenständig Anwendungen, die das Ganze besiegen Zweck. Ich möchte jeden von den Module können von selbst ausgeführt werden.
Nein, es besiegt den Zweck nicht.
Hier ist der Deal.
Nehmen wir an, Sie haben 3 Dienste.
Auf den ersten Blick könnte man sagen, dass es sich um drei verschiedene Dienste auf drei verschiedenen Rechnern handelt, die auf drei verschiedenen Webservern laufen.
Aber die Wahrheit ist, dass diese alle auf der SAME-Maschine, auf dem SAME-Webserver laufen können, sogar bis zu (um dies auf die Spitze zu treiben), die genau dieselbe Logik ausführen.
Mit HTTP können Sie alle möglichen Dinge abbilden. HTTP selbst ist ein Mechanismus der Abstraktion.
Als Client interessiert Sie nur die zu verwendende URL und die zu sendende Payload. Mit welcher Maschine es spricht, oder mit welchem tatsächlichen Code es ausgeführt wird, ist nicht das Problem des Clients.
Auf einer Architekturebene haben Sie eine Art von Abstraktion und Modularisierung erreicht. Mit den URLs können Sie Ihr System so organisieren, wie Sie es wünschen. Die PHYSICAL-Implementierung unterscheidet sich von der logischen Sicht.
Diese drei Dienste können auf einer einzelnen Maschine ausgeführt werden, die von einem einzigen Prozess bedient wird. Auf der anderen Seite können sie 1000 Maschinen darstellen. Wie viele Maschinen reagieren Ihrer Meinung nach auf "www.google.com"?
Sie können problemlos alle drei Dienste auf einem einzigen Computer hosten, ohne den Code selbst zu speichern. Erleichtern Sie es, einen Dienst von seiner ursprünglichen Maschine auf eine andere Maschine zu verschieben.
Der Hostname ist die einfachste Möglichkeit, einen Service einer Maschine zuzuordnen. Jeder moderne Webserver kann eine beliebige Anzahl verschiedener Hosts bedienen. Jeder "virtuelle Host" kann eine beliebige Anzahl einzelner Dienstendpunkte innerhalb des Namensraums dieses Hosts bedienen. Auf der Ebene "host" ist es trivial, Code von einer Maschine zur anderen zu verschieben, wenn und wann es nötig ist.
Sie sollten mehr über die Möglichkeiten eines modernen Webservers erfahren, um beliebige Anfragen an die tatsächliche Logik auf dem Server zu richten. Sie werden sie sehr flexibel finden.
Ist das eine gute Idee?
Ja. Es ist die ganze Zeit fertig. So arbeiten beispielsweise alle Datenbankserver. Linux ist voll von Client / Server-Anwendungen, die über TCP / IP kommunizieren.
Wird die Datenübertragung zwischen ihnen langsam sein?
Nein. TCP / IP verwendet localhost als Abkürzung, um die tatsächlichen Netzwerk-E / A zu speichern.
Das HTTP-Protokoll ist nicht das Beste für dedizierte Verbindungen, aber es ist einfach und gut unterstützt.
Wenn ich das tue, dann muss jede Anwendung / Modul ein HTTP-Server sein, richtig?
Nicht unbedingt. Einige Module können Clients sein und keinen Server haben.
Wenn also meine Anwendung 100 Anwendungen / Module verwendet, muss jeder dieser lokalen HTTP-Webserver sein, die jeweils auf einem anderen Port ausgeführt werden (http: // localhost: 81, Ссылка , Ссылка und so weiter) oder?
Ja. So funktioniert es.
Irgendwelche Best Practices / Fehler, von denen ich wissen sollte?
Portnummern nicht "fest codieren".
Verwenden Sie nicht die "privilegierten" Portnummern (unter 1024).
Verwenden Sie eine WSGI-Bibliothek und Sie werden am glücklichsten sein, wenn Sie alle Ihre Module in WSGI-Anwendungen einbinden. Sie können dann einen trivialen 2-Zeilen-HTTP-Server verwenden, um Ihr Modul zu umbrechen.
Lesen Sie dies. Ссылка
Um ehrlich zu sein, glaube ich nicht, dass Sie 100 Server für 100 Anwendungen brauchen, vielleicht nur 100 Ports auf demselben Server.
und auch RESTful-Schnittstelle gibt Ihnen die Flexibilität, die Server zu erweitern und Load-Balancing zu aktivieren, wenn Sie das Potenzial haben, zu groß zu skalieren.
Nein - es ist keine gute Idee, wenn Sie keinen guten Grund haben. Es ist eine gute Idee, den Code Ihrer Anwendung so zu schichten, dass er zu einem späteren Zeitpunkt "ruht", wenn Sie ihn brauchen. (Oder eine Leistungsverbesserung wird als notwendig erachtet.) Die erhöhte Bereitstellungskomplexität von "serverbasierten Schichten" ist ein guter Grund, dies nicht zu tun. Ich würde vorschlagen:
Ein besserer Ansatz besteht darin, die gesamte Anwendung zu verteilen. Wenn Sie auf dem App-Server so etwas wie Rails mit keinem Status machen, sollte es kein Problem sein, mehrere Instanzen parallel laufen zu lassen.
Wenn Sie nach Komplexität suchen - ignorieren Sie meine Antwort. : -)
Tags und Links python ruby javascript rest node.js