在《從「軟件」到「服務」——【對象存儲】的發展歷程(上)》中,咱們和你們在對象存儲大規模普及以前,大量的數據存儲和處理是怎麼實現的。但這些方案大都專一於解決其中一類問題,缺乏足夠的普適性。那麼對象存儲出現後,究竟解決了什麼問題?優點又爲什麼呢?安全
跟上一篇提到的各個軟件相比,對象存儲與之最大的區別不在於實現的機制,而在於形態從軟件到服務的一個大飛躍。在這兒我想用一個可能不太恰當的比喻來講這事——傳統的體重計。服務器
不論是電子的仍是機械的,他只是一個工具,咱們評價的標準更可能是價格、準確度、易用性、量程。而互聯網的體重計,能幫你記錄你的體重變化曲線,你關心的可能更可能是數據聯動、可視化、以及根據你的體重給出的建議。固然,若是你真的對減肥有強烈的需求,那麼找一個合適的教練,由教練來指導你的減肥流程才合適,而互聯網體重計只是教練手中的一個工具而已。架構
服務跟軟件相比,有幾個大的不一樣點:app
做爲一個部署在雲端的服務,它的接口和實現是分離的,也就是說我能夠在保持接口不變的狀況下持續演化實現。咱們能夠想象一下第一次在 AWS S3 上傳的數據還有一些直到今天也沒有刪除,但這些數據可能已經經歷了不少代的硬盤(畢竟硬盤的壽命通常也就3-5年),以及不少代的存儲引擎了。這也是與傳統存儲軟件不一樣的地方,傳統存儲軟件若是大幅度更改了架構,那麼一般是以一個新的存儲軟件的形式來出現。框架
背後的緣由至少有兩點:運維
存儲類的軟件運維永遠是一個問題,磁盤的壽命通常是3~5年,在3副本的狀況下,1PB存儲須要300塊10TB硬盤,5年總共260周,也就是說,平均每週都要進行一次以上的硬盤更換操做。而採用對象存儲,對應的麻煩通常交給服務供應商來解決。服務供應商通常會選擇將壞盤留在機架上,等服務器到期後一次性銷燬,來下降運維成本。此外,爲了不單機架、單AZ(Available Zone,可用區,通常一個AZ對應一個機房,兩個AZ之間間距不低於20km,且不高於100km)故障致使數據不可用,通常還會採用一些反親和策略,好比同一數據的多個副本,放在3個機架上,而且至少兩個不一樣的AZ來存儲。工具
跟運維相關的採購負擔也是使用存儲軟件的一個大難題,在不少業務剛開始推廣時,並不知道須要多少存儲和上傳帶寬。若是按照上限準備,勢必形成大量的浪費。若是準備不足,一旦存儲用滿,客戶沒法上傳,就是影響運營的超大事故。而使用對象存儲,這些問題都再也不存在。網站
採用對象存儲後,咱們能夠更方便地引入控制流和數據流分離。以一個UGC(User-generated content,用戶生成內容,好比抖音、快手)類型的圖片或者短視頻網站爲例,若是控制流和數據流不分離,那麼爲了提供用戶訪問網站的體驗,咱們須要租賃優質的多線BGP機房,這類機房的帶寬成本很是昂貴,而圖片和短視頻的帶寬需求巨大(主要是上傳所需的帶寬和CDN回源所需的帶寬),形成總成本太高。若是把圖片/短視頻相關的上傳和CDN都挪到對象存儲服務商,只把控制相關的部分保留在昂貴的多線BGP機房。首先是上傳基本免費,若是租賃同一個服務商的CDN,CDN回源費用也能夠打折,而上傳、下載的質量保證則由服務商去作保證,在得到足夠質量的同時能大幅度節省費用。因爲對象存儲通常提供各種回調功能和轉碼功能,因此你原有的功能需求通常也能經過架構微調來知足。3d
除此以外,對象存儲服務還能提供徹底無縫的遷移方案,利用鏡像存儲等功能,能夠作到在遷移時,終端用戶徹底無感知。好比從原始存儲站點A遷移到對象存儲B,通常步驟以下:視頻
固然實際狀況可能會更復雜,好比還涉及到圖片轉碼等功能的遷移。
圖片和音視頻處理算是頗有中國特點的一個對象存儲的擴展了,這也跟中國的對象存儲發展跟富媒體網站的興起時間重疊有必定的關係。基於對象存儲的富媒體處理的好處不只僅在於簡化了使用流程,免除了客戶本身維護圖片轉碼集羣負擔,還大幅度下降了圖片相關的安全風險。衆所周知,圖片相關的 libjpeg, libpng 等庫是安全漏洞的重災區,UGC類的業務很難避免黑客上傳惡意圖片來攻擊。對象存儲的供應商能使用的手段也不只僅是緊盯CVE及時升級,還包括了使用容器來加固轉碼引擎,按期清理容器來避免APT攻擊等手段。
綜上所述,採用對象存儲,跟採用存儲軟件相比,最主要的收益來自於運維負擔、採購風險轉移給了對象存儲供應商,其次的收益還包括更靈活的架構於使用方式。其實對象存儲的功能還有不少,若是對象存儲兼容經常使用的 S3 協議的話,對應的生態也很強大,不只有大量的工具,常見的框架通常也有S3的支持。
*點擊「免費試用」免費領取京東雲10GB對象存儲額度