Lange Zeit habe ich den Unterschied zwischen RPC (also Remote Procedure Call) und HTTP-Aufrufen nicht herausgefunden. Bitte erlauben Sie mir, hier zu lachen~Naiv! Dieser Artikel stellt kurz die beiden Formen der C/S-Architektur vor, erstens ihren wichtigsten Unterschied, nämlich dass RPC hauptsächlich auf dem TCP/IP-Protokoll basiert, während HTTP-Dienste hauptsächlich auf dem HTTP-Protokoll basieren. Wir wissen alle, dass das HTTP-Protokoll über dem Transportschichtprotokoll TCP liegt, sodass RPC in Bezug auf Effizienz natürlich besser ist! Lassen Sie uns im Detail über RPC-Dienste und HTTP-Dienste sprechen.
OSI-Netzwerk-Sieben-Schicht-Modell
Bevor wir über den Unterschied zwischen RPC und HTTP sprechen, halte ich es für notwendig, das Sieben-Schicht-Netzwerkstrukturmodell von OSI zu verstehen (obwohl es in der Praxis im Grunde fünf Schichten sind), das in folgende Schichten unterteilt werden kann: (von oben nach unten)
- Die erste Schicht: Anwendungsschicht. Schnittstellen für Kommunikation und Datenübertragung im Netzwerk sind definiert;
- Die zweite Schicht: die Darstellungsebene. Definition des Übertragungsformats, der Kodierungs- und Dekodierungsspezifikationen von Daten in verschiedenen Systemen usw.;
- Die dritte Ebene: die Gesprächsebene. Verwalten Sie Benutzersitzungen und steuern Sie die Einrichtung und Unterbrechung logischer Verbindungen zwischen Nutzern.
- Die vierte Schicht: die Transportschicht. Es verwaltet die End-to-End-Datenübertragung im Netzwerk;
- Schicht 5: Netzwerkschicht. Definieren, wie Daten zwischen Netzwerkgeräten übertragen werden;
- Sechste Schicht: Link-Schicht. Die Datenpakete der darüberliegenden Netzwerkschicht sind in Datenframes gekapselt, um die Übertragung der physischen Schicht zu erleichtern.
- Schicht 7: Physische Schicht. Diese Schicht dient hauptsächlich der Übertragung dieser binären Daten.
In der praktischen Anwendung gibt es in der fünfschichtigen Protokollstruktur keine Präsentations- und Sessionschicht. Es sollte erwähnt werden, dass sie mit der Anwendungsebene zusammengefasst werden. Wir sollten uns auf die Anwendungsschicht und die Transportschicht konzentrieren. Weil HTTP ein Anwendungsschichtprotokoll ist, während TCP ein Transportschichtprotokoll ist. Jetzt, wo wir das Network Layering-Modell kennen, können wir besser verstehen, warum RPC-Dienste besser sind als HTTP-Dienste!
RPC-Dienste
RPC-Dienste werden aus drei Perspektiven eingeführt: RPC-Architektur, synchrone asynchrone Aufrufe und beliebte RPC-Frameworks.
RPC-Architektur
Lassen Sie uns über die grundlegende Architektur von RPC-Diensten sprechen. Erlauben Sie mir, beschämend ein Bild zu stehlen~ Wir sehen deutlich, dass eine vollständige RPC-Architektur vier Kernkomponenten enthält, nämlich Client, Server, Client-Stub und Server-Stub, die als Stub verstanden werden können. Lassen Sie uns über diese Komponenten einzeln sprechen:
- Kunde, der Anrufer des Dienstes.
- Server, der eigentliche Dienstleister.
- Der Client-Stub speichert die Adressnachricht des Servers, packt dann die Anfrageparameter des Clients in eine Netzwerknachricht und sendet diese anschließend aus der Ferne über das Netzwerk an die Servicepartei.
- Der serverseitige Stub empfängt vom Client gesendete Nachrichten, entpackt die Nachrichten und ruft lokale Methoden auf.
RPC wird hauptsächlich in großen Unternehmen eingesetzt, da große Unternehmen über viele Systeme, komplexe Geschäftsbereiche verfügen und Effizienzvorteile sehr wichtig sind. Das geschieht in der eigentlichen Entwicklung, und Projekte werden in der Regel mit Maven verwaltet. Zum Beispiel haben wir einen Systemdienst, der Bestellungen verarbeitet, zuerst alle seine Schnittstellen deklariert (hier speziell die Schnittstelle in Java) und dann das gesamte Projekt in ein JAR-Paket packt. Warum machst du das? Der Hauptzweck ist es, die Größe des JAR-Pakets auf der Client-Seite zu verringern, da jedes Mal, wenn ein Paket freigegeben wird, zu viele JAR-Pakete die Effizienz beeinträchtigen. Es entkoppelt außerdem Client und Server, um die Portabilität des Codes zu verbessern.
Synchrone und asynchrone Aufrufe
Was ist ein synchroner Anruf? Was ist ein asynchroner Anruf? Ein synchroner Aufruf ist, wenn der Client darauf wartet, dass der Aufruf abgeschlossen ist, und das Ergebnis zurückgibt. Asynchrone Aufrufe bedeuten, dass der Client nicht darauf wartet, dass der Aufruf ausgeführt und das Ergebnis zurückgegeben wird, aber dennoch die Benachrichtigung über das Rückrufergebnis über die Rückruffunktion erhalten kann. Wenn dem Kunden das Ergebnis egal ist, kann es zu einem Einweggespräch werden. Dieser Prozess ähnelt in gewisser Weise den aufrufbaren und ausführenden Schnittstellen in Java; wenn wir asynchron ausgeführt werden, können wir, wenn wir das Ergebnis der Ausführung wissen müssen, die aufrufbare Schnittstelle verwenden und die Ergebnisse der asynchronen Ausführung über die Future-Klasse erhalten. Wenn dir das Ausführungsergebnis egal ist, kannst du einfach die ausführende Oberfläche verwenden, weil sie das Ergebnis nicht zurückgibt – natürlich ist Callable auch möglich, wir brauchen die Zukunft nicht.
Beliebtes RPC-Framework
Es gibt immer noch viele beliebte Open-Source-RPC-Frameworks. Hier sind drei Highlights:
- gRPC ist eine kürzlich angekündigte Open-Source-Software von Google, die auf dem neuesten HTTP-2.0-Protokoll basiert und viele gängige Programmiersprachen unterstützt. Wir wissen, dass HTTP 2.0 eine verbesserte Version des HTTP-Protokolls auf Binärcode ist, und große Browser unterstützen es derzeit in rasantem Tempo. Dieses RPC-Framework basiert auf dem HTTP-Protokoll, und das zugrunde liegende Framework unterstützt das Netty-Framework.
- Thrift ist ein Open-Source-Projekt für Facebook, in erster Linie ein Cross-Language-Service Development Framework. Es verfügt über einen Codegenerator, der automatisch ein Service-Code-Framework für die von ihm definierte IDL-Definitionsdatei generiert. Nutzer müssen nur die Sekundärentwicklung vorher durchführen, und die zugrundeliegende RPC-Kommunikation ist transparent. Für die Nutzer gibt es jedoch dennoch gewisse Kosten, um die Sprache eines bestimmten Fachgebiets zu erlernen.
- Dubbo ist ein bekanntes RPC-Framework Open Source von der Alibaba Group, das in vielen Internetunternehmen und Unternehmensanwendungen weit verbreitet eingesetzt wird. Sowohl Protokolle als auch Serialisierungsframeworks können eingesteckt werden. Die gleiche entfernte Schnittstelle basiert auf der Java-Oberfläche und basiert auf dem Spring-Framework für eine einfache Entwicklung. Sie kann leicht in einer einzigen Datei zusammengefasst und unabhängig ausgeführt werden, was mit dem aktuellen Konzept der Microservices übereinstimmt.
Insgeheim erzähle ich, dass die Gruppe dubbo kaum noch benutzt,Der, der heute häufiger verwendet wird, heißt HSF, auch bekannt als "so bequem". Es könnte später Open Source geben, also warten wir ab.
HTTP-Dienst
Tatsächlich habe ich das Unternehmensentwicklungsmodell vor langer Zeit immer als HTTP-Schnittstellenentwicklung charakterisiert, was wir oft RESTful-artige Service-Schnittstellen nennen. Tatsächlich ist es eine Kommunikationsmethode, die oft in der frühen Phase der Lösung von Informationsinseln bei wenigen Schnittstellen und geringerer Interaktion zwischen Systemen verwendet wird; Die Vorteile sind einfach, direkt und leicht zu entwickeln. Verwenden Sie das fertige HTTP-Protokoll für die Übertragung. Wir erinnern uns, dass wir bei der früheren Hintergrundentwicklung im Unternehmen hauptsächlich Schnittstellen entwickelten und auch ein großes Schnittstellendokument schreiben mussten, das strikt angab, was Eingabe und Ausgabe waren. Erkläre die Anforderungsmethode jeder Schnittstelle und die Aspekte, die in den Anforderungsparametern beachtet werden müssen. Zum Beispiel folgendes Beispiel:
BEREITSTELLENhttp://www.httpexample.com/restful/buyer/info/share
Die Schnittstelle kann eine JSON-Zeichenkette oder ein XML-Dokument zurückgeben. Der Client verarbeitet dann diese zurückgegebenen Informationen, was eine schnellere Entwicklung ermöglicht. Für große Unternehmen jedoch, wenn es viele interne Subsysteme und viele Schnittstellen gibt, werden die Vorteile des RPC-Frameworks deutlich: Erstens handelt es sich um eine lange Verbindung, und es ist nicht notwendig, jedes Mal dreimal die Hand zu schütteln wie bei HTTP, was den Netzwerkaufwand reduziert; zweitens verfügt das RPC-Rahmenwerk in der Regel über ein Registrierungszentrum sowie umfangreiche Überwachung und Verwaltung; Publishing, Offline-Schnittstellen, dynamische Erweiterung usw. sind für den Anrufer nicht wahrnehmbare und einheitliche Operationen.
Zusammenfassung
Im Allgemeinen sind RPC-Dienste hauptsächlich für große Unternehmen gedacht, während HTTP-Dienste hauptsächlich für kleine Unternehmen gedacht sind, da RPC effizienter ist und die Entwicklung von HTTP-Diensten schneller erfolgt. Kurz gesagt: Welche Art von Rahmen gewählt wird, hängt nicht davon ab, was auf dem Markt beliebt ist, sondern das gesamte Projekt vollständig zu bewerten, um die Auswirkungen der beiden Entwicklungsrahmen auf das gesamte Projekt sorgfältig zu vergleichen und schließlich zu entscheiden, was am besten für das Projekt geeignet ist. Wir dürfen RPC nicht für jedes Projekt um des RPC willen verwenden, sondern uns an lokale Bedingungen anpassen und die spezifische Situation analysieren.
|
Veröffentlicht am 01.04.2019 14:02:45
|
|
|
|
