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