关于容器:Dragonfly-基于-P2P-的文件和镜像分发系统

文|孙景文、吴迪（Dragonfly Contributor）

本文 4138 字 浏览 10 分钟

背 景

网络下载

提起网络下载畛域，你应该首先会想到基于 TCP/IP 协定簇的 C/S 模式。这种模式心愿每一个客户机都与服务器建设 TCP 连贯，服务器轮询监听 TCP 连贯并顺次响应，如下图：

上世纪末期，基于 C/S 模式的思维，人们倒退了 HTTP，FTP 等应用层协定。然而 C/S 模式的弊病很显著：服务器的负载过大，下载速率过慢。随着互联网规模的增大以及客户对于下载数据大小，下载速率等需要的回升，这些弊病被一直放大。

P2P 下载原理

基于上述背景，有人联合 P2P 网络与负载平衡的思维，提出 P2P 下载模式。这种模式不再把所有的下载压力丢给服务器，服务器只负责传递文件元数据，真正的文件下载连贯建设在客户机与客户机之间。同时一个文件能够被分片为多个块，同一个文件中不同的块能够在不同的客户机之上下载，使得下载文件在 P2P 网络中动静流通，大幅晋升了下载效率，如下图：

去中心化的 P2P 下载基于 DHT 技术，它采纳分布式全网形式来进行信息的存储和检索。所有信息均以哈希表条目模式加以存储，这些条目被扩散地存储在各个节点上，从而以全网形式形成一张微小的分布式哈希表。在此基础上做到对单服务器的去中心化，哈希表负责对负载的摊派，将全网负载均摊到多个机器之上。

我的项目简介及架构概述

Dragonfly 是一款基于 P2P 的智能镜像和文件散发工具。它旨在进步大规模文件传输的效率和速率，最大限度地利用网络带宽。在利用散发、缓存散发、日志散发和镜像散发等畛域被大规模应用。

原理

Dragonfly 联合 C/S 架构与 P2P 架构的长处。它提供面向客户的 C/S 架构下载模式。同时它也提供面向服务器集群的 P2P 回源模式，与传统 P2P 不同的是，对等网络建设在 Scheduler 外部，指标是最大化 P2P 外部下载效率，如下图：

架构简介

Dragonfly 面向镜像散发和文件散发，联合 P2P 网络和服务器集群的思维，向用户提供稳固的，高效的下载服务。Dragonfly 心愿在服务器外部构建 P2P 网络，将服务器的不同主机节点分为 Manager、Scheduler、Seed Peer 以及 Peer 四个角色，别离提供不同的性能。

其中 Manager 提供总体配置性能，拉取其余角色的配置并互相通信。Scheduler 提供下载调度性能，其调度后果间接影响下载速率。Seed Peer 负责回源下载，从内部网络中拉取所需的镜像或文件。Peer 作为 C/S 架构中的服务器，通过多种协定向客户提供下载性能。架构图如下：

其中，Seed Peer 反对应用多种协定从内部网络中回源下载，同时也反对当作集群当中一个 Peer 应用。Peer 提供基于多种协定的下载服务，也提供为镜像仓库或其余下载工作的代理服务。

组件详解

Manager

Manager 在多 P2P 集群部署的时候表演管理者的角色，提供前端控制台不便用户进行可视化操作 P2P 集群。其次要提供动静配置管理、保护集群稳定性以及保护多套 P2P 集群的关联关系等性能。对于保护集群整体稳定性 Manager 和各个服务放弃 Keepalive 保障可能在实例异常情况下将异样实例进行剔除。动静配置管理能够在 Manager 下面操作各个组件的管制单元，比方管制 Peer 和 Seed Peer 的负载数，Scheduler 调度 Parent 的个数等。

Manager 也能够保护多套 P2P 集群关联关系，一个 Scheduler Cluster、一个 Seed Peer Cluster 和若干个 Peer 组成一个残缺的 P2P 集群，当然不同 P2P 集群能够是网络隔离的。失常状况下采纳一个机房一套 P2P 集群，对立由一个 Manager 治理多个 P2P 集群。

Scheduler

Scheduler 次要工作就是为以后下载节点寻找最优父节点并触发 Seed Peer 进行回源下载。在适当时候让 Peer 进行回源下载。Scheduler 在启动时，先向 Manager 注册，注册胜利后初始化动静配置客户端，并从 Manager 拉取动静配置，接下来启动 Scheduler 本身所需的服务。

Scheduler 的外围就是选取一组最优 Parent 节点供以后下载 Peer 进行下载。Scheduler 面向 Task，一次 Task 就是一次残缺的下载工作，在 Scheduler 中存储 Task 信息和相应 P2P 下载网络的 DAG。调度过程是首先过滤异样 Parent 节点，依据多维度进行过滤，比方判断该 Peer 是否是 BadNode，判断逻辑为假如每个节点的响应时长都遵循正态分布，若一个节点目前的响应时长处于 6σ 范畴之外，那么认为该节点是 BadNode，剔除该节点。再依据历史下载特征值对残余待定 Parent 节点进行打分，返回一组分数最高的 Parent 提供给以后 Peer 进行下载。

Seed Peer 和 Peer

Seed Peer 和 Peer 有很多相似之处。他们都是基于 Dfdaemon，不同的是 Seed Peer 采纳 Seed Peer 模式，反对被动触发回源下载。Peer 采纳 Peer 模式，作为 C/S 架构中的服务器向用户提供下载性能，反对被 Scheduler 被动触发回源下载。

这表明 Peer 和 Seed Peer 的关系不是固定的，一个 Peer 能够通过回源使本人成为 Seed Peer，Seed Peer 也能够改变运行状态变为 Peer，Scheduler 会动静地对相应 DAG 进行改变。另外 Seed Peer 和 Peer 都须要参加调度下载过程当中，Scheduler 可能会选取 Seed Peer 或者 Peer 作为父节点向其余 Peer 提供下载性能。

Dfstore 和 Dfcache

Dfcache 是 Dragonfly 的缓存客户端，它与 dfdaemon 通信并对 P2P 网络中的文件进行操作，其中 P2P 网络充当缓存零碎。能够在 Scheduler 中存储相应 Task 和 DAG。

Dfstore 是 Dragonfly 存储客户端. 其能够依赖不同类型的对象存储服务作为 Backend，提供稳固的存储计划，当初反对 S3 和 OSS。Dfstore 依赖 Backend 对象存储服务联合 P2P 自身的减速特点。可做到快写快读，并且可能节俭回源以及跨机房流量，缩小源站压力。

劣势

稳定性

Dragonfly 会主动隔离异样节点来进步下载稳定性，Dragonfly 中各个组件通过 Keepalive 与 Manager 进行分割，Manager 可能保障返回给 Peer 的 Scheduler 地址和返回给 Scheduler 的 Seed Peer 地址都是可用的。不可用的 Scheduler 和 Seed Peer 不会被 Manager 推给须要进行下载工作的 Peer 或 Scheduler，从而达到隔离异样节点的目标，这也是实例维度的异样隔离，如下图：

另外 Dragonfly 在调度时以 Task 为单位，也确保了整个调度过程的稳定性。在收到一个新的 Task 调度申请之后，Scheduler 触发 Seed Peer 进行回源下载；在收到一个已有 Task 的调度申请之后，Scheduler 调度最优 Parent Peer 汇合返回给 Peer。这个逻辑确保了无论 Task 是否下载过，Dragonfly 都能够对其进行解决。此外在 Scheduler 调度过程中，对响应时长过慢的 Peer，认为目前是异样节点，将不会作为 Parent Peer 被返还。这也是 Task 维度的异样隔离。

高效性

Dragonfly 采纳 P2P 进行服务端外部的回源，P2P 下载自身即摊派负载，将每个服务端节点的负载降到最低，有以下几个细节保障了 Dragonfly 下载的高效性：

– Scheduler 通过为每个可能的 Parent 打分，返回给 Peer 目前部分最优的 Parent 汇合，Peer 基于此汇合做下载。

– 下载过程基于 Task，每个 Task 将待下载文件分为多个 Piece，Peer 拿到了最优的 Parent 之后，向此汇合播送每个 Piece 的下载申请，汇合中的 Parent 收到该申请后返回给 Peer 对应 Piece 的元信息，Peer 将第一个收到的 Piece 元信息所对应的 Parent Peer 作为该 Piece 的理论下载源。该做法思考到 Scheduler 返回可用 Parent 到触发下载这段时间内可能的变动，同时对不同的 Piece，容许 Peer 向不同的下载源获取数据。

– Dfdaemon 分为 Seed Peer 模式和 Peer 模式，容许 Seed Peer 和 Peer 进行切换，能够依据理论需要扭转作为 Seed Peer 和 Peer 的机器数目，动静调整更适应理论状况。

简略易用

Dragonfly 提供 Helm Charts、Docker Compose、Docker Image 以及二进制的多种部署形式。用户能够疾速一键部署进行一次简略 POC，并且也能够基于 Helm Charts 进行大规模生产部署。当然 Dragonfly 各个服务都有欠缺的 Metrics 也提供现成的 Granafa 模版，不便用户察看 P2P 的流量走势。

瞻望

Dragonfly 作为 CNCF 在镜像减速畛域规范解决方案，联合 Dragonfly 子项目 Nydus 进行按需加载能够最大限度晋升镜像下载速度，将来咱们也会持续致力建设镜像减速畛域的生态链。感激所有参加到社区建设的同学，心愿有更多对镜像减速畛域或 P2P 感兴趣的同学退出到咱们的社区当中。

🔎欢送搜寻群号：23304666 

或钉钉扫码入群哦🧸

【参考文档】

1. 我的项目地址:https://github.com/dragonflyoss/Dragonfly2
2. 官网:https://d7y.io/
3. Slack:https://cloud-native.slack.com/messages/dragonfly/
4. Twitter:https://twitter.com/dragonfly_oss
5. Developer Group Email:dragonfly-developers@googlegroups.com

本周举荐浏览

Nydus——下一代容器镜像的摸索实际

深刻 HTTP/3（2）|不那么 Boring 的 SSL

Go 代码城市上云——KusionStack 实际

MOSN 反向通道详解