g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Ali Double 11'in gizemli teknolojisini doğrudan vurdu: PB düzeyinde büyük ölçekli dosya dağıtım sistemi "Dragonfly"

Ali Kız Rehberi: 2017 Tmall Double 11'de işlem tepe değeri 325.000 / sn, ödeme tepe değeri 256.000 / sn ve veri tabanı işleme tepe değeri 42 milyon kere / sn olarak yeniden yeni rekorlar kırdı. Alibaba Group'un altyapısı Dragonfly, Double 11 sırasında eş zamanlı olarak 5 GB'lık veri dosyalarını on binlerce sunucuya dağıtarak Dragonfly sistemi tarafından büyük ölçekli dosya dağıtımının mükemmel bir şekilde gerçekleştirilmesini sağladı.

Dragonfly, büyük ölçekli dosya indirmelerindeki ve ağlar arası izolasyondaki çeşitli sorunları çözerek veri ön ısıtma ve büyük ölçekli konteyner görüntü dağıtımı gibi iş yeteneklerini büyük ölçüde geliştirdi. Aylık ortalama dağıtım sayısı 2 milyarı aştı ve dağıtılan veri hacmi 3,4 PB oldu. Kapsayıcı görüntü dağıtımı, natvie yönteminden 57 kata kadar daha hızlı olabilir ve kayıt defteri ağ çıkış trafiği% 99,5'ten daha fazla azaltılır. Bugün, Alimei, Alibaba altyapı iş grubunda kıdemli bir teknik uzman olan Ru Bai'yi, Dragonfly'ın dosya dağıtımından görüntü aktarımına kadar olan teknik yolunu detaylandırması için davet etti.

Yusufçuğun doğuşu

Alibaba'nın işindeki patlayıcı büyümeyle birlikte, sürüm sisteminin ortalama günlük sürüm hacmi 2015 yılında 20.000'i aştı ve birçok uygulamanın ölçeği 10.000'i aşmaya başladı ve sürüm başarısızlık oranı artmaya başladı. Temel neden, sürüm sürecinin büyük miktarda dosya çekme gerektirmesiydi. Sunucu çok sayıda isteği karşılayamaz.Elbette, sunucu genişletmeyi düşünmek kolaydır, ancak genişletmeden sonra, arka uç depolamanın bir darboğaz haline geldiği görülmüştür. Ek olarak, farklı IDC'lerden gelen çok sayıda istemci isteği, ağda tıkanıklığa neden olan büyük ağ bant genişliği tüketir.

Aynı zamanda, birçok hizmet uluslararası hale geliyor, çok sayıda uygulama yurtdışında konuşlandırılıyor ve denizaşırı sunuculardan yapılan indirmelerin kaynak ülkeye geri gönderilmesi gerekiyor ki bu çok fazla uluslararası bant genişliğini boşa harcıyor ve çok yavaş; büyük dosyaları aktarırsanız, ağ ortamı zayıftır ve başarısız olursa yeniden başlamanız gerekir. Yine, verimlilik son derece düşük.

Bu yüzden P2P teknolojisini düşünmek doğaldır çünkü P2P teknolojisi yeni değil O zamanlar birçok yerli ve yabancı sistem araştırıldı, ancak araştırmanın sonucu, bu sistemlerin ölçeği ve kararlılığının beklentilerimizi karşılayamadığı oldu. Yani Dragonfly ürünü var.

Tasarım hedefleri

Dragonfly, bu acı noktalara yanıt olarak tasarımın başında birkaç hedef belirledi:

1. Patlayan dosya kaynaklarının sorununu çözün, Ana Bilgisayarlar arasında bir P2P ağı kurun, dosya sunucuları üzerindeki baskıyı azaltın ve IDC'ler arasında ağ bant genişliği kaynaklarından tasarruf edin.

2. Dosya dağıtım hızını hızlandırın ve aynı anda on binlerce sunucunun indirilmesini sağlayın ve tek bir sunucunun indirilmesinde çok fazla dalgalanma olmamasını sağlayın.

3. Sınır ötesi indirme hızlandırma ve bant genişliği tasarrufu sorununu çözün.

4. Büyük dosyaları indirme sorununu çözün ve aynı zamanda devam ettirilebilir yüklemeyi desteklemesi gerekir.

5. İşi etkilemekten kaçınmak için Ana Bilgisayardaki Disk GÇ ve ağ GÇ'si kontrol edilebilir olmalıdır.

sistem yapısı

Yusufçuk genel mimarisi

Dragonfly'ın genel mimarisi üç katmana bölünmüştür: ilk katman, tüm Küme Yöneticilerini yöneten Konfigürasyon Hizmetidir ve Küme Yöneticisi tüm Ana Bilgisayarları yönetir. Ana bilgisayar terminaldir ve dfget, wget'e benzer bir istemci programıdır.

Config Service, temel olarak Küme Yöneticisi'nin, istemci düğümü yönlendirmesinin, sistem yapılandırma yönetiminin, ısınma hizmetinin vb. Yönetiminden sorumludur. Basitçe ifade etmek gerekirse, ana bilgisayar kendisine en yakın küme yöneticisini her zaman bulabilmesi için ana bilgisayara en yakın küme yöneticisinin adres listesini söylemekten ve bu listeyi düzenli olarak sürdürmekten ve güncellemekten sorumludur.

Küme Yöneticisinin iki ana sorumluluğu vardır:

1. Pasif CDN modunda dosya kaynağından dosyaları indirin ve bir dizi çekirdek blok verisi oluşturun;

2. Bir P2P ağı oluşturun ve her bir eşin belirtilen blok verilerini birbirine iletmesini planlayın.

Dfget, Ana Bilgisayarda depolanır ve dfget'in sözdizimi wget'e çok benzer. Ana işlevler dosya indirme ve P2P paylaşımını içerir.

Ali'de, bir grup makinenin aynı anda dosya indirmesine izin vermek için dfget komutları vermek için StarAgent'ı kullanabiliriz. Belirli bir senaryoda, bir grup makine Alinin tüm sunucuları olabilir, bu nedenle kullanımı çok verimlidir. İstemciye ek olarak, Dragonfly ayrıca dosyaları bir grup sunucuya "PUSH" uygulamanıza izin veren bir Java SDK'ya sahiptir.

Aşağıdaki şekil, iki terminal aynı dosyayı indirmek için aynı anda dfget'i çağırdığında sistemin etkileşim diyagramını göstermektedir:

Dragonfly P2P ağ mantığı diyagramı

İki Ana Bilgisayar ve CM, bir P2P ağı oluşturacak. İlk olarak, CM yerel bir önbellek olup olmadığını kontrol edecek, yoksa, kaynağa geri indirecek. Elbette, dosya parçalanacak. CM, bu parçaları birden çok iş parçacığı halinde indirecek ve aynı anda indirecektir. Parçalar, indirilmek üzere Ana Bilgisayarlara sağlanır. Ana Bilgisayar bir parçayı indirdikten sonra, tüm Ana Makineler indirilene kadar aynı anda indirilmeleri için eşlere sağlanır ve bu böyle devam eder.

Yerel olarak indirirken, indirme parçaları meta verilere kaydedilecektir.İndirme aniden kesilirse, dfget komutunu tekrar çalıştırın ve indirme devam edecektir.

İndirme bittikten sonra, indirilen dosyanın kaynak dosya ile tamamen aynı olduğundan emin olmak için MD5 karşılaştırılacaktır. Dragonfly, CM'nin dosya önbellekleme süresini kontrol etmek için HTTP önbellek protokolünü kullanır.Elbette, CM ayrıca uzun vadeli hizmetleri desteklemek için yeterli alan olduğundan emin olmak için diski düzenli olarak temizleme yeteneğine de sahiptir.

Ali'de, birçok dosya ön ısıtma senaryosu vardır ve konteyner görüntüleri, dizin dosyaları, iş optimizasyonu için önbellek dosyaları vb. Dahil olmak üzere dosyaların önceden CM tarafına gönderilmesi gerekir.

İlk sürüm piyasaya sürüldükten sonra, bir dizi test gerçekleştirdik ve sonuçlar aşağıdaki gibidir:

Geleneksel indirme ve Dragonfly P2P indirme testi sonuçlarının karşılaştırma tablosu

X ekseni müşteri sayısıdır, Y ekseni indirme süresidir,

Dosya kaynağı: test hedef dosyası 200MB (ağ kartı: gigabit bit / sn)

Ana bilgisayar tarafı: 100M bit / sn ağ kartı

CM tarafı: 2 sunucu (24 çekirdek 64G, ağ kartı: Gigabit bit / sn)

Bu şekilde iki sorun görülebilir:

1. Geleneksel modda istemcilerin artmasıyla, indirme süresi artar, ancak dfget 7000'e kadar istemciyi destekleyebilir ve hala gelişmemiştir.

2. Geleneksel model 1200 istemcisine ulaştıktan sonra, veri kaynağı yok edildiği için veri yoktur.

Yayıncılık sisteminden altyapıya

2015'te Double 11'in ardından Dragonfly'ın indirmeleri ayda 120.000'e ulaştı ve dağıtım hacmi 4 TB oldu. O zamanlar Ali'de wget, curl, scp, ftp vb. Gibi başka indirme araçları ve kendi kendine oluşturulmuş küçük ölçekli bir dosya dağıtım sistemi vardı. Kendi yayıncılık sistemimizin kapsamlı kapsamına ek olarak, küçük ölçekli tanıtım da yaptık. 2016'da yaklaşık Double 11 ile indirmelerimiz ayda 140 milyona ulaştı, dağıtım hacmi 708 TB oldu ve işimiz neredeyse bin kat büyüdü.

2016'da Double 11'den sonra, Ali'nin büyük ölçekli dosya dağıtımının ve büyük dosya dağıtımının% 90'ının Dragonfly tarafından gerçekleştirileceğini umarak daha yüksek bir hedef belirledik.

Bu hedefle en iyi P2P dosya dağıtım sistemini eğitmeyi umuyorum. Ek olarak, grup içindeki tüm dosya dağıtım sistemleri birleştirilebilir. Birleştirme daha fazla kullanıcıya fayda sağlayabilir, ancak birleştirme asla nihai hedef değildir .. Birleştirmenin amacı: 1. Gereksiz inşaatı azaltmak, 2. Küresel optimizasyon.

Dragonfly sistemi optimize edildiği sürece, tüm grup faydalanabilir. Örneğin, sistem dosyalarının her gün ağa dağıtıldığını ve bu dosyayı tek başına sıkıştırmanın şirketin her gün 9 TB'lık ağ trafiğini azaltabileceğini gördük. Çok uluslu bant genişliği kaynakları özellikle değerlidir. Ve eğer herkes kendi dağıtım sistemini kullanırsa, bunun gibi global optimizasyon mümkün olmayacaktır.

Yani yeniden birleşme zorunludur!

Büyük miktarda veri analizine dayanarak, tüm grup için belge dağıtım hacminin haftada yaklaşık 350 milyon kez olduğu, o sırada oranımızın sadece% 10'dan az olduğu sonucuna vardık.

Altı aylık yoğun bir çalışmanın ardından Nisan 2017'de nihayet bu hedefe ulaşarak% 90'dan fazla iş payına ulaştık, iş hacmini haftada 300 milyon defaya çıkardık (temelde daha önce analiz ettiğimiz verilerle tutarlıydı) ve dağıtım hacmi 977 TB oldu. Bu rakam bir ay öncesine göre daha fazla.

Tabii ki, bunun Alibaba'nın konteynerizasyonundan da ayrılamayacağı ve görüntü dağıtım trafiğinin yaklaşık yarısını oluşturduğu söylenmelidir. Aşağıda, Dragonfly'ın ayna dağıtımını nasıl desteklediğini anlatacağız. Görüntü dağıtımından bahsetmeden önce Ali'nin konteyner teknolojisinden bahsedelim.

Ali'nin konteyner teknolojisi

Doğal olarak, konteyner teknolojisinin avantajlarının tanıtılmasına gerek yoktur. Küresel olarak, konteyner teknolojisine, pazarın çoğunu oluşturan Docker hakimdir. Elbette, başka çözümler de vardır: rkt, Mesos Uni Container, LXC vb. Ve Alinin konteyner teknolojisi adlandırılmıştır. Kese için. Ali, 2011 gibi erken bir tarihte, LXC'ye dayalı konteyner teknolojisi T4'ü bağımsız olarak geliştirdi, ancak o zaman yansıtma konseptini yaratmadık. T4 hala sanal bir makine olarak kullanılıyor ve elbette sanal bir makineden çok daha hafif.

Ali, 2016 yılında bugünün Poşetine dönüşen T4 temelinde büyük bir yükseltme yaptı ve açık kaynaklı oldu. Şu anda, Pouch konteyner teknolojisi Alibaba Group'un neredeyse tüm iş birimlerini kapsıyor ve çevrimiçi iş yüzbinlerce ölçekle% 100 kapsayıcıya alınmış durumda. Yansıtma teknolojisinin değeri, konteyner teknolojisinin uygulama sınırını genişletti ve Ali'nin böylesine büyük bir uygulama senaryosunda, verimli "ayna dağıtımı" nın nasıl sağlanacağı önemli bir teklif haline geldi.

Ayna seviyesine geri dönün. Makro düzeyde, Alibaba büyük ölçekli konteyner uygulama senaryolarına sahiptir; mikro düzeyde, her uygulama görüntüsü yansıtıldığında kalite de dengesizdir.

Teorik olarak, yansıtma veya geleneksel "temel" modu kullanıyorsanız, uygulama boyutunda büyük bir fark olmamalıdır. Ama aslında bu tamamen Dockerfile'ın kalitesine ve ayrıca görüntü katmanlamanın makul olup olmadığına bağlıdır. Ali aslında dahili olarak en iyi uygulamalara sahiptir, ancak her takım kabulün farklı olduğunu ve kesinlikle faydalı olacağını anlar. Özellikle başlangıçta herkesin 3 ~ 4GB'lık bir ayna yazması çok yaygındır.

Dolayısıyla bir P2P dosya dağıtım sistemi olarak Dragonfly'ın kendine has yetenekleri vardır.Görüntü ne kadar büyük olursa olsun, kaç makineye dağıtılırsa dağıtılsın, görüntünüz kötü oynatılsa bile çok verimli dağıtım sağlayacağız ve darboğaz olmayacaktır. . Bu bize konteyner teknolojisinin hızlı bir şekilde tanıtımını sağlar, herkesin konteyner çalıştırma ve bakım modelini kabul etmesine izin verir ve sindirmek için bize yeterli zaman verir.

Konteyner görüntüsü

Görüntü dağıtımından bahsetmeden önce kısaca kapsayıcı görüntülerden bahsedelim. Ubuntu sisteminin imajına bir göz atalım: ubuntu: 14.04'ü docker history ubuntu: 14.04 komutuyla kontrol edebiliriz, sonuçlar aşağıdaki gibidir:

Boş ayna denilen d2a0ecffe6fa ayna katmanında içerik bulunmadığına dikkat edilmelidir.

Ayna görüntüsü katmanlanır, her katmanın kendi kimliği ve boyutu vardır, burada 4 katman vardır ve son olarak görüntü bu katmanlardan oluşur.

Docker görüntüsü, Dockerfile aracılığıyla oluşturulur, basit bir Dockerfile'a bakın:

Görüntü oluşturma süreci aşağıdaki şekilde gösterilmektedir:

Gördüğünüz gibi, yeni görüntü temel görüntüden katman katman oluşturulur. Bir yazılım parçası her kurulduğunda, mevcut görüntüye bir katman eklenir.

Konteyner başladığında, görüntünün üst katmanına yazılabilir bir katman yüklenecektir.Bu okunabilir ve yazılabilir katman aynı zamanda "konteyner katmanı" olarak da adlandırılır. Konteyner katmanının altında, salt okunur olan "ayna katmanı" bulunur.

Görüntü katmanının içeriği boşsa, karşılık gelen bilgi image json dosyasında açıklanacaktır, görüntü katmanının içeriği boş değilse, OSS'de bir dosya olarak saklanacaktır.

Ayna dağıtımı

Docker görüntüsü indirme akış şeması

Alibaba Bulut Konteyner Hizmetini örnek olarak ele alalım.Geleneksel görüntü aktarımı yukarıdaki şekilde gösterilmektedir. Elbette bu en basitleştirilmiş mimari modudur. Gerçek dağıtım durumu çok daha karmaşık olacak ve kimlik doğrulama, güvenlik, yüksek kullanılabilirlik vb. De dikkate alınacaktır.

Yukarıdaki şekilden de görülebileceği gibi, görüntü aktarımı ve dosya dağıtımında benzer sorunlar vardır.Aynı anda 10.000 ana bilgisayar Tescil talebinde bulunduğunda, Tescil bir darboğaz haline gelecektir.Ayrıca, denizaşırı Ana Bilgisayarlar yerel Tescil'e eriştiğinde bant genişliği kaybı olacaktır. Daha uzun gecikme ve daha düşük başarı oranı gibi sorunlar.

Aşağıda Docker Pull'un yürütme süreci açıklanmaktadır:

Docker görüntüsü katmanlı indirme diyagramı

Docker Daemon, aynanın Manifestini almak için Kayıt API'sini çağırır Manifest'ten her katmanın URL'si hesaplanabilir.Daha sonra Daemon, Kayıt Defteri'nden tüm ayna katmanlarını paralel olarak Ana Bilgisayar yerel deposuna indirir.

Sonuç olarak, aktarımın aynalanması sorunu, her bir yansıtma katmanındaki dosyaların paralel olarak indirilmesi sorunu haline geldi. Dragonfly'ın iyi olduğu şey, her görüntü dosyası katmanını Kayıt Defterinden P2P modunda yerel depoya aktarmaktır.

Peki bunu tam olarak nasıl yaptı?

Aslında, Ana Bilgisayarda dfGet proxy'sini başlatacağız ve Docker / Pouch Engine'den gelen tüm komut istekleri bu proxy üzerinden geçecek. Aşağıdaki resme bakalım:

Dragonfly P2P konteyner görüntü dağılımının şematik diyagramı

İlk olarak, docker pull komutu dfget proxy tarafından durdurulacaktır. Daha sonra, dfget proxy, CM'ye bir planlama isteği gönderir. İsteği aldıktan sonra CM, indirilen ilgili dosyanın yerel olarak önbelleğe alınıp alınmadığını kontrol eder. Önbelleğe alınmamışsa, ilgili dosyayı Kayıt Defterinden indirir ve çekirdek bloklar oluşturur. Veriler (çekirdek blok verileri, oluşturulduktan hemen sonra kullanılabilir); önbelleğe alınmışsa, blok görevi doğrudan oluşturulur ve talep eden, karşılık gelen blok görevini ayrıştırır ve diğer eşlerden veya süper düğümlerden blok verilerini indirir. Bir katmanın tüm bölümleri indirildikten sonra, bir katman indirilir Benzer şekilde, tüm katmanlar indirildiğinde, görüntünün tamamı indirilir.

Dragonfly, kapsayıcı görüntü dağıtımını destekler ve birkaç tasarım hedefi vardır:

1. Büyük ölçekli eşzamanlılık: Yüz bin ölçeğinde eşzamanlı Çekme yansıtmayı destekleyebilmelidir.

2. Konteyner teknolojisi çekirdeğine izinsiz giriş yok (Docker Daemon, Registry): Yani konteyner hizmetinin herhangi bir kodunu değiştiremezsiniz.

3. Docker, Pouch, Rocket ve Hyper gibi tüm konteyner / sanal makine teknolojilerini destekleyin.

4. Görüntü ısınmasını destekleyin: inşa ederken Yusufçuk kümesi CM'ye itin.

5. Büyük resim dosyalarını destekleyin: en az 30GB.

6. Güvenlik

Yerel Docker V.S Dragonfly

İki takım deney yaptık:

Deney 1: 1 müşteri

1. Test resim boyutu: 50MB, 200MB, 500MB, 1GB, 5GB

2. Yedek depo bant genişliği: 15 Gb / sn

3. İstemci bant genişliği: çift 100M bit / sn ağ ortamı

4. Test ölçeği: tek indirme

Tek istemcinin farklı modlarının karşılaştırılması

Native ve Dragonfly (akıllı sıkıştırma özelliği kapalıyken) temelde ortalama olarak aynıdır ve Dragonfly biraz daha yüksektir, çünkü Dragonfly indirme işlemi sırasında her veri bloğunun MD5 değerini doğrular ve ayrıca indirdikten sonra tüm dosyanın MD5'ini doğrular. , İndirilen dosyanın kaynak dosyayla tutarlı olmasını sağlamak için ve akıllı sıkıştırma modu açıldığında, zaman alıcı Yerel moddakinden daha düşüktür!

Deney 2: Çok müşterili eşzamanlılık

1. Test resim boyutu: 50MB, 200MB, 500MB, 1GB, 5GB

2. Yedek depo bant genişliği: 15 Gb / sn

3. İstemci bant genişliği: çift 100M bit / sn ağ ortamı

4. Çoklu eşzamanlılık: 10 eşzamanlı, 200 eşzamanlı, 1000 eşzamanlı

Farklı ayna boyutları ve eşzamanlılığın karşılaştırılması

Yukarıdaki şekilden de görülebileceği gibi, indirme ölçeğinin genişletilmesiyle Dragonfly ve Native modu arasındaki zaman alan fark önemli ölçüde arttı ve maksimum hız 20 kat artırılabilir. Test ortamında kaynağın bant genişliği de çok önemlidir Kaynağın bant genişliği 2 Gbps ise hız 57 kat artırılabilir.

Aşağıdaki şekil, indirilen dosyaların toplam trafiği (eşzamanlı sayı * dosya boyutu) ile kaynağa dönüş trafiği (Kayıt defterinden indirilecek trafik) arasındaki bir karşılaştırmadır:

Yusufçuk ayna dağılımı trafik karşılaştırma tablosu

500 milyon görüntüyü 200 düğüme dağıtmak, docker native moduna göre daha düşük ağ trafiği kullanır.Deneysel veriler, Dragonfly kabul edildikten sonra, kayıt defterinin giden trafiğinin% 99,5'ten fazla azaldığını ve aynı anda 1000'lik bir ölçekte kayıt defterinin giden trafiğinin daha da iyi olduğunu göstermektedir. Yaklaşık% 99,9'a düşürün.

Alibaba uygulama etkisi

Ali'de yaklaşık iki yıldır kullanılmakta olan Dragonfly, son iki yılda hızla gelişti, dağıtım sayısına göre şu anda ayda 2 milyara yaklaşarak 3,4 PB veri dağıtıyor. Konteyner görüntülerinin dağıtım hacmi neredeyse yarı yarıya.

Dragonfly, Ali dosyalarındaki trafik eğilimlerini yansıtmaya karşı dağıtır

Ali'deki en büyük dağıtım, 5 GB'lık veri dosyalarının aynı anda on binlerce sunucuya dağıtılması gereken Double 11 döneminde olmalıdır.

Zekaya doğru

Ali, AIOps'u ilk başlatan kişi olmasa da, son yıllarda yoğun bir yatırım yaptık ve bunu birçok ürüne uyguladık. Yusufçuk aşağıdaki uygulamalara sahiptir:

Akıllı akış kontrolü

Karayolu trafiğinde akış kontrolü çok yaygındır.Örneğin, Çin'deki yollarda hız sınırı merkez hattı olmayan yollar için 40 km / s'dir; aynı yönde yalnızca bir otoyol bulunan yollar için hız sınırı 70 km / s'dir; ekspres yollar 80 kilometre; otoyolların maksimum hız limiti saatte 120 kilometredir vb. Bu tür bir hız limiti her araç için aynıdır ve yeterince esnek olmadığı açıktır, bu nedenle, yol çok boşta olduğunda yol kaynakları aslında çok israf olur ve genel verimlilik çok düşüktür.

Trafik ışıkları aslında bir akış kontrol aracıdır. Günümüzde trafik ışıkları sabit bir zamanda sabitlenmiştir ve gerçek trafiğe dayalı olarak akıllıca kararlar vermez. Bu nedenle, geçen yıl Ekim ayında düzenlenen Yunqi Konferansı'nda Dr. Wang Jian, dünyanın en ücra köşesinin olduğunu hissetti. Mesafe Güney Kutbundan Kuzey Kutbu'na değil, trafik ışıklarından trafik kamerasına kadardır.Aynı kutup üzerindedirler, ancak hiçbir zaman veri yoluyla bağlanmamışlardır.Kameranın gördüğü şey asla bir trafik ışığı eylemi haline gelmeyecektir. Bu sadece şehrin veri kaynaklarını boşa harcamakla kalmaz, aynı zamanda şehir işletim ve geliştirme maliyetlerini de artırır.

Dragonfly'ın parametrelerinden biri, disk ve ağ bant genişliği kullanımını kontrol etmektir.Kullanıcılar, parametreler aracılığıyla ne kadar ağ G / Ç / disk GÇ kullanılacağını ayarlayabilir. Yukarıda bahsedildiği gibi, bu yöntem çok katıdır. Bu nedenle, istihbarat alanındaki ana fikirlerimizden biri, benzer parametrelerin artık manuel olarak ayarlanmayacağını, ancak iş koşullarına ve sistem çalışmasına bağlı olarak bu parametrelerin yapılandırmasını akıllıca belirleyeceğini ummaktır. Başlangıçta en uygun çözüm olmayabilir, ancak bir süre çalıştırma ve eğitimden sonra, kaynak israfını önlemek için ağ ve disk bant genişliğinden mümkün olduğunca tam olarak yararlanırken istikrarlı iş operasyonunu sağlamak için otomatik olarak optimum duruma ulaşacaktır.

Akıllı zamanlama

Blok görev planlaması, tüm dosya dağıtımının verimliliğini belirleyen önemli bir faktördür.Sadece rastgele zamanlama veya diğer sabit öncelikli planlama gibi basit bir planlama stratejisi yoluyla yapılıyorsa, bu yaklaşım genellikle indirme hızında sık sık titremelere neden olur ve bu da kolaydır Bu, çok fazla indirme hatasına yol açar ve genel indirme verimliliği de çok zayıftır. Görev planlamasını optimize etmek için, sayısız girişim ve keşiften geçtik ve son olarak, birden çok boyutun (makine donanım yapılandırması, coğrafi konum, ağ ortamı, geçmiş indirme sonuçları ve hız vb.) Veri analizinden geçtik. Gradyan iniş algoritması, diğer algoritmalar daha sonra denenecek), akıllıca ve dinamik olarak mevcut istek sahibi için en iyi sonraki blok görev listesini belirler.

Akıllı sıkıştırma

Akıllı sıkıştırma, dosyanın en değerli kısmı için karşılık gelen sıkıştırma stratejisini uygular ve bu da çok sayıda ağ bant genişliği kaynağından tasarruf sağlayabilir.

Konteyner görüntülerinin mevcut gerçek ortalama verilerinden, sıkıştırma oranı (Sıkıştırma Oranı)% 40'tır, bu da 100MB görüntülerin 40MB'ye sıkıştırılabileceği anlamına gelir. Eşzamanlı 1000 ölçeğini hedefleyen trafik, akıllı sıkıştırma yoluyla% 60 azaltılabilir.

Emniyet

Belirli hassas dosyaları (gizli anahtar dosyaları veya hesap veri dosyaları, vb.) İndirirken, aktarım güvenliği etkin bir şekilde garanti edilmelidir.Bu bağlamda, Dragonfly iki ana görevi yerine getirmiştir:

1. Başlıklar aracılığıyla izin doğrulaması gerektiren dosya kaynaklarını karşılamak için HTTP başlık verilerini taşıma desteği;

2. Dosyanın içeriğini şifrelemek için simetrik bir şifreleme algoritması kullanın.

Açık kaynak

Konteyner teknolojisinin popülaritesi ile birlikte, konteyner görüntüleri gibi büyük dosyaların dağıtımı önemli bir konu haline geldi.Konteyner teknolojisinin gelişimini ve büyük ölçekli dosyaların veri merkezlerinde dağıtımını daha iyi desteklemek için Ali, teknolojinin gelişimini daha iyi desteklemek için Dragonfly'ı açık kaynak yapmaya karar verdi. Alibaba, açık kaynak topluluğunu desteklemeye ve sahada test edilmiş teknolojilerini topluluğa katkıda bulunmaya devam edecek. Bizi izlemeye devam edin.

sonuç olarak

Dragonfly, akıllı sıkıştırma, akıllı akış kontrolü ve diğer yenilikçi teknolojileri birleştirirken P2P teknolojisini kullanarak büyük ölçekli dosya indirmeleri ve ağlar arası izolasyon gibi senaryolarda çeşitli dosya dağıtım sorunlarını çözer ve veri ön ısıtmasını ve büyük ölçekli konteyner görüntü dağıtımını büyük ölçüde geliştirir. kabiliyet.

Dragonfly, kabın kendisinde herhangi bir değişiklik yapmadan çeşitli kapsayıcı teknolojilerini destekler Görüntü dağıtımı natvie yönteminden 57 kat daha hızlı olabilir ve kayıt ağı giden trafiği% 99,5'ten fazla azaltılır. PB seviyesinde trafik taşıyan Dragonfly, işin hızla büyümesine ve Double 11'in tanıtımına eşlik ederek Ali'nin önemli altyapılarından biri haline geldi.

Not: Bulut Verimliliği 2.0 Akıllı İşletim ve Bakım Platformu - Dünya çapında etkili bir akıllı işletim ve bakım platformu oluşturmaya kararlıyız, kıdemli teknik / ürün uzmanları, çalışma yerleri: Hangzhou, Pekin ve Amerika Birleşik Devletleri arıyoruz. İlgilenenler, makalenin sonundaki "Orijinal metni okuyun" u tıklayabilir Daha fazla bilgi edin.

Referans

Docker'a Genel Bakış:

https://docs.docker.com/engine/docker-overview/

Docker görüntüleri nerede depolanır:

Görüntü Özellikleri:

https://github.com/moby/moby/blob/master/image/spec/v1.md

Torba açık kaynak adresi:

https://github.com/alibaba/pouch

Dragonfly açık kaynak adresi:

https://github.com/alibaba/dragonfly

Alibaba Bulut Konteyner Hizmeti:

https://www.aliyun.com/product/containerservice