某廠面試：如何優(yōu)雅使用 SPI 機制

代碼不多，文章可能有點長。朋友面試某廠問到的 SPI 機制，聯(lián)想到自己項目最近寫到的 SPI 場景，文章簡要描述下 SPI 機制的發(fā)展歷程

 

產(chǎn)出背景

因為最近項目中使用分庫分表以及數(shù)據(jù)加密使用到了 ShardingSphere，所以決定這段時間看看源碼實現(xiàn)。問我為什么要讀源碼？不看源碼怎么提高逼格嘞，就是這么樸實無華～

 

Sharding-Jdbc SPI

看源碼的歷程，往往從點開 Jar 包的瞬間開始。好巧不巧，就看到源代碼包下有個 SPI 包，處于好奇心就點了一點，嗯～ 代碼果然很熟悉，還是那個配方原來的味道

看了許久，陷入深深的沉思。內心小九九：這玩意好像之前看過，但是在哪我忘了，這到底是個啥？

代碼還是那個代碼，只是它認識我，我不認識它了

這一塊的 SPI 接口是 shrding-jdbc 預留自定義加密器的接口

看到這里相信就遇到過絕大多數(shù)技術同學都會遇到的一個問題，那就是 認為自己會了，實際情況呢？不一定。所以，學習一門技術，一定要多看幾遍，嘗試去理解記憶。千萬不要看一遍之后，眼高手低認為技術 so easy，然后隔十天半個月就啥都不記的

繼續(xù)回過頭來說說今天的主角：SPI。首先回答這么一個問題，什么是 SPI 機制

SPI 全稱為 Service Provider Interface，是一種服務發(fā)現(xiàn)機制。為了被第三方實現(xiàn)或擴展的 API，它可以用于實現(xiàn)框架擴展或組件替換

SPI 機制本質是將 接口實現(xiàn)類的全限定名配置在文件中，并由服務加載器讀取配置文件，加載文件中的實現(xiàn)類，這樣運行時可以動態(tài)的為接口替換實現(xiàn)類

看文字描述介紹總是枯燥無味且空洞的。簡單一點來說，就是你在 META-INF/services 下面定義個文件，然后通過一個特殊的類加載器，啟動的時候加載你定義文件中的類，這樣就能擴展原有框架的功能

就這么簡單，那可能有讀者會問：我不定義在 META-INF/services 下面行不行？就想定義在別的地方

不行滴，請遏制住這么危險的想法，人家怎么定義你就怎么實現(xiàn)。這是 JDK 規(guī)定好的配置路徑，你隨便定義，類加載器怎么知道去哪里加載

看到這個 PREFIX 常量之后，想法比較活躍的小伙子不知道清醒點了么。簡單畫張圖來描述下 SPI 的運行機制

有點 SPI 基礎的同學看到圖之后應該又開始自信了，這不就是我之前看過的那玩意么？是的，技術還是那個技術，可以繼續(xù)往下看看，有沒有自己不知道的

 

為什么要有 SPI

了解一項技術的前提，一定要知道它為了解決什么樣的痛點而存在，JDK 作者也不會沒屁事加點代碼玩

引入了 SPI 機制后，服務接口與服務實現(xiàn)就會達成分離的狀態(tài)，可以實現(xiàn) 解耦以及程序可擴展機制。服務提供者（比如 springboot starter）提供出 SPI 接口后，客戶端（平常的 springboot 項目）就可以通過本地注冊的形式，將實現(xiàn)類注冊到服務端，輕松實現(xiàn)可插拔

數(shù)據(jù)加密舉例

以實際項目舉個例子，就拿 sharding-jdbc 數(shù)據(jù)加密模塊來說，sharding-jdbc 本身支持 AES 和 MD5 兩種加密方式。但是，如果客戶端不想用內置的兩種加密，偏偏想用 RSA 算法呢？難道每加一種算法，sharding-jdbc 就要發(fā)個版本么

sharding-jdbc 可不會這么干，首先提供出 Encryptor 加密接口，并引入 SPI 的機制，做到服務接口與服務實現(xiàn)分離的效果。如果客戶端想要使用新的加密算法，只需要在客戶端項目 META-INF/services 目錄下定義接口的全限定名稱文件，并在文件內寫上加密實現(xiàn)類的全限定名，就像這樣式的

通過 SPI 的方式，就可以將客戶端提供的加密算法加載到 sharding-jdbc 加密規(guī)則中，這樣就可以在項目運行中選擇自定義算法來對數(shù)據(jù)進行加密存儲

通過 sharding-jdbc 的例子，可以很好的看出來，上面提到的 SPI 優(yōu)點，都體現(xiàn)了出來

1. 客戶端（自己的項目）提供了服務端（sharding-jdbc）的接口自定義實現(xiàn)，但是與服務端狀態(tài)分離，只有在客戶端提供了自定義接口實現(xiàn)時才會加載，其它并沒有關聯(lián)；客戶端的新增或刪除實現(xiàn)類不會影響服務端
2. 如果客戶端不想要 RSA 算法，又想要使用內置的 AES 算法，那么可以隨時刪掉實現(xiàn)類，可擴展性強，插件化架構

配合實際案例理解 SPI 是不是很簡單。為了防止有些小伙伴沒有理解 sharding-jdbc 的例子，這里再舉一個真實的例子

對象存儲舉例

假如你是一家集團公司里做公共架構開發(fā)的（可以把這個集團想大一點，幾百家子公司的那種 ??? ），領導給你安排了個開發(fā)任務，需要你開發(fā)一個對象存儲服務，讓其它業(yè)務線的團隊使用，統(tǒng)一集團內部的對象存儲

OK，開發(fā)訴求明白了，這個時候就該想想怎么去完成這個需求（主要想給領導留個好印象，升官發(fā)財 ing...）。首先應該考慮的是要兼容多套對象存儲供應商，比如阿里 OSS、騰訊 COS、華為云 OBS，最基本的三連對吧

高高興興的封裝了個 starter，告訴領導封裝完成了，然后就下發(fā)到各項目組去用了。但是這個時候其中一個子公司負責人告訴你，說他們之前用的七牛云 Kodo

心態(tài)炸了呀，難道要給他再適配一個七牛云么？萬一適配完這個，又一位大哥說項目自建 HDFS 咋整

聊到這，大家就明白了吧，SPI 的場景可不就出現(xiàn)了么。就是身為服務提供者，在你無法形成絕對規(guī)范強制的時候，"放權" 往往是比較明智的選擇，適當讓客戶端去自定義實現(xiàn)

這個時候，回過頭想一想最初的一個問題。為什么 sharding-jdbc 不多實現(xiàn)幾套算法，而是提供出一個 SPI 接口呢

因為開發(fā)者明白，不論提供多少接口，總有個別用戶因各方面因素導致的個性化需求。個性化這個事情是追摸不透的，就像 女生的心思一樣，永遠不知道在想什么...（重點都加黑加粗了，剩下的全靠自己領悟）

 

實戰(zhàn)講解

都說到這了，不來個實戰(zhàn)，感覺有點說不過去。吹過的牛逼，負責到底！就實現(xiàn)上面說的統(tǒng)一對象存儲服務的代碼

最簡單的對象存儲，只需要兩個接口就可以實現(xiàn)功能，分別是 上傳和下載

定義好上傳、下載接口后，我們就要考慮，如何讓客戶端項目可以選擇底層的對象存儲服務器，以及如何通過 SPI 的方式將客戶端自定義的文件存儲組件加載到服務端

我們可以定義個對象存儲容器，存放可以使用的對象存儲服務，然后再 使用 SPI 的機制加載客戶端自定義組件放到容器。對象存儲服務放到容器中自然需要一個標識，那么就需要給文件接口加一個獲取類型接口

定義好了接口，就要寫具體的代碼了。我們?yōu)?對象存儲服務提供出一個對外的門面，所有訪問對象存儲的服務，必須訪問門面對象進行文件的上傳下載操作

下面這段代碼將 對象服務 bean 存儲至容器，并提供根據(jù)客戶端的自定義配置，選擇合適的對象存儲服務

代碼里用到的關鍵字 var 是 lombok 的注解，可以自動識別對象類型

因為是個示例 demo，所以將獲取對象存儲和具體的上傳、下載耦合在了一起，如果小伙伴有類似需求，一定要將不同行為拆分開，類職責盡量單一些

這段代碼整體邏輯不算復雜，所以也有點自信回頭，就沒跑單元測試，不過問題應該不大。解釋一下其中具體邏輯：

1. FileServiceFactory 大家可以理解為文件服務對外的統(tǒng)一訪問入口。實現(xiàn)了 spirng 初始化的一個接口，可以在 bean 初始化時進行代碼邏輯操作
2. bean 初始化時，通過 ServiceLoader 類加載器負責加載對象存儲接口，這樣就能加載到客戶端存放到 META-INF/services 中的自定義對象存儲實現(xiàn)
3. 獲取到自定義對象存儲后，和服務端本身自帶的對象存儲一起存放至容器中，這樣就可以根據(jù)項目中的 fileStoreType 獲取對應的服務了

結合實際的項目場景，一個簡簡單單的 SPI 應用就完成了，自我感覺比 JDBC 裝配的例子更好理解一些

上面的業(yè)務只是為了讓不理解 SPI 的小伙伴更好的掌握應用場景，其實對象存儲服務是一種可窮舉的業(yè)務場景，SPI 并不是唯一的解決思路。當然，為了省事使用 SPI 也沒啥問題。最后提一句，SPI 最合適的還是沒有統(tǒng)一業(yè)務實現(xiàn)場景，就像上面提到過的加密算法

 

深入解析 SPI

一篇技術解析文章，適當放一些源碼解析感覺會更好一些。下面一起來看看 ServiceLoader 底層都做了什么事情

通過 ServiceLoader 的 load 方法創(chuàng)建一個新的 ServiceLoader，并實例化其中的成員變量

應用程序通過迭代器接口獲取對象實例，這里首先會判斷 providers 對象中是否有實例對象

如果有實例，那么就返回；如果沒有，執(zhí)行類的裝載步驟，具體類裝載實現(xiàn)如下：

1. LazyIterator#hasNextService 讀取 META-INF/services 下的配置文件，獲得所有能被實例化的類的名稱，并完成 SPI 配置文件的解析
2. LazyIterator#nextService 負責實例化 hasNextService() 讀到的實現(xiàn)類，并將實例化后的對象存放到 providers 集合中緩存

如果你不知道上面的一些 "黑話" 不要緊，因為都是 ServiceLoader 底層執(zhí)行的方法，跟著下面這個程序敲一遍代碼就懂了

這里為了跟源碼，也是把上面對象存儲的邏輯，簡單寫了個 SPI 示例，證明是沒有問題的。如果小伙伴想真正了解，就需要跟下源碼去看看，其它源碼部分就不細說了

 

結言

上面說了很多關于 SPI 機制的優(yōu)點以及應用場景，這里總結下關鍵內容

1. SPI 機制優(yōu)勢就是解耦。將接口的定義以及具體業(yè)務實現(xiàn)分離，而不是和業(yè)務端全部耦合在一端。可以實現(xiàn) 運行時根據(jù)業(yè)務實際場景啟用或者替換具體組件
2. SPI 機制的場景就是 沒有統(tǒng)一實現(xiàn)標準的業(yè)務場景。一般就是，服務端有標準的接口，但是沒有統(tǒng)一的實現(xiàn)，需要業(yè)務方提供其具體實現(xiàn)。比如說 JDBC 的 java.sql.Driver 接口和不同云廠商提供的數(shù)據(jù)庫實現(xiàn)包

每個事物都是既有優(yōu)點，同時也伴隨著缺點。要從兩個方面去看，不能總盯著一方面。這里說一下 SPI 機制的缺點

1. 不能按需加載。雖然 ServiceLoader 做了延遲加載，但是只能通過遍歷的方式全部獲取。如果其中某些實現(xiàn)類很耗時，而且你也不需要加載它，那么就形成了資源浪費
2. 獲取某個實現(xiàn)類的方式不夠靈活，只能通過迭代器的形式獲取。這兩點可以參考 Dubbo SPI 實現(xiàn)方式進行業(yè)務優(yōu)化

文章通過圖文并茂的方式幫助大家重新梳理了一遍 SPI 的場景、優(yōu)勢和缺點，看完文章后相信大家對 SPI 機制有了更深入的認識

梳理出 SPI 的場景以及優(yōu)勢后，小伙伴最好再去 Debug 源代碼，這樣會大家對 SPI 的實現(xiàn)才能更加清楚。只有對一個知識點真正掌握，才不至于事后很快遺忘

另外可以通過項目中的場景，比如文中提到的加密、對象存儲，通過類比的方式結合項目邏輯去實現(xiàn)代碼代入，這樣能夠更好的去學習以及擴展相關的設計思路

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??