Da molto tempo non ho capito la differenza tra RPC (cioè Remote Procedure Call) e chiamate HTTP. Per favore, permettimi di ridere qui~Ingenuo! Questo articolo introduce brevemente le due forme di architettura C/S, prima di tutto, la loro differenza più essenziale, cioè che RPC si basa principalmente sul protocollo TCP/IP, mentre il servizio HTTP si basa principalmente sul protocollo HTTP; sappiamo tutti che il protocollo HTTP si basa sul protocollo di livello di trasporto TCP, quindi in termini di efficienza, RPC è ovviamente migliore! Parliamo in dettaglio dei servizi RPC e dei servizi HTTP.
Modello OSI a sette livelli di rete
Prima di parlare della differenza tra RPC e HTTP, ritengo necessario comprendere il modello di struttura di rete a sette livelli dell'OSI (anche se in pratica è fondamentalmente a cinque livelli), che può essere suddiviso nei seguenti livelli: (dall'alto verso il basso)
- Il primo livello: livello applicativo. Sono definite interfacce per la comunicazione e la trasmissione dati nella rete;
- Il secondo livello: il livello di rappresentazione. Definire il formato di trasmissione, codificare e decodificare le specifiche dei dati in diversi sistemi, ecc.;
- Il terzo livello: quello della conversazione. Gestire le sessioni utente e controllare l'instaurazione e l'interruzione delle connessioni logiche tra gli utenti.
- Il quarto strato: quello di trasporto. Gestisce la trasmissione end-to-end dei dati nella rete;
- Livello 5: Livello di rete. Definire come i dati vengono trasferiti tra dispositivi di rete;
- Sesto livello: livello di collegamento. I pacchetti dati del livello di rete sopra sono incapsulati in frame dati per facilitare la trasmissione del livello fisico.
- Livello 7: Livello fisico. Questo livello riguarda principalmente la trasmissione di questi dati binari.
Nell'applicazione pratica, non esiste un livello di presentazione e uno di sessione nella struttura protocollare a cinque livelli. Va detto che si fondono con il livello applicativo. Dovremmo concentrarci sul livello applicativo e sul livello trasporto. Poiché HTTP è un protocollo a livello applicativo, mentre TCP è un protocollo a livello trasporto. Bene, ora che conosciamo il modello di stratificazione di rete, possiamo capire meglio perché i servizi RPC sono migliori dei servizi HTTP!
Servizi RPC
I servizi RPC sono introdotti da tre prospettive: architettura RPC, chiamate asincrone sincrone e framework RPC popolari.
Architettura RPC
Parliamo dell'architettura di base dei servizi RPC. Permettetemi di rubare vergognosamente un quadro~ Possiamo vedere chiaramente che un'architettura RPC completa contiene quattro componenti principali, ovvero Client, Server, Client Stub e Server Stub, che possono essere intesi come uno stub. Parliamo separatamente di questi componenti:
- Cliente, il chiamante del servizio.
- Server, il vero fornitore di servizi.
- Il client stub memorizza il messaggio di indirizzo del server, poi impacchettando i parametri della richiesta del client in un messaggio di rete, inviandoli alla parte del servizio da remoto tramite la rete.
- Lo stub lato server riceve i messaggi inviati dal client, li scarta e chiama metodi locali.
La RPC è utilizzata principalmente nelle grandi imprese, perché le grandi imprese dispongono di molti sistemi, linee di business complesse e vantaggi di efficienza sono molto importanti. Questo avviene nello sviluppo effettivo, e i progetti sono generalmente gestiti tramite Maven. Ad esempio, abbiamo un servizio di sistema che elabora gli ordini, prima dichiara tutte le sue interfacce (qui specificamente l'interfaccia in Java), e poi impacchettando l'intero progetto in un pacchetto jar. Perché farlo? Lo scopo principale è ridurre la dimensione del package jar lato client, perché ogni volta che un package viene rilasciato, troppi package jar influenzeranno sempre l'efficienza. Inoltre, disaccoppia client e server per migliorare la portabilità del codice.
Chiamate sincrone e asincrone
Cos'è la chiamata sincrona? Cos'è una chiamata asincrona? Una chiamata sincrona è quando il client attende che la chiamata completi l'esecuzione e restituisce il risultato. Le chiamate asincrone significano che il client non attende che la chiamata venga eseguita per restituire il risultato, ma può comunque ricevere la notifica del risultato di ritorno tramite la funzione di callback. Se al cliente non importa dell'esito, può trasformarsi in una decisione a senso unico. Questo processo è in qualche modo simile alle interfacce chiamabili e eseguibili in Java: quando eseguiamo in modo asincrono, se dobbiamo conoscere il risultato dell'esecuzione, possiamo usare l'interfaccia chiamabile e ottenere le informazioni di risultato dell'esecuzione asincrona tramite la classe Future. Se non ti interessa il risultato di esecuzione, puoi semplicemente usare l'interfaccia eseguibile perché non restituisce il risultato, ovviamente anche il modo chiamabile è possibile, non abbiamo bisogno del futuro.
Framework RPC popolare
Esistono ancora molti framework RPC open source molto popolari. Ecco tre punti salienti:
- gRPC è un software open-source recentemente annunciato da Google, basato sull'ultimo protocollo HTTP 2.0, e supporta molti linguaggi di programmazione comuni. Sappiamo che HTTP 2.0 è una versione aggiornata del protocollo HTTP basata su binario, e i principali browser lo supportano attualmente a un ritmo rapido. Questo framework RPC si basa sul protocollo HTTP e quello sottostante utilizza il supporto del framework Netty.
- Thrift è un progetto open-source per Facebook, principalmente un framework di sviluppo di servizi cross-language. Dispone di un generatore di codice per generare automaticamente un framework di codice di servizio per il file di definizione IDL che definisce. Gli utenti devono solo effettuare uno sviluppo secondario prima di esso, e la comunicazione RPC sottostante è trasparente. Tuttavia, per gli utenti, c'è comunque un certo costo nell'apprendere la lingua di un campo specifico.
- Dubbo è un noto framework RPC open source sviluppato dal gruppo Alibaba, ampiamente utilizzato in molte aziende Internet e applicazioni aziendali. Sia i protocolli che i framework di serializzazione possono essere collegati. La stessa interfaccia remota si basa sull'interfaccia Java e si basa sul framework spring per uno sviluppo semplice. Può essere facilmente confezionato in un unico file ed eseguito in modo indipendente, il che è coerente con il concetto attuale di microservizi.
Ti dico di nascosto che il gruppo non usa più molto il dubbo,Quello più comunemente usato oggi si chiama HSF, noto anche come "così comodo". Potrebbe esserci open source più avanti, quindi aspettiamo e vediamo.
Servizio HTTP
In effetti, molto tempo fa, ho sempre caratterizzato il modello di sviluppo enterprise come sviluppo di interfacce HTTP, che è ciò che spesso chiamiamo interfacce di servizio in stile RESTful. In effetti, è un metodo di comunicazione spesso utilizzato nelle prime fasi della risoluzione delle isole informative in caso di poche interfacce e minore interazione tra sistemi; I vantaggi sono semplici, diretti e facili da sviluppare. Utilizzare il protocollo HTTP pronto a termine per la trasmissione. Ricordiamo che quando facevamo sviluppo background in azienda prima sviluppavamo principalmente interfacce, e dovevamo anche scrivere un grande documento di interfacce, indicando rigorosamente quali erano l'input e l'output. Spiega il metodo di richiesta di ogni interfaccia e le questioni a cui bisogna prestare attenzione nei parametri della richiesta. Ad esempio, il seguente esempio:
INSERISCIhttp://www.httpexample.com/restful/buyer/info/share
L'interfaccia può restituire una stringa JSON o un documento XML. Il client poi elabora queste informazioni restituite, consentendo uno sviluppo più rapido. Tuttavia, per le grandi imprese, quando ci sono molti sottosistemi interni e molte interfacce, i vantaggi del framework RPC sono evidenti: innanzitutto, si tratta di un collegamento lungo e non c'è bisogno di stringere la mano 3 volte come in http ogni volta, riducendo il sovraccarico di rete; in secondo luogo, il framework RPC generalmente dispone di un centro di registrazione e di un monitoraggio e gestione ricchi; La pubblicazione, le interfacce offline, l'espansione dinamica, ecc., sono operazioni non percettive e unificate per il chiamante.
sommario
In generale, i servizi RPC sono principalmente per grandi imprese, mentre i servizi HTTP sono principalmente per piccole imprese, perché RPC è più efficiente e le iterazioni di sviluppo dei servizi HTTP saranno più veloci. In breve, il tipo di framework da scegliere non è determinato da ciò che è popolare sul mercato, ma da valutare completamente l'intero progetto, per confrontare attentamente l'impatto dei due framework di sviluppo sull'intero progetto e infine decidere quale sia il più adatto al progetto. Non dobbiamo usare RPC per ogni progetto solo per il gusto di usarlo, ma adattarci alle condizioni locali e analizzare la situazione specifica.
|
Pubblicato su 01/04/2019 14:02:45
|
|
|
|
