摘要:在這篇文章內,我站在開發者的角度解析一下的商業化架構。的商業化架構首先,我們采用了分層的方式來實現整體架構,包含區塊鏈層激勵層存儲層數據分發層音視頻等應用層。我認為去中心化服務的另外一種說法就是霧計算,或者邊緣技術。
目前大多數的區塊鏈項目,設計時更重視代幣發行,PPIO 的設計則非常重視業務場景的落地。我認為,存儲和數據分發是區塊鏈最適合的應用場景之一,因為存儲和數據分發能夠通過類似于比特幣的激勵方法,把價格降到最低。前面一篇文章介紹了 PPIO 在分發領域的優勢。在這篇文章內,我站在開發者的角度解析一下 PPIO 的商業化架構。
PPIO 的商業化架構首先,我們采用了分層的方式來實現 PPIO 整體架構,包含區塊鏈層、激勵層、存儲層、數據分發層、音視頻等應用層。
我們從傳統云服務的架構來對照分析和講解 PPIO 的技術架構。你可以把 PPIO 看作是去中心化的 AWS,服務是有不同層次的,每個層次都有 API 的輸出,開發者可以根據自己的需求對接不同的 API 來實現自己的應用。如果你只是基于 PPIO 的區塊鏈網絡購買存儲和帶寬,可以選擇使用 IaaS 層的 API;如果你選擇使用類似 AWS 的對象存儲服務,你可以選擇使用 PaaS 的 API,如 POSS;如果你明確是搭建直播,或者點播等流媒體音視頻傳輸服務,你可以選擇使用 Application Services 層的 API。
PPIO 的架構圖如下:
PPIO 和中心化的服務最根本的不同,是計費機制。
中心化的服務的核心,是服務提供商自己可管可控。所有節點(數據中心和機房)都是服務商自己部署,不存在信用問題。沒有外部資源參與問題,就沒有不公平問題,也沒有作惡問題和薅羊毛問題。采用簡單的普通的中心化計費機制,足矣。其成本機制也是自己內部根據成本定價。
而去中心的服務則不同,其核心是參與和競爭。所謂參與,就是允許廣大社會的外部資源能夠自由參與。因為是公開的,分配的公正性問題、作惡問題、薅羊毛問題就都出現了,所以區塊鏈技術是解決這些問題的最好方案。除了參與,還有競爭。在這個 PPIO 網絡中,我們設計的是分地域進行資源的競爭,對于存儲節點而言,誰的資源優質,誰的報價低,誰就能獲得更大的收益。
另外,中心化服務(如 AWS)和 去中心化服務(如 PPIO)的根基是不同的。
這是中心化服務(AWS)的機房部署圖 :
中心化服務,采用的是昂貴、集中化的主干網資源,自己建設機房和機器,自己拉寬帶光纖,搭建成本的昂貴決定中心化服務的節點數不會太多。
這是未來去中心化服務(PPIO)的節點分布圖:
去中心化的服務通過區塊鏈的激勵,鼓勵千萬礦工去部署存儲節點,使用廉價、分散的城域網資源來部署服務,因此節點會有很多很多。而去中心化服務要做的事就是在相對不穩定的基礎設施下建立起穩定的服務。
中心化服務就像云,對每個人來說,像在天上一樣遙遠;去中心化服務就像霧,霧就彌漫在身邊,隨時可以觸及。我認為去中心化服務的另外一種說法就是霧計算,或者邊緣技術。
正是因為最底層基礎設施根本上的不同,導致了上層建筑的巨大不同。
下面說一下商業服務的層次,一般來說做 toB 的商業服務,有三個不同層次的服務。
IaaS:基礎設施服務,Infrastructure-as-a-Service
PaaS:平臺服務,Platform-as-a-Service
Application Services:應用型服務,Application Services
IaaS 層IaaS 層,即基礎設施服務層。
對于?AWS?等中心化的服務來說,IaaS?層是直接硬件資源的租用,如果在?AWS?的?EC2上購買虛擬機,每個虛擬機會搭配固定數量的硬盤和帶寬,如果要增加硬盤和帶寬,就要購買塊存儲等特別的服務,支付額外的費用。這些就是?IaaS?服務,相當于購買了服務器裸機,至于買來之后干嘛,由開發者自己決定。
對于去中心化的服務 PPIO 而言,IaaS 層,也是資源的租用。具體就是硬盤租用和帶寬租用,沒有包裝或任何附加的其他服務。PPIO IaaS 層對存儲和分發的設計,有以下邏輯。
存儲邏輯。簡單地說,一個用戶,如果看中了哪個存儲節點的資源(存儲和帶寬),花錢買下來,然后一段時間就可以占用這些資源,按照資源的實際使用來計費,存儲資源按照 Chunk 大小和占用時間來付費,帶寬資源按照流量來付費。
數據分發邏輯。數據分發邏輯和存儲邏輯不同。錢都是開發者支付的,因為開發者要分發數據,對礦工(存儲節點來)說,只要該數據有人下載,就能獲得收費。所以礦工會主動預測什么文件下載的人會很多,只要礦工盡可能地拿到最熱的文件,就可以獲得最大的收益。
開發者如果在 IaaS 層的 API 上購買硬盤和帶寬,其實購買的是裸的服務,所以 PPIO 在 IaaS 層的設計上,是不支持糾刪算法的,糾刪算法是在 PaaS 層支持的。而由于去中心化的服務,單個零散的資源的穩定性是不如中心化服務的,所以 PPIO 雖然支持 IaaS 層接口,但是并不推薦開發者直接使用 IaaS 層的接口。
PaaS 層PaaS 層,即平臺服務。首先看看云服務的 PaaS 層,PaaS 是在 IaaS 的基礎上經過了一定包裝后,推出的具有非常大的通用性的服務。
對于 AWS 等中心化的服務來說,使用最多的兩個 PaaS 服務就是 OSS(對象存儲服務,Object Storage Service)和 CDN(內容分發網絡 Content Delivery Network)。AWS 的 S3 服務就是 OSS 服務,是做存儲的;AWS 的 CloudFront 就是 CDN 服務,這是做數據分發的。OSS 和 CDN 服務對于中心化服務來說,都不是單一機器能夠搭建的,都是要多臺機器協作才能完成。
去中心化服務 PPIO,也在去中心化的 IaaS 之上,參照 OSS 和 CDN? 構建了兩個 PaaS 服務,POSS 和? PCDN,兩個服務不是靠云服務器來實現,而是靠多個節點為核心來完成。
#1 POSS,面向存儲
如同 AWS S3 一樣,糾刪算法是在 Application Services 層這里實現的,我們采用了糾刪算法。也就是把文件分了了 k 份,再擴展成 n 份糾刪編碼,只要在 n 份里面有任意k份還能在線,就能恢復出整個文件。正因為如此,才能用極小的副本數來大大提升文件的不丟失率,如果需要了解更多參見文章,《PPIO存儲為什么能做到11個9的不丟失率》。
#2. PCDN,面向數據分發
P2SP 的下載引擎就在這一層,P2SP 不同于 P2P,P2P 是 Peer-to-Peer,是完全節點之間的對等傳輸,而 P2SP 是 Peer to Server and to Peer。這里的 Server 指的是 Http / Https 服務器。也就是說下載的時候既可以從 Http 下載,也可以從其他 Peer 下載,這樣 PPIO 的方案不是完全取代傳統的 CDN,而是對傳統的 CDN 進行 P2P 的補充,這樣既降低成本,又提升體驗。
PaaS 層的定位,還是比較通用的,比較基礎的。PPIO 在 PaaS 不同于 IaaS 層的是,在 PaaS 層要推出穩定的服務 PPIO 的核心技術能力,就是在相對不太穩定的基礎設施上構建出穩定可靠廉價的服務。但是 PaaS 的定位是支持相對通用的服務,所以在 PaaS 層,不會和特殊應用場景產生關系。
#3. PRoute,面向智能路由
PRoute 是 PPIO 專門為兩點之間找到最近網絡通路而設計的,也可以簡單理解為智能路由。智能路由是 P2P 的常規技術,所謂智能路由,就是在兩個節點之間找到最快的穩定傳輸路徑,在 TCP / IP 層之上實現,而并非在網絡底層實現。PPIO 實現智能路由支持不止一條鏈路,可以多條鏈路完成。
和傳統的云服務類似, 流媒體和音視頻的支持不是 PaaS 層的事,在設計 PPIO 的時候,我把流媒體音視頻放在了更上層,Application Services 層。
應用型服務層應用型服務層,Application Services,這一層的定位更加接近于應用場景。PaaS 提供的通用的存儲和數據傳輸場景,而 Application Services 就面向于更加貼近于垂直應用的場景。前面說過,在現有的數據分發業務中有58%都是音視頻類業務,PPIO 在設計的時候,必須考慮對音視頻和流媒體的支持。
對于中心化的云服務來說,Application Services 層的服務非常豐富,有大量的場景應用,例如有圖片應用,只要開發者上傳一個原始圖片到 OSS 上,就能直接獲取不同分辨率的圖片,甚至還支持圖片的防盜,加水印等功能。又如視頻服務,支持不同類型的傳輸協議和方式,如 iOS 支持的 HLS(Http Live Streaming)等特殊傳輸方式。Application Services 的服務更加接近于具體場景,把每一類貼近于具體場景的服務抽象化,再對開發者提供服務,開發者基于 Application Services 層的API,只要自己的開發場景符合,就能夠很快地開發出應用來。
設計 PPIO 的時候,也是這樣考慮,在 PaaS 層之上,還貼近于應用場景的 API 以便于開發者快速開發。由于 PPIO 的實現原理和傳統的云服務不同,PPIO 的節點彌漫在用戶身邊到處都有,我認為是霧服務,霧計算。
(圖:云和霧的區別)
我們計劃近期提供的 Application Services 層接口,有直播霧、點播霧、圖片霧、音頻通訊霧等。由于視頻的應用在數據應用中占有大比例,我們計劃優先支持直播霧和點播霧。
Application Services 和 PaaS 層不同,PaaS 層給出的是通用的 PCDN 傳輸方式,不會涉及到流媒體以及切片的細節,而 Application Services 層則不用,要做好直播和點播,就必須要做好服務質量(QoS),可以簡單理解最基礎的 QoS 就是:秒啟、不卡頓、低延遲。為了做好 QoS,就要深入到流媒體本身去切分片段。并且傳輸的時候,以分片的緊急程度做為切換不同下載策略的依據。
例如:在通用的文件中,文件的分片是這樣的
那么遇到FLV視頻的時候
又如,下載算法也有不同之處。
PPIO 除了提供普通的文件下載以外,還專門為流媒體提供了優化的 P2P 傳輸系統,為了保證點播類應用的體驗,下載數據必須非常實時,并且能夠應對 P2P 網絡的不穩定性,我們采用了數據驅動的 P2P 下載技術,并基于這個理念后做了很大的改進和優化,設計了一套基于預分配方式的 P2P 多點調度系統。
P2P 流媒體傳輸具有如下特點:
順序下載:優先選擇當前流媒體播放位置的后續就近內容進行下載,以保證流媒體的不間斷播放。
最稀有片段:選擇最稀有的 Piece(通常是流媒體中的最冷門部分內容),盡管對于流媒體而言,這似乎是違反常識的。但選擇最稀有的部分進行下載將有助于整個 Segment 的加速獲取,因此最終有助于提升流媒體下載效率和播放體驗。
基于錨點:在流媒體播放中,用戶常常跳過部分內容并向前或向后跳躍,為此,流媒體中需要定義錨點并優先下載,當用戶嘗試跳轉到流媒體中的某個特定位置時,將使用最接近的錨點進行開始播放并繼續順序下載。
(圖:下載預分配算法的模擬)
PPIO 的 P2P 傳輸網絡是完全動態的。每個 Peer 可以同時響應多個下載節點的多個請求,每個下載節點必須經常處理如何向不同的 Peer 發送下載請求以及處理請求失敗。同時,下載節點也可能作為其他下載節點的 Peer 提供下載服務。通過 PPIO 數據驅動的兩種調度算法,動態傳輸大規模數據的效率被充分發揮出來。
Application Services 層除了分片方式和下載算法以外,還要根據更進一步的場景來更多特定化的事情。
APP 層APP 層就是應用了,這部分不是屬于 PPIO 的,這是屬于開發者。如果你是開發者,你將來可以根據 PPIO 的三層 API 開發出符合你的應用。
這是 PPIO 的架構全圖
上面介紹完了每層的架構之后,現在匯總一下,這就 PPIO 架構中在每個層次完成的事情
PPIO 將陸續提供3套 API:
基于 IaaS 層的存儲空間和帶寬租用 API
基于 PaaS 的 POSS,PCDN,PRoute 的 API
基于 Application Services 層的點播霧、直播霧、圖片霧等更多 API 接口。開發者可以選擇在任意一層進行開發,完成自己的 APP 或者 DAPP
PPIO 將發動盡可能多的閑置資源,最終實現比云服務更便宜,更高速,更隱私的存儲和數據分發服務。
綜上所述,這些就是 PPIO 在數據分發領域的優勢。如果你想了解更多,歡迎加入我們的開發者社區共同討論!
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/24678.html
摘要:的分片方式是和文件結構或者流媒體協議相關的。需要注意的是,這里的普通文件不是流媒體視頻文件,不具備流媒體的特性。,也就是分段流媒體的原始分段。除了支持分段流和連續流以外,后面還計劃逐步支持其他媒體格式和協議。 工作日早晨8點的地鐵,Lisa 拿出手機打開 Tik Tok 來打發半小時的通勤時間;12點,吃完午飯的 Lisa 趁著午休時間忙里偷閑看看 YouTube 上有趣搞笑的視頻;晚...
摘要:存在個人隱私數據被審查的風險。首先,我們認為違法數據的審查有利于社會和經濟的安定。永不關停對于去中心化存儲的用戶來說,不用擔心運營方關停的可能性,因為最終去中心化存儲是屬于用戶的,屬于社區的,并不是屬于公司的。 在這個信息爆炸的時代,數據存儲與我們每一個人息息相關。從打孔卡到軟盤硬盤再到中心化云端存儲服務,人類在尋求更便捷有效的數據存儲方式的道路上從未停下過腳步。未來會出現比如今最流行...
摘要:的關鍵技術主要有內容存儲和分發技術。分發本身是和存儲密不可分的存儲和分發的實質都是數據的讀取和使用,兩者是不可能分割的。只是存儲場景和分發場景,設計有些不同,服務質量的要求也不一樣。根據區域和時段的不同,存儲的價格也會有不同。 showImg(https://segmentfault.com/img/remote/1460000019478027); PPIO 是為開發者打造的去中心化...
閱讀 3208·2021-11-23 09:51
閱讀 3667·2021-09-22 15:35
閱讀 3644·2021-09-22 10:02
閱讀 2956·2021-08-30 09:49
閱讀 508·2021-08-05 10:01
閱讀 3375·2019-08-30 15:54
閱讀 1632·2019-08-30 15:53
閱讀 3557·2019-08-29 16:27