摘要：于是便誕生了隨行付分布式文件系統(tǒng)簡稱，提供的海量安全低成本高可靠的云存儲(chǔ)服務(wù)。子系統(tǒng)相關(guān)流程圖如下核心實(shí)現(xiàn)主要為隨行付各個(gè)業(yè)務(wù)系統(tǒng)提供文件共享和訪問服務(wù)，并且可以按應(yīng)用統(tǒng)計(jì)流量命中率空間等指標(biāo)。

傳統(tǒng)Web應(yīng)用中所有的功能部署在一起，圖片、文件也在一臺(tái)服務(wù)器；應(yīng)用微服務(wù)架構(gòu)后，服務(wù)之間的圖片共享通過FTP+Nginx靜態(tài)資源的方式進(jìn)行訪問，文件共享通過nfs磁盤掛載的方式進(jìn)行訪問，無論是單體架構(gòu)還是微服務(wù)架構(gòu)下的應(yīng)用都存在大量圖片、文件讀寫操作，但是昂貴的磁盤空間、高性能服務(wù)器無疑增加了運(yùn)營成本。

所以我們希望文件服務(wù)也能微服務(wù)、獨(dú)立化，這樣既能降低運(yùn)營成本，又能對(duì)文件進(jìn)行統(tǒng)一的管理和維護(hù)，所以搭建獨(dú)立的文件服務(wù)是解決文件共享、釋放業(yè)務(wù)系統(tǒng)壓力的最優(yōu)選擇。于是便誕生了隨行付分布式文件系統(tǒng)簡稱OSS(Object Storage Service)，提供的海量、安全、低成本、高可靠的云存儲(chǔ)服務(wù)。它具有與平臺(tái)無關(guān)的RESTful API接口，能夠提供數(shù)據(jù)可靠性和服務(wù)可用性。

隨著互聯(lián)網(wǎng)圖片、視頻時(shí)代的到來，對(duì)文件的處理成為各個(gè)業(yè)務(wù)系統(tǒng)面臨的巨大挑戰(zhàn)，沒有文件服務(wù)器之前，系統(tǒng)之間處理圖片的方式大相徑庭：FTP、NFS、數(shù)據(jù)庫存儲(chǔ)等等，雖然都實(shí)現(xiàn)了對(duì)文件的存儲(chǔ)、訪問，但是系統(tǒng)之間很難達(dá)到文件共享，所以文件服務(wù)可以形成一個(gè)統(tǒng)一的訪問標(biāo)準(zhǔn)，降低各個(gè)系統(tǒng)之間的互相依賴，提高開發(fā)效率、釋放業(yè)務(wù)系統(tǒng)壓力，所以文件服務(wù)的意義如下：

降低WEB服務(wù)器壓力

分擔(dān)業(yè)務(wù)服務(wù)器的I0、流程負(fù)載，將耗費(fèi)資源的文件訪問、讀寫操作分離到文件服務(wù)器，可以提高服務(wù)器的性能和穩(wěn)定性，降低WEB服務(wù)器成本。

獨(dú)立服務(wù)易擴(kuò)展

文件服務(wù)像微服務(wù)架構(gòu)獨(dú)立化，可以有針對(duì)性的進(jìn)行配置提高性能；獨(dú)立域名讓圖片管理、CDN緩存文件更方便，隨時(shí)擴(kuò)展文件服務(wù)器數(shù)量，即不影響業(yè)務(wù)又能增加文件服務(wù)器并發(fā)訪問。

統(tǒng)一訪問格式

開發(fā)者無需關(guān)心存儲(chǔ)路徑、存儲(chǔ)介質(zhì)、文件備份等，豐富的API幫助系統(tǒng)快速存儲(chǔ)、共享文件，提高項(xiàng)目開發(fā)速度。

安全認(rèn)證

文件服務(wù)對(duì)資源訪問可以增加認(rèn)證、權(quán)限等安全措施，防止服務(wù)器資源被盜用，有效的隔離了數(shù)據(jù)訪問。

為便于更好的理解對(duì)象存儲(chǔ)OSS，需要了解對(duì)象存儲(chǔ)中的幾個(gè)概念。

對(duì)象/文件(Object)

對(duì)象是OSS存儲(chǔ)數(shù)據(jù)的基本單元，也被稱為OSS的文件。對(duì)象由元信息(Object Meta)，用戶數(shù)據(jù)(Data)和文件名(Key)組成。對(duì)象由存儲(chǔ)空間內(nèi)部唯一的Key來標(biāo)識(shí)。對(duì)象元信息是一個(gè)鍵值對(duì)，表示了對(duì)象的一些屬性，比如最后修改時(shí)間、大小等信息，同時(shí)用戶也可以在元信息中存儲(chǔ)一些自定義的信息。對(duì)象的生命周期是從上傳成功到被刪除為止。在整個(gè)生命周期內(nèi)，對(duì)象信息不可變更。重復(fù)上傳同名的對(duì)象會(huì)覆蓋之前的對(duì)象，因此，OSS 不支持修改文件的部分內(nèi)容等操作。

存儲(chǔ)空間(Bucket)

存儲(chǔ)空間是用于存儲(chǔ)對(duì)象(Object)的容器，所有的對(duì)象都必須隸屬于某個(gè)存儲(chǔ)空間。可以設(shè)置和修改存儲(chǔ)空間屬性用來控制地域、訪問權(quán)限、生命周期等，這些屬性設(shè)置直接作用于該存儲(chǔ)空間內(nèi)所有對(duì)象，因此可以通過靈活創(chuàng)建不同的存儲(chǔ)空間來完成不同的管理功能。

同一個(gè)存儲(chǔ)空間的內(nèi)部是扁平的，沒有文件系統(tǒng)的目錄等概念，所有的對(duì)象都直接隸屬于其對(duì)應(yīng)的存儲(chǔ)空間。
每個(gè)用戶可以擁有多個(gè)存儲(chǔ)空間。
存儲(chǔ)空間的名稱在 OSS 范圍內(nèi)必須是全局唯一的，一旦創(chuàng)建之后無法修改名稱。
存儲(chǔ)空間內(nèi)部的對(duì)象數(shù)目沒有限制。

訪問密鑰(AppKey & AppSecret)

AppKey代表應(yīng)用身份，AppSecret即應(yīng)用密鑰，用于生成簽名認(rèn)證，請(qǐng)求文件服務(wù)時(shí)必須要傳遞appkey和簽名生產(chǎn)的token，網(wǎng)關(guān)根據(jù)請(qǐng)求驗(yàn)證請(qǐng)求的合法性性和時(shí)效性。

應(yīng)用場景 功能描述

上傳文件 創(chuàng)建存儲(chǔ)空間后，您可以上傳任意文件到該存儲(chǔ)空間

搜索文件 可以在存儲(chǔ)空間中搜索文件或文件夾

查看或下載文件 通過文件 URL 查看或者下載文件

刪除文件或文件夾 刪除單個(gè)或者多個(gè)文件/文件夾，還可以刪除分片上傳產(chǎn)生的碎片，節(jié)省存儲(chǔ)空間
訪問權(quán)限 可以通過應(yīng)用授權(quán)和桶授權(quán)的方式，授予存儲(chǔ)空間和對(duì)象訪問權(quán)限的訪問策略

訪問信息 自動(dòng)記錄對(duì)OSS資源的詳細(xì)訪問信息

防盜鏈 防止OSS上的數(shù)據(jù)被其他人盜用，設(shè)置防盜鏈

監(jiān)控服務(wù) 預(yù)警OSS服務(wù)使用情況的實(shí)時(shí)信息，如基本的系統(tǒng)運(yùn)行狀態(tài)和性能

API和SDK OSS 提供 RESTful API和各種語言的SDK開發(fā)包方便您快速進(jìn)行二次開發(fā)
架構(gòu)設(shè)計(jì)

OSS以分布式文件系統(tǒng)ceph作為底層存儲(chǔ)，支持SDK或者瀏覽器以http的形式上傳和下載文件，網(wǎng)關(guān)負(fù)責(zé)路由訪問請(qǐng)求到文件服務(wù)集群ossWork，ossWork生成文件唯一保存路徑后存儲(chǔ)文件到ceph，并返回加密后訪問地址給用戶。 架構(gòu)圖如下：

1.OSS采用OpenResty作為網(wǎng)關(guān)處理請(qǐng)求轉(zhuǎn)發(fā)和校驗(yàn),OpenResty匯聚了nginx的核心功能模塊，還支持lua腳本方便對(duì)nginx功能的擴(kuò)展，而且nginx多路復(fù)用機(jī)制和非阻塞的IO非常適合耗時(shí)短、業(yè)務(wù)簡單的校驗(yàn)操作：權(quán)限驗(yàn)證、防盜鏈、黑白名單等，不僅如此nginx還能作為網(wǎng)關(guān)的緩存，這些特性極大提升了網(wǎng)關(guān)性能和并發(fā)訪問。

2.ossWork作為文件服務(wù)，處理圖片水印、縮放、url加密、解密等，還封裝與底層存儲(chǔ)的交互。

3.ossKeeper作為文件管理后臺(tái)，負(fù)責(zé)權(quán)限接入注冊、申請(qǐng)、監(jiān)控報(bào)表展示。

4.ossMonitor日志收集、計(jì)算匯總、數(shù)據(jù)存儲(chǔ)。

5.ossBackup負(fù)責(zé)文件異步備份。

oss子系統(tǒng)相關(guān)流程圖如下：

OSS主要為隨行付各個(gè)業(yè)務(wù)系統(tǒng)提供文件共享和訪問服務(wù)，并且可以按應(yīng)用統(tǒng)計(jì)流量、命中率、空間等指標(biāo)。下面將介紹OSS核心功能以及實(shí)現(xiàn)。主要包括：緩存、用戶認(rèn)證、權(quán)限管理、url加密解密、監(jiān)控統(tǒng)計(jì)等。

提升性能的關(guān)鍵是緩存，OSS采用二級(jí)緩存：瀏覽器緩存、網(wǎng)關(guān)層緩存提升響應(yīng)速度，具體如下：

第一次請(qǐng)求文件時(shí)，OSS返回文件給瀏覽器http的狀態(tài)碼是200

第二次請(qǐng)求時(shí)同一個(gè)文件時(shí)，服務(wù)器根據(jù)請(qǐng)求中HTTP協(xié)議中的max-age/Expires，判斷文件未修改，返回狀態(tài)碼403，告訴瀏覽器可以繼續(xù)使用本地緩存

第三次請(qǐng)求F5強(qiáng)制刷新，網(wǎng)關(guān)根據(jù)If-Modified-Since、Cache-Control:no-cache和Pragma:no-cache等信息重新返回nginx中緩存文件

第四次請(qǐng)求url時(shí)，requesturi不一樣但文件是同一個(gè)，nginx根據(jù)requesturi判斷網(wǎng)關(guān)中無此文件，請(qǐng)求底層存儲(chǔ)返回文件。

為避免文件、圖片盜用，浪費(fèi)服務(wù)器流量和IO等資源，OSS采用防盜鏈的方式認(rèn)證請(qǐng)求。每個(gè)使用OSS服務(wù)的系統(tǒng)都需要進(jìn)行注冊、申請(qǐng)應(yīng)用，成功后自動(dòng)生成appkey、appsecret。appkey代表應(yīng)用身份，appsecret即應(yīng)用密鑰，用于生成簽名認(rèn)證，請(qǐng)求文件服務(wù)時(shí)必須要傳遞appkey和簽名生產(chǎn)的token，網(wǎng)關(guān)根據(jù)請(qǐng)求驗(yàn)證請(qǐng)求的合法性性和時(shí)效性。后臺(tái)管理appkey的生成及防盜鏈的簽名如下圖：

手機(jī)端認(rèn)證同server端一樣，但是由于賬戶信息的安全問題，appkey和appsecret只能保存在服務(wù)端，手機(jī)終端訪問oss時(shí)無法生成簽名，那么手機(jī)端如何訪問oss服務(wù)？這里我們采用oauth認(rèn)證的原理：

app用戶登錄終端系統(tǒng)，App發(fā)送請(qǐng)求OSS request請(qǐng)求

server收到請(qǐng)求后，向OSS申請(qǐng)資源的臨時(shí)授權(quán)token

OSS接收授權(quán)請(qǐng)求后，生成臨時(shí)訪問token返回給server

server組裝文件地址與臨時(shí)的token，返回給app

每個(gè)應(yīng)用有了自己的appkey，文件訪問時(shí)通過appkey驗(yàn)證身份，默認(rèn)文件的歸屬只有上傳者可以查看或修改，上傳者可以授權(quán)給其他賬戶，通過在后臺(tái)管理-權(quán)限配置功能授權(quán)授權(quán)的級(jí)別分為：修改、查看、刪除，不同的級(jí)別對(duì)應(yīng)不同的操作，后臺(tái)管理系統(tǒng)會(huì)實(shí)時(shí)同步文件權(quán)限到文件系統(tǒng)。這樣其他賬戶只需要傳遞自身的appkey就可以對(duì)此文件訪問。具體流程及具體配置如下：


URL加解密、規(guī)范（實(shí)現(xiàn)參考）

底層存儲(chǔ)中的文件名稱必須全局唯一，oss采用自定義算法生成文件名稱，命名規(guī)范=時(shí)間戳+分隔符+線程ID+分隔符+進(jìn)程ID+分隔符+客戶端IP，URL規(guī)范圖解如下：

為了保證oss服務(wù)器的安全，防止程序文件和目錄外泄，oss對(duì)url進(jìn)行了私有協(xié)議的加密，按分隔符“_”對(duì)每一項(xiàng)進(jìn)行base64編碼，再按62位字典碼加密生成加后的url，當(dāng)然也有其他的算法實(shí)現(xiàn)，是要實(shí)現(xiàn)url加密即可。解密是對(duì)加密的逆向操作，解密后的url即為儲(chǔ)存的訪問url。服務(wù)端的規(guī)范樣例及客戶端的url規(guī)范樣例：


oss統(tǒng)計(jì)監(jiān)控

為保證文件服務(wù)的質(zhì)量和可靠性，系統(tǒng)的監(jiān)控和告警是必不可少的，各個(gè)階段的運(yùn)行信息，以日志的形式寫到文件中，再使用Flume日志收集組件采集各個(gè)子系統(tǒng)的日志，按日志類別直接發(fā)送到kafka的不同topic，ossMonitor讀取kafka中消息，以時(shí)間為單位計(jì)算流量、命中率，以空間為單位統(tǒng)計(jì)使用率，根據(jù)上傳日志是否有異常發(fā)送告警郵件，流程如下：

Flume是由cloudera軟件公司產(chǎn)出的可分布式日志收集系統(tǒng),由source,channel,sink三個(gè)組件組成：

Source:

從數(shù)據(jù)發(fā)生器接收數(shù)據(jù),并將接收的數(shù)據(jù)以Flume的event格式傳遞給一個(gè)或者多個(gè)通道channal,Flume提供多種數(shù)據(jù)接收的方式,比如Avro,Thrift,txt等

Channel:

channal是一種短暫的存儲(chǔ)容器,它將從source處接收到的event格式的數(shù)據(jù)緩存起來,直到它們被sinks消費(fèi)掉,它在source和sink間起著一共橋梁的作用,channal是一個(gè)完整的事務(wù),這一點(diǎn)保證了數(shù)據(jù)在收發(fā)的時(shí)候的一致性. 并且它可以和任意數(shù)量的source和sink鏈接. 支持的類型有: JDBC channel , File System channel , Memort channel等.

Sink:

sink將數(shù)據(jù)存儲(chǔ)到集中存儲(chǔ)器比如Hbase和kafka,它從channals消費(fèi)數(shù)據(jù)(events)并將其傳遞給目標(biāo)地.

Flume配置如下：

gateway.sources = fileEvent
gateway.channels = kafkaChannel
gateway.sinks = loggerSink

gateway.sources.fileEvent.type = TAILDIR
gateway.sources.fileEvent.positionFile = / xxx.json

    gateway.sources.fileEvent.filegroups = events

gateway.sources.fileEvent.filegroups.events=/xxx.log

gateway.sources.fileEvent.channels = kafkaChannel

gateway.sinks.loggerSink.type = org.apache.flume.sink.kafka.KafkaSink

gateway.sinks.loggerSink.channel = kafkaChannel
gateway.sinks.loggerSink.kafka.bootstrap.servers=xxx.xxx.xxx.xxx:9092
gateway.sinks.loggerSink.kafka.topic=oss-gateway-events
gateway.sinks.loggerSink.kafka.batchSize=20
gateway.sinks.loggerSink.kafka.producer.requiredAcks=1

gateway.channels.kafkaChannel.type = memory

gateway.channels.kafkaChannel.capacity = 30000
gateway.channels.kafkaChannel.transactionCapacity = 100

統(tǒng)計(jì)圖如下：