我之前在傳統IT公司幹活，後來來了網際網路，感受到了很多不同，其中有一點就是兩者使用到的技術有一些差別。比如說分散式呼叫技術。

我在的這家公司內部的服務架構是基於Thrift的，服務基於Thrift進行釋出，以至於很多人沒有聽過、使用過Web Service。

話說傳統IT傳了很多年的SOA就是基於Web Service，已經有了一整套完整的理論和產品進行支援，網際網路竟然很多沒涉及過。後來想了想，也是，傳統IT更多做的是各種資源的整合，偏重各種異構，遺留系統整合的複雜度，對效率要求不高。網際網路則是對效率要求到了極致，內部系統使用Web Service效能跟不上。而且現在對外發布的服務有了更優的REST，使用Web Service的場景也沒那麼多。

我用一個比較大的詞“分散式呼叫“來表示一臺機器對另外一臺機器的訪問。分散式這個東東說白了就是隨著技術和業務的發展，一臺單獨機器的計算，儲存能力不能夠滿足日益增長的IT業務需求，所以需要把計算，儲存能力擴大到多臺機器上。

分散式呼叫的底層基礎就是網路程式設計，一臺機器向另外一臺機器傳送訊息，另外一臺機器收到訊息後，根據某種協議來做一些事情：

1. 比如進行一個方法的呼叫

2. 比如對某個資源進行操作

分散式呼叫大體上就分為兩類，RPC式的，REST式的，兩者的區別主要是就是：

1. RPC是面向動作的（方法呼叫）

2. REST是面向資源的（URL表示資源，HTTP動詞表示動作）

從變現形式來看，RPC的程式設計模型較重量級，REST的程式設計模型更輕量級

分散式呼叫技術的主要關注點有四個，前面兩點比較常見，最後兩點是我新加的：

1. 採用什麼傳輸協議，TCP, HTTP，還是其他

2. 採用什麼序列化協議(也叫CodeC,編解碼，Marshalling)，比如基於文字的XML（自定義XML，或者SOAP），基於二進位制流（Java序列化，或者自定義序列化協議，比如Thrift, Protobuf, JBoss Marshalling）

3. 採用什麼IO形式，阻塞IO，非阻塞同步IO(select / poll / epoll)，非阻塞非同步IO

4. 採用什麼方式執行，執行在HTTP伺服器上，還是以單獨程序執行

根據第一點來看，RPC陣營如下

1. Web Service採用HTTP協議做傳輸層協議，採用SOAP做應用層協議

2. XML-RPC，採用HTTP協議做傳輸層協議，使用自定義XML做應用層協議

3. JMI, Thrift, Protobuf等都使用TCP做傳輸協議，使用自定義應用層協議

REST直接使用HTTP做應用層協議，使用URL表示資源，使用HTTP動詞表示動作

根據第二點來看，RPC陣營如下

1. Web Service和XML-RPC採用基於文字的XML進行序列化

2. RMI基於Java序列化協議

3. Thrfit, Protobuf等採用了基於二進位制流的序列化協議，比如就是採用訊息頭訊息體的方式傳輸，通過訊息頭來定義長度，從而保證能夠正確讀寫資料

根據第三點來看，隨著NIO的廣泛應用，越來越多的伺服器端支援非阻塞IO，客戶端可以採用同步IO，也可以採用非阻塞IO。

關於第四點，Web Service和REST都執行在HTTP伺服器上，Thrift這樣的都是以單獨程序執行

另外多說幾句Web Service，Web Service採用HTTP層做傳輸協議，採用文字格式的SOAP做應用層協議，相比於基於二進位制流的RPC協議，

好處是：基於HTTP傳輸，採用文字方式，可以穿越防火牆，適合組織內向組織外提供服務

壞處是：基於文字的序列化效率低下，傳輸層基於HTTP，相比於TCP，多了一層協議，效能也有影響，不適合對效能要求高的場景

REST近年來有取代Web Service的趨勢，主要是Web Service的優點它都有，而且更輕量級，採用JSON來序列化資料效能也還可以，程式設計模型更加簡單，適合組織內向組織外發布服務。

組織內部對效能要求高的場景可以使用Thrift這種的RPC技術，基於二進位制流的序列化協議，基於NIO的傳輸協議，效能較高，適合高併發的場景