Sono sicuro che il titolo abbia suscitato una reazione sana — “Ecco che comincia di nuovo…” Ma permettetemi di catturare la vostra attenzione per 5-10 minuti e cercherò di non deludere le aspettative.
La struttura dell'articolo sarà la seguente: si prende un'affermazione stereotipata e si svela la “natura” dell'emergere di questo stereotipo. Spero che questo consenta di guardare alla scelta della paradigma di scambio dati nei vostri progetti sotto una nuova luce.
Per avere chiarezza su cosa sia RPC, propongo di esaminare lo standard . Con REST non c'è chiarezza. E non deve esserci. Tutto ciò che serve sapere su REST è che è indistinguibile da .
Le richieste RPC sono più veloci ed efficienti, perché consentono di effettuare batch requests.
Si tratta del fatto che in RPC è possibile eseguire in un'unica richiesta la chiamata a più procedure contemporaneamente. Ad esempio, creare un utente, aggiungervi un avatar e nella stessa richiesta iscriverlo a alcuni argomenti. Un'unica richiesta, ma quanta utilità!
In effetti, se avete solo un nodo backend, questo sembrerà più veloce con una richiesta batch. Perché tre richieste REST richiederanno tre volte più risorse da un singolo nodo per stabilire le connessioni.
Si prega di notare che la prima richiesta nel caso di REST deve restituire l'identificativo dell'utente, per poter eseguire le richieste successive. Questo influisce negativamente sul risultato complessivo.
Tuttavia, tali infrastrutture si possono incontrare, se non altro, nelle soluzioni in-house e per le aziende. Al massimo, in piccoli progetti WEB. Ma non si dovrebbe costruire soluzioni WEB complete, definite HighLoad in questo modo. La loro infrastruttura deve soddisfare i criteri di alta disponibilità e carico. E la situazione cambia.
I canali di attività dell'infrastruttura sono evidenziati in verde nello stesso scenario. Si noti come ora si comporta RPC. La richiesta utilizza l'infrastruttura solo su un lato dal bilanciatore al backend. Mentre REST perde ancora nella prima richiesta, recupera il tempo perduto utilizzando l'intera infrastruttura.
Basta introdurre nello scenario non due richieste di arricchimento, ma ad esempio cinque o dieci… e la risposta alla domanda “chi vince ora?” diventa meno ovvia.
Ti propongo di esaminare più in profondità il problema. Nello schema si vede come vengono utilizzati i canali dell'infrastruttura, ma l'infrastruttura non si limita ai canali. Una componente importante di un'infrastruttura ad alto carico sono le cache. Adesso otteniamo qualche artefatto utente. Diverse volte. Diciamo 32 volte.
Guarda come l'infrastruttura su RPC è visibilmente "migliorata" per rispondere alle esigenze di un alto carico. La questione è che REST sfrutta appieno la potenza del protocollo HTTP, a differenza di RPC. Nel diagramma fornito, questa potenza è realizzata attraverso il metodo di richiesta — GET.
I metodi HTTP, tra l'altro, hanno strategie di caching. Puoi familiarizzare con esse nella documentazione su . Per RPC si utilizzano richieste POST, che non sono considerate idempotenti, il che significa che la ripetizione di richieste POST identiche può restituire risultati diversi (per esempio, dopo ogni invio di un commento, apparirà una nuova copia di questo commento).).
Di conseguenza, RPC non è in grado di utilizzare efficacemente le cache infrastrutturali. Questo porta alla necessità di utilizzare cache software. Nello schema, Redis è rappresentato in questo ruolo. La cache software, a sua volta, richiede agli sviluppatori uno strato di codice aggiuntivo e notevoli modifiche all'architettura.
Ora calcoliamo quanti richieste ha generato REST e RPC nell'infrastruttura considerata?
Richieste
In arrivo
al backend
al DBMS
alla cache software (Redis)
TOTALE
REST
1/32*
1
1
0
3 / 35
richiesta RPC
32
32
1
31
96
[*] nel miglior caso (se la cache locale viene utilizzata) 1 richiesta (una!), nel peggiore 32 richieste in arrivo.
Rispetto al primo schema la differenza è notevole. Ora diventa evidente il vantaggio di REST. Ma propongo di non fermarci qui. Un'infrastruttura avanzata include un CDN. Spesso risolve anche il problema di contrastare attacchi DDoS e DoS. Otteniamo:
A questo punto, per RPC tutto diventa abbastanza tragico. RPC non è in grado di delegare il lavoro con il carico del CDN. Resta solo da sperare nei sistemi di mitigazione degli attacchi.
Si può finire qui? E di nuovo, no. I metodi HTTP, come già detto, hanno la loro 'magia'. Non è un caso che il metodo GET sia ampiamente utilizzato in Internet. È importante notare che questo metodo può accedere a parte del contenuto, può stabilire condizioni che possono essere interpretate dai componenti dell'infrastruttura prima di passare il controllo al tuo codice, e così via. Tutto ciò consente di creare infrastrutture flessibili e gestibili, capaci di gestire flussi di richieste davvero elevati. Tuttavia, in RPC questo metodo... è ignorato.
Allora perché il mito persiste che le richieste batch (RPC) siano più veloci? Personalmente, penso che la maggior parte dei progetti non raggiunga mai un livello di sviluppo in cui REST possa mostrare la sua forza. Inoltre, nei progetti più piccoli, tende a mostrare le sue debolezze.
La scelta tra REST o RPC non è una decisione arbitraria di una singola persona nel progetto. Questa scelta deve rispondere alle esigenze del progetto. Se il progetto è in grado di sfruttare al massimo ciò che REST può offrire, e ciò è davvero necessario, allora REST sarà un'ottima scelta.
Ma se per ottenere tutti i vantaggi di REST sarà necessario assumere DevOps per scalare rapidamente l'infrastruttura, amministratori per gestire l'infrastruttura, un architetto per progettare tutti i livelli del servizio WEB... e il progetto, nel contempo, vende solo tre confezioni di margarina al giorno... io mi fermerei a RPC, poiché questo protocollo è più utilitario. Non richiede una profonda conoscenza dei meccanismi di caching e dell'infrastruttura, e consente allo sviluppatore di concentrarsi su chiamate semplici e chiare delle procedure di cui ha bisogno. Gli affari saranno soddisfatti.
Le richieste RPC sono più affidabili perché possono eseguire richieste batch all'interno di un'unica transazione.
Questa caratteristica di RPC è senza dubbio un vantaggio, poiché mantiene facilmente il database in uno stato consistente. Al contrario, con REST la situazione è più complicata. Le richieste possono arrivare in modo non sequenziale su nodi backend diversi.
Questo "svantaggio" di REST è il rovescio della medaglia del suo vantaggio descritto sopra: la capacità di utilizzare in modo efficiente tutte le risorse dell'infrastruttura. Se l'infrastruttura è mal progettata, e ancor di più, se l'architettura del progetto e del database in particolare è scadente, allora si tratta davvero di un grande problema.
Ma sono davvero affidabili le richieste batch come sembrano? Consideriamo il seguente caso: creiamo un utente, arricchiamo il suo profilo con una descrizione e inviamo un SMS con un segreto per completare la registrazione. Quindi, tre chiamate in una richiesta batch.
Esaminiamo lo schema. Qui è rappresentata l'infrastruttura con elementi di alta disponibilità. Ci sono due canali di comunicazione indipendenti con gateway SMS. Ma... cosa vediamo? Durante l'invio di SMS si verifica un errore 503: servizio temporaneamente non disponibile. Poiché l'invio di SMS è incapsulato in una richiesta batch, l'intera richiesta deve essere annullata. Le azioni nel DB vengono annullate. Il cliente riceve un errore.
Il tentativo successivo è una lotteria. O la richiesta andrà di nuovo sulla stessa nod e restituirà nuovamente un errore, oppure sarà fortunato e verrà eseguita. Ma la cosa principale è che almeno una volta la nostra infrastruttura ha già lavorato invano. C'era un carico, ma nessun profitto.
Bene, immaginiamo di aver fatto uno sforzo (!) e di aver pensato a una soluzione in cui la richiesta possa essere eseguita parzialmente con successo. E il resto, proveremo nuovamente a eseguirlo dopo un certo intervallo di tempo (Quale? Decide il front-end?). Ma la lotteria rimane. La richiesta di invio SMS ha una probabilità del 50/50 di fallire di nuovo.
Ammettiamo che, dal punto di vista del cliente, il servizio non sembra così affidabile come si vorrebbe… e cosa dire del REST?
Il REST utilizza ancora la “magia” dell'HTTP, ma ora con i codici di risposta. Quando si verifica un errore 503 sul gateway SMS, il backend trasmette questo errore al bilanciatore di carico. Il bilanciatore, ricevendo questo errore e senza interrompere la connessione con il cliente, reindirizza la richiesta a un altro nodo, che gestisce con successo la richiesta. In altre parole, il cliente riceve il risultato atteso, mentre l'infrastruttura conferma il suo elevato titolo di “alta disponibilità”. L'utente è soddisfatto.
E non è tutto. Il bilanciatore non ha solo ricevuto il codice di risposta 503. Questo codice, secondo lo standard, dovrebbe essere accompagnato dall'intestazione “Retry-After”. L'intestazione informa il bilanciatore che non è opportuno contattare questo nodo lungo questo percorso per un certo periodo di tempo. Pertanto, le successive richieste di invio SMS saranno indirizzate immediatamente a un 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, in questo caso, la vittima sarà l'affidabilità del sistema nel suo complesso.
L'output è in gran parte simile a quello precedente. Quando l'infrastruttura è semplice, la chiarezza di JSON-RPC è sicuramente un vantaggio. Se il progetto prevede alta disponibilità con un carico elevato, REST appare come una soluzione più appropriata, sebbene più complessa.
La barriera d'ingresso per REST è più bassa.
Penso che l'analisi sopra condotta, che sfata i miti consolidati su RPC, abbia chiaramente dimostrato che la barriera d'ingresso per REST è sicuramente più alta rispetto a RPC. Questo è dovuto alla necessità di una profonda comprensione del funzionamento di HTTP, oltre a dover possedere conoscenze sufficienti sugli elementi infrastrutturali esistenti che possono e devono essere applicati nei progetti web.
Allora, perché molti pensano che REST sia più semplice? A mio parere, questa apparente semplicità deriva dai manifesti stessi di REST. Cioè, REST non è un protocollo, ma un concetto… REST non ha uno standard, ci sono alcune raccomandazioni… REST non è più complicato di HTTP. La apparente libertà e anarchia attraggono i “liberi artisti”.
Senza dubbio, REST non è più complesso di HTTP. Ma HTTP è un protocollo ben progettato che ha dimostrato la sua validità per decenni. Se non c'è una comprensione profonda di HTTP stesso, non si può nemmeno giudicare REST.
Ma su RPC — si può. Basta prendere la sua specifica. Quindi, hai davvero bisogno di ? Или все же хитрый REST? Решать вам.
Spero sinceramente di non aver sprecato il tuo tempo.
Fonte: habr.com
