編者按
在數字政府領域，許多項目中都有各種類型的文件，它們有不同的大小、不同的用途，甚至編碼方式都會千差萬別。我們希望通過OSS來將這些文件按照一定的規則存儲起來，在我們需要的時候，能很快的取出來，並且應用到當前的項目中，甚至能和其他的應用系統集成起來，形成一整套的基於OSS存儲的生態系統。百分點基於實踐探索自主研發出了OSS，可以將海量的網頁內容、圖片、音視頻等非結構化數據，在高併發的場景下被快速、準確的存儲及方便的下載。
對象存儲服務（Object Storage Service，簡稱OSS），是百分點對外提供的海量、安全、低成本、高可靠的對象存儲服務。用戶可以通過簡單的REST接口，進行數據的上傳和下載。同時，OSS提供Java語言的SDK，簡化用戶的編程。基於OSS，用戶可以搭建出各種個人和企業數據備份、業務數據應用等基於大規模數據存儲的服務。同時OSS還可以與其他組件搭配使用，廣泛應用於海量數據存儲與備份，數據加工與處理，內容加速分發，業務數據挖掘等多種業務場景。
1.架構設計
基於對OSS的要求，我們設計的架構如下圖所示：
我們採用了HBase+Ceph來進行底層存儲，對於小於1MB的數據進入HBase，對於大於1MB的數據進入Ceph，同時數據通過Tomcat提供對外服務。基於上面的架構，我們的OSS可以實現以下的性能目標。
1.1 高吞吐性
OSS的底層存儲充分利用各組件的性能優勢，來使整個集羣可以達到較高的吞吐量。
HBase（Hadoop Database），是一個高可靠性、高性能、面向列、可伸縮的分佈式存儲系統，利用HBase技術可在廉價PCServer上搭建起大規模結構化存儲集羣。對於小於1MB的文件寫入HBase是一個很棒的設計。
那麼大於1MB的文件，我們存入哪裏呢？有這麼幾種方案可供我們選擇，比如Hadoop，FastDFS，Ceph等組件。我們最終選擇了Ceph做大文件存儲。
Ceph是一種爲優秀的性能、可靠性和可擴展性而設計的統一的、分佈式文件系統。Ceph的開發目標可以簡單定義爲以下三項：
- 可輕鬆擴展到數PB容量
- 支持多種工作負載的高性能
- 高可靠性
1.2 高可用性
高可用性對文件存儲系統是極爲重要的，因爲數據是極爲寶貴的，如果數據在OSS中很容易丟失或者不可靠，那麼它的存在意義就不大了。
對於OSS的高可用，我們早就做了深思熟慮的思考。HBase的數據最終存儲HDFS中，而HDFS是指被設計成適合運行在通用硬件(commodity hardware)上的分佈式文件系統（DistributedFile System）。我們可以通過定義它的多副本機制來達到它的高可用性。
和HBase類似，Ceph也可以通過多副本機制來實現它的高可用性。
同時，我們可以定義存儲的文件的過期時間來避免存儲的文件無限增長，在我們的應用中，默認設置爲90天。
1.3 可擴展性
當系統的吞吐量越來越大，或者存儲容量以及快達到OSS所能承受的流量瓶頸時，我們可以通過橫向擴展相關組件來應對流量的變化。
對於直接對外提供Rest接口的Tomcat服務，如果單Tomcat服務器達到性能瓶頸時，我們可以增加Tomcat服務器來進行橫向擴展，同時爲了對外提供統一的網關，我們增加了LVS+Keepalived這一層來實現，如下圖所示：
正常情況下，LVS使用DR模式代理若干臺Tomcat服務器，keepalived是實現LVS的高可用的。當其中一臺LVS出現故障下線後，keepalived通過虛擬IP技術快速切換到另外一臺可用的LVS上。
另外對於HBase和Ceph的擴展性是簡單易於實現的，只需要增加待擴展的機器，進行相關配置，即可快速加入集羣，相應的數據也會進行rebalance。
1.4 限流算法
在上面的功能概覽中簡單的說明了在某些場景中我們需要進行流量限制，那麼這裏將詳細介紹限流的原理。
在OSS中，我們使用Guava的RateLimiter作爲限流的組件。Guava的RateLimiter的限流方式有兩種：漏桶算法和令牌桶算法。我們採用的是令牌桶算法。
對於很多應用場景來說，除了要求能夠限制數據的平均傳輸速率外，還要求允許某種程度的突發傳輸。這時候漏桶算法可能就不合適了，令牌桶算法更爲適合。如圖所示，令牌桶算法的原理是系統會以一個恆定的速度往桶裏放入令牌，而如果請求需要被處理，則需要先從桶裏獲取一個令牌，當桶裏沒有令牌可取時，則拒絕服務。
我們的OSS就是採用令牌桶的方式來對流量進行限制的，當客戶端以某一穩定的速率來向OSS寫入的時候，系統是穩定的並且大多數的時候是這樣的。但是我們有時需要應對流量峯值，這個時候超過我們規定的流量就會被限制。現在問題來了，被限制的流量如果直接丟棄，那麼可能重要的文件被丟棄，這樣顯然不符合我們對OSS定位爲高可用存儲系統的要求。於是在限流的邏輯中我們加入了以下處理流程：當流量達到系統的瓶頸時，我們將被限流的流量寫入kafka，等到系統負載降低的時候，再從kafka中讀取這部分流量重放至OSS,這樣既保證了OSS的穩定性，又解決因限流帶來的數據丟失問題。
2.功能概覽
2.1 文件上傳
客戶端以RESTFul接口方式向OSS服務器發送上傳文件的請求，OSS將文件存儲到HBase或Ceph中，然後向客戶端返回存儲的狀態。
我們將文件名作爲存儲的唯一標識，這樣設計的好處有兩點，第一，我們不需要返回用戶文件在OSS服務器的存儲路徑；第二，也可以避免同名文件反覆上傳。
2.2 文件下載
客戶端以RESTFul接口方式帶上需要查詢的文件名請求OSS服務器，OSS根據文件名查詢對應的文件，返回請求客戶端。
2.3 流量限制
流量限制是以一種被動的方式來對流量進行控制的方式。我們可以通過壓力測試來粗略估計OSS所能承受的最大壓力，然後在配置文件中配置限流的數值。這裏要注意的是，需要根據業務的特點對限制的流量進行處理，其一，可以完全丟棄掉被限制的流量；其二，也可以對限制的流量進行相應的處理。
3.場景分析
現以公司某項目做講解來進一步說明OSS在項目中的實際應用以及最佳實踐。
3.1 項目的現狀
3.1.1 流量情況
以中期某城市交付爲基準：每秒約120Gb流量，每天1.5億個文件，每秒大概1800個文件。
其它各分中心的數據均爲上述城市的倍數，比如A中心的比例係數爲33.33，那麼它每秒的流量約4000Gb，每天約34億個文件，每秒大概6萬個文件，以此類推。
3.1.2 單機性能
目前單機Tomcat能支撐最大12000TPS，對於各中心每秒的數據量，單機顯然不能支撐這麼大的數據量，我們需要採用Tomcat集羣來支撐這麼大的數據流量。
3.1.3 流量峯值
在進行機器數以及相關硬件進行評估時，需要考慮流量峯值的情況，我們一般以正常流量的2到3倍來進行規劃，比如，某個分中心的流量爲每秒1300Gb，那麼我們設計時就需要考慮峯值的情況，也就是最大能支撐每秒3900的流量。
3.2 集羣的設計目標
基於上面描述的項目現狀，經過分析，我們的整個OSS集羣需要實現以下設計目標：
- 各中心採用Tomcat集羣來支撐數據流量
- 各中心的流量均衡打到每臺Tomcat服務器
- 負載均衡設備的高可用
- 存儲服務的穩定性
3.3 最佳實踐
3.3.1 如何保證Tomcat單機的性能最優
我們主要從以下幾個方面來優化Tomcat的性能：
1）JVM內存大小
2）最大線程數（maxThreads）
3）最大連接數（maxConnections）
4）全連接隊列長度（acceptCount）
我們選用單臺機器來測試Tomcat的性能，硬件配置如下：
| CPU（Product Model） | CPU（Core） | Mem（GB） | HardDisk（Type） | HardDisk（RPM） |
|---|---|---|---|---|
| E5-2620 v2 | 24 | 64 | SATA | 7200 |
Tomcat的版本選用8.5.43。
測試的目標：
- 單臺Tomcat支持的最大併發數
- 單臺Tomcat支持的最大TPS
- NIO模型和APR模型的性能對比
測試工具使用：ApacheBench。
我們使用對比測試的方法，分別測試在上傳1KB，10KB，100KB，1M，10M，100M的時候，Tomcat各項指標的數值。
Tomcat配置：maxThreads=100，minSpareThreads=10，acceptCount=102400，maxConnections=1000000，acceptorThreadCount=2
JVM配置：-Xmx16384m -Xms16384m
-Xmn1024m -XX:+UseConcMarkSweepGC
-XX:MaxPermSize=256m
1、使用NIO模型的測試結果如下：
| 文件大小 | 併發數 | TPS | 成功率 |
|---|---|---|---|
| 1KB | 100 | 30173.99 | 100% |
| 1KB | 400 | 31222.82 | 99.99856% |
| 10KB | 100 | 25351.94 | 100% |
| 10KB | 400 | 25931.42 | 99.99889% |
| 100KB | 400 | 11399.33 | 100% |
| 100KB | 600 | 11266.33 | 99.99997% |
| 1MB | 500 | 1091.73 | 100% |
| 1MB | 700 | 1094.17 | 100% |
| 10MB | 20 | 58.64 | 100% |
| 10MB | 40 | 59.17 | 100% |
| 100MB | 2 | 4.20 | 100% |
| 100MB | 50 | 4.13 | 100% |
根據以上測試結果可得出以下結論：
1）在上傳相同文件大小的情況下，隨着併發數的增大，會出現一定的丟包情況；
2）在相同併發量的情況下，隨着上傳文件大小增大，吞吐量會隨之下降。
2、使用APR模型的測試結果如下：
| 文件大小 | 併發數 | TPS | 成功率 |
|---|---|---|---|
| 1KB | 100 | 31192.96 | 100% |
| 1KB | 200 | 31222.82 | 99.99856% |
| 10KB | 300 | 24777.20 | 99.99739% |
| 100KB | 500 | 10820.51 | 99.992275% |
| 1MB | 500 | 912.60 | 100% |
| 10MB | 20 | 69.72 | 100% |
| 100MB | 2 | 5.35 | 100% |
根據以上測試結果以及對比NIO模型的測試結果，我們可以得出以下結論：
1）小文件上傳APR模式不如NIO模式，大文件上傳APR模式要好於NIO模式；
2）隨着併發的增加，TPS先增加後減少，平均響應時間不斷增加；
3）小文件應該關注TPS，大文件應該關注平均響應時間；
4）小文件TPS大概在2萬到3萬之間，能接受的併發在300到500之間。
3.3.2 如何保證HBase存儲的穩定性
HBase以高吞吐著稱，那麼我們應該如何在保證高吞吐的情況下，能保證穩定的存儲。主要應該關注兩個點：
1）GC的次數以及停頓時間；
2）HBase的compaction機制。
3.3.2.1 GC調優
由於HBase是使用Java編寫的，所以垃圾收集（GC）對HBase的影響也是很大的，我們需要適當調整GC相關的參數，使得HBase能達到較好的性能和穩定的運行。在JVM中，有很多種垃圾收集器，我們在項目中使用的是CMS GC，下面首先介紹CMS GC的工作原理，再詳細說明調優的相關細節。
3.3.2.2 GC調優目標
在介紹具體的調優技巧之前，有必要先來看看GC調優的最終目標和基本原則：
1）平均Minor GC時間儘可能短；
2）CMS GC次數越少越好。
3.3.2.3 HBase 場景內存分析
一般來講，每種應用都會有自己的內存對象特性，分類來說無非就兩種：一種是對象的生存期較短的工程，比如大多數的HTTP請求處理工程，這類的對象可能佔到所有對象的70%左右；另一種是對象生存期居多的工程，比如類似於HBase，Flink等這類大內存工程。這裏以HBase爲例，來看看具體的內存對象：
1）RPC請求對象
2）Memstore對象
3）BlockCache對象
因此可以看到，HBase系統屬於對象生存期居多的工程，因爲GC的時候只需要將RPC這類對象生存期較短的Young區淘汰掉就可以達到最好的GC效果。
在HBase優化中比較關鍵的兩個GC的參數。
1）年輕代Young區的大小；
2）年輕代Young區中的Survivor區的大小以及進入老年代的閾值。
3.3.2.4 生產環境中的GC配置
假設我們機器的物理內存是80G，所以根據上面的分析，我們可以對相關的參數做如下配置：
1）緩存模式採用BucketCache策略Offheap模式
2）內存我們採用如下配置：
-Xmx64g -Xms64g -Xmn4g -Xss256k
-XX:MaxPermSize=512m
-XX:SurvivorRatio=2
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+CMSParallelRemarkEnabled
-XX:MaxTenuringThreshold=15
-XX:+UseCMSCompactAtFullCollection
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=75
-XX:-DisableExplicitGC
3.3.3 如何保證大流量情況下系統穩定運行
流量限制是以一種被動的方式來對流量進行控制的方式。我們可以通過壓力測試來粗略估計OSS所能承受的最大壓力，然後在配置文件中配置限流的數值。這裏要注意的是，需要根據業務的特點對限制的流量進行處理，其一，可以完全丟棄掉被限制的流量；其二，也可以對限制的流量進行相應的處理。
4.OSS監控
OSS在運行過程中，我們需要了解相關的監控信息，比如每種文件類型在一段時間的佔比，或者在一段時間的網絡吞吐量等等，下面就來一一介紹我們是如何來對OSS進行監控的吧。
4.1 以文件類型劃分的指定時間段內的總存儲佔比
該圖表用於統計當前OSS中各文件類型存儲的佔比。
4.2 以文件類型劃分的指定時間段內的文件數量佔比
該圖表用於統計當前OSS中各文件類型數量的佔比。
4.3 OSS服務指定時間段內的網絡吞吐量
該圖表用於統計OSS的吞吐量。
4.4 OSS服務指定時間段內的每秒併發處理數（TPS）
該圖表用於統計當前OSS的負載情況。
5.結語與展望
我們認爲，OSS一定會成爲一個集安全性、可靠性於一體的底層存儲服務。基於OSS，在公安領域可以存儲天網中的卡口和視頻數據，並與公安內部的其他應用形成一個基於高可用存儲、多方向應用的解決方案；在社會治理方面，可以存儲網絡上的各種類型的數據，包括文字、音頻以及視頻，通過使用人工智能分析其中的關聯性，爲社會提供更安全的保證。
本文轉載自公衆號百分點（ID：baifendian_com）。
原文鏈接：