什么是RPC協(xié)議？

RPC是一種遠程過程調(diào)用的協(xié)議，使用這種協(xié)議向另一臺計算機上的程序請求服務(wù)，不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。

在 RPC 中，發(fā)出請求的程序是客戶程序，而提供服務(wù)的程序是服務(wù)器。

早期單機時代，一臺電腦上運行多個進程，大家各干各的，老死不相往來。假如A進程需要一個畫圖的功能，B進程也需要一個畫圖的功能，程序員就必須為兩個進程都寫一個畫圖的功能。這不是整人么？于是就出現(xiàn)了IPC（Inter-process communication，單機中運行的進程之間的相互通信）。OK，現(xiàn)在A既然有了畫圖的功能，B就調(diào)用A進程上的畫圖功能好了，程序員終于可以偷下懶了。

到了網(wǎng)絡(luò)時代，大家的電腦都連起來了。以前程序只能調(diào)用自己電腦上的進程，能不能調(diào)用其他機器上的進程呢？于是就程序員就把IPC擴展到網(wǎng)絡(luò)上，這就是RPC（遠程過程調(diào)用）了?，F(xiàn)在不僅單機上的進程可以相互通信，多機器中的進程也可以相互通信了。

要知道實現(xiàn)RPC很麻煩呀，什么多線程、什么Socket、什么I/O，都是讓咱們普通程序員很頭疼的事情。于是就有牛人開發(fā)出RPC框架（比如，CORBA、RMI、Web Services、RESTful Web Services等等）。

OK，現(xiàn)在可以定義RPC框架的概念了。簡單點講，RPC框架就是可以讓程序員來調(diào)用遠程進程上的代碼一套工具。有了RPC框架，咱程序員就輕松很多了，終于可以逃離多線程、Socket、I/O的苦海了。

• 簡單的說，RPC就是從一臺機器（客戶端）上通過參數(shù)傳遞的方式調(diào)用另一臺機器（服務(wù)器）上的一個函數(shù)或方法（可以統(tǒng)稱為服務(wù)）并得到返回的結(jié)果。
  

• RPC 會隱藏底層的通訊細節(jié)（不需要直接處理Socket通訊或Http通訊）
  

• RPC 是一個請求響應(yīng)模型。客戶端發(fā)起請求，服務(wù)器返回響應(yīng)（類似于Http的工作方式）
  

• RPC 在使用形式上像調(diào)用本地函數(shù)（或方法）一樣去調(diào)用遠程的函數(shù)（或方法）。
  

• 
  

 一個通用的網(wǎng)絡(luò)RPC框架，它應(yīng)該包括如下功能：

1.具有服務(wù)的分層設(shè)計，借鑒Future/Service/Filter概念
2.具有網(wǎng)絡(luò)的分層設(shè)計，區(qū)分協(xié)議層、數(shù)據(jù)層、傳輸層、連接層
3.獨立的可適配的codec層，可以靈活增加HTTP，Memcache，Redis，MySQL/JDBC，Thrift等協(xié)議的支持。
4.將多年各種遠程調(diào)用High availability的經(jīng)驗融入在實現(xiàn)中，如負(fù)載均衡，failover，多副本策略，開關(guān)降級等。
5.通用的遠程調(diào)用實現(xiàn)，采用async方式來減少業(yè)務(wù)服務(wù)的開銷，并通過future分離遠程調(diào)用與數(shù)據(jù)流程的關(guān)注。
6.具有狀態(tài)查看及統(tǒng)計功能
7.當(dāng)然，最終要的是，具備以下通用的遠程容錯處理能力，超時、重試、負(fù)載均衡、failover……

HTTP是一種超文本傳輸協(xié)議。是WWW瀏覽器和WWW服務(wù)器之間的應(yīng)用層通訊協(xié)議。

RPC協(xié)議與HTTP協(xié)議的區(qū)別

1、RPC是一種API，HTTP是一種無狀態(tài)的網(wǎng)絡(luò)協(xié)議。RPC可以基于HTTP協(xié)議實現(xiàn)，也可以直接在TCP協(xié)議上實現(xiàn)。

2、RPC主要是用在大型網(wǎng)站里面，因為大型網(wǎng)站里面系統(tǒng)繁多，業(yè)務(wù)線復(fù)雜，而且效率優(yōu)勢非常重要的一塊，這個時候RPC的優(yōu)勢就比較明顯了。

HTTP主要是用在中小型企業(yè)里面，業(yè)務(wù)線沒那么繁多的情況下。

3、HTTP開發(fā)方便簡單、直接。開發(fā)一個完善的RPC框架難度比較大。

4、HTTP發(fā)明的初衷是為了傳送超文本的資源，協(xié)議設(shè)計的比較復(fù)雜，參數(shù)傳遞的方式效率也不高。開源的RPC框架針對遠程調(diào)用協(xié)議上的效率會比HTTP快很多。

5、HTTP需要事先通知，修改Nginx/HAProxy配置。RPC能做到自動通知，不影響上游。

6、HTTP大部分是通過Json來實現(xiàn)的，字節(jié)大小和序列化耗時都比Thrift要更消耗性能。RPC，可以基于Thrift實現(xiàn)高效的二進制傳輸。

SEO網(wǎng)站需要選擇怎么樣的的框架，需要多方面的評估，再對兩種開發(fā)框架進行比較，哪種最適合。不要為了使用RPC而每個項目都用RPC，而是要因地制宜，具體情況具體分析。

• RPC
• HTTPS