寫在前面
目前在很多業務中，存儲都大量的依賴了雲存儲，比如阿里雲的 oss、華爲雲的 obs 等。但是如果有大量的上傳/下載任務，雲存儲上的網絡 I/0 就變成了一個很大的瓶頸。
於是我們打算在內網實現一個對象緩存服務，具體表現爲：託管內網上傳的對象，並最終轉發到雲存儲；hold 住內網的下載請求，並從雲存儲把對象下載下來並緩存返回，這樣下次該對象的請求就能直接由內網處理。
需要實現的功能
- 上傳/下載接口必須與雲存儲的一致。這樣內部服務接入的時候不用關心是內網還是外網；
- 域名一致。實現在內網訪問，域名轉發到緩存服務；在外網訪問，域名轉發到雲存儲服務；
- 緩存服務和雲存儲服務的交互；比如：內網刪除了對象，雲儲存服務能感知到；雲存儲服務刪除了對象，內網能感知到；
- 權限問題。緩存服務和雲存儲服務具有相同共用的權限；
實現思路
上傳/下載接口必須與雲存儲的一致。這一點就是相同的接口分別對應兩種實現，一種部署在內網，一種部署在在外網；
域名一致。解析問題找公司的運維配置不同的 DNS 解析即可；
緩存服務和雲存儲服務的交互問題。就是兩個不同環境服務之間的通信問題，大致實現方案有：
- websocket 長連接
- 輪詢
- 長輪詢
- SSE
- 消息隊列
相關資料：
認識長輪詢：配置中心是如何實現推送的？
Server-Sent Events 教程
SSE技術詳解：一種全新的HTML5服務器推送事件技術
Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE
最終在實現上選擇了長輪訓的方案，理由是：即時響應、實現簡單、沒有很大的連接需求要用到 ws 的地步。
權限問題。權限問題我們參考了 s3-client 的設計思路，頒發給接入端 ak/sk， 然後接入端通過 ak/sk + 參數來生成簽名，生成的簽名當作認證信息通過 Authorization Header 傳遞給服務端，和服務端生成的相比較，如果一致則說明認證通過，這樣的校驗思路不僅能達到認證的目的，也順便把驗籤的問題解決了。
值得注意的是，既然叫緩存服務，它就是可以不用保證完全可靠，它應該被設計的足夠輕量，儘可能少的依賴外部，並且能夠隨時被拿掉而不會影響雲存儲服務。因此在設計上我們選擇了依賴 h2 數據庫，並且直接用 guava 做內存緩存。