[Microservices] Warum RPC anstelle von HTTP für Anrufe zwischen Diensten verwenden?

1. Was ist RPC?

RPC (Remote Procedure Call) - Remote Procedure Call, ein Protokoll zum Anfordern von Diensten von Remotecomputerprogrammen über das Netzwerk, ohne die zugrunde liegende Netzwerktechnologie verstehen zu müssen. Wenn beispielsweise zwei verschiedene Dienste A und B auf zwei verschiedenen Computern bereitgestellt werden, was sollte Dienst A tun, wenn er eine Methode in Dienst B aufrufen möchte? Es ist sicherlich möglich, HTTP-Anforderungen zu verwenden, aber es kann langsamer sein und einige Optimierungen sind nicht gut. Die Entstehung von RPC soll dieses Problem lösen.

2. Prinzip der RPC

Der Dienstkonsument (Client) ruft den Dienst in einem lokalen Anrufmodus auf.
Der Client-Stub ist für das Zusammenstellen von Methoden und Parametern zu einem Nachrichtentext verantwortlich, der nach Empfang des Anrufs über das Netzwerk übertragen werden kann.
Der Client-Stub findet die Dienstadresse und sendet die Nachricht an den Server.
Der Server-Stub decodiert die Nachricht nach dem Empfang.
Der Server-Stub ruft den lokalen Dienst gemäß dem Decodierungsergebnis auf.
Der lokale Dienst wird ausgeführt und das Ergebnis an den Server-Stub zurückgegeben.
Der Server-Stub packt das zurückgegebene Ergebnis in eine Nachricht und sendet es an den Verbraucher.
Der Client-Stub empfängt die Nachricht und decodiert sie.
Der Service-Konsument erhält das Endergebnis.

Hier ist ein weiteres Online-Sequenzdiagramm:

3. Welches Problem löst RPC?

Zusammenfassend lässt sich sagen, dass RPC aus der obigen Einführung in RPC hauptsächlich folgende Probleme löst: Anrufe zwischen verschiedenen Diensten in einem verteilten System oder einem Mikroservice-System sind so einfach wie Ortsgespräche.

Gemeinsames RPC-Framework

RMI (in JDK integriert): Der in JDK integrierte RPC weist viele Einschränkungen auf und wird nicht empfohlen.
Dubbo: Dubbo ist ein leistungsstarkes und exzellentes Service-Framework, das von Alibaba als Open-Source-Lösung bereitgestellt wird. Es ermöglicht Anwendungen die Implementierung von Service-Ausgabe- und Eingabefunktionen über Hochleistungs-RPC und kann nahtlos in das Spring-Framework integriert werden. Dubbo ist zu einer offiziellen Komponente in Spring Cloud Alibaba geworden.
gRPC : gRPC ist ein modernes Open Source-Hochleistungs-RPC-Framework, das in jeder Umgebung ausgeführt werden kann. Es kann Dienste innerhalb und zwischen Rechenzentren durch steckbare Unterstützung effektiv verbinden, um Lastausgleich, Nachverfolgung, Integritätsprüfungen und Authentifizierung zu erreichen. Dies gilt auch für die letzte Meile des verteilten Rechnens, um Geräte, mobile Anwendungen und Browser mit Back-End-Diensten zu verbinden.
Hessisch: Hessisch ist ein leichtes Remoteonhttp-Tool, das RMI-Funktionen auf einfache Weise bereitstellt. Im Vergleich zu WebService ist Hessisch einfacher und schneller. Das binäre RPC-Protokoll wird übernommen, da es sich um ein binäres Protokoll handelt und sich daher sehr gut zum Senden von binären Daten eignet.
Thrift: Apache Thrift ist das sprachübergreifende Open-Source-RPC-Kommunikationsframework von Facebook. Es wurde der Apache Foundation zur Verwaltung gespendet. Aufgrund seiner sprachübergreifenden Funktionen und seiner hervorragenden Leistung wurde es in vielen Internetunternehmen eingesetzt. Kompetente Unternehmen werden dies sogar tun Entwicklung basierend auf Sparsamkeit. Eine Reihe von verteilten Service-Frameworks, die Funktionen wie Service-Registrierung und Service-Erkennung hinzufügen.

3.1 Warum sollten Sie bei HTTP RPC für Serviceabrufe verwenden?

RPC ist nur ein Design

RPC ist nur ein Konzept und ein Entwurf zur Lösung des Problems des Anrufs zwischen verschiedenen Diensten . Es enthält im Allgemeinen zwei Übertragungsprotokolle und Serialisierungsprotokolle . Das Übertragungsprotokoll, das RPC implementiert, kann direkt auf TCP oder auf dem HTTP-Protokoll erstellt werden. Die meisten RPC-Frameworks verwenden TCP-Verbindungen (gRPC verwendet HTTP2).

HTTP 和 TCP

Vielleicht sind jetzt viele Freunde, die mit Computernetzwerken nicht vertraut sind, verwirrt. Wenn Sie wirklich verstehen wollen, müssen Sie kurz die Grundlagen von Computernetzwerken überprüfen:

Wir sprechen normalerweise über die fünfschichtige Protokollarchitektur von Computernetzwerken: Anwendungsschicht, Transportschicht, Netzwerkschicht, Datenverbindungsschicht und physikalische Schicht.

Die Aufgabe der Anwendungsschicht besteht darin, bestimmte Netzwerkanwendungen durch die Interaktion zwischen Anwendungsprozessen zu vervollständigen. HTTP ist ein Protokoll auf Anwendungsebene, das Daten (HTML-Dateien, Bilddateien, Abfrageergebnisse usw.) basierend auf dem TCP / IP-Kommunikationsprotokoll überträgt. Das HTTP-Protokoll funktioniert auf einer Client-Server-Architektur. Als HTTP-Client sendet der Browser alle Anforderungen über die URL an den HTTP-Server, nämlich den WEB-Server. Der Webserver sendet Antwortinformationen gemäß der empfangenen Anforderung an den Client. Das HTTP-Protokoll baut auf dem TCP-Protokoll auf.

Die Hauptaufgabe der Transportschicht besteht darin, allgemeine Datenübertragungsdienste für die Kommunikation zwischen den beiden Hostprozessen bereitzustellen . TCP ist ein Transportschichtprotokoll, das hauptsächlich dazu dient, die Datenübertragung im Netzwerk zu lösen. Im Vergleich mit UDP, TCP bietet verbindungsorientierte und zuverlässige Datenübertragungsdienste.

Der Hauptschlüssel liegt im Unterschied zwischen dem von HTTP verwendeten TCP-Protokoll und unserem benutzerdefinierten TCP-Protokoll in Bezug auf Nachrichten.

Das TCP-Paket des http1.1-Protokolls enthält zu viele Informationen, die während der Übertragung möglicherweise unbrauchbar sind:

HTTP/1.0 200 OK 
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84
 
<html>
  <body>Hello World</body>
</html>

Durch die Verwendung eines benutzerdefinierten TCP-Protokolls für die Übertragung wird das oben genannte Problem vermieden und der Aufwand für die Datenübertragung erheblich reduziert. Dies ist der eigentliche Grund, warum RPC normalerweise mit benutzerdefinierten TCP-Protokollen für Serviceanrufe verwendet wird. Darüber hinaus bietet das ausgereifte RPC-Framework auch Funktionen wie "automatische Registrierung und Erkennung von Diensten", "intelligenter Lastausgleich", "visuelle Dienststeuerung sowie Betrieb und Wartung", "Laufzeitverkehrsplanung" usw., die ebenfalls berücksichtigt werden können Wählen Sie RPC für die Serviceregistrierung und entdecken Sie einen der Gründe!

3.2 Ein häufiges Missverständnis

In vielen Artikeln wird auch erwähnt, dass im Vergleich zum benutzerdefinierten TCP-Nachrichtenprotokoll der erhöhte Overhead des HTTP-Protokolls das Herstellen und Trennen der Verbindung ist. Diese Ansicht wurde jedoch abgelehnt. Das Folgende ist ein Abfangen einer der Antworten:

Zunächst müssen wir leugnen, dass im Vergleich zum benutzerdefinierten TCP-Nachrichtenprotokoll der erhöhte Overhead des HTTP-Protokolls im Herstellen und Trennen der Verbindung liegt. Das HTTP-Protokoll unterstützt die Wiederverwendung des Verbindungspools, dh, eine bestimmte Anzahl von Verbindungen wird ohne Trennung hergestellt, und Verbindungen werden nicht häufig erstellt und zerstört. Was ich sagen möchte, ist, dass HTTP auch Protobuf, ein binäres Codierungsprotokoll, zum Codieren von Inhalten verwenden kann. Der größte Unterschied zwischen beiden besteht also im Übertragungsprotokoll.

Abschweifung

Darüber hinaus sollte beachtet werden, dass Spring Cloud Netflix das RPC-Framework nicht zum Tätigen von Anrufen zwischen verschiedenen Diensten verwendet, sondern das HTTP-Protokoll für Anrufe verwendet. Obwohl die Geschwindigkeit nicht so hoch ist wie bei RPC, wird auch das HTTP-Protokoll verwendet bringen viele andere Vorteile