使用七牛雲端儲存的一些經驗總結

P_Chou水冗發表於2019-02-16

近段時間將使用七牛雲端儲存來存放使用者上傳的資料，客戶端通過七牛的js-sdk與七牛互動，服務端C#實現了七牛相關的介面。在這過程中多多少少遇到點問題，在這裡總結一下。原文：使用七牛雲端儲存的一些經驗總結

599錯誤處理

如果在與七牛的互動中出現http狀態碼為599的錯誤，一句話，不要猶豫，直接聯絡七牛技術支援。七牛的文件也在很多地方提到這個錯誤，都是指導大家去聯絡技術支援的。筆者是在分塊上傳後的mkfile呼叫時出現的，聯絡技術支援後，說是調整了一下，讓我重試。後來就好了…

分塊上傳無法從回撥中獲得檔案的原始名

簡單上傳採用的是multipart/form-data方式上傳，七牛服務端能夠從請求中獲得檔案的原始名，並支援使用魔法變數$(fname)回撥業務伺服器。不過當使用分片上傳的時候情況有所不同。分片上傳需要在最後呼叫mkfile，來將分片拼接起來。但是，mkfile介面支援普通的請求，並沒有附帶檔名，所以七牛也就無法獲得檔名，此時從$(fname)中是取不到檔名的。這個問題我也向七牛技術支援提交了問題，得到的結果是使用自定義變數mkfile支援將自定義變數放在url中，回撥的時候自定義變數可以傳遞給業務伺服器。

慎用圖片預處理

七牛雲支援很多對檔案的預處理，其中最常用的應該就是圖片預處理了，可以對圖片的大小做變換等。七牛推薦使用GET的方式直接指定圖片處理結果的url，像這樣：

http://qiniuphotos.qiniudn.com/gogopher.jpg?imageView2/1/w/200/h/200

處理後的圖片會自動快取，使用者不用關心，只要每次訪問都用這個url就行了。然而，筆者在開始的時候，為了保持與其他檔案形式統一的處理方法，對圖片使用了預處理（因為視訊什麼的只能預處理），即在token中指定了預處理。此時問題出現了，從後臺的日誌看到，圖片的預處理通知回撥竟然比正常的上傳成功回撥還要快！這就導致預處理結果到來之前，我的業務伺服器的資料庫中還沒有這個圖片，無法儲存預處理結果了。所以推薦還是使用url直接處理，對圖片要慎用預處理

視訊檔案無法快進播放

通常使用者在觀看視訊的時候都會根據自己的喜好，快速將視訊定位到指定的時間播放。實現這個功能，需要視訊本身有關鍵幀資訊、服務端需要支援關鍵幀播放請求，在這篇文章中有詳細討論。
但是筆者發現，在使用七牛雲轉化後的視訊，這樣做是無效的。於是諮詢技術支援，得到的答案是：轉化的檔案是具有關鍵幀的，但七牛使用CDN加速，所以關鍵幀請求需要CDN的支援，如果想要用這個功能的話，需要單獨聯絡銷售或技術支援在CDN上配置，而且時間比較長。筆者聯絡了銷售和技術支援，說是幫我配置，但到現在還沒有搞定，因為最近這個也不是特別重要，所以也沒有跟下去。

Callback校驗

這是可選的一個步驟。由於七牛雲會在上傳完成之後回撥業務伺服器，所以理論上說業務伺服器需要校驗這個回撥的合理性。原理在七牛的文件中有，需要用到HMAC-SHA1簽名函式。但是七牛的sdk中沒有提供直接的方式來做校驗，在研讀文件、多次失敗和檢視sdk原始碼後，筆者終於校驗成功了。關鍵的分歧在於，文件中的這句話：

獲取明文：data = Request.URL.Path +”
” +Request.Body

這裡的Request.URL.Path是否包含Querystring?答案是包含的!下面是筆者C#服務端的校驗程式碼，使用的是ASP.NET Web Api：

byte[] key = System.Text.Encoding.UTF8.GetBytes(Qiniu.Conf.Config.SECRET_KEY);
using (HMACSHA1 hmac = new HMACSHA1(key))
{
    var t = filterContext.Request.Content.ReadAsStringAsync();
    t.Wait();
    string rawbody = t.Result;
    log.DebugFormat("request`s rawbody : {0}", rawbody);
    string text = filterContext.Request.RequestUri.PathAndQuery + "
" + rawbody;
    log.DebugFormat("PathAndQuery + \n + rawbody : {0}", text);
    byte[] digest = hmac.ComputeHash(System.Text.Encoding.UTF8.GetBytes(text));
    string computed = Qiniu.Util.Base64URLSafe.Encode(digest);
    log.DebugFormat("Computed hash after base64 : {0}", computed);

    IEnumerable<string> auths;
    if (filterContext.Request.Headers.TryGetValues("Authorization", out auths) && auths.Count() == 1)
    {
        string auth = auths.First();
        log.DebugFormat("Authorization in header : {0}", auth);
        if (auth.StartsWith("QBox "))
        {
            var arr = auth.Substring(5).Split(`:`);
            if (arr.Length == 2)
            {
                if (arr[1] != computed)
                {
                    log.ErrorFormat("Authorization failed. Since auth from header {0} not equals computed {1}", arr[1], computed);
                }
                else
                {
                    log.Debug("Authorization success.");
                    //only pass can be return
                    return;
                }
            }
            else
            {
                log.Error("Callback Authorization`s format is invalid, can not find two part after split by `:`.");
            }
        }
        else
        {
            log.Error("Callback Authorization`s format is invalid, missing leading `QBox `.");
        }
    }
    else
    {
        log.Error("The request from qiniu callback is missing `Authorization`");
    }

    filterContext.Response = filterContext.Request.CreateResponse(System.Net.HttpStatusCode.Forbidden);

}

如下幾個注意點：

  • 明文應當是請求的path+querystring部分和rawbody
  • 對於.NET而言，明文和key都需要用UTF-8編碼變換成位元組才能進行簽名。而php中的hash_hmac函式完全不用這麼複雜…
  • 簽名的結果再用base64的url安全的方式編碼，再與請求的http頭部的Authorization比較

建議官方在文件中加入一些相對底層一些的程式語言的實現，php太高階了…

js-sdk實現略顯粗糙

在使用過程中，我發現官方的js-sdk有幾個我覺得不好的地方：

不能為每個檔案獲取UpToken

試想，在檔案上傳過程中有獲取UpToken是必須的，而且UpToken又需要包含預處理指令，不同的檔案顯然需要不同的UpToken，而在js-sdk的實現中，只在初始化這個上傳元件物件的時候請求一次上傳憑證，後面所有的上傳都需要使用這個預先得到的UpToken：

uploader.bind(`Init`, function(up, params) {
    getUpToken();
});

於是我修改了這部分，在BeforeUpload事件中請求UpToken。建議官方考慮更改這個地方

只能實現分片上傳，無法斷點續傳

js-sdk的實現在分片上傳的實現上，是很簡單的，不僅沒有使用分片，而是分塊（一塊4m，呼叫mkblk），而且沒有實現持久化ctx，或者類似的回撥或介面。4m分塊這個問題還可以不追究，沒有實現持久化ctx就說不過去了，不持久化怎麼實現斷點續傳撒?!就算不實現，也應該給出回撥的入口，讓呼叫者來實現持久化，而我實在無法找到這個`空子`可鑽，只能直接在原始碼上改動了。

沒有複用流行類庫的東西

這個其實算不上問題，因為作為一個不依賴jquery的sdk，當然不能使用jquery現成的東西，比如ajax。不依賴jquery就算了，依賴plupload是幾個意思嘛，還依賴全域性物件…於是最後，我乾脆自己將sdk改成了Backbone的類，將不要的東西統統去掉，使用jquery和underscore簡化程式碼了…

相關文章