Sono sicuro che il titolo abbia suscitato una sana reazione: "beh, è ricominciato ..." Ma lascia che attiri la tua attenzione per 5-10 minuti e cercherò di non ingannare le aspettative.
La struttura dell'articolo sarà la seguente: viene presa un'affermazione stereotipata e viene rivelata la "natura" dell'emergere di questo stereotipo. Spero che questo ti permetta di guardare la scelta del paradigma di scambio di dati nei tuoi progetti da una nuova prospettiva.
Per essere chiari su cosa sia RPC, propongo di considerare lo standard . Non c'è chiarezza con REST. E non dovrebbe esserlo. Tutto quello che devi sapere su REST è che è indistinguibile da .
Le richieste RPC sono più veloci ed efficienti perché consentono di effettuare richieste batch.
Il punto è che in RPC è possibile chiamare più procedure contemporaneamente in una richiesta. Ad esempio, crea un utente, aggiungigli un avatar e iscrivilo ad alcuni argomenti nella stessa richiesta. Una sola richiesta, e quanti vantaggi!
In effetti, se hai un solo nodo di backend, sembrerà più veloce con una richiesta batch. Perché tre richieste REST richiederanno tre volte più risorse da un nodo per stabilire connessioni.
Si noti che la prima richiesta nel caso di REST deve restituire un ID utente per effettuare le richieste successive. Il che influisce negativamente anche sul risultato complessivo.
Ma tali infrastrutture possono essere trovate, forse, in soluzioni interne e Enterprise. Come ultima risorsa, in piccoli progetti WEB. Ma le soluzioni WEB a tutti gli effetti, e persino chiamate HighLoad, non dovrebbero essere costruite in questo modo. La loro infrastruttura deve soddisfare i criteri di disponibilità e carico elevati. E il quadro sta cambiando.
Il verde contrassegna i canali di attività dell'infrastruttura nello stesso scenario. Nota come si comporta ora RPC. La richiesta utilizza l'infrastruttura solo su una spalla dal sistema di bilanciamento al back-end. Mentre REST perde ancora alla prima richiesta, ma recupera utilizzando l'intera infrastruttura.
Basta inserire nella sceneggiatura non due richieste di arricchimento, ma, diciamo, cinque o dieci ... e la risposta alla domanda "chi vince adesso?" diventa invisibile.
Propongo di dare uno sguardo più ampio al problema. Il diagramma mostra come vengono utilizzati i canali dell'infrastruttura, ma l'infrastruttura non è limitata ai canali. Le cache sono un componente importante di un'infrastruttura altamente caricata. Prendiamo ora alcuni artefatti utente. Ripetutamente. Diciamo 32 volte.
Guarda come l'infrastruttura su RPC si è notevolmente "ripresa" per soddisfare i requisiti di carico elevato. Il fatto è che REST utilizza tutta la potenza del protocollo HTTP, a differenza di RPC. Nel diagramma sopra, questo potere è realizzato attraverso il metodo di richiesta - GET.
I metodi HTTP, tra le altre cose, hanno strategie di memorizzazione nella cache. Puoi trovarli nella documentazione all'indirizzo . Per RPC vengono utilizzate richieste POST, che non sono considerate idempotenti, ovvero la ripetizione ripetuta delle stesse richieste POST può restituire risultati diversi (ad esempio, dopo l'invio di ogni commento, verrà visualizzata un'altra copia di questo commento) ().
Di conseguenza, RPC non è in grado di utilizzare in modo efficiente le cache dell'infrastruttura. Ciò porta al fatto che devi "importare" le soft cache. Il diagramma mostra Redis in questo ruolo. La soft cache, a sua volta, richiede un ulteriore livello di codice e notevoli cambiamenti nell'architettura da parte dello sviluppatore.
Calcoliamo ora quante richieste REST e RPC "hanno partorito" nell'infrastruttura in esame?
richieste
Posta in arrivo
per eseguire il backend
al DBMS
alla cache morbida (Redis)
TOTALE
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Rispetto al primo schema, la differenza è sorprendente. Ora il vantaggio di REST diventa evidente. Ma suggerisco di non fermarci qui. L'infrastruttura sviluppata include CDN. Spesso risolve anche il problema di contrastare gli attacchi DDoS e DoS. Noi abbiamo:
Qui per RPC tutto diventa abbastanza deplorevole. RPC non è semplicemente in grado di delegare il lavoro a un carico CDN. Possiamo solo sperare in sistemi per contrastare gli attacchi.
È possibile finire qui? E ancora, no. I metodi HTTP, come accennato in precedenza, hanno la loro "magia". E non per niente il metodo GET è totalmente utilizzato su Internet. Si noti che questo metodo è in grado di accedere a una parte di contenuto, è in grado di impostare condizioni che gli elementi dell'infrastruttura possono interpretare prima di passare il controllo al codice e così via. Tutto ciò consente di creare infrastrutture flessibili e gestibili in grado di gestire richieste davvero grandi. E in RPC questo metodo è ... ignorato.
Allora perché il mito secondo cui le richieste batch (RPC) sono più veloci è così persistente? Personalmente, mi sembra che la maggior parte dei progetti semplicemente non raggiunga un tale livello di sviluppo quando REST è in grado di mostrare la sua forza. Inoltre, nei piccoli progetti, è più disposto a mostrare la sua debolezza.
La scelta di REST o RPC non è una scelta volontaria di un individuo in un progetto. Questa scelta deve soddisfare i requisiti del progetto. Se il progetto è in grado di spremere tutto ciò che può veramente da REST e ne ha davvero bisogno, allora REST è un'ottima scelta.
Ma se per ottenere tutti i profitti REST, è necessario assumere devops per il progetto per ridimensionare rapidamente l'infrastruttura, amministratori per gestire l'infrastruttura, un architetto per progettare tutti i livelli del servizio WEB... e il progetto, al stesso tempo, vende tre confezioni di margarina al giorno ... mi fermerei da RPC, tk. questo protocollo è più utilitaristico. Non richiede una conoscenza approfondita del funzionamento delle cache e dell'infrastruttura, ma concentrerà lo sviluppatore su chiamate semplici e comprensibili alle procedure di cui ha bisogno. Gli affari saranno felici.
Le richieste RPC sono più affidabili perché possono eseguire richieste batch all'interno di una singola transazione
Questa proprietà di RPC è un vantaggio decisivo, perché è facile mantenere il database in uno stato coerente. Ma con REST diventa sempre più difficile. Le richieste possono arrivare in modo incoerente a diversi nodi back-end.
Questo "difetto" di REST è il rovescio del suo vantaggio sopra descritto: la capacità di utilizzare in modo efficiente tutte le risorse dell'infrastruttura. Se l'infrastruttura è progettata male, e ancora di più se l'architettura del progetto e il database in particolare sono progettati male, allora questo è davvero un grosso problema.
Ma le richieste batch sono affidabili come sembrano? Facciamo un caso: creiamo un utente, arricchiamo il suo profilo con qualche descrizione e gli inviamo un SMS con una secret per completare la registrazione. Quelli. tre chiamate in una richiesta batch.
Consideriamo un diagramma. Presenta un'infrastruttura con elementi di alta disponibilità. Esistono due canali di comunicazione indipendenti con i gateway SMS. Ma... cosa vediamo? Quando si invia un SMS, si verifica un errore 503: il servizio è temporaneamente non disponibile. Perché l'invio di SMS è impacchettato in una richiesta batch, quindi l'intera richiesta deve essere annullata. Le azioni nel DBMS vengono annullate. Il client riceve un errore.
Il prossimo tentativo è una lotteria. O la richiesta cadrà nuovamente sullo stesso nodo e restituirà nuovamente un errore, oppure sarai fortunato e verrà eseguita. Ma la cosa principale è che almeno una volta la nostra infrastruttura ha già funzionato invano. C'era un carico, ma non c'era profitto.
Ok, immaginiamo di esserci tesi (!) e di aver pensato all'opzione quando la richiesta può essere parzialmente eseguita con successo. E il resto, proveremo di nuovo a eseguire dopo un certo intervallo di tempo (Cosa? Decide il fronte?). Ma la lotteria è rimasta la stessa. La richiesta di invio di un SMS con probabilità 50/50 fallirà nuovamente.
D'accordo, dal lato client, il servizio non sembra affidabile come vorremmo ... ma per quanto riguarda REST?
REST utilizza nuovamente la "magia" di HTTP, ma ora con codici di risposta. Quando si verifica un errore 503 sul gateway SMS, il back-end trasmette questo errore al sistema di bilanciamento. Il bilanciatore che riceve questo errore, e senza interrompere la connessione con il client, invia la richiesta a un altro nodo, che elabora correttamente la richiesta. Quelli. il cliente riceve il risultato atteso e l'infrastruttura conferma il suo alto titolo di "altamente accessibile". L'utente è felice.
E ancora, non è tutto. Il bilanciatore non ha ricevuto solo un codice di risposta 503. Secondo lo standard, è auspicabile fornire questo codice con l'intestazione "Riprova dopo" durante la risposta. Il titolo chiarisce al bilanciatore che questo nodo non deve essere disturbato su questa rotta durante il tempo specificato. E le successive richieste di invio di SMS verranno inviate immediatamente al nodo che non ha problemi con il gateway SMS.
Come possiamo vedere, l'affidabilità di JSON-RPC è sopravvalutata. In effetti, è più facile organizzare la coerenza nel database. Ma la vittima, in questo caso, sarà l'affidabilità del sistema nel suo complesso.
La conclusione è in gran parte simile a quella precedente. Quando l'infrastruttura è semplice, l'ovvietà di JSON-RPC è sicuramente un vantaggio. Se il progetto prevede un'elevata disponibilità con un carico elevato, REST sembra una soluzione più corretta, anche se più complessa.
REST Soglia di ingresso inferiore
Penso che l'analisi di cui sopra, sfatando gli stereotipi consolidati su RPC, abbia mostrato chiaramente che la soglia di ingresso per REST è indubbiamente superiore a quella per RPC. Ciò è dovuto alla necessità di una profonda comprensione del lavoro di HTTP, nonché alla necessità di avere una conoscenza sufficiente degli elementi dell'infrastruttura esistente che possono e devono essere utilizzati nei progetti WEB.
Allora perché molte persone pensano che REST sarà più semplice? La mia opinione personale è che questa apparente semplicità derivi dal REST che si manifesta. Quelli. REST non è un protocollo, ma un concetto… REST non ha uno standard, ci sono alcune linee guida… REST non è più complicato di HTTP. L'apparente libertà e anarchia attirano "artisti liberi".
Indubbiamente, REST non è più complicato di HTTP. Ma lo stesso HTTP è un protocollo ben congegnato che ha dimostrato il suo valore per decenni. Se non c'è una profonda comprensione dell'HTTP stesso, REST non può essere giudicato.
Ma riguardo a RPC, puoi. È sufficiente prendere la sua specifica. Quindi hai bisogno ? O è ancora complicato REST? Tu decidi.
Spero sinceramente di non avervi fatto perdere tempo.
Fonte: habr.com