クラスタサイズの拡大に伴い、これまで流通の問題により、ミラーを悩ませて？シーンに応じて、我々は別の画像配信方法を使用します。
- P2PベースCNCF / トンボ（以下、「トンボ」と呼ばれる）配信センタは、ミラーの帯域幅を容易にし、時間を配布する最も直接的な方法を低減することです。
- リモートストレージミラーリングプログラムでCNCF / containerdリモート・ファイル・システムのスナップショットは、直接、容器エンジンは、ほとんどの時間を配布するために、ネットワークを介して映像コンテンツを読み出します。
あなたは第二のアプローチは、ネットワークの安定性に依存しています。この記事では、コンテンツの動的画像要求がローカルトレードオフとして画像の保存、およびリモートからロードされた読み取り方法をまとめ方法鏡画像を選択します。
背景
場合中小企業、単一のマシンは、単一の容器の展開であってもよい;しかし、取引量、およびアプリケーションの複数に分割するとき、同じマシン上で複数のアプリケーションをデプロイすることが必要である。依存この時点で複数のアプリケーションこれは、より困難な問題です。そして、同時に複数のアプリケーションを実行し、それはまた、お互いに干渉されています。
最初に、あなたは仮想マシンは、基本的には依存関係の競合が存在しない、各アプリケーションが、仮想マシンはまだスロースタート、問題や大型の一連の占有スペースを持っているように、達成するために仮想マシンを使用することができます。
技術としての背後に、アプリケーションが動作モードアイソレーション・アプリケーションを実現するために、別の名前空間で実行することができますLXC技術、と。
ここでは、静的な分離の問題を解決するために仮想マシンを見ることができ、LCXは、分離および静的な二つの問題の状態に対応しつつドッカーが実行されている間、状態を実行している分離問題を解決するため、親しい友人を取得します。
ドッカーコア
ドッカーの3つのコア：ミラー、コンテナ、倉庫。ドッカー前に、コンテナは、LXCのように異なる実装を、持っています。ドッカーの偉大な革新をミラーリングし、倉庫。ミラーリングは、その中央エンティティ、集中保管倉庫であり、容器は、場合ミラーを実行しています。
上記のお好きなプラットフォームでの開発テスト（例えばUbuntuの）のための学生の開発を、ノードが実際に配備され、それはRedHatの/ CentOSのサーバであってもよい：ミラーリングによってドッキングウィンドウは、例えば、魔法のように達成することができます。
ドッカーは、ミラーベースであるので、そこにミラーランタイム容器、及び容器でなければならず、コミットドッカーによって画像を生成することができます。しかし、最初の画像から来ますか？ドッキングウィンドウのインポート/ロードのようにして導入することができます。そして、画像はミラーの中心に方向ドッキングウィンドウのプッシュ/プルを介してアップロード、または鏡像センターからダウンロードすることができます。
ミラーリング
ドッカーは、イメージを作成するのは簡単ドッキングウィンドウのビルド・メカニズムを提供します。何のドッキングウィンドウには、次の手順をミラーリングする仕組みを構築していない、想像してみて：
- ベース画像から出発して容器。
- そのようなパッケージをインストールするなどの容器に対応するコマンドを実行し、ファイルなどを追加します。
- ドッカーがちょうど鏡画像コンテナをコミットするためにcommitコマンドを使用します。
- やるべき他のステップがある場合、すべての操作まで、コミット、コンテナに新しいイメージを開始する必要があります。
ドッキングウィンドウのビルド機構が、唯一dockerfileを必要とし、上記の手順は、ドッカーの自動化は、最終的に目的の画像を生成します。
容器
、上から見た、ミラー、層によってミラー層、デザインは、すべてのミラー層は読み取り専用で、ミラーへのaufs / overlayfs方法により、Linuxがホストにマウントする方法の詳細な外観です下部層は、読み取り専用画像層である最上層は、書き込み可能な層の容器、すべての操作は、この層の上に実行するように書かれている書き込み容器です。
大規模クラスタ遅いイメージのダウンロード
ドッカーのレジストリまたは参照するには、他のサイト上などbusyboxの、nginxのは、MySQL、などがM Mの外観の数十〜数百ある大きな鏡、ではありません。
しかし、アリ・ババの画像は、一般的なような大きな鏡には多くの理由が、そこにある、3〜4Gを持っています：
- グループは、より親しみやすい開発者は以前の経験に開発を行うことができます開発する仮想マシンと同様の方法でモデルの豊富なコンテナを使用し、多くの学習コストを必要としない、ベース画像群につながる2を持っています〜3G;
- 当社グループの事業開発ミドルウェアの数に依存し、分散的に使用され、完全に統一されていない理由によるミドルウェアのバージョン、すべてのミドルウェアは、Mの数百を持っている;、プラスJavaビジネスパッケージ自体は小さくありませんそう、一般的に3〜4Gは正常です。
- 集团有上十万的物理机，上面运行着上百万的容器，每天有着上千次发布。可以想像一下，就单单把镜像从镜像中心下载到物理机上面，每天消耗的带宽是巨大的。
这就导致一个问题：镜像中心很有可能被打爆。
这种情况在集团出现多次，在打爆的情况下，当前的镜像拉取被阻塞，同时又有更多的镜像拉取请求上来，导致镜像中心严重超负荷运行，并且致使问题越来越严重，可能会导致整个系统奔溃。因此，必须解决镜像下载导致的问题。
蜻蜓架构
集团开发了蜻蜓（Dragonfly ）这套 P2P 下载系统。上面是蜻蜓的架构图，蜻蜓可以分为三层，最上层是一个配置中心，中间是超级节点，下面就是运行容器的物理节点。
配置中心管理整个蜻蜓集群，当物理节点上有镜像要下载时，它通过 dfget 命令向超级节点发出请求，而向哪些超级节点发出请求是由配置中心配置的。
以下图为例：
当下载一个文件时，物理节点发送了一个 dfget 请求到超级节点，超级节点会检查自身是否有这部分数据，如果有，则直接把数据传送给物理节点；否则会向镜像中心发出下载请求，这个下载请求是分块的，这样，只有下载失败的块需要重新下载，而下载成功的块，则不需要。
更为重要的是，如果是两个或更多物理节点请求同一份数据，那么蜻蜓收到请求后，只会往镜像中心发一个请求，极大地降低了镜像中心的压力。
关于 P2P，也就是说如果一个节点有了另一个节点的数据，为了减少超级节点的压力，两个节点可以完成数据的互传。这样更高效地利用了网络带宽。
蜻蜓效果
从上面的蜻蜓效果图可以看到：
随着镜像拉取的并发量越来越大，传统方式所消耗的时间会越来越多，后面的线条越来越陡；但是蜻蜓模式下，虽然耗时有增加，但只是轻微增加。效果还是非常明显的。
蜻蜓里程碑
应该说，集团内是先有蜻蜓，后面才有 docker 的。原因是集团在全面 docker 之前，使用了 t4 等技术，不管哪种技术，都需要在物理机上面下载应用的包，然后把应用跑起来。
所以，从里程碑上看，2015 年 6 月就已经有了蜻蜓 p2p 了，随着集团全面 Docker 化，在 2015 年 9 月，蜻蜓提供了对 Docker 镜像的支持，后面的几个时间点上，可以看到蜻蜓经受了几次双 11 的考验，并且经过软件迭代，在 2017 年 11 月的时候实现了开源。
现在蜻蜓还在不断演化，比如说全部使用 golang 重写，解决 bug，提供更多能力集，相信蜻蜓的明天更美好。
蜻蜓也不能完美解决的问题——镜像下载
蜻蜓在集团取得了极好的效果，但是并不能解决所有问题，比如我们就遇到了以下比较突出的问题：
- 镜像下载导致业务抖动
在实践中，上线的业务运行经常有抖动的现象，分析其中原因，有部分业务抖动时，都在做镜像下载。
分析原因发现：镜像层采用的是 gzip 压缩算法。这一古老的算法，是单线程运行，并且独占一个 CPU，更要命的是解压速度也很慢，如果几个镜像层同时展开的话，就要占用几个 CPU，这抢占了业务的 CPU 资源，导致了业务的抖动。
- 应用扩容要更好的时效性
平时应用发布、升级时，只需要选择在业务低峰，并且通过一定的算法，比如只让 10% 左右的容器做发布、升级操作，其它 90% 的容器还给用户提供服务。这种不影响业务、不影响用户体验的操作，对于时效性要求不高，只要在业务高峰来临前完成操作即可，所以耗时一两个小时也无所谓。
假设遇到大促场景，原计划 10 个容器可以服务 100 万用户，但是，突然来了 300 万用户，这时所有用户的体验将会下降，这时就需要通过扩容手段来增加服务器数量，此时对容器扩出来有着极高的时效要求。
- 如何而对云环境
现在所有公司都在上云，集团也在上云阶段，但云上服务器的一些特性与物理机还是有些差别，对镜像来讲感受最深的就是磁盘 IO 了，原来物理机的 SSD 磁盘，IO 可以达到 1G 以上，而使用 ECS 后，标准速度是 140M，速度只有原来的十分之一。
Gzip 优化
对于 gzip 的问题，通过实测及数据分析，如上图所示：
1 与 2 下载的是同一个镜像层，只是 1 下载的是一个 gzip 格式的，而 2 下载的是一个没有压缩的镜像层。可以看到 2 因为下载的数据量要大很多，所以下载的时间要长许多，但是 1 中将 400M 的 gzip 还原成 1G 的原始数据却又消耗了太多时间，所以最终两者总体时效是差不多的。
并且由于去掉 gzip，镜像下载不会抢占业务的 CPU 资源。自从上了这一方案后，业务抖动的次数明显减少了许多。
在蜻蜓的章节，镜像下载是镜像层从超级节点到物理机，在这一过程中，蜻蜓有一个动态压缩能力，比如使用更好的 lz4 算法，即达到了数据压缩的效果，又不会造成业务抖动。这就是图 3，整体上这一点在集团的应用效果很不错。
远程盘架构
解决了镜像下载对业务的干扰后，扩容、云环境的问题还没有解决。这时远程盘就派上用场了。
从上面的架构图看，集团有一套镜像转换机制，将原始的镜像层放在远端服务器上，第一个层都有一个唯一的远程盘与之对应。然后镜像中保存的是这个远程盘的 id，这样做下来，远程盘的镜像可以做到 kB 级别。对于 kB 级别的镜像，下载耗时在 1~2 秒之间。
通过远程盘，解决了镜像下载的问题，同时由于远程盘放在物理机同一个机房，容器运行时读取镜像数据，相当于从远程盘上面读取数据，因为在同一个机房，当然不能跟本地盘比，但是效果可以与云环境的云盘性能相媲美。
远程盘的问题
远程盘虽然解决了镜像下载的问题，但是所有镜像的数据都是从远程盘上读取，消耗比较大的网络带宽。当物理机上环境比较复杂时，远程盘的数据又不能缓存在内存时，所有数据都要从远端读取，当规模上来后，就会给网络带来不小的压力。
另外一个问题是，如果远程盘出现问题，导致 IO hang，对于容器进程来讲，就是僵尸进程，而僵尸进程是无法杀死的。对于应用来讲，一个容器要么是死，要么是活，都好办，死的了容器上面的流量分给活着的容器即可，但对于一个僵尸容器，流量没法摘除，导致这部分业务就受损了。
最后，远程盘因为要服务多台物理机，必然要在磁盘 IO 上面有比较好的性能，这就导致了成本较高。
DADI
针对上述问题，集团采用的 DADI 这一项技术，都是对症下药：
- 使用 P2P 技术
远程盘是物理机所有数据都要从远程盘上读，这样会导致对远程盘机器的配置较高的要求，并且压力也很大。
而通过 P2P 手段，可以将一部分压力分担掉，当一台机器已经有另一台需要的数据时，它俩之间可以完成数据互传。
- 高效压缩算法
同样是解决网络带宽的问题，远程盘对应的数据都是没有压缩的，传输会占用比较多的带宽。
而 DADI 则在传输过程中，跟蜻蜓一样，对数据进行压缩，减少网络压力。
- 本机缓存
这个是核心买点了，当容器启动后，DADI 会把整个镜像数据拉取到本地，这样即使网络有问题，也不会导致容器进程僵尸，解决了业务受损的问题。