暢談 | 從“軟體”到“服務”——【物件儲存】的發展歷程（下）

軟體架構運維技術 · 發表 2019-05-07 19:49:57

摘要：在《從“軟體”到“服務”——【物件儲存】的發展歷程（上）》中，我們和大家在物件儲存大規模普及之前，大量的資料儲存和處理是怎麼實現的。但這些方案大都專注於解決其中一類問題，缺少足夠的普適性。那麼物件儲存出現後，究竟解決了什麼問題？優勢又為何呢？ 1 . 軟體 V.S 服務跟上一...

在《從“軟體”到“服務”——【物件儲存】的發展歷程（上）》中，我們和大家在物件儲存大規模普及之前，大量的資料儲存和處理是怎麼實現的。但這些方案大都專注於解決其中一類問題，缺少足夠的普適性。那麼物件儲存出現後，究竟解決了什麼問題？優勢又為何呢？

1 .

軟體 V.S 服務

跟上一篇提到的各個軟體相比，物件儲存與之最大的區別不在於實現的機制，而在於形態從軟體到服務的一個大飛躍。在這兒我想用一個可能不太恰當的比喻來說這事——傳統的體重計。

不管是電子的還是機械的，他只是一個工具，我們評價的標準更多是價格、準確度、易用性、量程。而網際網路的體重計，能幫你記錄你的體重變化曲線，你關心的可能更多是資料聯動、視覺化、以及根據你的體重給出的建議。當然，如果你真的對減肥有強烈的需求，那麼找一個合適的教練，由教練來指導你的減肥流程才合適，而網際網路體重計只是教練手中的一個工具而已。

服務跟軟體相比，有幾個大的不同點：

首先是 自由演化 ——物件儲存的客戶可以只關心SLA，並不關心你實現SLA的手段，所以演化更自由；
其次是使用服務完全不用關心 運維問題 ——運維問題完全交給服務提供商來解決；
最後是採用服務形態後，業務的 架構方式 更靈活——比如控制面和資料面分離更輕鬆等。

作為一個部署在雲端的服務，它的介面和實現是分離的，也就是說我可以在保持介面不變的情況下持續演化實現。我們可以想象一下第一次在 AWS S3 上傳的資料還有一些直到今天也沒有刪除，但這些資料可能已經經歷了很多代的硬碟（畢竟硬碟的壽命一般也就3-5年），以及很多代的儲存引擎了。這也是與傳統儲存軟體不同的地方，傳統儲存軟體如果大幅度更改了架構，那麼通常是以一個新的儲存軟體的形式來出現。

背後的原因至少有兩點：

不同儲存引擎之間的平滑過渡和資料遷移難度很高，耗時很長，風險也很大，對於軟體的使用者來講根本不願承受這些風險；
每個儲存引擎都有自己的優缺點，如果是服務的提供方，還能接受新引擎的缺點，也能通過硬體或者使用其他方式來彌補，但作為軟體來使用的話，部分喜歡老版本優點的使用者會長期停留在老版本，這經常會導致社群的分裂。

2 .

傳統儲存 V.S 物件儲存

儲存類的軟體運維永遠是一個問題，磁碟的壽命一般是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回源費用也可以打折，而上傳、下載的質量保證則由服務商去做保證， 在獲得足夠質量的同時能大幅度節省費用。 由於物件儲存一般提供各類回撥功能和轉碼功能，所以你 原有的功能需求一般也能通過架構微調來滿足。

除此之外，物件儲存服務還能 提供完全無縫的遷移方案 ，利用映象儲存等功能，可以做到在 遷移時，終端使用者完全無感知。 比如從原始儲存站點A遷移到物件儲存B，一般步驟如下：

在B上配置映象存儲，保證在物件儲存無法取到檔案時，可以去原始儲存站點A讀取，保證服務可用

開始測試B站點，確保功能沒有問題

通過DNS調整，灰度部分使用者的下載到物件儲存站點B，確認功能正常

從A站點到B站點做離線的批量遷移，保證絕大部分資料在B站點存在

切換全部下載到B站點

切換全部上傳到B站點，此後A站點進入只讀

最後再做一遍A站點資料的全量遷移和校驗

最後清理A站點所用的資源

當然實際情況可能會更復雜，比如還涉及到圖片轉碼等功能的遷移。

3 .

物件儲存在中國的特色擴充套件

圖片和音視訊處理算是很有中國特色的一個物件儲存的擴充套件了，這也跟中國的物件儲存發展跟富媒體網站的興起時間重疊有一定的關係。基於物件儲存的富媒體處理的好處不僅僅在於簡化了使用流程，免除了客戶自己維護圖片轉碼叢集負擔，還大幅度降低了圖片相關的安全風險。眾所周知，圖片相關的 libjpeg, libpng 等庫是安全漏洞的重災區，UGC類的業務很難避免黑客上傳惡意圖片來攻擊。物件儲存的供應商能使用的手段也不僅僅是緊盯CVE及時升級，還包括了使用容器來加固轉碼引擎，定期清理容器來避免APT攻擊等手段。