Ali Middleware Performance Challenge başlatıldı ve "açık kaynak" rekabet soruları özel olarak analiz edildi!
26 Nisan'da, 2018 Yunqi Konferansı'nın Nanjing Zirvesi'nde Alibaba araştırmacısı Lin Hao, dördüncü Alibaba Middleware Performance Challenge'ı resmen yayınladı. Zorluk, açık kaynaklı projelere dayanmaktadır ve temel teknolojiler Dubbo ve RocketMQ'dur.Amaç, açık kaynak ruhunu yarışma yoluyla teknoloji meraklılarına aktarmaktır.
Lin Hao, "Geliştiriciler için, birçok iş açık kaynaklı şeyler kullanıyor ve açık kaynak tüm dünya üzerinde çok büyük bir etkiye sahip. Aynısı Alibaba için de geçerli. Alibaba da açık kaynaklı yazılım kullanıyor. Bu süreçte, tüm açık kaynaklı üründe birçok iyileştirme yapmak ve topluluğa geri vermeye devam etmek için Alinin senaryolarıyla birleştirdik. "
Alibaba'nın açık kaynak temposu 2017'den beri artıyor.
RocketMQ, Eylül 2017'de Apache'den mezun oldu ve Apache Top Level Project (TLP) oldu. Ekim ayında, OpenMessaging, dağıtılmış mesajlaşma ara yazılımı ve akış işleme alanında uygulama geliştirme standardını yayınladı ve şimdi resmi olarak Linux Vakfı'na girdi. Bu, aynı zamanda küresel olarak başlatılan dağıtılmış mesajlaşma alanındaki ilk uluslararası standarttır. Kasım ayında, topluluk aniden hareketlendi ve Dubbo hızla güncellendi, bu da büyük ilgi gördü. Bu yıl Dubbo, şu anda kuluçka döneminde olan Apache'ye girdi.
Apache Vakfı'nın kurucu ortağı Jim Jagielski, en iyi Apache projesi RocketMQ'nun son derece güçlü ve dönüştürücü bir yazılım projesi olduğunu ve birçok şirketin derin kullanıcıları olduğunu söyledi. Dubbo şu anda Apache Yazılım Vakfı'nda kuluçkaya yatırılmaktadır ve büyük bir potansiyele sahiptir.
Middleware Performance Challenge artık dördüncü kez. Bu, daha fazla teknik geliştiricinin katılmasına izin vermek için yarışma sorularının açık kaynak arka planına ilk kez ayarlanması.
Aşağıda, bu rekabetin ayrıntılı bir analizini yapacağız.
Dubbo'yu tanıyan arkadaşlar, Dubbo'nun sadece yüksek performanslı bir RPC iletişim çerçevesi olmadığını, aynı zamanda eksiksiz bir mikro hizmet çözümleri seti - hizmet kaydı ve keşfi, yük dengeleme, hizmet yönetimi vb. Olduğunu bilirler, bunların hepsi bize tanıdık gelir. Kabiliyet. Ancak Dubbo'nun da doğal eksiklikleri var ve ön turun sorunu bundan kaynaklandı.
1. Asıl niyet
Dubbo, Java uygulamalarına üretim ortamlarında kullanılabilecek verimli, kararlı ve RPC iletişim yetenekleri sağlamayı her zaman taahhüt etmiştir.Ancak, gRPC ve Spring Cloud ile karşılaştırıldığında Dubbo'nun diller arası yetenekleri büyük bir zayıflıktır. RESTful arayüzünü kullanmadan, kullanıcıların Dubbo'yu diğer dillerde uygulanan sistemlere bağlamaları zordur. Bu nedenle, bu yarışma dil engelini aşacaktır.Katılımcı takımlar en sevdiğiniz teknolojiyi, ana akım veya ana akım olmayanları özgürce seçebilirler - Umursamıyoruz - Dubbo'nun çok dilli yönde ilk sırada yer almasına izin vermeyiz. adım.
Dubbo'ya gelince, mikro hizmetler hakkında konuşmak zorundasınız.Microservisler söz konusu olduğunda, Service Mesh için bir yer olmalıdır.
Geleneksel mikro hizmetler bize hizmetin geleceği için bir plan gösterdiler ve ayrıca yapısal değişiklikleri tamamlamamıza rehberlik edecek birçok metodoloji ve en iyi uygulama sağladılar. Ancak, mikro hizmetleri uygulayan arkadaşlar, bunun son derece karmaşık ve belirsiz bir dönüşüm süreci olduğunun farkında olmalıdır - tek sistemi ortadan kaldıran ve hizmet bileşenlerini tanıtan (Dubbo ilk tercihiniz değilse, siz Bu rekabete dikkat etmek için daha fazla neden var), dahili aramaları uzaktan aramalara dönüştürmek ve uzak ve dağıtık aramaların neden olduğu çeşitli ikincil sorunları (ağ sorunları, güvenlik sorunları, durum yönetimi sorunları, tutarlılık sorunları vb.) Bekle). Karmaşık sistemlere sahip organizasyonlarda, böyle bir dönüşüm kabustan daha az değildir. Her türlü standart dışı Java uygulamalarını, PHP uygulamalarını ve Python uygulamalarını açma ve sunma ihtiyacını düşünün. Ya rüya görüyorsunuz ya da müşteriler rüya görüyor.
Ancak böyle bir rüya yüzleşmemiz gereken gerçektir ve Service Mesh şüphesiz rüya mimarın size vereceği hayat kurtaran bir pipettir. Kısacası, Service Mesh, hizmetin derinliklerine inmeden, hizmetle bir Aracı biçiminde birlikte var olan başka bir yaklaşımı benimser ve Aracı, mikro hizmetlerin gerektirdiği tüm yetenekleri sağlar. Adından da anlaşılacağı gibi, Service Mesh, altındaki çeşitli hizmetleri kapsayan bir ızgara gibidir. Bu ön yarışmanın konusu, yarışmacıların Dubbo'yu hizmet ağı ağına entegre etmek için yüksek performanslı bir Ajan uygulaması yazacaklarını ummaktır.
İkincisi, sahne
Bu yarışmada eksiksiz bir Service Mesh çerçevesi uygulamaya gerek olmadığı için sahneyi sınırladık. Docker tarafından sağlanan konteynerizasyon yetenekleri sayesinde istenilen senaryoyu kolayca simüle edebiliyoruz. Şekilde gösterildiği gibi, tüm sahne 5 Docker örneğinden (mavi kutular), çalışan etcd, Tüketici, Sağlayıcı hizmetleri (yeşil kutular) ve Aracı temsilcilerinden (kırmızı daireler) oluşur.
Sağlayıcı, hizmet sağlayıcıdır, Tüketici hizmet tüketicisidir ve Tüketici, Sağlayıcı tarafından sağlanan hizmeti tüketir. Temsilci, Tüketici ve Sağlayıcı hizmetlerinin acentesidir ve her Tüketici veya Sağlayıcıya bir simbiyotik Temsilci eşlik edecektir. etcd, hizmet kayıt bilgilerini kaydetmek için kullanılan bir kayıt hizmetidir. Tüketici ile Sağlayıcı arasındaki iletişimin doğrudan yapılmadığı, ancak Acente tarafından aktarıldığı şekilden görülebilmektedir. Görünüşte fazlalık olan bu bağlantı, Hizmet Ağı mimarisinde önemli bir rol oynar.
Her şeyden önce, Aracının yük dengeleme becerisine ihtiyacı vardır. Şekilde, mavi kutunun boyutu, kabın performansını temsil etmektedir. Bir Tüketici örneğinin performansının, üç Sağlayıcı örneğinin performansının toplamı olduğunu ve üç Sağlayıcının performansının 1: 2: 3 oranında tahsis edildiğini görebiliriz. Genel sistem performansı 60 ise, Tüketici (küçük) 30, Sağlayıcı (küçük) 5, Sağlayıcı (orta) 10 ve Sağlayıcı (büyük) 15 hesaplar. Bu nedenle, herhangi bir Sağlayıcı hizmetinin performansı Tüketicininkinden daha düşüktür ve Temsilci, herhangi bir Sağlayıcı hizmetinin bunaltılmamasını sağlamak için yük dengeleme gerçekleştirmelidir.
İkinci olarak, Temsilcinin hizmet kaydı ve keşfi yeteneğini gerçekleştirmesi gerekir. Hizmet kaydı ve keşfi, mikro hizmetlerin temel yetenekleridir.Tüketici Temsilcisi tarafından erişilecek Sağlayıcı Aracısı, yapılandırma dosyasında sabit kodlanmış değil, dinamik olarak keşfedilmiştir. Basitçe ifade etmek gerekirse, Agent başladığında, kendi bilgilerini etcd kayıt defterine yazması gerekir.Bir servis çağrısı gerçekleştiğinde, ilgili kayıt bilgilerini etcd'den okur.Bu işlem en basit servis kaydı ve keşfidir.
Üçüncüsü, Aracının protokol dönüştürmesini uygulama becerisine ihtiyacı vardır. Service Mesh'in önemli bir özelliği, protokol dönüştürme yeteneklerine dayanarak farklı diller, farklı çerçeveler ve farklı protokoller arasında hizmetlerin ara bağlantısını ve karşılıklı iletişimini gerçekleştirebilmesidir. Oyun kurgusu sahnesinde Tüketici HTTP protokolünü ve Sağlayıcı Dubbo protokolünü kullanır Temsilcinin yardımı olmadan birbirleriyle iletişim kuramazlar.
Bir Hizmet Ağı Aracısı olarak, akış kontrolü, hizmet bozulması veya sigortası, güvenlik sertifikası vb. Gibi aslında birçok ulaşılabilir işlev vardır, ancak yukarıdaki üç nokta, bu yarışmada elde edilmesi gereken yeteneklerdir ve diğer yetenekler gerekli değildir. Ek olarak, Temsilcinin çok yönlülüğünü de göz önünde bulundurmamız gerekir Çok yönlülüğü olmayan bir Temsilcinin ticari değeri yoktur. Ek olarak, Temsilciler tarafından kullanılan sistem kaynakları olabildiğince küçük olmalı ve simbiyotik hizmetlerle kaynaklar için rekabet etmemelidir, aksi takdirde "cilt olmayacak ve saç yapışacaktır." Hizmet yanıtını kaybederse, Temsilcinin performansı ne kadar iyi olursa olsun, bunun bir anlamı yoktur.
Üç, koşu noktaları
Çalışma ortamı 4 çekirdekli bir 8G pres ve 8 çekirdekli bir 16G baskıdan oluşur. 5 Docker örneğinin tümü sıkıştırılmış makinede çalışıyor. Her projenin devam eden her şubesinin özel bir baskısı vardır. İşlem kabaca şu şekildedir:
Alt ortamı çalıştırmaya, çalışma alanını oluşturmaya ve kilitlemeye hazırlanın
Gönderilen adrese göre ayna görüntüsünü ayna deposundan çekin
Kurcalamayı önlemek için Sağlayıcı, Tüketici ve başlangıç komut dosyalarının imzalarını doğrulayın
Etcd örneğini başlatın ve hizmet kullanılabilirliğini doğrulayın
Üç Sağlayıcı örneği başlatın ve hizmet kullanılabilirliğini doğrulayın
Tüketici örneğini başlatın ve hizmet kullanılabilirliğini doğrulayın
En yüksek eşzamanlı sayı ile sistemi ısıtın
Sistem üzerinde birkaç kez farklı basınç seviyelerinde basınç testi yapın ve QPS değerini kaydedin
En iyi QPS'yi son koşu puanı olarak alın ve Tianchi sistemine bildirin
Sırayla Tüketici örneğini, üç Sağlayıcı örneğini ve etcd örneğini durdurun
Docker örneklerini ve görüntülerini temizleyin
Günlükleri toplayın ve OSS'ye yükleyin
Çalışma alanının kilidini açın, ortamı temizleyin
Bu yarışma, dil ve teknoloji ile sınırlı olmadığından, oyuncuların koşu ortamını izole etmek için bir araca ihtiyaç vardır. Docker imajının yardımıyla, yarışmacılar çalışma zamanı ortamını kurabilir, bileşen kitaplıkları ekleyebilir ve Agent'ın başlangıç komut dosyasını istedikleri zaman özelleştirebilir.
Ancak Sağlayıcı ve Tüketici hizmetleri ve Temsilci simbiyotik olduğundan, hepsinin aynı Docker görüntüsünde vurulduğu unutulmamalıdır. Oyuncuların yalnızca yarışmanın değiştirilmesine izin verilen kısmına - Temsilci ile ilgili içeriğe - dikkat etmesini sağlamak için yarışmayı tasarlarken kodu tamamen izole ettik. Ancak yine de, bir Docker görüntüsü oluşturma girişimi herkesin elinde olduğundan, Sağlayıcı ve Tüketici ile bunların başlangıç komut dosyalarında değişiklik yapma olasılığı mutlaka vardır. Bu nedenle adillik ilkesine dayalı olarak ilgili belgelerin imzasının doğrulanması süreci devam eden sürece eklenmiştir.İmza başarısız olursa değerlendirme fırsatı kaybedilecektir.
Dört, optimizasyon
Optimizasyon süreci bu rekabetin odak noktası olduğundan, çok fazla genişletme yapamayız, sadece birkaç referans yön verelim.
Eşgörünümleri kullanın. Koroutin, iş parçacığı değiştirmenin neden olduğu performans kaybını koruyabilen hafif bir iş parçacığı olarak anlaşılabilir.
Eşzamansız iletişim kullanın. Aracı ve Aracı arasındaki iletişim mekanizması tamamen oyuncuların kendileri tarafından kontrol edilir ve engellemeyen eşzamansız iletişim mekanizması sistem performansını etkili bir şekilde iyileştirebilir.
Önbelleği kullan. Yanıt sonuçlarını makul bir şekilde önbelleğe alın Aynı istek tekrar geldiğinde, çağrı zinciri sistemdeki her düğümden geçmek zorunda kalmadan mümkün olan en kısa sürede geri dönebilir.
Yukarıdakiler, yarışmanın asıl amacı, uygulama senaryoları, çalışma ortamı ve süreci ve biraz optimizasyon yönü perspektifinden bu yarışmanın konusunun basit bir analizidir.Umarım yarışmaya katılmak üzere olanlara yardımcı olur. Tüm yarışmacılara mükemmel sonuçlar diliyorum ve yarı finallere ve finallere girmelerini diliyorum.
Alibaba Middleware Performance Challenge, Alibaba Group tarafından başlatıldı ve 2015'ten bu yana üç kez başarıyla gerçekleştirildi. Asıl amacımız, teknolojiyi seven gençlerin birinci sınıf teknik sorunlara meydan okumaları için bir sahne sağlamaktır.Umarız ki, oyuncuların en üst düzey performansın peşinden giderken, teknik insanların yaratıcılığını derinden takdir edebilir ve teknolojiyi tüm toplum için daha fazla değer yaratmak için kullanabiliriz.
Ziyarete hoş geldiniz: https://tianchi.aliyun.com/markets/tianchi/aliware2018contest,
Daha fazla bilgi edinin ve yarışmaya katılın.
