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類的實例是不安全的。