服務之間的調用為啥不直接用 HTTP 而用 RPC？
什么是 RPC?
RPC(Remote Procedure Call)—遠程過程調用，它是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。比如兩個不同的服務 A、B 部署在兩臺不同的機器上，那么服務 A 如果想要調用服務 B 中的某個方法該怎么辦呢?使用 HTTP請求 當然可以，但是可能會比較慢而且一些優化做的并不好。 RPC 的出現就是為了解決這個問題。
RPC原理是什么?
- 服務消費方(client)調用以本地調用方式調用服務;
- client stub接收到調用后負責將方法、參數等組裝成能夠進行網絡傳輸的消息體;
- client stub找到服務地址，并將消息發送到服務端;
- server stub收到消息后進行解碼;
- server stub根據解碼結果調用本地的服務;
- 本地服務執行并將結果返回給server stub;
- server stub將返回結果打包成消息并發送至消費方;
- client stub接收到消息，并進行解碼;
- 服務消費方得到最終結果。
下面再貼一個網上的時序圖：
RPC 解決了什么問題?
從上面對 RPC 介紹的內容中，概括來講RPC 主要解決了：讓分布式或者微服務系統中不同服務之間的調用像本地調用一樣簡單。
常見的 RPC 框架總結?
- RMI(JDK自帶)： JDK自帶的RPC，有很多局限性，不推薦使用。
- Dubbo: Dubbo是 阿里巴巴公司開源的一個高性能優秀的服務框架，使得應用可通過高性能的 RPC 實現服務的輸出和輸入功能，可以和 Spring框架無縫集成。目前 Dubbo 已經成為 Spring Cloud Alibaba 中的官方組件。
- gRPC ：gRPC是可以在任何環境中運行的現代開源高性能RPC框架。它可以通過可插拔的支持來有效地連接數據中心內和跨數據中心的服務，以實現負載平衡，跟蹤，運行狀況檢查和身份驗證。它也適用于分布式計算的最后一英里，以將設備，移動應用程序和瀏覽器連接到后端服務。
- Hessian： Hessian是一個輕量級的remotingonhttp工具，使用簡單的方法提供了RMI的功能。 相比WebService，Hessian更簡單、快捷。采用的是二進制RPC協議，因為采用的是二進制協議，所以它很適合于發送二進制數據。
- Thrift： Apache Thrift是Facebook開源的跨語言的RPC通信框架，目前已經捐獻給Apache基金會管理，由于其跨語言特性和出色的性能，在很多互聯網公司得到應用，有能力的公司甚至會基于thrift研發一套分布式服務框架，增加諸如服務注冊、服務發現等功能。
既有 HTTP ,為啥用 RPC 進行服務調用?
RPC 只是一種設計而已
RPC 只是一種概念、一種設計，就是為了解決 不同服務之間的調用問題, 它一般會包含有 傳輸協議 和 序列化協議 這兩個。
實現 RPC 的可以傳輸協議可以直接建立在 TCP 之上，也可以建立在 HTTP 協議之上。大部分 RPC 框架都是使用的 TCP 連接(gRPC使用了HTTP2)。
HTTP 和 TCP
可能現在很多對計算機網絡不太熟悉的朋友已經被搞蒙了，要想真正搞懂，還需要來簡單復習一下計算機網絡基礎知識：
我們通常談計算機網絡的五層協議的體系結構是指：應用層、傳輸層、網絡層、數據鏈路層、物理層。
應用層(application-layer)的任務是通過應用進程間的交互來完成特定網絡應用。HTTP 屬于應用層協議，它會基于TCP/IP通信協議來傳遞數據(HTML 文件, 圖片文件, 查詢結果等)。HTTP協議工作于客戶端-服務端架構為上。瀏覽器作為HTTP客戶端通過 URL 向HTTP服務端即WEB服務器發送所有請求。Web服務器根據接收到的請求后，向客戶端發送響應信息。HTTP協議建立在 TCP 協議之上。
運輸層(transport layer)的主要任務就是負責向兩臺主機進程之間的通信提供通用的數據傳輸服務。TCP是傳輸層協議，主要解決數據如何在網絡中傳輸。相比于UDP,TCP 提供的是面向連接的，可靠的數據傳輸服務。
主要關鍵就在 HTTP 使用的 TCP 協議，和我們自定義的 TCP 協議在報文上的區別。
http1.1協議的 TCP 報文包含太多在傳輸過程中可能無用的信息：
- HTTP/1.0 200 OK
- Content-Type: text/plain
- Content-Length: 137582
- Expires: Thu, 05 Dec 1997 16:00:00 GMT
- Last-Modified: Wed, 5 August 1996 15:55:28 GMT
- Server: Apache 0.84
- <html>
- <body>Hello World</body>
- </html>
使用自定義 TCP 協議進行傳輸就會避免上面這個問題，極大地減輕了傳輸數據的開銷。 這也就是為什么通常會采用自定義 TCP 協議的 RPC 來進行進行服務調用的真正原因。除此之外，成熟的 RPC 框架還提供好了“服務自動注冊與發現”、"智能負載均衡"、“可視化的服務治理和運維”、“運行期流量調度”等等功能，這些也算是選擇 RPC 進行服務注冊和發現的一方面原因吧!
一個常見的錯誤觀點
很多文章中還會提到說 HTTP 協議相較于自定義 TCP 報文協議，增加的開銷在于連接的建立與斷開，但是這個觀點已經被否認，下面截取自某乎中一個回答：
首先要否認一點 HTTP 協議相較于自定義 TCP 報文協議，增加的開銷在于連接的建立與斷開。HTTP 協議是支持連接池復用的，也就是建立一定數量的連接不斷開，并不會頻繁的創建和銷毀連接。二一要說的是 HTTP 也可以使用 Protobuf 這種二進制編碼協議對內容進行編碼，因此二者最大的區別還是在傳輸協議上。
題外話
除此之外，還需要注意的一點是 Spring Cloud Netflix 并沒有使用 RPC 框架來進行不同服務之間的調用，而是使用 HTTP 協議進行調用的，速度雖然不比 RPC ,但是使用 HTTP 協議也會帶來其他很多好處(這一點，可以自行查閱相關資料了解)。
