PPIO 商业化架构解析 - 区块链前沿 - BitMere

目前大多数的区块链项目，设计时更重视代币发行，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 在数据分发领域的优势。如果你想了解更多，欢迎加入我们的开发者社区共同讨论！