Ich bin sicher, dass die Überschrift eine gesunde Reaktion hervorrief - „Nun, es hat wieder angefangen ...“ Aber lassen Sie mich 5-10 Minuten lang Ihre Aufmerksamkeit erregen, und ich werde versuchen, die Erwartungen nicht zu täuschen.
Der Artikel wird wie folgt strukturiert: Es wird eine stereotype Aussage getroffen und die „Natur“ der Entstehung dieses Stereotyps wird enthüllt. Ich hoffe, dass Sie damit die Wahl des Datenaustauschparadigmas in Ihren Projekten aus einem neuen Blickwinkel betrachten können.
Um zu verdeutlichen, was RPC ist, schlage ich vor, den JSON-RPC 2.0- Standard zu berücksichtigen. Es gibt keine Klarheit mit REST. Und das sollte nicht sein. Alles, was Sie über REST wissen müssen - es ist nicht von HTTP zu unterscheiden .
RPC-Anforderungen sind schneller und effizienter, da sie Stapelanforderungen ermöglichen.
Der Punkt ist, dass es in RPC möglich ist, mehrere Prozeduren in einer Anforderung aufzurufen. Erstellen Sie beispielsweise einen Benutzer, fügen Sie ihm einen Avatar hinzu, und signieren Sie ihn in derselben Anforderung zu bestimmten Themen. Nur eine Bitte und wie viel Gutes!
In der Tat, wenn Sie nur einen Backend-Knoten haben, wird dies mit einer Batch-Anfrage schneller erscheinen. Weil drei REST-Anforderungen dreimal so viele Ressourcen von einem Knoten erfordern, um Verbindungen herzustellen.
Bitte beachten Sie, dass die erste Anforderung im Fall von REST die Benutzer-ID für nachfolgende Anforderungen zurückgeben sollte. Was sich auch negativ auf das Gesamtergebnis auswirkt.
Solche Infrastrukturen finden sich jedoch möglicherweise in unternehmensinternen Lösungen und in Enterprise. Als letzter Ausweg in kleinen WEB-Projekten. Aber vollwertige WEB-Lösungen, auch HighLoad genannt, sollten nicht so gebaut werden. Ihre Infrastruktur muss die Kriterien für hohe Verfügbarkeit und Arbeitslast erfüllen. Und das Bild ändert sich.
Grün zeigt Infrastrukturaktivitätskanäle im selben Szenario an. Beachten Sie, wie sich RPC jetzt verhält. Die Anfrage nutzt die Infrastruktur nur mit einer Schulter vom Balancer bis zum Backend. REST verliert zwar noch in der ersten Anfrage, gleicht aber verlorene Zeit mit der gesamten Infrastruktur aus.
Es reicht aus, in das Skript nicht zwei Anreicherungsanfragen, sondern beispielsweise fünf oder zehn einzutragen ... und die Antwort auf die Frage „Wer gewinnt jetzt?“ Wird unübersehbar.
Ich schlage vor, das Problem noch umfassender zu betrachten. Das Diagramm zeigt, wie Infrastrukturkanäle verwendet werden, die Infrastruktur ist jedoch nicht auf Kanäle beschränkt. Ein wichtiger Bestandteil einer stark ausgelasteten Infrastruktur sind Caches. Lassen Sie uns jetzt ein Benutzerartefakt besorgen. Mehrmals. Sprich 32 mal.
Sehen Sie, wie sich die Infrastruktur auf dem RPC sichtbar "erholt" hat, um den Anforderungen einer hohen Auslastung gerecht zu werden. Die Sache ist, dass REST im Gegensatz zu RPC die volle Leistung 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 können sie in der HTTP- Dokumentation kennenlernen. Für RPC werden POST-Anforderungen verwendet, die nicht als idempotent gelten. Das heißt, die wiederholte Wiederholung derselben POST-Anforderungen kann unterschiedliche Ergebnisse liefern (z. B. wird nach dem Senden jedes Kommentars eine weitere Kopie dieses Kommentars angezeigt) ( Quelle ).
Folglich können RPCs Infrastruktur-Caches nicht effizient nutzen. Dies führt dazu, dass Sie Software-Caches „importieren“ müssen. Das Diagramm zeigt Redis in dieser Rolle. Der Soft-Cache erfordert vom Entwickler eine zusätzliche Codeschicht und wesentliche Änderungen in der Architektur.
Berechnen wir nun, wie viele Anforderungen REST und RPC in der betreffenden Infrastruktur „hervorgebracht“ haben.
[*] im besten Fall (wenn der lokale Cache verwendet wird) 1 Anfrage (eine!), in den schlechtesten 32 eingehenden Anfragen.
Im Vergleich zum ersten Schema ist der Unterschied auffällig. Der REST-Sieg ist jetzt ersichtlich. Aber ich schlage vor, hier nicht aufzuhören. Die entwickelte Infrastruktur umfasst CDN. Oft löst er auch das Problem der Abwehr von DDoS- und DoS-Angriffen. Wir bekommen:
Hier für RPC wird alles sehr bedauerlich. RPC ist einfach nicht in der Lage, die Arbeit mit dem Laden von CDN zu delegieren. Man kann sich nur auf Systeme verlassen, um Angriffen entgegenzuwirken.
Ist es möglich, dies zu beenden? Und wieder nein. HTTP-Methoden haben, wie oben erwähnt, ihre eigene "Magie". Und aus gutem Grund wird die GET-Methode im Internet vollständig verwendet. Bitte beachten Sie, dass diese Methode auf einen Teil des Inhalts zugreifen kann, Bedingungen festlegen kann, die die Infrastrukturelemente interpretieren können, bevor die Steuerung auf Ihren Code übertragen wird usw. All dies ermöglicht es Ihnen, flexible, verwaltbare Infrastrukturen zu erstellen, die wirklich große Anforderungsströme verarbeiten können. Und in RPC wird diese Methode ... ignoriert.
Warum ist der Mythos so hartnäckig, dass Stapelanforderungen (Batch Requests, RPC) schneller sind? Persönlich scheint es mir, dass die meisten Projekte einen solchen Entwicklungsstand schlichtweg nicht erreichen, wenn REST seine Stärke unter Beweis stellen kann. Darüber hinaus zeigt er in kleinen Projekten eher seine Schwäche.
Die Wahl von REST oder RPC ist keine freiwillige Wahl einer Person im Projekt. Diese Auswahl sollte den Anforderungen des Projekts entsprechen. Wenn das Projekt in der Lage ist, alles aus REST herauszuholen, was wirklich möglich und notwendig ist, ist REST eine ausgezeichnete Wahl.
Aber wenn Sie alle REST-Gewinne erzielen möchten, müssen Sie Entwickler einstellen, um die Infrastruktur schnell zu skalieren, Administratoren, die die Infrastruktur verwalten, einen Architekten, der alle Ebenen des WEB-Dienstes entwirft ... und das Projekt verkauft drei Packungen Margarine pro Tag ... I würde auf RPC da aufhören Dieses Protokoll ist nützlicher. Es erfordert keine gründlichen Kenntnisse über den Betrieb von Caches und der Infrastruktur, sondern konzentriert den Entwickler auf einfache und verständliche Aufrufe der erforderlichen Prozeduren. Das Geschäft wird erfreut sein.
RPC-Anforderungen sind zuverlässiger, da sie Stapelanforderungen in einer einzigen Transaktion ausführen können
Diese Eigenschaft von RPC ist ein klares Plus einfach, die Datenbank in einem konsistenten Zustand zu halten. Bei REST ist jedoch alles komplizierter. Anfragen können inkonsistent auf verschiedenen Backend-Knoten eintreffen.
Dieser „Nachteil“ von REST ist die Kehrseite seiner oben beschriebenen Vorteile - die Fähigkeit, alle Infrastrukturressourcen effektiv zu nutzen. Wenn die Infrastruktur schlecht ausgelegt ist und insbesondere die Architektur des Projekts und die Datenbank schlecht ausgelegt sind, ist dies ein großer Schmerz.
Aber sind Batch-Anfragen so zuverlässig, wie sie scheinen? Schauen wir uns den Fall an: Erstellen Sie einen Benutzer, bereichern Sie sein Profil mit einer Beschreibung und senden Sie ihm eine SMS mit einem Geheimnis, um die Registrierung abzuschließen. Das heißt drei Anrufe in einer Stapelanforderung.
Betrachten wir das Schema. Es präsentiert die Infrastruktur mit Elementen hoher Verfügbarkeit. Es gibt zwei unabhängige Kommunikationskanäle mit SMS-Gateways. Aber ... was sehen wir? Beim Senden von SMS tritt der Fehler 503 auf - der Dienst ist vorübergehend nicht verfügbar. Weil Das Senden von SMS wird in einer Stapelanforderung verpackt. Anschließend sollte die gesamte Anforderung zurückgesetzt werden. Aktionen im DBMS werden abgebrochen. Der Client erhält einen Fehler.
Der nächste Versuch ist eine Lotterie. Entweder geht die Anfrage erneut an denselben Knoten und gibt einen Fehler zurück, oder Sie haben Glück und es wird ausgeführt. Hauptsache ist aber, dass zumindest einmal unsere Infrastruktur bereits vergeblich funktioniert hat. Es gab eine Ladung, aber keinen Gewinn.
Stellen wir uns vor, wir haben uns angespannt (!) Und uns überlegt, wo die Anfrage teilweise erfolgreich abgeschlossen werden könnte. Und den Rest werden wir nach einiger Zeit erneut versuchen zu erfüllen (Welches? Entscheidet die Front?). Aber die Lotterie blieb. Eine Anforderung zum Senden einer SMS mit einer Wahrscheinlichkeit von 50/50 schlägt erneut fehl.
Stimmen Sie zu, dass der Service auf Kundenseite nicht so zuverlässig zu sein scheint, wie wir es uns wünschen ... aber wie steht es mit REST?
REST verwendet wieder HTTP-Magie, jetzt jedoch mit Antwortcodes. Wenn auf dem SMS-Gateway ein 503-Fehler auftritt, sendet das Back-End diesen Fehler an den Balancer. Der Balancer, der diesen Fehler empfängt, sendet die Anforderung an einen anderen Knoten, der die Anforderung erfolgreich verarbeitet, ohne die Verbindung zum Client zu unterbrechen. Das heißt Der Kunde erhält das erwartete Ergebnis und die Infrastruktur bestätigt seinen hohen Rang als „hoch zugänglich“. Der Benutzer ist glücklich.
Und das ist nochmal nicht alles. Der Balancer hat nicht nur den Antwortcode 503 erhalten. Es wird empfohlen, diesen Code beim Antworten mit dem Header "Retry-After" zu versehen. Der Header macht dem Balancer klar, dass Sie diesen Knoten auf dieser Route für eine bestimmte Zeit nicht stören sollten. Und die folgenden SMS-Sendeanfragen wird sofort an einen Knoten gesendet, der keine Probleme mit dem SMS-Gateway hat.
Wie wir sehen können, wird die Zuverlässigkeit von JSON-RPC überbewertet. In der Tat ist es einfacher, die Datenbankkonsistenz zu organisieren. Das Opfer wird in diesem Fall jedoch die Zuverlässigkeit des gesamten Systems sein.
Die Schlussfolgerung ähnelt weitgehend der vorherigen. Wenn die Infrastruktur einfach ist, ist die Offensichtlichkeit von JSON-RPC zweifellos das Plus. Wenn ein Projekt eine hohe Verfügbarkeit mit einer hohen Last beinhaltet, sieht REST nach einer genaueren, wenn auch komplexeren Lösung aus.
REST-Eintrittsschwelle unter
Ich denke, dass die obige Analyse, die die etablierten Stereotype über RPC entlarvt, eindeutig gezeigt hat, dass der Schwellenwert für die Eingabe von REST zweifellos höher ist als in RPC. Dies liegt an der Notwendigkeit eines umfassenden Verständnisses von HTTP sowie an der Notwendigkeit, ausreichende Kenntnisse über die vorhandenen Infrastrukturelemente zu haben, die in WEB-Projekten verwendet werden können und sollten.
Warum denken viele Leute, dass REST einfacher sein wird? Meine persönliche Meinung ist, dass sich diese scheinbare Einfachheit aus dem REST manifestiert. Das heißt REST ist kein Protokoll, sondern ein Konzept ... REST hat keinen Standard, es gibt einige Empfehlungen ... REST ist nicht komplizierter als HTTP. Scheinbare Freiheit und Anarchie ziehen „freie Künstler“ an.
Zweifellos ist REST nicht komplizierter als HTTP. HTTP selbst ist jedoch ein gut entwickeltes Protokoll, das sich seit Jahrzehnten bewährt hat. Wenn es kein tiefes Verständnis von HTTP selbst gibt, kann REST nicht beurteilt werden.
Aber über RPC - das können Sie. Es reicht aus, seine Spezifikation zu übernehmen. Benötigen Sie einen dummen JSON-RPC ? Oder ist es schlauer REST? Es liegt an dir.
Ich hoffe aufrichtig, dass ich Ihre Zeit nicht vergeblich verschwendet habe.