背景
1、由于文件直接通過服務(wù)器再到文件存儲(chǔ)服務(wù)會(huì)驗(yàn)證影響到服務(wù)的性能，要是存在大批量文件的行為脐嫂，可能會(huì)直接拖垮服務(wù)；目前我們使用OSS文件存儲(chǔ)服務(wù)紊遵，OSS文件存儲(chǔ)支持上傳回調(diào)账千，這樣會(huì)減少服務(wù)器壓力和網(wǎng)絡(luò)帶寬；
?2暗膜、采用服務(wù)端簽名后直傳方案有個(gè)問題：大多數(shù)情況下匀奏，用戶上傳數(shù)據(jù)后，應(yīng)用服務(wù)器需要知道用戶上傳了哪些文件以及文件名学搜；如果上傳了圖片娃善，還需要知道圖片的大小等。
解決思路
使用OSS官網(wǎng)介紹方案瑞佩，利用OSS官網(wǎng)的對應(yīng)語言的操作示例聚磺，來實(shí)現(xiàn)我們需要的方案
方案介紹
詳細(xì)流程
1、流程如下：
用戶向應(yīng)用服務(wù)器請求上傳Policy和回調(diào)炬丸。
應(yīng)用服務(wù)器返回上傳Policy和回調(diào)設(shè)置瘫寝。
用戶直接向OSS發(fā)送文件上傳請求。
OSS根據(jù)用戶的回調(diào)設(shè)置稠炬，發(fā)送回調(diào)請求給應(yīng)用服務(wù)器焕阿。
應(yīng)用服務(wù)器返回響應(yīng)給OSS。
OSS將應(yīng)用服務(wù)器返回的內(nèi)容返回給用戶首启。
policy封裝（類似token的權(quán)限校驗(yàn)+需要的參數(shù)）
2暮屡、內(nèi)容解析如下：
CallbackUrl：OSS往這個(gè)服務(wù)器發(fā)送的URL請求。
callbackHost：OSS發(fā)送這個(gè)請求時(shí)毅桃，請求頭部所帶的Host頭褒纲。
callbackBody：OSS請求時(shí)，發(fā)送給應(yīng)用服務(wù)器的內(nèi)容钥飞，可以包括文件的名稱莺掠、大小、類型代承。如果是圖片汁蝶，可以是圖片的高度、寬度论悴。
callbackBodyType：請求發(fā)送的Content-Type掖棉。
3、客戶端/web上傳
?客戶端/web上傳圖片膀估，是根據(jù)返回的policy信息幔亥，把對應(yīng)的圖片文件上傳到服務(wù)器，上傳后會(huì)有個(gè)回調(diào)地址察纯，從服務(wù)端返回帕棉，客戶端可以根據(jù)返回內(nèi)容判斷是否上傳成功。
?在客戶端源碼upload.js文件中饼记，callbackbody的值是步驟2中應(yīng)用服務(wù)器返回給客戶端消息body中callback的內(nèi)容香伴。如下代碼是官網(wǎng)例子：
new_multipart_params = {
'key' : key + '${filename}',
'policy': policyBase64,
'OSSAccessKeyId': accessid,
'success_action_status' : '200', //讓服務(wù)端返回200，不設(shè)置則默認(rèn)返回204
'callback': callbackbody,
'signature': signature,
};
遇到的問題
1具则、由于對接的圖片加密上傳有web端即纲、JAVA口蝠、python歧胁、c++等一些服務(wù)，有c++的對接的同事反應(yīng)會(huì)存在一些問題愉择，改成python進(jìn)行封裝匪凡。由于對接服務(wù)語言較多膊畴，參考OSS官網(wǎng)會(huì)沒有封裝成SDK進(jìn)行處理，會(huì)有有一些語言的操作示例病游，需要根據(jù)官網(wǎng)進(jìn)行對接唇跨。
?2、之前上傳圖片存在幾萬或者幾十萬張的級別上傳的情況下衬衬，有反饋請求反應(yīng)太慢轻绞，后面排查是客戶端進(jìn)行多線程操作，把帶寬拉滿佣耐，導(dǎo)致部分圖片上傳失敗政勃，建議對接注意該問題，防止文件丟失兼砖。
總結(jié)
參考OSS的設(shè)計(jì)奸远，避免了很多不必要的性能，還增加一些流程的閉環(huán)讽挟；在以后設(shè)計(jì)一些中間件和業(yè)務(wù)代碼的過程中可以借鑒類似方式懒叛；
參考文章：https://help.aliyun.com/document_detail/31927.html?spm=a2c4g.11186623.6.1372.11174367XkuM4R
