百分點大資料技術團隊：可插拔OSS架構設計和實戰經驗

編者按：隨著網際網路、大資料和人工智慧等技術的發展，資訊資源得到最大程度的共享，但隨之而來的海量檔案存取的功能和效能問題也日漸突出。在政務領域解決方案中，物件儲存往往扮演著非常重要的角色，如全國各地的健康寶的頭像和核酸報告檔案或圖片的高速併發存取，不同地區應用介面和後端儲存的快速適配等。

百分點科技基於海外多個專案的建設經驗，沉澱出基於HBase和Ceph的混合物件儲存服務，能夠有效解決海量檔案高速儲存的問題，並通過寫事件通知，將小檔案內容傳輸至Kafka，實現下游系統以順序方式讀取檔案，提升系統整體的吞吐效能。

一、 背景介紹

百分點科技早期的OSS整體架構如下圖所示，客戶端通過LVS代理向OSS服務上傳檔案，OSS服務會根據檔案大小路由到不同的儲存服務。

由於資料分佈廣，所以OSS服務部署在不同的資料中心，每個中心OSS服務(包含儲存服務)的叢集規模從十幾臺到五六十臺伺服器不等，共儲存十餘PB的檔案資料。

雖然老版OSS通過了海量資料的考驗，但針對不同場景仍有不足，具體表現如下：

• 針對演示環境或中小規模資料場景，HBase和Ceph的混合方案顯得過於笨重，對於這類場景，本地檔案系統或單節點的MinIO即可滿足需求；
• 老版架構層面缺乏設計，僅完成特定場景下的基本功能，不同功能的程式碼耦合性太強，很難擴充套件，比如檔案型別探測，基於檔案後設資料的儲存路由等；
• 老版不管檔案大小，均使用位元組陣列儲存所有檔案，對記憶體佔用過大。

為提升效益，百分點大資料技術團隊對老版OSS進行了改造升級，新版OSS不僅擁有出色的檔案存取能力，而且更加靈活，具體亮點功能如下：

• 全域性外掛化設計，擴充套件能力非常好；
• 高效能的檔案型別識別，支援數千種型別，並且支援自定義分類介面；
• 基於後設資料的鏈式過濾，如基於檔案型別或其它後設資料對檔案進行過濾；
• 動態限流控制，防止單臺OSS服務節點壓力過大；
• 動態路由控制，如基於後設資料動態路由至後端儲存；
• 支援大量的儲存外掛，可以基於不同場景進行差異化配置；
• 豐富的事件通知，如讀寫通知，讀寫錯誤通知，讀寫效能通知等；
• 支援Office及PDF等文件的內容提取；
• 支援自定義檔案後設資料資訊並儲存；
• 效能增強，充分展現後端儲存及網路的IO能力。

二、 應用設計

1. 整體設計

針對老版OSS的痛點，並圍繞OSS服務功能本身，百分點科技重新設計了OSS服務，新版OSS的架構如下圖所示：

服務編排

Processor用於編排檔案讀寫邏輯，可呼叫Router、Detector、Filter、Storage和Notification介面。所有使用者API的請求均重定向至Processor，由Processor統一管理。

檔案分類

在老版OSS服務中，一大使用痛點是檔案型別是不可知的，強依賴客戶端提供的僅僅幾種檔案型別資訊。因此，在新版設計中，百分點科技引入了檔案型別探測的功能，能夠探測出檔案的具體型別，比如圖片會識別為image/jpg、image/png等不同的細分型別。

鏈式過濾

在老版OSS服務中，不管檔案型別和大小以及來源，上傳檔案是全部儲存的，但是在客戶實際使用中，可能只會用到特定部分的資料，所以，百分點科技增加了根據來源，檔案型別等的過濾鏈，過濾到用不到的檔案。如果之前不需要某種型別檔案，現在需要了，修改過濾規則即可。

動態路由

在老版OSS服務中，我們使用HBase+Ceph作為後端的儲存服務，使用檔案大小來決定是存入HBase還是Ceph。但這個邏輯的實現程式碼耦合性很強，想要增加其他的規則很麻煩。因此，在新服務中將這個功能抽取成路由外掛，可以自定義規則實現動態路由。

內容提取

在老版OSS服務中，對於office和PDF類等文件，在ES中是索引不到文件內容的，在新服務中，我們在上傳檔案時增加了檔案型別的探測，如果探測到是office和PDF類等文件，則通過Tika提取出內容，最終內容存入到ES中就可以檢索了。

2. API介面設計

API層主要設計瞭如下幾個API：

上傳介面

POST /upload?file_id=eb42cf02-9865-11ec-b909-0242ac120002&file_name=Meeting.pdf

下載介面

GET /download?file_id=eb42cf02-9865-11ec-b909-0242ac120002

批量下載介面

GET /batchDownload{"fileIds": "eb42cf02-9865-11ec-b909-0242ac120002, 629fe326-9868-11ec-b909-0242ac120002"}

配額查詢

GET /getAvailableTokens

3. 類介面設計

這樣通過介面的方式實現了各個元件的定義，具體的功能實現在具體元件的實現中實現，具有很大的靈活性和擴充套件性。

如上面類關係圖所示，儲存可以選擇HBase或者S3協議相容型的儲存。同時，各個元件的選擇用配置引數的方式配置在配置檔案中，這樣切換不同型別儲存或者不同訊息通知等元件的時候，修改配置檔案就可以實現。

4. 配置設計

服務的配置基於SpringBoot的YML配置檔案進行配置，但是為了靈活控制服務各外掛的行為和功能，我們使用了SpringBoot動態注入Bean的方式類來生成具體的外掛。比如關於路由器的配置如下：

具體程式碼如下：

public class SizeBasedRouter implements Router {

private String id;

private String smallFileStorageId;

private String largeFileStorageId;

}

@Bean(name = "router")

@Scope("singleton")

public Router router() throws Exception {

Map<String, Object> config = processorProperties.getRouter();

String klass = MapUtils.getString(config, "class");

Object object = newObject(klass, config);

return (Router) object;

}

private <T> T newObject(String className, Map<String, Object> properties) throws ClassNotFoundException, InstantiationException, IllegalAccessException, InvocationTargetException {

Assert.hasLength(className, "Class property is mandatory");

Class klass = Class.forName(className);

Object object = klass.newInstance();

BeanUtils.populate(object, properties);

return (T) object;

}

5. 外掛設計

Processor

Processor用於編排檔案讀寫邏輯，可呼叫Router，Detector，Filter，Storage和Notification介面。所有使用者API的請求均重定向至Processor，由Processor統一管理。

類圖如下：

Detector

Detector用於檔案型別識別。本系統提供FastDetector，CustomDefaultDetector， ExtraOfficeDetector， FastStringDetector， StringDetector，TokenDetector和TextDetector等。

基於Tika型別探測的基礎上進行擴充套件，通過Stream頭尾位元組，綜合運用了Tika自身和自定義的擴充套件探測能力，可以實現對上傳檔案型別的快速探測，不同檔案型別的探測能力達到10w/s，甚至100w/s。

其中，帶Fast字首的為優化版本， 適合海量資料的檔案型別探測，單執行緒探測效能在每秒數萬至百萬級別。

類圖如下：

Filter

Filter用於檔案過濾，因為很多檔案是沒有價值的圖片/js/css/二進位制檔案等，為了提高OSS的整體效率，實現了基於網站和型別的檔案過濾功能。

檔案過濾正則示例：

"*:+|+text/html|+text/xml|+text/plain|+application/*json*|+application/*xml*|+application/*form*|+message/*|+multipart/*

+application/pdf|+application/*office*|+application/*word*|+application/*excel*|+application/*powerpoint*

+application/*document*|+application/zip|+application/rar|-*/*"

類圖如下：

RateLimiter

RateLimiter用於限流，根據既定規則在請求過載的時候進行限流。類圖如下：

Router

Router用於對讀寫請求進行路由，以實現大小檔案分發、按型別分發等功能，可同時路由到多個儲存以實現讀負載均衡或雙寫等特殊場景。此外，Router方法可返回null值，表示該物件被過濾。可包括SingleRouter，SizeBasedRouter。如果在寫時路由變數多於讀時路由變數，則可能需要使用快取記錄檔案ID、檔案路徑及儲存ID間的關係。

類圖如下：

Storage

Storage用於呼叫實際的儲存元件進行讀寫，已相容HBase，FastDFS和Ceph、 SeaweedFS、MinIO等相容S3協議儲存，如果要實現一個服務目前不支援的後端儲存，只需要實現相應後端儲存的Storage外掛即可。

類圖如下：

Notification

Notification用於呼叫各類通知元件，用於讀寫事件、錯誤及效能問題的通知，如果需要對檔案進行進一步處理，也可以通過Spark或者Flink消費Kafka中的資料進行處理。

類圖如下：

6. 監控設計

OSS服務監控主要使用Prometheus+Grafana實現，各元件使用各自Exporter，或者自身作為Endpoint為Prometheus提供監控資料，Grafana負責監控展示。通過監控能夠觀測到叢集的整體執行情況，及時告警出現的問題，方便問題排查。

整體OSS服務的監控架構如下：

業務監控

主要是用來監控OSS的吞吐情況，如下圖，顯示的是OSS每秒上傳檔案的個數。

應用系統監控

主要是監控OSS服務的記憶體使用和垃圾回收情況。

後端儲存監控

因為使用HBase和Ceph作為混合儲存，因此後端儲存監控也分為HBase和Ceph的監控。

HBase監控如下圖：

Ceph監控如下圖：

三、 效能測試

1. 測試目標

通過Jmeter進行壓力測試，得出OSS服務對於不同型別、不同大小檔案的吞吐情況，以驗證新版OSS服務是否達到設計之初的目標，並將測試資料用作後續OSS叢集規劃的重要依據；在壓測的過程中通過Jprofiler進行觀測，找出效能瓶頸點並進行優化，最終提高服務的整體效能。

2. 測試工具

• 效能壓測工具：Apachejmeter
• 效能分析工具：Jprofiler
• 監控工具：Prometheus+Grafna

3. 測試環境

元件共使用了6臺機器，OSS服務單獨使用一臺，HBase、Ceph和Kafka部署在5臺伺服器上，具體部署情況如下：

4. 軟體版本

5. 測試用例

對於不同型別和大小的測試用例，在File Path中指定相應的檔案，URL中最後一個欄位為檔名，使用Jmeter提供的UUID函式隨機生成不同的檔名以使檔案存入HBase不同的Region裡面。

不同型別的檔案分為不同Jmeter指令碼，如下圖所示：

通過對不同型別檔案的上傳測試可以得出不同型別檔案的吞吐情況，因為新版OSS服務增加了對無用型別檔案的過濾，所以即使相同大小的兩個檔案，如果其中一個檔案被Filter元件過濾掉，兩個檔案的吞吐量會相差很大。

6. 測試結果

• 在檔案沒被過濾的情況下，效能基本與老版OSS效能持平，不同的檔案大小下各有差異；
• 在多型別檔案混合負載測試，效能達到78,000/s，遠遠優於老版OSS，並且在過濾掉資料後能節省不少儲存空間。

具體各型別檔案的測試結果如下：

結語

新版可插拔OSS架構設計不僅擁有出色的檔案存取能力，而且更加靈活，檔案儲存服務是百分點科技常用場景之一，結合資料特點，部署靈活可擴充套件並且高效能的檔案儲存服務，不但能更好地滿足客戶需求，也能在一定業務場景下節省大量的儲存伺服器，是對相關業務整體解決方案的一大助力。

目前，該方案已經投入到百分點科技CBB（Common Building Block）等專案建設中，相信隨著實踐經驗的累積和技術的不斷優化升級，百分點科技將會為客戶提供更加完善的OSS服務。

關注公眾號：百分點科技，瞭解更多資訊。