基於 spring cloud gateway filter 統一生成阿里雲 OSS 檔案簽名

阿新 • • 發佈：2019-12-31

問題

我們的檔案（使用者的身份證件，隱私視訊等）都放在阿里雲 OSS，OSS Bucket Name 儲存空間的讀寫許可權設定為私有，代表屬於這個 bucket name 的檔案都需要經過身份認證才能訪問。

目前檔案 uri 分佈在各個服務中，前端如果需要操作或顯示圖片，都要通過 OSS SDK 生成可預覽 URL 才有許可權訪問。

那麼這個問題就變成，“通過 OSS SDK 生成可預覽 URL” 這個職責應該交給誰（前端 or 後端）來承擔更合適？

問題舉例

假設這個問題由後端解決，那麼就會有以下用例：

給定 /test 介面

並且 /test 介面返回以下資料

{
    "name" 
: "越前龍馬","url": "yqlm.jpeg","testItem": {
        "imageUrl": "test111111.png","name": "test111111"
    },"testItems": [
        {
            "imageUrl": "test-image.jpeg","name": "test-image"
        }
    ]
}
複製程式碼

當前端呼叫 /test 介面

那麼前端將得到以下資料

{
    "name": "越前龍馬","url": "https://endpoint/yqlm.jpeg?Expires=1571308870&OSSAccessKeyId=xxx&Signature=BdNd1zAcr3r4GZyupVW134W2UQ0=" 
,"testItem": {
        "imageUrl": "https://endpoint/test111111.png?Expires=1571308870&OSSAccessKeyId=xxx&Signature=pQUh8SzS+kQnxOkGwoS6NaRTmJs=","testItems": [
        {
            "imageUrl": "https://endpoint/test-image.jpeg?Expires=1571308870&OSSAccessKeyId=xxx&Signature=KAcEkGb2P68/mFpLoJcak42kMtw=" 
,"name": "test-image"
        }
    ]
}
複製程式碼

解決方案

方案1：前端承擔

優勢：後端不需要額外呼叫 OSS SDK API（特別是分頁介面比較繁瑣）。

劣勢：把問題拋給前端，前端有 IOS、Android、和 WEB，導致每個端都需要關注這個問題。

整體上這個方案可行，不過對各個前端不友好，還不是理想的解決方案。

方案2：各個服務自己承擔

優勢：各個前端不需要關注如何對檔案進行身份認證。

劣勢：把問題拋給各個服務的負責人，每個服務都需要整合 OSS SDK，還需要了解如何正確使用；而且很明顯這些都是重複程式碼。

這個方案跟第一個方案差不多，把問題從前端拋給了各個服務，還不是理想的解決方案。

方案3：新增一個檔案服務來承擔

優勢：職責更加合理，各個服務通過 Feign 或 RPC 跟檔案服務互動，具體的細節封裝在檔案服務中。

劣勢：各個服務還是需要關注何時該呼叫檔案服務生成可預覽 URL。

通過增加檔案服務來承擔生成檔案可預覽 URL 的職責，消除各個服務的重複的關注點，非常適合私有檔案比較少的場景，明顯方案 3 比之前兩個方案都要合理一些，算是一個備選方案。

方案4：檔案服務承擔，API 統一處理

優勢：各個前端和各個後端服務都不需要關注何時需要生成可預覽的 URL，何時以及如何生成統一交給 API 閘道器處理。

劣勢：API 閘道器需要維護好與檔案服務的呼叫關係，還需要分析每個請求的 response body 並修改 response body，這些操作處理起來都需要謹慎小心，做好充足的單元測試和 API 測試，避免影響所有的 API 介面。

筆者在寫這邊文章的時候，就已經基於 spring cloud gateway 實現了方案 4，該方案確實特別方便，實現起來也沒什麼難度，不過需要前後端約定好儲存到資料庫的 file uri 的格式。

總結

基於微服務架構風格，該問題筆者已經總結了 4 種解決方案（真實情況遠遠不止 4 種），每種解決方案都有利弊，如果還有更好的解決方案，歡迎一起交流。

基於 spring cloud gateway filter 統一生成阿里雲 OSS 檔案簽名

問題

問題舉例