Dikkatli değilseniz, RPC'nin zaman aşımı ayarı çevrimiçi bir kazadır
Yazar | Luo Junwu
Kaynak | BT uzmanlarının kariyer gelişimi (ID: BestITer)
Yukarıdaki izleme resmi, sunucu tarafındaki Ar-Ge öğrencileri için çok tanıdık geliyor. Günlük sistem bakımında, "fazla servis", en çok izleme alarmına sahip sorunlar kategorisine girmelidir.
Özellikle mikro hizmet mimarisinde, bir isteğin uzun bir bağlantıdan geçmesi gerekebilir ve sonuç yalnızca birden çok hizmette çağrıldıktan sonra döndürülebilir. Bir hizmet zaman aşımı meydana geldiğinde, Ar-Ge öğrencileri genellikle kendi sistemlerinin performansını ve bağımlı hizmetlerinin performansını analiz etmek zorunda kalırlar.Bu nedenle hizmet zaman aşımını araştırmak, hizmet hatalarını ve anormal hizmet çağrılarını araştırmaktan daha zordur.
Bu makale sistematik olarak aşağıdakileri gerçek bir çevrimiçi kaza yoluyla tanıtacaktır: Mikro hizmet mimarisi altında, RPC arabiriminin zaman aşımı süresinin doğru şekilde nasıl anlaşılacağı ve ayarlanacağı, böylece sunucu arabirimini geliştirirken herkesin daha genel bir görüşe sahip olması sağlanır. İçerik aşağıdaki 4 bölüme ayrılacaktır:
-
Bir RPC arayüzü zaman aşımının neden olduğu çevrimiçi bir kazadan konuşma
-
Zaman aşımının gerçekleşme ilkesi nedir?
-
Çözülecek zaman aşımı süresini ayarlamanın amacı nedir?
-
Zaman aşımı süresi makul bir şekilde nasıl ayarlanır?
Çevrimiçi bir kazadan konuşmak
Kaza, e-ticaret APP ana sayfasındaki öneri modülünde meydana geldi.Bir öğlen anında kullanıcı geri bildirimi aldım: APP ana sayfasındaki banner görüntüsü ve gezinme alanına ek olarak aşağıdaki öneri modülü boş bir sayfa oldu (öneri modülü ana sayfadaki alanın 2 / 3'ünü kaplar, Algoritma tarafından kullanıcı ilgi alanlarına göre gerçek zamanlı olarak önerilen malların bir listesidir).
Yukarıdaki iş senaryosu, aşağıdaki çağrı zincirinin yardımıyla anlaşılabilir:
-
APP, hizmet ağ geçidine bir HTTP isteği başlatır
-
İş ağ geçidi RPC'si, önerilen ürünlerin bir listesini almak için öneri hizmetini arar
-
2. adımdaki arama başarısız olursa, destek için popüler malların bir listesini almak üzere mal sıralama hizmetini aramak için hizmetin derecesi düşürülür ve RPC olarak değiştirilir.
-
3. adım çağrısı başarısız olursa, tekrar eski sürüme geçin ve Redis önbelleğindeki sıcak satış ürünlerinin listesini doğrudan alın
İlk bakışta, her iki hizmete bağlı sürüm düşürme stratejisi de göz önünde bulundurulmuştur Teorik olarak, öneri hizmeti veya ürün sıralama hizmeti kapatılsa bile, sunucunun verileri APP'ye geri gönderebilmesi gerekir. Bununla birlikte, APP tarafında önerilen modül boş görünmektedir ve düşürme stratejisi etkili olmayabilir Konumlandırma süreci aşağıda ayrıntılı olarak açıklanacaktır.
1. Sorun tespit süreci
Adım 1: APP tarafı, paket yakalama yoluyla keşfeder: HTTP isteğinde bir arayüz zaman aşımı vardır (zaman aşımı süresi 5 saniyeye ayarlanmıştır).
Adım 2: Hizmet ağ geçidi, günlük aracılığıyla önerilen hizmeti çağıran RPC arabiriminin geniş bir zaman aşımı alanına sahip olduğunu (zaman aşımı süresi 3 saniyeye ayarlanmıştır) buldu ve hata mesajı aşağıdaki gibidir:
Adım 3: Günlükte bulunan önerilen hizmet: dubbo'nun iş parçacığı havuzu tükendi ve hata mesajı aşağıdaki gibidir:
Yukarıdaki 3 adımda, sorun temelde öneri hizmetinde bulundu. Daha sonra, daha fazla araştırma, öneri hizmetinin dayandığı redis kümesinin kullanılamadığını ortaya çıkardı, bu da zaman aşımına neden oldu ve bu da iş parçacığı havuzunun tükenmesine neden oldu. Ayrıntılı neden burada genişletilmemiştir ve bu makalede tartışılan konuyla ilgili değildir.
2. Düşürme stratejisinin neden yürürlüğe girmediğinin analizi
Tekrar analiz edelim: Önerilen servis çağrısı başarısız olduğunda, servis ağ geçidinin sürüm düşürme politikası neden devreye girmiyor? Teorik olarak, destek için emtia ayırma hizmetini çağırmak, indirgenmemeli mi?
Son olarak, izleme analizi temel nedeni buldu: APP tarafında servis ağ geçidini çağırmak için zaman aşımı süresi 5 saniyedir, servis ağ geçidi tarafından önerilen hizmeti çağırmak için zaman aşımı süresi 3 saniyedir ve 3 zaman aşımı yeniden denemesi ayarlanmıştır, böylece önerilen servis çağrısı başarısız olduğunda, ilki İki yeniden denemeden sonra, HTTP isteği zaman aşımına uğradı, bu nedenle hizmet ağ geçidinin tüm sürüm düşürme ilkeleri etkili olmayacak. Aşağıdaki daha sezgisel bir diyagramdır:
3. Çözüm
-
Servis ağ geçidinin önerilen servisi araması için zaman aşımı süresi 800 ms olarak değiştirildi (önerilen hizmet için TP99 yaklaşık 540 ms'dir) ve zaman aşımı yeniden deneme sayısı 2 olarak değiştirildi
-
İş ağ geçidinin emtia sıralama hizmetini çağırması için zaman aşımı süresi 600 ms olarak değiştirildi (emtia ayırma hizmetinin TP99'u yaklaşık 400 ms'dir) ve zaman aşımı yeniden deneme sayısı da 2 olarak değiştirildi
Zaman aşımı süresinin ayarlanması ve yeniden deneme sayısı ile ilgili olarak, tüm çağrı zincirindeki tüm bağımlı hizmetlerin zaman alması ve her hizmetin bir çekirdek hizmet olup olmadığı gibi birçok faktörü dikkate almak gerekir. Burada genişletmeyeceğim ve özel yöntem daha sonra ayrıntılı olarak tanıtılacak.
Zaman aşımının gerçekleşme ilkesi nedir?
Sadece RPC çerçevesinin zaman aşımı uygulama ilkesini anlayarak onu daha iyi kurabiliriz. Dubbo, SpringCloud veya büyük bir üretici (JD.com'un JSF'si gibi) tarafından geliştirilen bir mikro hizmet çerçevesi olsun, zaman aşımının uygulama ilkesi temelde benzerdir. Spesifik uygulamayı görmek için örnek olarak dubbo 2.8.4 sürümünün kaynak kodunu alalım.
Dubbo'ya aşina olanlar, zaman aşımı süresini yapılandırmak için iki yer olduğunu bilir: sağlayıcı (sunucu, servis sağlayıcı) ve tüketici (tüketici, servis arayan). Sunucunun zaman aşımı yapılandırması, tüketicinin varsayılan yapılandırmasıdır. Yani, sunucu zaman aşımı süresini ayarladığı sürece, tüm tüketicilerin bunu ayarlaması gerekmez ve kayıt defteri aracılığıyla tüketiciye iletilebilir. Bu şekilde: bir yandan yapılandırma basitleştirilir, diğer yandan Sunucu, arayüz performansının daha fazla farkında olduğundan, onu kurmak için sunucuya bırakmak mantıklıdır.
dubbo, yöntem düzeyi, arabirim düzeyi ve genel gibi çok ince taneli zaman aşımı ayarlarını destekler. Tüm seviyeler aynı anda yapılandırılırsa, öncelik şudur: tüketici yöntemi seviyesi > Sunucu yöntemi seviyesi > Tüketici arayüz seviyesi > Sunucu arayüz seviyesi > Tüketici global > Sunucu globaldir.
Kaynak kodu üzerinden, önce sunucu tarafı zaman aşımı işleme mantığına bakalım.
1public sınıfı TimeoutFilter, Filter {23 public TimeoutFilter {4} uygular 56 public Result invoke (...) RpcException {7 // Gerçek mantık çağrılarını yürütün ve süreyi sayın 8 long start = System.currentTimeMillis; 9 Sonuç sonucu = invoker.invoke (invocation); 10 uzun geçen = System.currentTimeMillis-start; 1112 // Zaman aşımına uğrayıp uğramadığını belirle 13 if (invoker.getUrl! = elapsed > zaman aşımı) {14 // Uyarı günlüğünü yazdır 15 logger.warn ("zaman aşımını çağır ..."); 16} 1718 dönüş sonucu; 19} 20}Sunucu zaman aşımına uğramış olsa bile, yalnızca bir uyarı günlüğü yazdırdığını görebilirsiniz. bu nedenle Sunucu tarafı zaman aşımı ayarı, gerçek arama sürecini etkilemez, zaman aşımına uğrasa bile tüm işleme mantığı yürütülür. .
Tüketici tarafındaki zaman aşımı işleme mantığına tekrar bakalım
1public class FailoverClusterInvoker {23 public Result doInvoke (...) {4 ... 5 // (int i = 0; i için 6 numaralı döngü çağrısı için ayarlanan yeniden deneme sayısı < retryTimes; ++ i) {7 ... 8 try {9 Result result = invoker.invoke (invocation); 10 return result; 11} catch (RpcException e) {12 // Eğer işletme anormalse, sonlandır ve eğer 13'ü tekrar dene (e.isBiz) {14 throw e; 15} 1617 le = e; 18} catch (Throwable e) {19 le = new RpcException (...); 20} nihayet {21 ... 22} 23} 2425 throw new RpcException ("..."); 26} 27}FailoverCluster, küme hata toleransının varsayılan modudur.Arama başarısız olduğunda, diğer sunucuları aramaya geçecektir. DoInvoke yöntemine tekrar bakın.Arama başarısız olduğunda, önce bunun bir iş istisnası olup olmadığını belirleyecektir.Eğer öyleyse, yeniden deneme sonlandırılacak, aksi takdirde yeniden deneme girişimlerinin sayısına ulaşılana kadar yeniden denemeye devam edecektir.
Çağırıcının invoke yöntemini izlemeye devam edin ve sonucun, istek gönderildikten sonra Future'ın get yöntemi ile elde edildiğini görebilirsiniz.Kaynak kodu aşağıdaki gibidir:
1public Object get (int zaman aşımı) {2 if (timeout < = 0) {3 timeout = 1000; 4} 56 if (! İsDone) {7 long start = System.currentTimeMillis; 8 this.lock.lock; 910 try {11 // Cycle judgment 12 while (! İsDone) {13 // Kilitten vazgeçin ve bekleme durumuna girin 14 done.await ((long) timeout, TimeUnit.MILLISECONDS); 1516 // Sonucun döndürülüp döndürülmediğini veya zaman aşımına uğrayıp uğramadığını belirleyin 17 long geçti = System.currentTimeMillis-start; 18 if (isDone || geçen > (uzun) zaman aşımı) {19 break; 20} 21} 22} catch (InterruptedException var8) {23 throw new RuntimeException (var8); 24} nihayet {25 this.lock.unlock; 26} 2728 if (! isDone) {29 // Sonuç döndürülmezse, bir zaman aşımı istisnası atılır 30 yeni TimeoutException (...); 31} 32} 3334 return returnFromResponse; 35}Yöntemi girdikten sonra, zamanlamayı başlatın.Eğer dönüş sonucu ayarlanan zaman aşımı süresi içinde elde edilmezse, TimeoutException atılır. bu nedenle Tüketici tarafındaki zaman aşımı mantığı iki parametre tarafından kontrol edilir, zaman aşımı süresi ve zaman aşımı sayısı Örneğin, ağ anormallikleri ve yanıt zaman aşımları, yeniden deneme sayısına ulaşılana kadar her zaman yeniden denenecektir.
Zaman aşımı süresini ayarlamanın amacı nedir?
RPC çerçevesinin zaman aşımı yeniden deneme mekanizması hangi sorunu çözer? Mikro hizmet mimarisinin makro perspektifinden bakıldığında, hizmet bağlantısının kararlılığını sağlamak ve çerçeve düzeyinde bir hata toleransı sağlamaktır. Mikro düzeyde nasıl anlaşılır? Aşağıdaki özel durumlardan görülebilir:
1. Tüketici sağlayıcıyı arar Zaman aşımı süresi belirlenmemişse, tüketicinin yanıt süresi kesinlikle sağlayıcının yanıt süresinden daha uzun olacaktır. Sağlayıcının performansı kötüleştiğinde, tüketicinin performansı da etkilenecektir, çünkü sağlayıcının dönüşü için süresiz olarak beklemesi gerekir. Çağrı bağlantısının tamamı birden fazla A, B, C ve D hizmetinden geçerse, D'nin performansı kötüleştiği sürece, aşağıdan yukarıya doğru A, B ve C'yi etkileyecek ve sonunda tüm bağlantının zaman aşımına uğramasına veya hatta felce uğramasına neden olacaktır. Zaman aşımı süresi çok gereklidir.
2. Tüketicinin temel mal hizmeti olduğu ve sağlayıcının çekirdek olmayan inceleme hizmeti olduğu varsayıldığında, değerlendirme hizmetinin performans sorunları olduğunda, emtia hizmeti hizmetin sağlanmaya devam edebilmesini sağlamak için değerlendirme bilgilerini kabul edebilir ve geri göndermeyebilir. Bu durumda, bir zaman aşımı süresi ayarlanmalıdır Değerlendirme hizmeti bu eşiği aştığında, emtia hizmetinin beklemesi gerekmez.
3. Sağlayıcı, anlık bir ağ seğirmesi veya yüksek makine yükünün neden olduğu bir zaman aşımı olabilir.Zaman aşımından hemen sonra pes ederseniz, bazı senaryolar iş kayıplarına neden olur (örneğin, envanter arayüzü zaman aşımı siparişin başarısız olmasına neden olur). Bu nedenle, bu tür bir geçici hizmet seğirmesi için, zaman aşımından sonra tekrar denerseniz kaydedilebilir, bu nedenle bir yeniden deneme mekanizmasıyla çözmeniz gerekir.
Ancak zaman aşımı yeniden deneme mekanizmasını tanıttıktan sonra her şey mükemmel değildir. Yan etkileri de beraberinde getirir.Bunlar, RPC arayüzleri geliştirirken dikkat edilmesi gereken konulardır ve aynı zamanda en kolay gözden kaçan konulardır:
Tekrar isteği: Sağlayıcının yürütmeyi bitirmiş olması mümkündür, ancak ağ jitter tüketicisi zaman aşımına uğradığını düşündüğü için, bu durumda yeniden deneme mekanizması tekrarlanan isteklere neden olacak ve bu da kirli veri sorunlarına neden olacaktır, bu nedenle sunucu arabirimin idempotansını dikkate almalıdır.
Tüketicinin yük kapasitesini azaltın : Sağlayıcı geçici bir seğirme değilse, ancak bir performans sorunu varsa, birden çok kez tekrar denemek imkansız olacaktır, ancak tüketicinin ortalama yanıt süresini uzatacaktır. Örneğin, normal şartlar altında, sağlayıcının ortalama yanıt süresi 1 saniyedir, tüketici zaman aşımı süresini 1,5 saniyeye ayarlar ve yeniden deneme sayısı 2 olarak ayarlanır, böylece tek bir istek 3 saniye sürer ve tüketicinin toplam yükü aşağı çekilir. Zincirleme reaksiyonlara ve çığlara neden olabilen yüksek QPS hizmetidir.
Patlayıcı yeniden deneme fırtınası : Bir çağrı bağlantısı 4 hizmetten geçerse, en düşük hizmet D zaman aşımına uğrayacaktır, bu nedenle tüm yukarı akış hizmetleri yeniden deneme başlatacaktır. Yeniden deneme sayısının 3 kez ayarlandığı varsayıldığında, B normal koşullar altında 3 kat daha fazla yükle karşılaşacaktır. Miktar, C 9 kat, D 27 kat, tüm hizmet kümesi çığ olabilir.
Zaman aşımı süresi makul bir şekilde nasıl ayarlanır?
RPC çerçevesinin zaman aşımı uygulama ilkesini ve olası yan etkileri anladıktan sonra, zaman aşımını aşağıdaki yönteme göre ayarlayabilirsiniz:
-
Arayanın zaman aşımı süresini ayarlamadan önce, öncelikle bağımlı hizmetin TP99 yanıt süresini anlayın (bağımlı hizmet performansı dalgalanırsa, TP95'e de bakabilirsiniz), arayanın zaman aşımı süresi bu temelde% 50 artırılabilir
-
RPC çerçevesi çok tanecikli zaman aşımı ayarlarını destekliyorsa: genel zaman aşımı süresi, arabirim düzeyinin en uzun zaman alan süresinden biraz daha büyük olmalıdır, her arabirimin zaman aşımı süresi, yöntem düzeyinin en uzun zaman alan süresinden ve her yöntemin zaman aşımından biraz daha büyük olmalıdır. Zaman, gerçek yöntem yürütme süresinden biraz daha uzun olmalıdır
-
Bunun yeniden denenebilir bir hizmet mi yoksa yeniden denenemez bir hizmet mi olduğunu ayırt edin. Arayüz idempotence uygulamıyorsa, yeniden deneme sayısını ayarlamasına izin verilmez. Not: Okuma arabirimi doğal olarak idempotenttir ve yazma arabirimi, iş belgesi kimliğini kullanabilir veya arayan üzerinde benzersiz bir kimlik oluşturabilir ve sunucuya iletebilir. Bu kimlik, tekrarlamayı önlemek ve kirli verilerin girmesini önlemek için kullanılır
-
RPC çerçevesi sunucu tarafı zaman aşımı ayarını destekliyorsa, önceki 3 kurala göre de sırayla ayarlanır; bu, istemcinin makul bir şekilde ayarlanmadan yapılandırılmasını önleyebilir ve gizli tehlikeleri azaltabilir.
-
İş açısından bakıldığında, hizmet kullanılabilirliği gereksinimleri çok yüksek değilse (dahili uygulama sistemleri gibi), zaman aşımı yeniden deneme sayısını ayarlamadan doğrudan manuel olarak yeniden deneyebilirsiniz.Bu, arabirim uygulamasının karmaşıklığını azaltabilir, ancak daha faydalıdır bakım sonrası
-
Yeniden deneme sayısı ne kadar fazla ayarlanırsa, hizmet kullanılabilirliği o kadar yüksek olur ve iş kaybı daha da azaltılabilir, ancak potansiyel performans riskleri de daha büyük olacaktır. Bunun birkaç kez (genellikle 2 kata kadar, 3 kata kadar) ayarlanması gerekir
-
Arayan kişi yüksek QPS hizmetiyse, sunucu zaman aşımı durumunda düşürme ve devre kesici stratejisi dikkate alınmalıdır. (Örneğin, isteklerin% 10'undan fazlası yanlışsa, yeniden deneme mekanizmasını durdurun ve doğrudan kaynaştırın ve diğer hizmetleri, asenkron MQ mekanizmasını çağırmak için değiştirin veya arayanın önbelleğe alınmış verilerini kullanın)
Son olarak kısaca özetleyelim:
RPC arayüzünün zaman aşımı ayarı basit görünüyor, ancak aslında pek çok soru var. Yalnızca birçok teknik sorunu (arayüz idempotansı, hizmet bozulması ve birleştirme, performans değerlendirme ve optimizasyon gibi) içermekle kalmaz, aynı zamanda gerekliliği bir iş perspektifinden de değerlendirmesi gerekir. Sebebini ve nedenini bilmek, bu bilginin RPC arayüzlerini geliştirirken size daha küresel bir bakış açısı sunmasını umuyoruz.
Gartner'ın konteyner ürününde birinciliği kazanan Alibaba Cloud, bulut yerel için önemli savaşı kazandı!
Tencent mülakatçısı bana bunun gibi ikili ağaç hakkında soru sordu, bunda iyiyim | Kuvvet Projesi
GitHub 2000+ Star'ı edinerek, Aliyun'un açık kaynak Alink makine öğrenimi platformu çift 11 veri "oyunundan" nasıl daha iyi performans gösteriyor? | AI teknolojisi ekolojisi
Microsoft bir kişi için bir şirket mi satın alıyor? Sony programlarını kırın, hacker romanları yazın ve sağlam program hayatını izleyin!
Makine öğrenimi proje şablonu: Makine öğrenimi projesinin 6 temel adımı
IBM, Microsoft, Apple, Google, Samsung ... blok zincirindeki teknoloji devleri şimdiden çok şey yaptı!
Kıdemli programcının özeti: Linux sürecini analiz etmek için 6 yöntem, size hepsini anlatacağım
Bugünün refahı: yorum alanı seçildi, çevrimiçi 299 yuan değerinde "2020 AI Geliştiricileri Konferansı" nı alabilirsiniz Bir canlı bilet . Parmaklarınızı hareket ettirin ve söylemek istediklerinizi yazın.
