Ich bin mir sicher, dass die Überschrift eine gesunde Reaktion hervorgerufen hat – „Nun, es geht wieder los …“ Aber lassen Sie mich Ihre Aufmerksamkeit für 5–10 Minuten fesseln und ich werde versuchen, Ihre Erwartungen nicht zu enttäuschen.
Der Aufbau des Artikels wird wie folgt sein: Es wird eine stereotype Aussage getroffen und die „Natur“ der Entstehung dieses Stereotyps offengelegt. Ich hoffe, dass Sie dadurch die Wahl des Datenaustauschparadigmas in Ihren Projekten aus einem neuen Blickwinkel betrachten können.
Um klarzustellen, was RPC ist, schlage ich vor, den Standard zu berücksichtigen . Bei REST gibt es keine Klarheit. Und das sollte nicht sein. Alles, was Sie über REST wissen müssen – es ist nicht von zu unterscheiden .
RPC-Anfragen sind schneller und effizienter, da sie die Durchführung von Batch-Anfragen ermöglichen.
Der Punkt ist, dass Sie in RPC mehrere Prozeduren gleichzeitig in einer Anfrage aufrufen können. Erstellen Sie beispielsweise einen Benutzer, fügen Sie ihm einen Avatar hinzu und abonnieren Sie ihn in derselben Anfrage für einige Themen. Nur eine Anfrage und wie viel Nutzen!
Wenn Sie nur einen Backend-Knoten haben, scheint es mit einer Batch-Anfrage schneller zu sein. Denn drei REST-Anfragen erfordern dreimal mehr Ressourcen von einem Knoten, um Verbindungen herzustellen.
Beachten Sie, dass die erste Anfrage im Fall von REST die Benutzer-ID zurückgeben muss, damit nachfolgende Anfragen gestellt werden können. Was sich auch negativ auf das Gesamtergebnis auswirkt.
Solche Infrastrukturen sind jedoch nur in Inhouse-Lösungen und Enterprise zu finden. Als letztes Mittel bei kleinen WEB-Projekten. Aber vollwertige WEB-Lösungen, und selbst solche mit dem Namen HighLoad, lohnen sich nicht. Ihre Infrastruktur muss den Kriterien hoher Verfügbarkeit und Auslastung genügen. Und das Bild verändert sich.
Infrastrukturaktivitätskanäle im selben Szenario sind grün markiert. Beachten Sie, wie sich RPC jetzt verhält. Die Anfrage nutzt die Infrastruktur nur auf einem Bein vom Balancer bis zum Backend. Während REST bei der ersten Anfrage immer noch verliert, gleicht es die verlorene Zeit durch Nutzung der gesamten Infrastruktur aus.
Es reicht aus, nicht zwei Anreicherungswünsche in das Drehbuch einzutragen, sondern beispielsweise fünf oder zehn ... und die Antwort auf die Frage „Wer gewinnt jetzt?“ wird unklar.
Ich schlage vor, das Problem noch umfassender zu betrachten. Das Diagramm zeigt, wie Infrastrukturkanäle genutzt werden, die Infrastruktur ist jedoch nicht auf Kanäle beschränkt. Ein wichtiger Bestandteil einer Hochlast-Infrastruktur sind Caches. Lassen Sie uns nun eine Art Benutzerartefakt erhalten. Mehrmals. Sagen wir 32 Mal.
Sehen Sie, wie sich die RPC-Infrastruktur deutlich verbessert hat, um den Anforderungen hoher Auslastung gerecht zu werden. Tatsache ist, dass REST im Gegensatz zu RPC die volle Leistungsfähigkeit des HTTP-Protokolls nutzt. Im obigen Diagramm wird diese Leistung durch die Anforderungsmethode GET realisiert.
HTTP-Methoden verfügen unter anderem über Caching-Strategien. Sie finden sie in der Dokumentation unter . Für RPC werden POST-Anfragen verwendet, die nicht als idempotent gelten, d. h. wiederholte Wiederholungen derselben POST-Anfragen können unterschiedliche Ergebnisse liefern (z. B. wird nach dem Senden jedes Kommentars eine weitere Kopie dieses Kommentars angezeigt) ().
Folglich ist RPC nicht in der Lage, Infrastruktur-Caches effektiv zu nutzen. Dies führt dazu, dass Software-Caches „importiert“ werden müssen. Das Diagramm zeigt Redis in dieser Rolle. Der Software-Cache wiederum erfordert vom Entwickler das Hinzufügen einer zusätzlichen Codeschicht und spürbare Änderungen in der Architektur.
Zählen wir nun, wie viele Anfragen REST und RPC in der betrachteten Infrastruktur „gezeugt“ haben?
Anfragen
Posteingang
zum Backend
zum DBMS
zum Soft-Cache (Redis)
TOTAL
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Im Vergleich zum ersten Schema ist der Unterschied auffällig. Jetzt wird der Nutzen von REST deutlich. Aber ich schlage vor, hier nicht aufzuhören. Die entwickelte Infrastruktur umfasst ein CDN. Oftmals löst es auch das Problem der Abwehr von DDoS- und DoS-Angriffen. Wir bekommen:
Hier wird es für RPC richtig schlimm. RPC ist einfach nicht in der Lage, die Arbeitslast an ein CDN zu delegieren. Wir können uns nur auf Systeme zur Abwehr von Angriffen verlassen.
Ist es möglich, hier zu enden? Und noch einmal: Nein. HTTP-Methoden haben, wie oben erwähnt, ihre eigene „Magie“. Und nicht ohne Grund ist die GET-Methode im Internet weit verbreitet. Beachten Sie, dass diese Methode auf einen Inhalt zugreifen, Bedingungen festlegen kann, die Infrastrukturelemente interpretieren können, bevor die Kontrolle an Ihren Code übertragen wird, usw. All dies ermöglicht Ihnen die Schaffung flexibler, verwaltbarer Infrastrukturen, die wirklich große Anfrageströme bewältigen können. Aber in RPC wird diese Methode... ignoriert.
Warum ist der Mythos, dass Batch-Anfragen (RPC) schneller seien, so hartnäckig? Persönlich scheint mir, dass die meisten Projekte einfach nicht den Entwicklungsstand erreichen, auf dem REST seine Stärken ausspielen kann. Zudem ist er bei kleinen Projekten eher bereit, seine Schwächen zu zeigen.
Die Wahl von REST oder RPC ist keine freiwillige Entscheidung einer Person in einem Projekt. Diese Wahl muss den Anforderungen des Projekts entsprechen. Wenn ein Projekt in der Lage ist, alles, was es wirklich kann, aus REST herauszuholen und es wirklich braucht, dann ist REST eine ausgezeichnete Wahl.
Wenn Sie jedoch alle Vorteile von REST nutzen möchten, müssen Sie Entwickler-Spezialisten für das Projekt einstellen, um die Infrastruktur schnell zu skalieren, Administratoren für die Verwaltung der Infrastruktur, einen Architekten für die Gestaltung aller Schichten des WEB-Dienstes ... und des Projekts , verkauft gleichzeitig drei Packungen Margarine pro Tag... Ich würde bei RPC bleiben, weil... Dieses Protokoll ist eher zweckmäßig. Es erfordert keine tiefgreifenden Kenntnisse über die Funktionsweise von Caches und Infrastruktur, sondern konzentriert den Entwickler auf einfache und verständliche Aufrufe der von ihm benötigten Prozeduren. Das Geschäft wird glücklich sein.
RPC-Anfragen sind zuverlässiger, da sie Batch-Anfragen innerhalb einer einzelnen Transaktion ausführen können
Diese Eigenschaft von RPC ist ein klarer Vorteil, denn Es ist einfach, die Datenbank konsistent zu halten. Aber mit REST wird es immer komplizierter. Anfragen kommen möglicherweise inkonsistent bei verschiedenen Backend-Knoten an.
Dieser „Nachteil“ von REST ist die Kehrseite seines oben beschriebenen Vorteils – der Fähigkeit, alle Infrastrukturressourcen effizient zu nutzen. Wenn die Infrastruktur schlecht gestaltet ist, und noch mehr, wenn die Architektur des Projekts und insbesondere die Datenbank schlecht gestaltet sind, dann ist das wirklich ein großes Problem.
Aber sind Batch-Anfragen so zuverlässig, wie sie scheinen? Schauen wir uns einen Fall an: Wir erstellen einen Benutzer, ergänzen sein Profil mit einer Beschreibung und senden ihm eine SMS mit einem Geheimnis, um die Registrierung abzuschließen. Diese. drei Aufrufe in einer Batch-Anfrage.
Schauen wir uns das Diagramm an. Es stellt eine Infrastruktur mit Hochverfügbarkeitselementen dar. Mit SMS-Gateways stehen zwei unabhängige Kommunikationskanäle zur Verfügung. Aber... was sehen wir? Beim Senden einer SMS tritt der Fehler 503 auf – der Dienst ist vorübergehend nicht verfügbar. Weil Der SMS-Versand wird in einer Batch-Anfrage verpackt, dann muss die gesamte Anfrage zurückgesetzt werden. Aktionen im DBMS werden abgebrochen. Der Client erhält eine Fehlermeldung.
Der nächste Versuch ist die Lotterie. Entweder trifft die Anfrage immer wieder auf denselben Knoten und gibt einen Fehler zurück, oder Sie haben Glück und sie wird ausgeführt. Aber die Hauptsache ist, dass unsere Infrastruktur zumindest einmal schon vergeblich funktioniert hat. Es gab eine Ladung, aber keinen Gewinn.
Okay, stellen wir uns vor, wir haben uns angestrengt (!) und über die Option nachgedacht, wann die Anfrage teilweise erfolgreich abgeschlossen werden kann. Und wir werden versuchen, den Rest nach einiger Zeit (Welches? Entscheidet die Front?) erneut zu vervollständigen. Aber die Lotterie blieb gleich. Die Wahrscheinlichkeit, dass die Anfrage zum Versenden einer SMS erneut fehlschlägt, liegt bei 50/50.
Stimmen Sie zu, aus Sicht des Kunden scheint der Service nicht so zuverlässig zu sein, wie wir es gerne hätten ... was ist mit REST?
REST nutzt erneut die Magie von HTTP, jetzt jedoch mit Antwortcodes. Wenn auf dem SMS-Gateway ein Fehler 503 auftritt, sendet das Backend diesen Fehler an den Balancer. Der Balancer empfängt diesen Fehler und sendet die Anfrage, ohne die Verbindung zum Client zu unterbrechen, an einen anderen Knoten, der die Anfrage erfolgreich verarbeitet. Diese. Der Kunde erhält das erwartete Ergebnis und die Infrastruktur bestätigt ihr hohes Prädikat „hoch zugänglich“. Der Benutzer ist zufrieden.
Und wieder ist das noch nicht alles. Der Balancer hat nicht nur den Antwortcode 503 erhalten. Bei der Antwort empfiehlt es sich laut Standard, diesen Code mit dem Header „Retry-After“ zu versehen. Der Header macht dem Balancer klar, dass es sich nicht lohnt, diesen Knoten für eine bestimmte Zeit auf dieser Route zu stören. Und die nächsten Anfragen zum Senden von SMS werden direkt an einen Knoten gesendet, der keine Probleme mit dem SMS-Gateway hat.
Wie wir sehen, wird die Zuverlässigkeit von JSON-RPC überbewertet. Tatsächlich ist es einfacher, die Konsistenz in der Datenbank zu gewährleisten. Das Opfer wird in diesem Fall jedoch die Zuverlässigkeit des Systems als Ganzes sein.
Die Schlussfolgerung ähnelt weitgehend der vorherigen. Wenn die Infrastruktur einfach ist, ist die Offensichtlichkeit von JSON-RPC definitiv ein Plus. Wenn es bei dem Projekt um Hochverfügbarkeit mit hoher Auslastung geht, scheint REST die richtigere, wenn auch komplexere Lösung zu sein.
Die Eintrittsschwelle für REST ist niedriger
Ich denke, dass die obige Analyse, die die etablierten Stereotypen über RPC entlarvt, deutlich gezeigt hat, dass die Schwelle für den Einstieg in REST zweifellos höher ist als in RPC. Dies ist darauf zurückzuführen, dass ein tiefes Verständnis der Funktionsweise von HTTP erforderlich ist und dass ausreichende Kenntnisse über vorhandene Infrastrukturelemente erforderlich sind, die in WEB-Projekten verwendet werden können und sollten.
Warum glauben viele Leute, dass REST einfacher sein wird? Meine persönliche Meinung ist, dass diese scheinbare Einfachheit darauf zurückzuführen ist, dass sich REST manifestiert. Diese. REST ist kein Protokoll, sondern ein Konzept ... REST hat keinen Standard, es gibt einige Richtlinien ... REST ist nicht komplizierter als HTTP. Scheinbare Freiheit und Anarchie ziehen „freie Künstler“ an.
Natürlich ist REST nicht komplizierter als HTTP. Aber HTTP selbst ist ein gut konzipiertes Protokoll, das sich über Jahrzehnte bewährt hat. Wenn kein tiefes Verständnis von HTTP selbst vorhanden ist, kann REST nicht beurteilt werden.
Aber was RPC betrifft – das können Sie. Es reicht aus, seine Spezifikation zu übernehmen. Also brauchst du ? Oder ist es immer noch schwierig, REST? Du entscheidest.
Ich hoffe aufrichtig, dass ich Ihre Zeit nicht verschwendet habe.
Source: habr.com