NetCore Netty 框架 BT.Netty.RPC 系列隨講 —（前序） REST API 與 RPC 經典網絡基礎服務架構

        在服務體系架構內，咱們所知道的，有兩種請求模型: Http 請求模型，以及 RPC 請求模型。所以，在一個互聯網請求模型架構上，都是這兩種的請求模型的向互組合.

 

下面給出兩種常見的互聯網經典基礎架構圖：

 

  一：外：HTTP  內：RPC                                                                        二：外：HTTP 內： HTTP

 

                                     

 

下面講講這兩種網絡架構的優缺點： 這裏只發表我我的的見解。若是各位大神，若是有其餘見解的話，那麼也可隨意留言：

 

共同點： HTTP 主外，HTTP 主外有個兩個最大的優勢

 

    1：對於前端框架的易用性和對異構系統的對接性更較強. 也就是說HTTP 的跨平臺性跟跨協做方面來的更  加合適, 緣由爲啥：緣由 就是大部分同窗都知道HTTP 協議嘛。

 

     2：對於HTTP 來講，外部的客戶數量是不可控的，HTTP 的短連接，就很好的解決這方面服務的線程資源佔用的問題。 HTTP 本來初衷就是一次請求，一個線程，一次會話的模型。 而 RPC ，則是長鏈接模型。客戶端不活動，也會佔用服務的TCP  線程鏈接數。

 

兩張圖的不一樣之處在於：

 

圖一：內部服務集羣採用RPC,   圖二內部集羣採用HTTP。 這二者都有存在大廠中在， 問題仁者見仁，智者見智 

 

內部採用RPC的優勢：效率高，傳輸快. 而RPC 爲何會效率高，傳輸快： 這就講下RPC 與HTTP 本質上的區別：

 

 http協議是應用層協議，HTTP協議位於TCP/IP協議棧的應用層。基於HTTP協議的客戶/服務器模式的信息交換過程，分四個過程：創建鏈接、發送請求信息、發送響應信息、關閉鏈接。

 

而 RPC(Remote Procedure Call Protocol) 遠過程調用協議,在OSI網絡通訊模型中，RPC跨越了傳輸層和應用層。RPC信息協議由兩個不一樣結構組成：調用信息和答覆信息. 所以 在RPC 的協議包通常狀況下都是本身定義，本身封裝，封包。正是由於RPC 穿越了OSI 的 傳輸層與應用層，使得它的效率更高，傳輸更快，也是正是應爲RPC 的 協議包能夠自由定義，

 

所以，它的網絡傳輸載請求單位體積就能夠變得很是小, 並不像HTTP協議包臃腫肥大。可是也正由於如此，RPC 本質的維護成本以及開發成原本的更高。從另外個角度講，HTTP 的對於公司角度而言：服務的迭代以及開發成原本的更加快捷，方便。

 

    我的在內部局域網內服務羣集方面也是採用 HTTP ( 考慮到公司的開發協做成本方面，還有老服務遺留下來的歷史緣由）。  可是.NETCORE NETTY 仍是一個很是棒的實現RPC 底層框架。所以仍是值得咱們去發現。