RPC基本框架包括四個模塊：傳輸模塊、協議模塊、集群模塊以及Bootstrap模塊。 我們可以使用插件化架構的方法來擴展RPC基本框架，使其更加靈活適應將來可能得變更。 ...
07 | 架構設計：設計一個靈活的RPC框架
RPC就是把攔截到的方法參數，轉成可以在網路中傳輸的二進位，並保證在服務提供方能正確地還原出語義，最終實現像調用本地一樣地調用遠程的目的。
RPC的本質是一個遠程調用，需要通過網路來傳輸數據，我們一般採用TCP協議作為數據通信協議，為了屏蔽網路傳輸的複雜性，我們需要封裝一個獨立的數據傳輸模塊來收發二進位數據，這個模塊被稱為傳輸模塊。
我們在調用方法時，方法的出入參數都是對象數據，我們需要將對象轉換成二進位，即進行序列化操作，同時，我們還需要在方法調用參數的二進位數據後面增加“斷句”符號來分隔出不同的請求，這個過程被稱為協議封裝。
傳輸模塊和協議封裝都是為了保證數據在網路中可以正確傳輸，我們將這兩個模塊放在一起，稱為協議模塊。
我們還可以在協議模塊中添加壓縮功能，在方法調用參數或者返回值的二進位數據大於某個閾值時，我們使用壓縮框架對數據進行無損壓縮，然後再另外一段使用同樣的壓縮機制進行解壓處理，保證數據可以還原。
傳輸模塊和協議模塊是RPC中最基礎的功能，它們使得對象可以正確的傳輸到服務提供方。但是為了讓這兩個模塊可以同時工作，我們還需要手寫一些粘合代碼，這些代碼對於RPC框架的使用者來說是沒有意義的，屬於重覆工作，我們將這些事情進行封裝處理，形成RPC調用的入口，一般稱為Bootstrap模塊。
什麼是”服務發現“？
針對同一個介面有多個服務提供者，但這多個服務提供者對於我們的調用方來說是透明的，所以在RPC裡面我們還需要給調用方找到所有的服務提供方，並需要在RPC裡面維護好介面和服務提供者地址間的關係，這樣調用方在發起請求時才能快速找到對應的接收地址。
一個劃分為四層的RPC基礎架構的示意圖如下。
上面的框架有什麼問題嗎？最主要的問題就是擴展性不高，當我們有需求變更時，很容易需要大範圍調整框架。
我們可以嘗試使用插件化架構的方法論來優化我們的RPC架構。
我們怎麼在RPC框架裡面支持插件化架構？
我們可以將每個功能點抽象成一個介面，將這個介面作為插件的契約，然後把這個功能的介面與功能的實現分離，並提供介面的預設實現。
加入插件功能後，RPC框架就包含了兩大核心體系：核心功能體系和插件體系，示意圖如下。
彩蛋 - Java SPI
什麼是Java SPI？
SPI（Service Provider Interface）是JDK內置的一種服務提供發現機制，可以用來擴展框架和替換組件，它的核心思想是解耦。
例如針對DB驅動程式，java.sql.Driver介面定義了相關規範，不同的廠家會針對這一規範提供不同的實現，例如MySQL和PostgreSQL會提供不同的實現給用戶。
SPI和API有什麼區別？
- API是調用並用於實現目標的類、介面、方法等的描述。
- SPI是擴展和實現類似目標的類、介面和方法等的描述。
SPI的使用流程是怎樣的？
- 相關組織或者公司發佈介面規範定義。
- 第三方根據介面提供具體實現。
- 開發者在程式中針對SPI進行配置並使用。
JDK提供的SPI有哪些不足？
- 不能按需載入，需要遍歷所有的實現，並實例化，然後才能在迴圈中找到我們需要的實現。
- 獲取某個實現類的方式不夠靈活。
- 多個併發多線程使用ServiceLoader類的實例是不安全的。
