Mikro hizmet arabirimi akım sınırının tasarımı ve düşünülmesi (GitHub çerçeve kaynak koduyla)
Yazar | Wang Zheng
Düzenle | Genel hesabın yapısı hakkında Guo Lei-Talk
Mikro hizmetler ayrıldıktan sonra, sistemler arasındaki çağrı ilişkileri karmaşık hale gelir, platformun genel karmaşıklığı artar ve hata olasılığı ve sorun giderme zorluğu birkaç kat daha yüksektir. Bu nedenle, hizmet yönetişimi mikro hizmetlerin teknik bir odak noktası haline geldi. Hizmet yönetişimi kavramı, kimlik doğrulama, mevcut sınırlama, alt sınıflandırma, sigorta, izleme alarmları vb. Dahil olmak üzere nispeten büyüktür. Bu makale, mevcut sınırlamaya odaklanır ve yazarın gerçek savaş deneyimine dayanarak, mikro hizmet arabirimlerinin mevcut sınırlaması hakkında bazı düşüncelerimi paylaşırım.
Bu makale aşağıdaki soruları açıklamaya çalışmaktadır: Mevcut sınırlamalar hakkında benzer sorularınız varsa veya bir konuyla ilgileniyorsanız, bu makaleyi okumaya hoş geldiniz.
Mikro hizmet mimarisinde arayüz akım sınırı yoktur, hangi problemlerle karşılaşılabilir?
Mikro servis arayüzü akım sınırlaması için uygun bir akım sınırlayıcı algoritma nasıl seçilir?
Senaryo ve performans gereksinimlerine göre bağımsız veya dağıtılmış akım sınırlaması nasıl seçilir?
İş ihtiyaçlarına göre farklı akım sınırlayıcı sigorta mekanizmaları esnek bir şekilde nasıl seçilir?
Arayüz için uygun akım sınırı zaman ayrıntı düzeyi ve maksimum akım sınır değeri nasıl seçilir?
Mikro hizmet arabiriminin mevcut sınırlayıcı işlevinin geçerliliği ve doğruluğu nasıl doğrulanır?
Yüksek hata toleransı, yüksek TPS ve düşük gecikme süresine sahip akım sınırlayıcı bir çerçeve nasıl oluşturulur?
Makalenin sonunda, yazarın açık kaynak akım sınırlayıcı çerçevesini de tanıttım: ratelimiter4j, değiş tokuşa ve kullanmaya hoş geldiniz.
1 Mikro hizmet arabirimi akım sınırının arka planı
Ani yükselmeler, büyük promosyonlar, Double 11 ve 618 gibi yüksek performanslı basınç senaryoları ile uğraşırken, akım sınırlaması standart bir teknik çözüm haline geldi ve sistemin sorunsuz çalışmasını sağlamada kilit rol oynadı. Uygulama senaryosundan bağımsız olarak, mevcut sınırlama, beklentileri aşan trafik için önceden belirlenmiş mevcut sınırlama kuralları aracılığıyla belirli istekleri seçici bir şekilde "birleştirmekten" başka bir şey değildir. Alan sınırlamaları ve yazarın deneyimi ve yeteneği nedeniyle, bu makale esas olarak mikro hizmet mimarisi altındaki hizmet arabirimlerinin mevcut sınırlamasından bahsediyor.
Mikro hizmetler için, özellikle bazı orta ofis mikro hizmetleri için, arayüz talebi birçok sistemden gelebilir.Örneğin, kullanıcı hizmetinin arayüzü CRM, promosyon sistemi vb. Birçok dahili sistem tarafından çağrılacaktır. Birçok çağrı sistemine hizmet eden ve büyük arabirim isteklerine yanıt veren mikro hizmetler için arabirim akımı sınırı, yalnızca yukarıda belirtilen büyük artış senaryolarının bazılarına yanıt vermekle kalmaz, aynı zamanda aşağıdaki senaryolarda da büyük rol oynar.
Arayüz hizmetleri sağlayan bir mikro hizmet sistemi olarak, arayanların arayüzlerimizi nasıl kullanabileceğini kısıtlayamayız.Arayüzlerimizi istemek için aynı anda birden çok iş parçacığında işler çalıştıran bazı arayanlarla karşılaştık ve ayrıca bazı sorunlarla karşılaştık çünkü Arayanın kod hatası veya işletmedeki ani trafik, bu arayandan gelen arayüz isteklerinin sayısında ani bir artışa, hizmet iş parçacığı kaynakları için aşırı çekişmeye ve diğer arayanlardan gelen arayüz istekleri, yanıt veremeyecek kadar geç kaldıkları için sırada beklemeye neden oldu. İstek yanıt süresi uzar veya hatta zaman aşımına uğrar. Bu nedenle, arayüzün aşırı şekilde çalıştırılmasını önlemek için, her arayan için ayrıntılı bir erişim akış sınırı gereklidir.
Arayanın erişim sıklığını kısıtlamaya ek olarak, bazen belirli arayüzlerin erişim sıklığını da kısıtlamamız gerekir. Örneğin, bazı yavaş arabirimler için, karmaşık mantık nedeniyle işlem süresi daha uzun olabilir.Yavaş arabirimin erişim frekansı kısıtlanmazsa, çok fazla yavaş arabirim isteği her zaman hizmetin iş parçacığı kaynaklarını işgal eder ve serbest bırakılmaz, bu da diğer arabirim isteklerine yanıt vermede başarısızlıkla sonuçlanır. Mikro hizmet sisteminin genel verimini ve arabirim yanıt süresini etkiler ve hatta çok sayıda arabirim zaman aşımına neden olur. Yavaş arayüze ek olarak, bazı çekirdek arayüzler, çünkü anormal erişimin iş üzerinde daha büyük bir etkisi olduğu için, çağrı kimlik doğrulamasına ek olarak, beklenmedik anormal trafiği de sınırlamak gerekir.
Özetle, büyük promosyon artış senaryosu için yalnızca kaba taneli mikro hizmet arabirimi akım sınırlama işlevine ihtiyacımız yok: örneğin, mikro hizmet kümesindeki tek bir makine için saniyedeki istek sayısını sınırlamak için, farklı arayanlar ve hatta farklı arabirimler için daha fazlasını gerçekleştirmemiz gerekiyor. Ayrıntılı akım sınırı: Örneğin, belirli bir hizmetin belirli bir arayüzünün saniyede maksimum istek sayısını arayan A tarafından sınırlandırılır.
2 Mikro hizmet arabirimi akım sınırının arka planı
Mevcut sınırlamadaki "akış" kelimesi nasıl yorumlanır? Kısıtlanacak göstergeler tam olarak nedir? Farklı senaryolar, ağ trafiği, bant genişliği, saniye başına işlem (TPS), saniye başına istek (saniye başına isabet), eşzamanlı istekler ve hatta iş olabilen farklı "akış" tanımlarına sahiptir. Bir kullanıcının belirli bir süre içinde izin verdiği maksimum SMS doğrulama kodu talebi sayısı gibi bir gösterge.
Bir mikro hizmet sistemi için sistemin kararlılığını ve kullanılabilirliğini sağlama açısından en iyi akım sınırı göstergesi: eşzamanlı taleplerin sayısıdır. Eşzamanlı olarak işlenen isteklerin sayısını sınırlayarak, herhangi bir anda çok fazla isteğin kaynak tüketmesini sınırlayabilirsiniz.Örneğin, web kapsayıcısındaki servlet çalışan iş parçacığı sayısını 200 olarak yapılandırarak, herhangi bir zamanda yalnızca 200 istek işlenir. , Fazla istekler engellenecek ve sıraya alınacaktır.
Önceki bölümde bahsedildiği gibi, arayanların servis kaynakları için aşırı çekişmesi sorununu çözmek için, farklı arayanlar ve hatta farklı arayüzler için de ince ayarlı akım sınırlaması uygulamamız ve bu nedenle, genel sistemdeki eşzamanlı istek sayısını sınırlamamız gerekiyor. Ek olarak, her arayan veya hatta farklı arayüzler için eşzamanlı istek sayısını sınırlamak gerekir. Bununla birlikte, belirli bir arayan için izin verilen maksimum eşzamanlı çağrı sayısını makul bir şekilde ayarlamak daha zordur Bu değeri, izleme istatistikleri yoluyla elde etmek zordur.Çok küçük, yanlışlıkla öldürmek kolaydır ve yararsız olamayacak kadar büyüktür. Bu nedenle, diğer mevcut limit göstergelerine de ihtiyacımız var.
İki TPS göstergesini ve saniyedeki isabet sayısını karşılaştırarak, mevcut sınırlayıcı gösterge olarak saniyedeki isabet sayısını kullanmayı seçiyoruz. TPS'de mevcut sınırın yapılması aslında imkansız olduğundan, TPS saniyede işlenen işlem sayısı anlamına gelir. İşlemin başlangıcı, arayüz talebi alındığında ve işlemin sonu, işlemin tamamlanmasının geri dönüşüdür.Bu nedenle, belirli bir zaman aralığı vardır. Eşzamanlı akım limitine eşdeğer olan işlem sonunda akış sayacı bir artırılır ve akım sınır sayacı bir azaltılır. İşlem talebi, sayım zaman noktası olarak alınırsa, mevcut limit olarak saniyede isabet olarak dejenere olacaktır.İşlem sonu, sayma zaman noktası ise, sayacın değeri, sistemin mevcut ve sonraki sistem erişim baskısını temsil etmez. .
Saniyedeki vuruşlar için geçerli sınır, etkin bir akım sınırı göstergesi midir? Cevap evet, bu değer gözlemlenebilir ve istatistiktir, bu nedenle mevcut limit kurallarını yapılandırmak uygundur ve bu değer sistemin mevcut ve sonraki performans baskısını bir dereceye kadar yansıtır ve bu gösterge için mevcut limit gerçekten limite ulaşabilir Sistem kaynaklarının kullanımı.
Akışın tanımıyla birlikte, daha sonra yaygın olarak kullanılan birkaç akım sınırlama algoritmasına bakacağız: sabit zaman penceresi, kayan zaman penceresi, belirteç grubu algoritması, sızdıran kova algoritması ve bunların geliştirilmiş sürümleri.
3 Sabit ve kayan zaman penceresi akım sınırlama algoritması
Sabit bir zaman penceresine dayalı mevcut sınırlama algoritması çok basittir. Öncelikle, bir başlangıç noktası seçmeniz gerekir.Bundan sonra, sayaç, bir arabirim isteği her geldiğinde toplanacaktır. Geçerli zaman penceresinde, mevcut sınır kuralına göre (örneğin, saniyede maksimum 100 arabirim isteğine izin verilir), biriken erişim süreleri mevcut sınır değerini aşar. Daha sonra mevcut sınırlayıcı sigorta arayüz talebini reddeder. Bir sonraki zaman penceresine girdikten sonra, sayaç temizlenir ve tekrar sayılır.
Sabit bir zaman penceresine dayanan bu akım sınırlayıcı algoritmanın dezavantajı, akım sınırlama stratejisinin, iki zaman penceresinin kritik zamanı içinde patlama trafiği ile başa çıkmak için çok kaba olmasıdır. Bir örnek verelim: Mevcut sınırlama kuralımızın saniyede 100 arayüz isteğinden fazla olmadığını varsayalım. İlk 1'ler zaman penceresinde, 100 arayüz isteği son 10 ms'de ve ikinci 1'ler zaman penceresinde yoğunlaşıyor , İki zaman aralığındaki trafik mevcut sınır gereksinimlerini karşılasa da, 100 arabirim isteği ilk 10 ms'de yoğunlaşır ( < = 100 istek), ancak iki zaman penceresinin kritik 20ms'si içinde yoğunlaşan 200 arayüz isteği olacaktır.Şekil-1'de gösterildiği gibi, mevcut sınır uygulanmazsa, bu 20ms'de yoğunlaşan 200 istek sistemi boğabilir. :
Kayan zaman penceresi algoritması, sabit zaman penceresi algoritmasının bir iyileştirmesidir.Kayan zaman penceresi algoritması ile trafik şekillendirildikten sonra, izin verilen maksimum akım sınır değerinin herhangi bir zaman penceresinde aşılmayacağı ve akış eğrisinden daha düzgün olacağı garanti edilebilir. Yukarıda bahsedilen kritik patlama akış problemini kısmen çözebilir. Sabit zaman penceresi akım limiti algoritması ile karşılaştırıldığında, kayan zaman penceresi akım limiti algoritmasının zaman penceresi sürekli olarak kaymaktadır ve zaman penceresi içindeki arayüz taleplerinin sayısını kaydetmek için bir sayaca ek olarak, her bir arayüz talebinin zaman penceresi içinde gelişini de kaydetmesi gerekir. Zamanla daha fazla hafıza alacaktır. Kayan zaman penceresinin algoritma modeli aşağıdaki gibidir:
Kayan pencere listesi = (t_1, t_2, t_k) tarafından kaydedilen zaman noktası, zaman penceresi boyutu 1 saniyedir ve başlangıç noktası listedeki en küçük zaman noktasıdır. T_m'ye yeni bir istek ulaştığında, kayan zaman penceresini güncellemek ve mevcut sınırın aşılıp aşılmadığını belirlemek için aşağıdaki adımları kullanırız:
ADIM 1: Arayüz tarafından talep edilen t_m süresinin mevcut zaman penceresinde olup olmadığını kontrol edin
