Uber開源P2P容器倉庫Kraken，每秒分佈TB級資料
Docker容器倉庫的主要職能是儲存和分佈Docker映象。這是個看似容易的任務，但是當計算叢集達到Uber的規模後，容器倉庫很容易成為系統的瓶頸。尤其在混合雲多活架構下，映象分佈變得更加複雜。
為了解決私有容器倉庫的效能問題，Uber開發了P2P的映象倉庫——Kraken（海怪）。
容器技術一直以來是Uber架構的基礎（Uber為此還開發了自己的映象生成工具Makisu——捲簾），但是隨著計算叢集的增長，簡單在私有容器倉庫的基礎上做資料分片和增加cache無法提供Uber所需的流量。
Kraken在2016年應運而生。這個專案著重於可擴充套件性和可用性，並且適用於再混合雲架構中的映象管理，複製和分佈。Kraken還支援後臺擴充套件，可以以其他容器倉庫為後臺，單純的作為釋出層來部署。
架構
Uber的工程師經過了幾輪設計，最終選定P2P的架構。Kraken使用的P2P協議基於BitTorrent，但是加以了改進，使其更適合在資料中心內部署的企業級應用。
Kraken本身不負責資料的儲存，而是支援多種儲存後臺，比如AWS S3，HDFS，甚至是其他的應用倉庫。儲存後臺的介面設計非常通用，開發者可以輕鬆的加入新的實現。
Kraken的各個部分都可以自我修復，任意單一機器的問題都不會對系統整體造成影響。假如有多個異地叢集，Kraken還支援基於映象名的異地無損複製。
效能
Kraken在2018年初被部署入生產環境。自那以後，曾經的映象倉庫效能問題不復存在。
最忙碌的一個Kraken叢集每天分佈超過一百萬個映象層，其中有十萬個以上大小超過1GB。在高峰時期，Kraken可以在30秒內分佈2萬個大小在100MB和1GB之間的映象層。
Kraken的可擴充套件性使其可以輕鬆支援超過8000臺機器的計算叢集，而且可以以最大下載速度50%以上的速度向叢集中每臺機器分佈映象。事實上在Uber收集到的資料中，叢集和映象的大小對下載速度沒有明顯的影響。
對比
對於第一次聽說Kraken的開發者而言，難免會問到Kraken和阿里巴巴Dragonfly（蜻蜓）專案的區別。Dragonfly的架構中，由超級節點決定每一塊4MB資料塊的流向。雖然超級節點理論上可以做出最優的選擇，但是整個叢集的流量會被一臺或幾臺機器的處理能力所限制。隨著叢集或映象大小的增加，效能會呈線性下降。
Kraken的架構中，中心部件Tracker只負責搭建起一個隨機正則圖的網路拓撲結構，但是具體的資料傳輸的協商是由每臺機器上的peer程序負責，所以Kraken的效能不會太受叢集和映象大小的影響。此外，Kraken是一個高可用性的系統，並且支援異地無損複製，適合使用於混合雲環境。
開源
自從內部使用以來，Kraken已被用來管理Uber的所有映象。
Uber希望可以通過開源這個專案，來引發更多Docker相關領域的討論。
假如您對Kraken的實現細節有興趣，請訪問Kraken的GitHub頁面 。
原文連結：# Introducing Kraken, an Open Source Peer-to-Peer Docker Registry （作者：Yiran Wang）