企業(yè)神奇的中間件-RPC
在企業(yè)的業(yè)務發(fā)展到一定程度的時候，企業(yè)內(nèi)部的系統(tǒng)總會進行這樣或者那樣的系統(tǒng)切分。那么這會導致一個什么問題呢？原來直接通過直接本地調(diào)用方式的功能，已經(jīng)無法正常工作了，因為物理上或者邏輯上已經(jīng)隔離了。切分應用分別部署一般來說有四種方式。
1、同一主機不同端口。
2、同一主機跨虛擬機或者跨 Docker 容器。
3、跨主機同一內(nèi)網(wǎng)
4、跨主機跨網(wǎng)絡。
這就使得不論是從邏輯還是從物理上隔離，都使得遠程調(diào)用尤為重要。現(xiàn)在最常用的就四大類。
1、SpringCloud系列，以 RESTful API 為首的 HTTP 類交互。
2、消息隊列系列。
3、WebSocket系列。
4、RPC系列，遠程過程調(diào)用。
各自都有什么特點呢？
SpringCloud 系列，基本都是基于 HTTP 協(xié)議來進行傳輸?shù)模?RESTful 風格的開發(fā)方式，接口層面可以做到兼容所有開發(fā)語言，這對于開發(fā)語言非常多樣化的項目來說還是比較合適的。
消息隊列系列，可以做到系統(tǒng)間解耦，以及進行各種削峰等操作。缺點就是消息隊列一般是無法實時響應的，需要自己實現(xiàn)一套系統(tǒng)交互機制。
WebSocket系列。一般來說會用于瀏覽器和服務端的交互中，全雙工模式以及持久化鏈接的設計，可以方便地替代消息隊列交互中的輪詢機制。當然WebSocket 系列也可以作用于服務間，用來實現(xiàn)雙向推送。
RPC系列。一般來說，RPC不像HTTP一直要三次握手，RPC框架一般都伴隨著長連接。RPC并不是一個單點的技術，而是一類技術，目前比較有名的有 JMI、gRPC、Thrift、Dubbo、Motan（微博版Dubbo）、HSF、Hetty 、rpcx等等。
我們后面的專欄主題系列最主要就是針對 RPC 的設計及原理，以及各種 RPC 的入門，最后會給出各種 RPC 的比較以及建議，可以賞個一毛錢給大蕉表達你想看這個系列的意向嗎？
RPC是長什么樣子的？
RPC（Remote Procedure Call），遠程過程調(diào)用，從最簡單最抽象的模式來看，就是下面這個圖這樣。客戶端調(diào)用某個方法，然后中間經(jīng)過一系列的過程，調(diào)用到服務端的某個方法。服務端進行處理之后，做出相應，然后逐層原路返回到客戶端。
是不是很簡單，一般來說，開發(fā)者只需要關注藍色（ functions ）部分，而至于紅色部分（ stub句柄 ） 和黃色部分（socket 網(wǎng)絡）部分呢，框架層面會把它解決掉。藍色部分，服務端開發(fā)者要做的事情就是定義某個接口，客戶端開發(fā)者要做的事情就是調(diào)用某個接口，一切開發(fā)模式都跟本地調(diào)用無差別。
燃鵝，因為框架做得那么好了，所以出現(xiàn)了很多像我這樣只會定義RPC和調(diào)用RPC的人工智能開發(fā)工程師（嗯，人工寫代碼是挺智能的，人工智能怎么能少了人工呢），希望能通過這個系列，解除你的疑惑，如果能有點幫助那就更好了。今天不講太多 RPC 技術性細節(jié)性的東西，親愛的朋友們，你們希望看到些什么內(nèi)容留言告訴我吧。
【本文為51CTO專欄作者“大蕉”的原創(chuàng)稿件，轉載請通過作者微信公眾號“一名叫大蕉的程序員”獲取授權】
