Bir Yılbaşı partisi 5 milyar yuan kazandı. B İstasyonu mikro hizmet yönetimini nasıl araştırıyor ve uyguluyor?
Bu yıl B istasyonundaki Yılbaşı partisi başarılı bir şekilde çemberin dışına çıktı ve her David'i "asarak vurarak" çemberin dışına çıktı. Trafik, duygu, iki boyut, Çin ve Batı kültürü, gelenek ve modernliğin mükemmel birleşimi, gençler tarafından hayranların anılarındaki en hassas duyguları tatmin eden "telafi dersleri" olarak adlandırıldı. "Yürüme", B istasyonu partisinin başarısının anahtarıdır ve aynı zamanda B'nin mikro hizmet yönetişimindeki tavrıdır. Bu makale, Cao Guoliang'ın Qutoutiao Teknoloji Salonundaki "Mikro Hizmet Yönetişiminde B İstasyonunun Keşfi ve Uygulaması" konuşmasından derlenmiştir.
Herkes mikro hizmetlerin iki sorun noktası olduğunu bilir: Biri mikro hizmetlerin nasıl bölüneceği, mikro hizmetlerin sınırlarının nasıl bölüneceği ve formüle edileceği; diğeri ise, ölçeklendikten sonra mikro hizmetlerin nasıl yönetileceği, çünkü ölçeklendikleri sürece herhangi bir küçük sorun olabilir. Güçlenecek ve sonunda çığ etkisine yol açacaktır.
Mikro Hizmetlerin Getirdiği Zorluklar
Yukarıdaki resim, B istasyonumuzun tam bağlantı takibinin bir ekran görüntüsüdür Bu, zaten çok karmaşık olan topoloji diyagramlarından birinin yalnızca arama bağlantısıdır. Tüm şirketin çağrı bağlantıları olsaydı ne kadar karmaşık olacağını tahmin edebilirsiniz. Bu, mikro hizmet yönetişiminin karmaşıklığını beraberinde getirir: kayıt ve keşif nasıl sağlanır; birden çok bilgisayar odası için yüksek kullanılabilirlik nasıl sağlanır; düşük gecikme nasıl sağlanır vb.
İkinci olarak, mikro hizmetlerden sonra, daha fazla hizmet bölünmesi olur ve çağrı zinciri nispeten uzundur Çağrı zinciri, kötü bir düğümden kolayca etkilenir ve kullanıcı tarafında bir zaman aşımı olgusuna neden olur. Ek olarak, yük dengesizliği sıcak sorunlara neden olacak ve kaynak planlamasını etkileyecektir; tek bir düğüm kullanılamaz ve mevcut sınırlama veya sigorta araçları iyi yapılmazsa bir çığ etkisi olabilir; mikro hizmet temsilcilerinin dağıtılmış işlem sorunu ve dağıtılmış tutarlılık sorunu, Ve zamanlama, günlük kaydı ve bağlantı izleme gibi sorunlar.
B sitesi açık kaynak hizmet keşif çerçevesinde dile gidin - Keşif alıştırma kursu
2015'ten 2017'ye kadar, B istasyonunun mikro hizmetleri de Zookeeper'a dayanıyordu.Zookeeper, ağ bölümleri durumunda tutarlılığı ve kullanılabilirliği sağlayabilen bir CP sistemidir. Ancak CP sistemimizin bir sorunu var, yani çapraz makine odalarını desteklemek zor. Bilgisayar odası 1 ve bilgisayar odası 2'nin bazı kararsız nedenlerle bağlantısı kesilirse, sağlayıcı B'nin ZK Follower'a kaydı gerçekleştirilemez. ZK Follower'ın tüm istekleri son derece tutarlı ve ZK Leader ile senkronize olduğundan, bilgisayar odası 2 şu anda kayıt olamaz, ancak aslında Tüketici B ve Sağlayıcı B arasındaki ağ normaldir.
Zookeeper bir performans darboğazına sahiptir, çünkü son derece tutarlı sistemler genellikle tüm günlüğü önbelleğe alırken, ZK Leader tek bir düğümdür ve tüm yazma istekleri ZK Leader'a gider. Ek olarak, TCP tabanlı durum denetimi optimal değildir.
2018 yılında, kendi başımıza bir hizmet keşif çerçevesi geliştirmeye başladık ve bu çerçeve, B istasyonunda büyük ölçüde kullanıldı. Bu bir AP sistemidir Servis Sağlayıcı kaydedildikten sonra, tüm kayıtlar, sağlık kontrolleri ve kayıt silme işlemleri, nihai tutarlılığı sağlamak için Keşif Sunucusu aracılığıyla diğer Keşif Sunucuları ile eşzamansız olarak senkronize edilecektir.
Keşif Sunucusu, sağlıklı hizmet düğümlerinin kullanılabilir olmasını sağlamak için ağ bölümleme sırasında kendi kendini korumayı karşılamalıdır.
İstemci ve Keşif Sunucusu, HTTP Uzun Yoklama yoluyla bağlanır. Bu geliştirme yöntemi nispeten basittir ve sadece zaman içindeki düğüm değişikliklerini tespit etmekle kalmayıp aynı zamanda eşzamanlı programlamanın bakımını da kolaylaştıran itme-çekme kombinasyonunun faydalarına sahiptir.
Yukarıdaki şeklin altındaki tablo açık kaynak Eureka ile bir karşılaştırma çizelgesidir. Temelde Eureka yapabilir, Discovery yapabilir, Eureka yapamaz, Discovery yapabilir. (Ayrıntılar için tabloya bakın)
Ardından, bilgisayar odasının trafik planlamasını tanıtacağım.
Sağ alt köşedeki operasyon ve bakım kötüsü, bilgisayar odası A ile ilgili bir sorun olduğunu algılar ve bir talimat verebilir. Talimat, Keşif düğümü aracılığıyla B bilgisayar odasına dağıtılabilir. Difüzyon tamamlandıktan sonra, dağıtım için bilgisayar odası A'daki rastgele bir düğüm seçilecek ve son olarak zamanlama bilgileri Tüketici, tüketici trafiğin çoğunu otomatik olarak B'ye geçirir.
Nihai tutarlılık nasıl sağlanır?
Her hizmet sağlayıcı örneği küresel olarak benzersizdir ve hizmet örneği, hizmet kimliği + Ana BilgisayarAdı aracılığıyla küresel olarak konumlandırılabilir, böylece her hizmet sağlayıcı örneği bir anlaşmaya vardığında hizmet keşfi tamamlanır. Servis sağlayıcı örneği, onu Keşif düğümüne gönderdikten sonra monoton olarak artan bir dirtyTime koruduğu sürece, Keşif Sunucusu kayıt talebini veya diğer talepleri aldıktan sonra bu talepleri yayınlayacak ve verilerin tutarlılığı yayın sırasında kontrol edilebilecek.
Discovery'nin bir diğer önemli konusu afet toleransıdır. Ağ bölümleri ve ağ titreşimi oluştuğunda, kalp atışı bilgisi her Keşif arasında eşzamanlı olarak çoğaltılır, böylece kısa sürede çok sayıda kalp atışı kaybolur. Örneğin, dakikadaki kalp atışı eşikten düşükse, Discovery bunu algılayacak ve bu sırada ortadan kaldırılması gereken bazı talimatlar ortadan kaldırılmayacaktır. Kendini korumama moduna girmeseniz bile, Discovery, ani çıkarma nedeniyle tüm sürenin dolmasını önlemek için bunları adım adım rastgele kaldırır.
Yalnızca bazı Keşif düğümleri kullanılamadığında, çünkü her düğümde veri olduğundan, şu anda veri almak için yalnızca diğer normal Keşif düğümlerine bağlanmanız gerekir ve kullanılamayan düğümler yeniden başlatıldıktan sonra, normal düğümler otomatik olarak çekilir. , En son senkronizasyonu koruyun.
Tüm düğümler kullanılamıyorsa, istemci SDK verileri önbelleğe alır ve çok düşük sayıda örnekle herhangi bir anormal değişikliği reddeder; kesinti sırasında, hizmet sağlayıcı Disocvery düğümü yeniden başlayıp normale dönene kadar Keşif düğümüne sinyal istekleri göndermeye devam edecektir. Bundan sonra, 404 döndürülür ve servis sağlayıcı Kayıt arayüzünü arayarak yeniden kayıt olur.
Keşif çerçeve istemcisi temelde sıfır konfigürasyona sahiptir İstemci SDK, SLB'yi talep ederek tüm Discovery sunucu düğümlerini alır ve verileri çekmek için düğüm olarak rastgele bir düğüm seçer. İkinci olarak, kodda dinamik kayıt yaptık, yani her müşteri.Dial bir bağlantı oluşturacak, her bağlantı bir hizmet tüketecek ve her hizmet küresel olarak benzersiz bir uygulama kimliğine karşılık gelecek. Kod, appID tarafından yazılmıştır. Düğüm bilgilerini alın ve bağlanın. Bu appID yöntemi dinamik abonelik, dinamik yok etme ve sıfır yapılandırma sağlayabilir.
Sıfır konfigürasyonun bir özelliği, tüm istemci SDK'larının dinamik olarak oluşturulması, yani tüm aboneliklerin ve çekmelerin istemcide dinamik olarak ekolojik olması gerektiğidir. Şu anda, dünya çapında benzersiz bir İnşaatçı yaratmamız gerekiyor. Builder Arayüzü, biri Build ve diğeri Scheme olmak üzere iki yöntem uygular. Build yöntemi bir parametre-appID'yi kabul eder ve ardından Çözümleyiciye geri döndüğünde Çözümleyici watch'u çağırır. Global bir olay değişikliği olduğunda, Oluşturucu'ya gönderilecek ve Çözümleyici, Posta Kutusundan ilgili bilgileri alacak ve getirme yoluyla dinamik bildirim ve gerçek zamanlı itme gerçekleştirecektir.
Bunların hepsi Golang CSP eşzamanlılık modelimizden yararlanır. Discovery temelde bu şekilde iletişim kurar ve eşzamanlı programlama problemlerini çözmek için bu yöntemi kullanır. Discovery'de Go dilinin en iyi uygulamalarını sizinle paylaşın.
Birincisi hata grubunun kullanılmasıdır.Birden fazla grup ekibi başlattığımızda ve bunlardan biri başarısız olursa, bu eşzamanlı isteğin başarısız olduğu kabul edilir. Ancak hata grubunu kullandıktan sonra, bir grup ekibi başarısız olduğunda, dönüş hatasından sonra yeni bir bağlam oluşturulur, böylece hatayı yayarak kaynak israfı önlenebilir.
İkincisi, dağıtılmış istemci yeniden denemede başarısız olduğunda BackoffRetry'yi mümkün olduğunca çok kullanmaktır. Şu anda 100 müşteri olduğunu varsayarsak, arama sonu patladığında veya CPU dolduğunda, istemciler aynı anda yeniden denerse, durum çok kötüleşecek, herkes rekabet edecek ve kuyruk gittikçe daha ciddi hale gelecektir. BackoffRetry'yi kullanmak, rastgele bir miktar eklemeye, bir hatadan sonra rastgele Uyku'ya ve bir kaçınma kuralı eklemeye eşdeğerdir; örneğin, bu sefer 1 milisaniye ve bir sonraki sefer 2 milisaniyedir. Bu şekilde, yeniden denemenin başarı oranı mümkün olduğunca garanti edilebilir.
RPC yük dengeleme algoritmasının gelişimi
Hizmet keşfi bir AP sistemidir ve gecikmeler olabilir. Çektiğiniz düğüm yanlış bir düğüm olabilir, bu nedenle hızlı bir şekilde ortadan kaldırmak için yük dengelemeye ihtiyacımız var. Ek olarak, bir düğümün nispeten yüksek bir CPU'su veya ağ titremesi olduğunda, yük dengeleme de gereklidir.
Bu, yük dengeleme algoritmamızın 1.0 sürümüdür, daha yaygın olan Weighted Round Robin. Yukarıdaki şekilde de görülebileceği gibi, DüğümA ağırlığı: DüğümB ağırlığı: DüğümC ağırlığı = 3: 2: 1, yani DüğümA 3 kez, DüğümB 2 kez ve DüğümK 1 kez çağrılacaktır. Yükü dağıtmanın yolu. Ancak bu sürümün de bazı sorunları var: Biri sorunlu düğümlerin hızlı bir şekilde kaldırılamaması, diğeri arka uç yükünün dengelenememesi ve üçüncüsü genel gecikmenin azaltılamamasıdır.
Yukarıdaki sorunlara yanıt olarak, CPU kullanımını dahil etmek için her RPC isteğinin döndürdüğü Yanıtı kullanan, hizmet yükünü mümkün olduğunca algılayan ve düğümün ağırlık puanını düzenli aralıklarla bir bütün olarak ayarlayan dinamik duyarlı WRR algoritmasını geliştirdik.
Ancak bu sürümde de bir sorun var. Bir gün, hizmetin endişe verici olduğunu ve günlüğün 504 hata (yani, zaman aşımı yeniden denemesi) rapor ettiğini, ancak izleme sırasında hiçbir sorun bulunmadığını ve CPU kullanım oranının temelde% 90 civarında olduğunu gördük. CPU dolu olmadığında teorik olarak sadece bir veya iki zaman aşımı mümkündür ve çok sayıda zaman aşımı mümkün değildir Son olarak, WRR günlüğünü kontrol ederek, aslında bilgi gecikmesi ve dağıtımının neden olduğu bir sürü etkisi olduğu bulunmuştur.
Resimden görülebileceği gibi, dağ sıçanları altın madeni bilgisini aldıklarında akın edecekler, önden koşanlar altın madenlerini yakalayabilirler, ancak geri koşanlar onu yakalayamayabilir çünkü bilgi kesinlikle gecikmiştir. Ayrıca bu dağ sıçanlarının tamamı bağımsız bireylerdir, bir piyasa ekonomisi değildir, bilgi gecikse bile piyasa ekonomisi kaynakları planlama ve çizelgeleme yoluyla tahsis edebilir.
Yukarıdaki garip durumun nedeni, yük dengeleme sürüm 2.0'ın ağırlık değerini otomatik olarak yenilemesi, ancak yenileme sırasında tamamen gerçek zamanlı olamaması ve bir RTT'yi aşmanın imkansız olmasıdır ve bazı bilgi gecikme farklılıkları olacaktır. Arka plan kaynakları göreceli olarak kıt olduğunda, ağ titrediğinde düğüm patlayabilir, ancak izleme sırasında hissedilmez, çünkü CPU'nun ortalaması alınmıştır.
Bu sorunu keşfettikten sonra, Yük Dengeleme 3.0'ı kullanıma sunduk.
Ağırlık puanını hesaplayın. Bir talep geldiğinde gecikmeyi güncelleyeceğiz ve önceden elde edilen gecikmenin ağırlığını hafifletecek ve yeni elde edilen zamanın ağırlığını artıracak, böylece sürekli bir güncelleme elde edeceğiz.
Yukarıdaki şekil, iki algoritmanın en iyisidir: Her seferinde tüm düğümlerden rastgele A ve B düğümleri ve ardından puanları karşılaştırma algoritmasından geçer.Koddaki ağırlık değeri, Discovery'de ayarlanan ağırlık değerine atıfta bulunur.
RPC yük dengeleme nasıl test edilir? Bu test daha önemlidir. Çevrimiçi olurken biraz dikkatsizlik çığa neden olabilir, bu nedenle dikkatli olmanız gerekir. Temel birim testlerine ek olarak, test kodu ayrıca çok istemcili ve çok sunuculu senaryoları simüle edecek ve rastgele ağ titreşimi ve uzun kuyruk ekleyecektir. Gerçek senaryolarda istekler, sunucu yük değişimleri, istek hataları vb. Ortaya çıkabilir ve yeni işlevin etkili olup olmadığını belirlemek için sonuçları sonunda yazdırabilir.
Ek olarak, çevrimiçi Hata Ayıklama günlüğüne mevcut puan başarı oranı vb. Gibi bazı analizler de ekleyeceğiz.
Yukarıdaki resim, çevrimiçi olduktan sonra CPU yakınsamasının etkisini göstermektedir.
Akım sınırı ve sigorta
Mikro hizmetlerde yük dengeleme, teknik olarak kötü düğüm sorununu çözerken, akım sınırlama ve kaynaştırma esas olarak sistem aşırı yüklenmesini ve sistem çığlarını önler.
Bu, B istasyonunun başlangıcındaki birleştirme algoritmasıdır. Hystrix birleştirme algoritmasını ifade eder.İstek başarısızlık oranı belirli bir eşiğe ulaştığında, sigorta açılır ve bir süre uyur. Bu uyku süresinden sonra, sigorta yarı açık durumda olacaktır. Durumda, akışın bir kısmı geçici olarak bırakılacaktır Akışın bu kısmı başarılı bir şekilde çağrılırsa, sigorta tekrar kapanacaktır, aksi takdirde sigorta açık kalmaya devam edecek ve bir sonraki uyku döngüsüne girecektir.
Ancak bu kaynaştırma algoritmasının bir sorunu var.Herkese uyan tek bir boyutta ve tüm sistemleri aynı anda kapatacak.O zamanlar, sistem trafiğin% 30 veya% 20'sini geçebilir, ancak şimdi tüm trafik geçemez. Yarı açık durumda, geçici olarak yerleştirilen trafiğin tümü başarılı olmalıdır, ancak şu anda sistem zaten aşırı yüklenmiştir ve başarılı olmak zordur. Bu sorunlar nedeniyle, daha sonra Google SRE esnek birleştirme algoritmasını benimsedik. Esnek kaynaştırma, başarı oranına göre ayarlanır. Başarı oranı daha yüksek olduğunda, kaynaşma olasılığı daha küçüktür ve bunun tersi de geçerlidir. Aynı zamanda parametreler özelleştirilebilir ve birleştirme algoritması, parametreler ayarlanarak daha radikal veya hassas hale getirilebilir.
Tek makineli jeton grubu akım sınırlaması, başlangıçtan beri kullandığımız mevcut sınırlama algoritmasıdır, ancak şimdi hizmetlerin% 50'si bu algoritmayı kullanıyor. Jeton paketi başlangıçta bazı jetonlarla yüklenecek ve jeton paketine birkaç saniyede bir yeni jetonlar alınacaktır. Önleyen jeton paketinden jetonu aldığında, elde edilebilirse serbest bırakılacaktır. At gitsin.
Bu algoritmanın problemi, sadece yerel sunucunun mevcut limiti için olması ve global kaynakları kontrol edememesidir.Ayrıca, sistem yükü değiştiği için jeton paketinin kapasitesi ve jeton yerleştirme hızı iyi değerlendirilemez. Sistem herhangi bir nedenle çalışırsa Ölçeklendirme ve genişletme ayrıca manuel değişiklik gerektirir ve işletme ve bakım maliyetleri nispeten yüksektir. Ek olarak, jeton paketinin önceliği yoktur, bu nedenle önce önemli istekler iletilemez.
Bu, BBR algoritmasına dayalı olarak geliştirilen uyarlanabilir bir akım sınırlamasıdır BBR algoritması, mikro hizmetlerdeki mevcut sınırlamaya benzer bir TCP tıkanıklığı kontrolüdür. Sezgisel değer olarak CPU \ IOPS'ye dayanan uyarlanabilir akım sınırlama, sistemin maksimum taşıma kapasitesini belirlemek için BBR algoritmasını kullanarak, sıfır konfigürasyonlu akım sınırlama algoritmasına uyarlama: cpu > 800 VE Uçak İçi > (maxPass * minRtt * pencere / 1000).
Sezgisel değer olarak neden CPU \ IOPS kullanılıyor? Uyarlanabilir akım sınırlaması ile TCP tıkanıklığı kontrolü arasında farklılıklar olduğu için, TCP'deki istemci maxPass'ı tespit etmek için gönderme hızını kontrol edebilir, ancak RPC hattı akış oranını kontrol edemez, bu nedenle CPU standart olarak kullanılmalıdır. CPU neredeyse dolduğunda Zamanı gelince tekrar açın Bu zamanda, önceden tespit edilen maxPass'ın sistemin darboğazına yakın olduğunu düşünüyoruz.InFlight almak için minRtt ile çarpın.
Uyarlanabilir akım sınırlamasına ek olarak, Codel kuyrukları da yaptık.Geleneksel kuyruklar ilk giren ilk çıkar, ancak mikro hizmetlerin bu yaklaşım için uygun olmayabileceğini gördük.Çünkü mikro hizmetlerin zaman aşımına sahip olması kesinlikle imkansızdır. Bekleyin, belki SLP'niz 800 milisaniyelik bir zaman aşımı ayarladı.Bu zamanda eski bir istek serbest bırakılırsa, isteğin başarı oranı uzun süredir sıraya alınmış olabileceğinden daha düşük olacaktır.
Bu nedenle, şu anda atılacak işlem süresine dayalı bir kuyruğa ihtiyacımız var.Sistem yüksek yük altındayken, son giren ilk çıkar stratejisini uygulayın, yani uzun kuyruktaki istekleri aktif olarak atın ve bu kuyruğu kullanarak yeni isteklerin doğrudan geçmesine izin verin Önceki algoritmadaki tamponlama problemini telafi etmek ve trafikteki ani artışı absorbe etmek.
Bu uyarlanabilir sonsuz akışın etkisidir Mavi, isteğin geldiği QPS miktarıdır ve yeşil gerçekte geçen QPS miktarıdır.Şekilden de görebileceğiniz gibi CPU% 100'e ulaştığında istek çığdır.
Bu, uyarlanabilir sınırlı akışın etkisidir.Mavi hat artmasına rağmen yeşil hat geçiş miktarının etkilenmediği görülebilir.Yine de nispeten sabit bir geçiş oranını korur.Yeşil hattın biraz olduğu talebini reddetmenin maliyeti olabilir. Bazıları düşüktür, ancak genel etki küçüktür.
Geçmişe Bakış ve Beklenti
Önceki makaleye baktığımızda, Go dili doğal olarak eşzamanlı programlamayı destekler ve CSP modeli eşzamanlı senaryoların çoğunu tatmin eder. Discovery bu fikri çok sayıda uygulamıştır; bileşenleştirme fikrini uygulamak için Go arayüz tasarımı yeterlidir; Go dilinin program geliştirmesi Kod okunabilirliği ile performans arasında iyi bir denge kurun ve uygulama eşzamanlılık modeli kontrol altında olmalıdır.
Gelecek planlaması için esas olarak 5 küçük yönümüz var:
- Discovery çok odalı otomatik trafik planlaması (küresel perspektif)
- Keşif, Merkle Ağacı yapısını uygular ve Gossip protokolünü destekler
- RPC yük dengeleme soğuk başlatma ısınma
- Küresel bir bakış açısıyla dağıtılmış akım sınırlama şeması
- RPC istek öncelik sırası
Daha fazla ayrıntı için lütfen açık kaynak koduna bakın: https://github.com/bilibili/kratos
yazar hakkında:
Cao Guoliang, Bilibili Ana İstasyon Teknoloji Merkezi Kıdemli Ar-Ge Mühendisi.
