spring cloud深入學習(一)-----什麽是微服務？什麽是rpc？
近年來，微服務非常的流行，那麽為什麽是它？簡單介紹一下。
為什麽是微服務？
微服務架構是一種將單應用程序作為一套小型服務開發的方法，每種應用程序都在其自己的進程中運行，並與輕量級機制（通常是HTTP資源的API）進行通信。這些服務是圍繞業務功能構建的，可以通過全自動部署機制進行獨立部署。這些服務的集中化管理已經是最少的，它們可以用不同的編程語言編寫，並使用不同的數據存儲技術。
聽明白了嗎？反正我是不明白。對於一家稍微大點的公司來說，肯定會有N個系統，每個系統都有自己的功能與職責劃分，並且這些系統會通過一些中間件(消息發送系統)進行消息的交互。那麽按照傳統的項目構造方式，A系統需要調用B系統，B系統調用C系統，
C可能又調用B系統，對於業務復雜點的公司，這很正常。那麽如果哪天B系統改了某個功能，A系統就得跟著改變，然後一起上線；又或者使用的這些消息中間件突然發了一個新版本，所有用到消息中間件的系統都得去升級這些消息中間件的版本，這樣所帶來的
成本是非常大的。可能A系統這版本啥需求都沒有，但是由於B的改動，也需要去找開發留守上線，浪費人力資源。
那麽微服務是個啥樣的概念呢？每個消息中間件單獨為一個服務，而不是以jar包的形式存在，A、B、C系統之間的交互可以通過rpc的方式實現。著名的dubbo框架就是實現了rpc，那麽rpc是什麽？
什麽是rpc
1、概念
RPC 的全稱是 Remote Procedure Call 是一種進程間通信方式。它允許程序調用另一個地址空間（通常是共享網絡的另一臺機器上）的過程或函數，而不用程序員顯式編碼這個遠程調用的細節。即程序員無論是調用本地的還是遠程的，本質上編寫的調用代碼基本相同。
說白了就是調用遠程方法跟調用本地方法似的。
2、功能目標
RPC 的主要功能目標是讓構建分布式計算（應用）更容易，在提供強大的遠程調用能力時不損失本地調用的語義簡潔性。為實現該目標，RPC 框架需提供一種透明調用機制讓使用者不必顯式的區分本地調用和遠程調用。
3、rpc架構
- User
- User-stub
- RPCRuntime
- Server-stub
- Server
架構圖如下：
這裏 user 就是 client 端，當 user 想發起一個遠程調用時，它實際是通過本地調用 user-stub。user-stub 負責將調用的接口、方法和參數通過約定的協議規範進行編碼並通過本地的 RPCRuntime 實例傳輸到遠端的實例。遠端 RPCRuntime 實例收到請求後交給 server-stub 進行解碼後發起本地端調用，調用結果再返回給 user 端。
上面的圖是個粗粒度的，下面來個細粒度的架構圖：
RPC 服務方通過 RpcServer 去導出（export）遠程接口方法，而客戶方通過 RpcClient 去引入（import）遠程接口方法。客戶方像調用本地方法一樣去調用遠程接口方法，RPC 框架提供接口的代理實現，實際的調用將委托給代理RpcProxy 。代理封裝調用信息並將調用轉交給RpcInvoker 去實際執行。在客戶端的RpcInvoker 通過連接器RpcConnector 去維持與服務端的通道RpcChannel，並使用RpcProtocol 執行協議編碼（encode）並將編碼後的請求消息通過通道發送給服務方。RPC 服務端接收器 RpcAcceptor 接收客戶端的調用請求，同樣使用RpcProtocol 執行協議解碼（decode）。解碼後的調用信息傳遞給RpcProcessor 去控制處理調用過程，最後再委托調用給RpcInvoker 去實際執行並返回調用結果。
各組件解釋：
- 1. RpcServer
- 負責導出（export）遠程接口
- 2. RpcClient
- 負責導入（import）遠程接口的代理實現
- 3. RpcProxy
- 遠程接口的代理實現
- 4. RpcInvoker
- 客戶方實現：負責編碼調用信息和發送調用請求到服務方並等待調用結果返回
- 服務方實現：負責調用服務端接口的具體實現並返回調用結果
- 5. RpcProtocol
- 負責協議編/解碼
- 6. RpcConnector
- 負責維持客戶方和服務方的連接通道和發送數據到服務方
- 7. RpcAcceptor
- 負責接收客戶方請求並返回請求結果
- 8. RpcProcessor
- 負責在服務方控制調用過程，包括管理調用線程池、超時時間等
- 9. RpcChannel
- 數據傳輸通道
spring cloud深入學習(一)-----什麽是微服務？什麽是rpc？