Ich bin mir sicher, dass der Titel eine gesunde Reaktion hervorgerufen hat – "na, jetzt geht es wieder los..." Aber erlauben Sie mir, Ihre Aufmerksamkeit für 5–10 Minuten zu beanspruchen, und ich werde versuchen, Ihre Erwartungen nicht zu enttäuschen.
Die Struktur des Artikels wird folgendermaßen aussehen: Ein stereotypisches Statement wird aufgenommen und die "Natur" der Entstehung dieses Stereotyps wird erläutert. Ich hoffe, dies wird Ihnen eine neue Perspektive auf die Wahl der Paradigmen für den Datenaustausch in Ihren Projekten bieten.
Um Klarheit darüber zu schaffen, was RPC ist, schlage ich vor, den Standard . Mit REST gibt es keine Klarheit. Und das sollte es auch nicht. Alles, was man über REST wissen muss – es ist nicht von .
RPC-Anfragen sind schneller und effizienter, weil sie Batch-Anfragen ermöglichen.
Es geht darum, dass man in RPC mit einer einzigen Anfrage mehrere Verfahren gleichzeitig aufrufen kann. Zum Beispiel einen Benutzer erstellen, ihm ein Avatar hinzufügen und ihn in derselben Anfrage für bestimmte Themen anmelden. Nur eine Anfrage, und wie viel Nutzen daraus gezogen werden kann!
Tatsächlich wird es schneller erscheinen, wenn Sie nur einen Backend-Knoten haben, weil drei REST-Anfragen dreimal mehr Ressourcen von diesem Knoten für die Verbindungsherstellung benötigen.
Bitte beachten Sie, dass die erste Anfrage bei REST den Benutzeridentifikator zurückgeben muss, um folgende Anfragen auszuführen. Dies hat auch einen negativen Einfluss auf das Gesamtergebnis.
Solche Infrastrukturen findet man jedoch nur in Inhouse-Lösungen und im Enterprise-Bereich. Im schlimmsten Fall in kleinen WEB-Projekten. Vollständige WEB-Lösungen, die auch als HighLoad bezeichnet werden, sollten jedoch nicht so aufgebaut werden. Ihre Infrastruktur muss den Kriterien für hohe Verfügbarkeit und Belastbarkeit entsprechen. Und das Bild ändert sich.
Die aktiven Infrastrukturkanäle sind im Szenario grün markiert. Achten Sie darauf, wie sich RPC jetzt verhält. Die Anfrage nutzt die Infrastruktur nur über einen Arm von der Lastverteilung zum Backend. Während REST nach wie vor im ersten Request unterlegen ist, holt es jedoch durch die Nutzung der gesamten Infrastruktur den Rückstand auf.
Wenn wir ins Szenario nicht zwei Anfragen zur Anreicherung, sondern sagen wir fünf oder zehn eingeben… wird die Antwort auf die Frage „Wer gewinnt jetzt?“ nicht mehr offensichtlich.
Ich schlage vor, das Problem aus einer breiteren Perspektive zu betrachten. Das Diagramm zeigt, wie die Infrastrukturkanäle genutzt werden, aber die Infrastruktur beschränkt sich nicht nur auf diese Kanäle. Ein wichtiger Bestandteil einer stark beanspruchten Infrastruktur sind Caches. Lassen Sie uns nun ein Benutzerartefakt generieren. Mehrmals. Sagen wir 32 Mal.
Sehen Sie, wie sich die Infrastruktur bei RPC spürbar verbessert hat, um den Anforderungen hoher Lasten gerecht zu werden. Der Grund dafür ist, dass REST die gesamte Leistungsfähigkeit des HTTP-Protokolls nutzt, im Gegensatz zu RPC. In dem dargestellten Diagramm wird diese Leistungsfähigkeit durch die Anfragemethode – GET – realisiert.
HTTP-Methoden haben unter anderem Strategien für das Caching. Eine Einführung in diese finden Sie in der Dokumentation auf . Für RPC werden POST-Anfragen verwendet, die nicht als idempotent gelten, das heißt, die mehrfache Wiederholung derselben POST-Anfragen kann unterschiedliche Ergebnisse zurückgeben (zum Beispiel wird nach jeder Kommentarübermittlung eine neue Kopie dieses Kommentars erstellt).).
Daher kann RPC die Infrastruktur-Caches nicht effizient nutzen. Dies führt dazu, dass Software-Caches bereitgestellt werden müssen. In diesem Diagramm wird Redis für diese Rolle dargestellt. Der Software-Cache erfordert wiederum von den Entwicklern eine zusätzliche Code-Schicht und erhebliche Änderungen in der Architektur.
Lasst uns nun berechnen, wie viele Anfragen REST und RPC in der betrachteten Infrastruktur generiert haben.
Abfragen
Eingang
zum Backend
zur Datenbank
zum Software-Cache (Redis)
GESAMT
REST
1/32*
1
1
0
3 / 35
RPC
32
32
1
31
96
[*] im besten Fall (wenn der lokale Cache verwendet wird) 1 Anfrage (eine!), im schlimmsten Fall 32 eingehende Anfragen.
Im Vergleich zum ersten Diagramm ist der Unterschied frappierend. Nun wird der Vorteil von REST offensichtlich. Doch lassen Sie uns nicht bei dem Erreichten stehen bleiben. Eine entwickelte Infrastruktur umfasst auch ein CDN. Oft löst es auch das Problem der Abwehr von DDoS- und DoS-Attacken. Das Ergebnis ist:
Hier wird es für RPC wirklich schwierig. RPC ist einfach nicht in der Lage, die Arbeit mit der Last des CDN zu delegieren. Man bleibt nur auf die Systeme zur Abwehr von Angriffen angewiesen.
Kann man dabei enden? Und nochmals, nein. Die HTTP-Methoden haben, wie bereits erwähnt, ihre eigene „Magie“. Und nicht umsonst ist die GET-Methode die am häufigsten genutzte im Internet. Beachten Sie, dass diese Methode in der Lage ist, auf Teile des Inhalts zuzugreifen und Bedingungen zu setzen, die infrastrukturelle Elemente interpretieren können, noch bevor die Kontrolle an Ihren Code übergeben wird, usw. All dies ermöglicht die Schaffung flexibler, verwaltbarer Infrastrukturen, die in der Lage sind, tatsächlich große Anfragenströme zu bewältigen. In RPC wird diese Methode jedoch ignoriert.
Warum hält sich der Mythos, dass Batch-Anfragen (RPC) schneller sind? Persönlich denke ich, dass die meisten Projekte einfach nicht den Entwicklungsstand erreichen, an dem REST seine Stärken wirklich zeigen kann. Darüber hinaus zeigt es in kleinen Projekten eher seine Schwächen.
Die Wahl zwischen REST und RPC ist keine willkürliche Entscheidung einer einzelnen Person im Projekt. Diese Wahl sollte den Anforderungen des Projekts entsprechen. Wenn das Projekt in der Lage ist, alles Herauszuholen, was REST tatsächlich kann, und das wirklich benötigt wird, dann wird REST eine hervorragende Wahl sein.
Aber wenn dafür, um alle Vorteile von REST zu nutzen, DevOps für die operative Skalierung der Infrastruktur, Administratoren zur Verwaltung der Infrastruktur und einen Architekten für das Design aller Schichten des WEB-Dienstes eingestellt werden müssen… und das Projekt dabei drei Packungen Margarine pro Tag verkauft… würde ich bei RPC bleiben, da dieses Protokoll utilitaristischer ist. Es erfordert kein tiefes Verständnis von Caches und Infrastruktur und konzentriert den Entwickler auf einfache und klare Aufrufe der benötigten Prozeduren. Das Geschäft wird zufrieden sein.
RPC-Anfragen sind zuverlässiger, da sie Batch-Anfragen innerhalb einer einzigen Transaktion ausführen können.
Dieses Merkmal von RPC ist ein unbestreitbarer Vorteil, da es einfach ist, die Datenbank konsistent zu halten. Bei REST wird es hingegen komplizierter. Anfragen können unregelmäßig an verschiedene Backend-Knoten gesendet werden.
Dieser "Nachteil" von REST ist die Kehrseite seines oben beschriebenen Vorteils — die Fähigkeit, alle Ressourcen der Infrastruktur effizient zu nutzen. Wenn die Infrastruktur schlecht entworfen ist, insbesondere wenn die Architektur des Projekts und der Datenbank schlecht ist, kann das wirklich schmerzhaft sein.
Sind Batch-Anfragen wirklich so zuverlässig, wie sie scheinen? Lassen Sie uns ein Beispiel betrachten: Wir erstellen einen Benutzer, bereichern sein Profil mit einer Beschreibung und senden ihm eine SMS mit einem Geheimnis zur Abschluss der Registrierung. Das heißt, drei Aufrufe in einer Batch-Anfrage.
Betrachten wir das Schema. Es zeigt eine Infrastruktur mit Elementen hoher Verfügbarkeit. Es gibt zwei unabhängige Kommunikationskanäle mit SMS-Gateways. Aber… was sehen wir? Beim Senden der SMS tritt ein Fehler 503 auf – der Dienst ist vorübergehend nicht verfügbar. Da das Senden der SMS in einer Batch-Anfrage verpackt ist, muss die gesamte Anfrage zurückgerollt werden. Die Aktionen in der Datenbank werden annulliert. Der Kunde erhält einen Fehler.
Der nächste Versuch ist wie ein Glücksspiel. Entweder landet die Anfrage wieder auf demselben Knoten und gibt erneut einen Fehler zurück, oder wir haben Glück und sie wird erfolgreich ausgeführt. Aber das Wichtigste ist, dass unsere Infrastruktur bereits einmal umsonst gearbeitet hat. Es gab Last, aber keinen Gewinn.
Gut, stellen wir uns vor, wir haben uns angestrengt (!) und einen Plan ausgearbeitet, bei dem die Anfrage teilweise erfolgreich ausgeführt werden kann. Den Rest werden wir erneut nach einer bestimmten Zeit versuchen (Wann? Das entscheidet das Frontend?). Aber das Glücksspiel bleibt bestehen. Die Anfrage zum Senden der SMS wird mit einer Wahrscheinlichkeit von 50/50 erneut fehlschlagen.
Zugegeben, aus der Sicht des Kunden wirkt der Service nicht so zuverlässig, wie man es sich wünschen würde… und wie sieht es mit REST aus?
REST nutzt erneut die „Magie“ von HTTP, jedoch jetzt mit Antwortcodes. Wenn ein Fehler 503 beim SMS-Gateway auftritt, überträgt das Backend diesen Fehler an den Load Balancer. Der Load Balancer, der diesen Fehler erhält, beendet die Verbindung zum Kunden nicht, sondern leitet die Anfrage an einen anderen Knoten weiter, der die Anfrage erfolgreich bearbeitet. Das bedeutet, der Kunde erhält das erwartete Ergebnis, und die Infrastruktur bestätigt ihren hohen Status als „hochverfügbar“. Der Benutzer ist zufrieden.
Und das ist noch nicht alles. Der Load Balancer hat nicht einfach nur einen Antwortcode 503 erhalten. Dieser Code sollte gemäß Standard idealerweise mit dem Header „Retry-After“ versehen werden. Der Header signalisiert dem Load Balancer, dass er diesen Knoten auf diesem Weg für die angegebene Zeit nicht belästigen sollte. Die folgenden Anfragen zum Versenden von SMS werden direkt an einen Knoten gesendet, der keine Probleme mit dem SMS-Gateway hat.
Wie wir sehen können, ist die Zuverlässigkeit von JSON-RPC überschätzt. Tatsächlich ist es einfacher, die Konsistenz in der Datenbank zu gewährleisten. Doch wird in diesem Fall die Zuverlässigkeit des gesamten Systems in Mitleidenschaft gezogen.
Die Ausgabe ähnelt in vielerlei Hinsicht der vorherigen. Wenn die Infrastruktur einfach ist, ist die Klarheit von JSON-RPC zweifellos ein Vorteil. Wenn das Projekt jedoch hohe Verfügbarkeit mit hoher Last erfordert, scheint REST die passendere, wenn auch komplexere Lösung zu sein.
Die Einstiegsbarriere für REST ist niedriger.
Ich denke, die obige Analyse, die gängige Stereotype über RPC widerlegt, hat deutlich gezeigt, dass die Einstiegsbarriere für REST definitiv höher ist als für RPC. Dies liegt an der Notwendigkeit eines tiefen Verständnisses der Funktionsweise von HTTP sowie dem Bedarf an ausreichendem Wissen über vorhandene Infrastrukturkomponenten, die in WEB-Projekten verwendet werden können und sollten.
Warum denken also viele, dass REST einfacher ist? Meiner persönlichen Meinung nach kommt diese scheinbare Einfachheit aus den Manifesten von REST. Das heißt, REST ist kein Protokoll, sondern ein Konzept… REST hat keinen Standard, sondern einige Empfehlungen… REST ist nicht komplizierter als HTTP. Die scheinbare Freiheit und Anarchie ziehen "freie Künstler" an.
Zweifellos ist REST nicht schwieriger als HTTP. Aber HTTP selbst ist ein gut durchdachtes Protokoll, das sich über Jahrzehnte bewährt hat. Ohne ein tiefes Verständnis von HTTP kann man auch über REST nicht urteilen.
Über RPC hingegen kann man urteilen. Man muss nur seine Spezifikation zur Hand nehmen. Brauchen Sie also ? Или все же хитрый REST? Решать вам.
Ich hoffe aufrichtig, dass ich Ihre Zeit nicht umsonst in Anspruch genommen habe.
Quelle: habr.com
