網易云對象存儲系統架構實踐

   10年存儲老兵，對分布式文件系統、同意存儲等存儲產品有深入研究，曾任中科院、中科曙光等企事業機構。

一、對象存儲應用場景

IT時代產生的大部分數據都是沒有固定大小限制、沒有固定格式的非結構化數據（圖片、視頻、 文件、歸檔備份數據）等，面對如此龐大的數據量，時常需要專業的云存儲平臺幫助解決一站式全方位的需求。

針對存儲系統在擴展性、 可用性、可靠性上的擔憂，我們通過開發的全方位的SDK，快速提供了一種理想中的非結構化數據一站式解決方案。以下為幾種典型的引用場景：

1、資源分發下載

可以使用NOS并結合網易CDN服務實現一站式的數據上傳、存儲、下載分發服務，其對象包括：

• 網站、APP需要存儲、上傳和分發視頻(視頻網站、朋友圈)；

• 存儲、上傳和分發圖片（電商網站）；

• 發布APP安裝包等。

2、UGC業務場景

網易對象存儲提供邊緣節點上傳加速功能，其優勢為：

• 在不暴露NOS A/S KEY的情況下，讓移動端直接將數據上傳到NOS

• 利用分布全國的邊緣加速節點，更快的將數據上傳到NOS中，提高終端用戶上傳體驗

3、企業網盤

4 、云端數據處理

上傳文件到NOS后，可以很輕松地進行圖片處理服務和視頻處理服務。

5、網站/應用動靜分離

簡單管理網站上的圖片，腳本，視頻等靜態資源，通過BGP網絡或者CDN加速的方式，提供用戶就近訪問，有效降低WEB服務器負載，提升用戶體驗。

二、網易對象存儲核心競爭力

1、DDB分布式數據庫系統

分布式數據庫系統（Distributed DataBase，簡稱DDB）是網易杭研后臺技術中心研發的分布式關系數據庫平臺。

在NOS中用于元數據存儲，主要用于解決如下問題：

1）海量結構化數據存儲

2）高并發高吞讀數據訪問

均衡字段：用于計算哈希值的字段

兩級映射：結合哈希的高效性和路由表的可管理性

2 、DFS分布式文件系統

與之對應的，分布式文件系統（Ditributed FileSystem，簡稱DFB）是杭研后臺技術中心研發的分布式非結構化數據存儲平臺。

主要用于解決如下問題：

1）海量非結構化數據存儲

2）高并發吞吐數據訪問

3、富媒體服務

（1）概述

當前NOS承載著幾乎所有網易互聯網產品blob數據的存儲，圖片、視頻、附件等是最常見的應用場景，而其中很大一部分數據為圖片數據，比如網易lofter、網易云音樂、網易考拉海淘、易信朋友圈都有非常多的圖片應用場景。幾乎所有的這些產品都會大量得使用到NOS提供的圖片處理服務。

NOS圖片處理服務從2013年上線到現在已經上線差不多快3年半的時間， 圖片處理服務器從幾臺擴容到幾十臺；系統負載tps從幾百tps上升到現在的2w＋tps，近上百倍負載增長。功能從簡單的裁剪縮略到提供豐富的圖文水印、鏈式處理等功能，已能滿足專業的lofter圖片處理的需求。

架構不斷演變以適應更多的功能、性能、擴容性等各方面的需求。

以下為NOS圖片系統發展的timeline。

接下來我會從幾個方面介紹NOS圖片處理解決方案：

• 圖片核心處理單元

• 數據的獲取nosfs

• 系統過載控制

• 圖片處理架構

（2）圖片核心處理單元Tobie

分治永遠是解決所有復雜問題的解決方案,在計算機科學中體現的尤為明顯。如上為一個基本的圖片核心處理單元。主要分為以下幾個層次接口層、并發層、處理層、數據層。

• 接口網絡層

接口層向上層調用者提供HTTP RestFul Service，如下為對存儲在nos的一張圖片資源 Koala.jpg 執行簡單的縮略操作。

接口層為基于Libevent實現的 C++ http服務。Master負責網絡層的處理，包括接收來自客戶端的請求，進行合理解析分發到任務隊列，以及接收來自worker的處理結果并返回給客戶端。Master基于libevent實現Non-Blocking的網絡IO處理，所以基本單線程能夠hold住整個圖片處理單元的網絡負載。

• 并發處理層

并發層worker從任務隊列中獲取請求并進行實際的圖片處理工作，并發層Processor為通用的數據處理單元，當前已經整合Grapbic Magic 圖片處理單元以及ffmpeg視頻處理單元，后續如果有新的處理服務也可以非常方便的整合實現其它的處理功能。同時Processor也實現了Lua 擴張功能，可以非常方便的進行外部命令調用，從而非常快速的整合新的處理功能。

• 數據接口層

數據層實現了內存的數據接口以及本地文件系統的POSIX訪問接口。數據資源可以是本地資源，也可以是來自網絡資源。本地資源提供內存和File接口是非常直接的，網絡上的資源是(對于我們來說主要也是通過網絡方式來獲取NOS上的資源)通過基于nosfs模塊實現將NOS HTTP Rest API接口到Posix接口的轉換。

（3）nosfs

NOS提供的是標準的HTTP Restful API，而某些圖片或者視頻處理庫的只提供了基于本地文件的處理接口；所以面對這樣的場景我們基于fuse（用戶態文件系統開發框架）實現了nosfs，將NOS上的資源以文件系統中文件的 方式暴露給上層用戶。

NOFS的基本框架如上圖所示。APP（Tobie） 使用 open、read、write等文件系統POSIX API接口讀取文件內容，陷入內核后，Fuse 內核模塊會將用戶的調用請求轉發給上層我們基于libfuse實現的NOSFS模塊，NOSFS 將文件系統形式Read、Write 調用轉化為NOS HTTP PUT GET 請求實現協議的轉換和數據的讀取和寫入。

（4）處理單元的過載控制

1 ）過載與排隊

• 過載問題與解決方案

對于時延敏感的服務（同步調用），當外部請求超過系統處理能力，如果系統沒有做相應保護，可能導致歷史累計的超時請求達到一定規模，像雪球一樣形成惡性循環。由于系統處理的每個請求都因為超時而無效，系統對外呈現的服務能力為0，且這種情況下不能自動恢復。

對于圖片處理系統來說，是典型的CPU消耗性業務，往往32核機器對外只能提供幾百的TPS的服務能力。如果系統在高負載情況下CPU成為瓶頸而請求還是在不斷累積，那么很容易造成惡性循環。

NOS圖片服務剛上線的時候就因為此類問題吃過不少虧，下圖簡要說明了圖片服務剛上線之前的構架。邏輯層(tomcat)是統一的，不僅承擔了用戶數據的讀寫，還要轉發處理圖片服務請求。某次系統發生局部故障，Tobie處理集群中的某臺機器處理能力降低不能快速進行圖片處理，但是tobie的IO線程并沒有block，還可以正常得進行請求得接收，從而導致請求積壓，這不僅僅導致我們Tobie做了很多無用功（處理隊列中已經超時的請求），更重要的是導致上層調用方(諸業務服務器)等待在這個故障圖片處理節點上等待圖片處理結果，而不能處理其它包括文件讀寫等核心業務。

所以事后，我們做的第一件事情是核心服務的拆分，將上傳下載、圖片處理業務邏輯隔離開來。并且后續又針對圖片處理核心模塊系統層次的做了深層次的梳理，包括操作系統層次，保留libevent網絡庫層次，應用層次等。

如上圖所示，從服務端收到客戶端發送的Sync信號連接，連接進入Sync-Received隊列，到三次握手完成進入Establish隊列之后；再到上傳網絡庫libevent通過epoll多路服用方式將底層的連接Accept放入event隊列；直到連接上接收到一個完整的HTTP請求之后，IO線程回調上層應用的回調函數將HTTP請求插入請求隊列，最后worker從請求獲取請求進行處理。

當然系統層次或者libevent層次我們能夠控制的余地較小，在底層做控制也不是非常優雅和通用，所以我們通過在應用層對請求隊列做了一些控制，比如限制隊列的長度，超過隊列長度的時候直接拒絕請求；又比如每個請求插入隊列的時候打上時間戳，worker取請求的時候發現已經等待很長時間了直接丟棄請求返回錯誤等等。另外我們結合nginx的健康檢查機制，在服務已經過載情況下自動將請求調度到其它節點。

總結來說，以下幾點為我們實踐過程中總結出來的構架設計的關鍵點：

• 分布式系統中一個節點過載可能導致整個服務不可用，（tomcat類同步調用框架尤為容易受影響）

• 核心服務的隔離，拆分

• 前端不能信任后端, 所以第其他模塊調用必須設置合理超時、一定的保護后端的責任

• 后端應該盡力而為，服務不了果斷拒絕，SLA

2）圖片處理架構

如上為NOS圖片處理的整體框架，Nginx將圖片請求轉發到NosMeida，NosMedia層次的功能主要為圖片協議正確性檢查，調用NosAuth對用戶的請求進行認證。ATS(apache traffic server)緩存集群用戶緩存圖片處理結果(當前NOS使用的是代理緩存的模式)，tobie處理集群氛圍大集群以及小集群，小集群用戶處理較小的圖片資源的處理，大集群用戶處理超大圖片、以及針對視頻的操作。

（3）NCAN上傳加速

1. 客戶端到基站的丟包率非常高

2. 基站到數據中心的RTT也比較高

導致客戶端到數據中心的網速較低，上傳文件失敗率較高。

將上傳文件分為過程一分為二：

1. 客戶端到基站的帶寬低，但是rtt較低

2. Rtt較高，但是帶寬較高

我們將邊緣節點部署到離用戶最佳的地方。

針對兩個階段分別進行優化，加速上傳優化。

NOS在全球各地部署了上傳加速節點，幫助用戶以最快的速度上傳數據。上傳加速節點數量和線路在持續增加和優化。

關鍵技術點：

1）上傳協議

傳統標準OSS上傳協議：

• 分塊上傳、最小分塊5M

• 為服務端設計

NOS直傳協議：

• 支持任意大小分片

• 分片append協議

自定義的上傳協議，提高文件上傳的成功率。

2）移動端上傳優化

在一個TCP鏈接上并發發送數據，充分利用廣域網帶寬，提高上傳速率，Pipeline測試結果如下：

Pipeline能夠大幅度提高上傳速率。

3）廣域網TCP、HTTP優化

邊緣節點及時提供響應，在上傳完成之后，邊緣節點和中心機房進行一次同步即可，有效率用客戶端到邊緣節點&邊緣節點到中心機房兩段帶寬。

對邊緣節點到中心階段之間網絡進行優化（客戶端到邊緣節點的網絡不在可控范圍之內），主要是TCP send buffer的調優，使buffer不成為上傳速度的瓶頸，在不使用專線的情況下達到最優效果。

最下面一條線是杭州中心機房的base數據，我們對藍線代表的邊緣節點進行了優化，并對未進行優化的邊緣節點進行了對比測試，相應時間差距可達到70ms以上。

Q&A

Q1： Lua 的作用是什么？

A1： Lua的作用是用來做圖片處理在數學上的一些換算工作，在測試等階段可以做到不用重新編譯可以對一些裁剪縮略的規則進行直接的調整。

Q2： golang 是用來做哪一層的？

A2： golang 其實在我們系統里面很多地方用到，比如替換tomcat 這樣的thread base web server的，實現更高的并發性，比如上面提的圖片處理進來之后的接口層次的服務處理都是用golang 做的。

Q3： 視頻處理方面的，有沒有檢測視頻質量或者被人為修改的檢測算法？

A3： 沒有，整合視頻服務這塊，當前PPT里提到的，我們的功能比較簡單，主要是一些視頻云信息的獲取一集截圖之后結合圖片處理的一整個流程的傳來服務，比如打水印的，縮略啊，轉格式啊等等，你說的檢測視頻質量這沒有做。其他比如分布式轉碼等功能，不在今天的分享范圍內，后續可以再約。

Q4： 存儲用ceph？

A4： 存儲是自行開發的分布式文件系統，對小文件存儲做了大量的優化。

 

 

 

 

 

來自：https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650757065&idx=2&sn=d462bec566d832e3a71a4a8b53d2e800&chksm=f3f9e25cc48e6b4a0a4d17a5b0a78197116f903031b62d809d806f614ceea31a6f1f0ac07338&scene=0&key=&ascene=7&uin=&devicetype=android-23&version=26031b31&nettype=WIFI