PPIO 商業化架構解析

目前大多數的區塊鏈項目，設計時更重視代幣發行，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：

1. 基於 IaaS 層的存儲空間和帶寬租用 API

2. 基於 PaaS 的 POSS，PCDN，PRoute 的 API

3. 基於 Application Services 層的點播霧、直播霧、圖片霧等更多 API 接口。開發者能夠選擇在任意一層進行開發，完成本身的 APP 或者 DAPP

PPIO 將發動儘量多的閒置資源，最終實現比雲服務更便宜，更高速，更隱私的存儲和數據分發服務。

綜上所述，這些就是 PPIO 在數據分發領域的優點。若是你想了解更多，歡迎加入咱們的開發者社區共同討論！