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

Hem iş hem de platform açısından daha güvenilir mikro hizmetler nasıl tasarlanır?

Yazar Li Linfeng

Düzenle Xiaozhi

Mikro hizmetler birçok fayda sağlarken, sistem arızası olasılığını da artırır. Yazar, mikro hizmetlerin hem iş hem de platform açısından güvenilirliğinin nasıl artırılacağı konusunda çok bilgilendirici önerilerde bulunuyor.

Arka plan tanıtımı

Mikro hizmetlerden sonra, sistem dağıtılmış bir şekilde dağıtılır.Geleneksel tek bir sürecin yerel API çağrıları, birden fazla mikro hizmet arasında ağlar arası çağrılara bölünür.Ağ iletişiminin, serileştirmenin ve serileştirmenin kaldırılması nedeniyle sistem arızalanır Olasılık çok arttı.

Mikro hizmet hatalarının bazıları, işletmenin kendi tasarımından veya yanlış kodlamasından kaynaklanırken, bazıları da temeldeki mikro hizmet çerçevesinin hata toleransı eksikliğinden kaynaklanır. Gerçek projelerde, mikro hizmetlerin güvenilirliğini artırmak için hem iş hem de platformla başlamak gerekir.

Her yerde başarısızlık

Dağıtılmış dağıtım ve çağrı

Geleneksel monolitik mimarinin eksiksiz bir iş süreci, genellikle dağıtılmış işbirliğine ihtiyaç duymadan aynı süreç içinde işlenir. Çalışma prensibi aşağıdaki gibidir:

Geleneksel monolitik mimarinin yerel yöntem çağrısı

Mikro hizmetlerden sonra, farklı mikro hizmetler dağıtılmış küme dağıtımını benimser.Hizmetlerin tüketicileri ve sağlayıcıları genellikle farklı süreçlerde çalışır ve ağ üzerinden RPC çağrıları yapmaları gerekir. Çalışma prensibi aşağıdaki gibidir:

Mikro hizmet dağıtılmış RPC çağrısı

Dağıtılmış aramadan sonra, geleneksel monolitik mimarinin yerel yöntem çağrısı ile karşılaştırıldığında, esas olarak aşağıdaki potansiyel hata noktaları tanıtılmaktadır:

Serileştirme ve serileştirme: Mikro hizmet istekleri ve yanıtlarının serileştirilmesi ve serileştirilmesi gerekir. Mesajların ağlar arası iletişimi için, tutarsız veri yapıları, desteklenmeyen veri türleri ve diğer kodek hataları nedeniyle serileştirme gerçekleşir. Ve seriyi kaldırma işlemi başarısız olur ve bu da mikro hizmet çağrısının başarısız olmasına neden olur.
Ağ sorunları: yaygın ağ zaman aşımları, ağ yanıp sönmeleri, ağ tek noktalara yayınlar, ağ tıkanıklığı vb. Uzak mikro hizmet çağrılarının başarısız olmasına neden olabilir.

Büyük ölçekli sistemlerde mikro hizmetlerin birlikte konumlandırılması

İdeal olarak, her mikro hizmet bağımsız olarak paketlenir ve dağıtılır ve süreç düzeyinde izolasyon, mikro hizmetler arasında doğal olarak desteklenir.Ancak, aslında, büyük ölçekli bir kurumsal BT sistemi veya büyük bir web sitesi için yüzlerce mikro hizmet vardır. Hizmetlerden oluşur.Uygulamada, aşağıdaki nedenlerden dolayı mikro hizmetlerin% 100 bağımsız olarak dağıtılması genellikle imkansızdır:

Uygun geliştirme: Ekipler genellikle iş alanlarına göre bölünür.Aynı iş alanı genellikle birden fazla mikro hizmet içerir ve geliştirmeden bir ekip sorumludur. CI / CD'yi kolaylaştırmak için, aynı iş etki alanındaki mikro hizmetler, her mikro hizmetin bağımsız olarak paketlenip dağıtılması yerine genellikle birlikte paketlenir ve dağıtılır.

Rahat kullanım ve bakım: Büyük mikro hizmet süreçleri (örnek olarak 1000 mikro hizmet * 10 işlem örneğini alın), dağıtım maliyetini, veri toplamayı (performans KPI'leri ve günlükleri vb.), Alarmları ve sorun konumunu artıracaktır.İşletim ve bakımın otomasyon derecesi ise Yüksek değil, mikro hizmetlerin büyük ölçekli bağımsız dağıtımını desteklemek zordur.

Performansı artırın: Bazı işletmeler gecikmeye karşı çok hassastır.İş zincirindeki tüm mikro hizmet çağrıları ağlar arasında iletişim kuruyorsa, gecikme genellikle iş gereksinimlerini karşılayamaz. Aynı süreçte mikro hizmetleri birlikte konumlandırarak, kısa devreleri yönlendirerek ve RPC çağrılarını yerel yöntem çağrılarına dönüştürerek, performans büyük ölçüde iyileştirilebilir.

Dağıtılmış işlem işlemeyi basitleştirin: Dağıtılmış dağıtımdan sonra, dağıtılmış işlem sorunları ortaya çıkacaktır. Bazen, dağıtılmış işlemlerin işlenmesini basitleştirmek için işletme, dağıtılmış işlemleri yerel işlemlere dönüştürmek ve işlem işlemeyi basitleştirmek için işlemle ilgili mikro hizmetleri aynı süreçte dağıtır.

Aynı süreçte farklı mikro hizmetlerin birlikte konumlandırılması, aşağıdakiler gibi bir dizi potansiyel arıza noktası ortaya çıkaracaktır:

Daha yavaş mikro hizmetlerin işlenmesi diğer mikro hizmetleri engeller;
Bir mikro hizmet arızasının yayılması, tüm işlemin kullanılamaz olmasına neden olabilir;
Düşük öncelikli mikro hizmetler, yüksek öncelikli mikro hizmetlerin kaynaklarını ele geçirir.

Mikro hizmet sağlığı

Geleneksel olarak, hizmet kaydı genellikle mikro hizmetlerin durumunu tespit etmek için kullanılır.Hizmet sağlayıcının uygun olmadığı tespit edildiğinde, hatalı hizmet bilgileri kümedeki tüm düğümlere yayınlanır.Tüketici hizmet hatası bildirim mesajını aldıktan sonra, arıza bilgisine dayalı olacaktır. Sistemin hizmet adı, IP adresi ve diğer bilgileri hatalı düğümü izole edebilir. Aşağıdaki gibi çalışır:

Mikro hizmet durum tespiti

Kalp atışı veya oturum tabanlı mikro hizmet durumu algılamayı kullanarak, mikro hizmetin bulunduğu süreçte kesinti ve ağ arızaları gibi sorunları keşfedebilirsiniz.Ancak, gerçek iş dünyasında mikro hizmetler "ölü veya canlı" değildir ve "yetersiz durumda" olabilir. Servis çağrısı başarısızlık oranı yüksek, ancak tümü başarısız olmadı. Veya mikro hizmet zaten aşırı yüklenmiş bir akış denetimi durumundadır ve hizmetin kalitesi bozulur, ancak tamamen kesintiye uğramaz.

Basit mikro hizmet durumu algılamasını kullanarak bu senaryolarla uğraşmak zordur. Mikro hizmetlerin işletim kalitesini modelleyerek, mikro hizmet sağlık modelini kullanarak, toplanan çeşitli göstergelere göre gerçek zamanlı olarak mikro hizmetlerin durumunu puanlayarak ve puanlama sonuçlarına göre karşılık gelen güvenilirlik önlemlerini alarak sistemin performansını daha spesifik olarak garanti edebilir güvenilirlik.

Eşzamanlı G / Ç işlemleri

Mikro hizmet çağırma sürecinin tamamında, esas olarak üç tür G / Ç işlemi söz konusudur:

Ağ okuma ve yazmayı içeren ağ G / Ç işlemleri;
Disk G / Ç işlemleri, esas olarak günlükleri kaydetme, çağrı faturaları, yerel dosyalar yazma vb .;
Veritabanı erişimi, örneğin, Java, veritabanı işlemleri için JDBC sürücüsünü kullanır.

Mikro hizmetlerle ilgili ana G / Ç işlemleri

Java'nın BIO'su, dosya okuma ve yazma işlemleri, veritabanı erişimi JDBC arayüzü vb. G / Ç işlemi eşzamanlı engelleme modundaysa, dahil olan tüm G / Ç işlemleri eşzamanlı olarak engellenir. Erişilen ağ, disk veya veritabanı örneği yavaş olduğu sürece, arayan iş parçacığının engellenmesine neden olur. İş parçacıkları, Java sanal makinesinin nispeten önemli bir kaynağı olduğundan, çok sayıda mikro hizmet çağrısı iş parçacığı engellendiğinde, sistemin verimi ciddi şekilde azalacaktır.

Üçüncü taraf SDK API çağrısı

Mikro hizmetlerde, üçüncü taraf SDK API'lerinin çağrılması, FTP istemcileri aracılığıyla uzak FTP hizmetlerine erişim veya MQ hizmetlerine erişmek için MQ istemcilerinin kullanılması gibi yeni hata noktaları da ortaya çıkarabilir. Bu istemci API'leri hata toleransı için tasarlanmışsa İyi değilse, arayanın kademeli arızalarına da yol açacaktır.Bu arızalar gizli ve gizlidir ve genellikle tasarım sırasında kolayca gözden kaçabilir, ancak getirdikleri risk ve tehlikeler çok büyüktür.

Mikro hizmet güvenilirliği

Yazılım güvenilirliği, yazılımın belirli bir ortamda belirli bir süre içinde hatasız çalışma olasılığını ifade eder. Yazılım güvenilirliği aşağıdaki üç unsuru içerir:

Belirtilen süre: Yazılım güvenilirliği yalnızca işletim aşamasında yansıtılır, bu nedenle işletim süresi, belirtilen sürenin bir ölçüsü olarak alınır. Çalışma süresi, yazılım sistemi çalıştıktan sonra kümülatif çalışma ve askıya alma (başlatma ancak boşta) süresini içerir. Yazılım çalıştırma ortamının rasgeleliğinden ve program yolu seçiminden dolayı, yazılımın başarısızlığı rastgele bir olaydır, bu nedenle çalışma süresi rastgele bir değişkendir.

Belirtilen çevresel koşullar: Çevresel koşullar, yazılımın çalışma ortamını ifade eder. Destekleyici donanım, işletim sistemi, diğer destekleyici yazılımlar, giriş veri formatı ve kapsamı ve işletim prosedürleri gibi yazılım sistemi çalışması için gerekli olan çeşitli destek unsurlarını içerir.

Belirtilen işlevler: Yazılım güvenilirliği, belirtilen görevler ve işlevlerle de ilgilidir. Tamamlanması gereken görevler farklı olduğu için adı verilen alt modüller farklıdır (yani program yol seçimi farklıdır) ve güvenirliği farklı olabilir. Bu nedenle, bir yazılım sisteminin güvenilirliğini doğru bir şekilde ölçmek için önce görevlerini ve işlevlerini netleştirmelidir.

Anahtar güvenilirlik faktörleri

Kendi güvenilirlik faktörlerine ek olarak, mikro hizmetlerin işletim kalitesi, ağ, veritabanı erişimi ve diğer ilgili mikro hizmet işletim kalitesi gibi diğer faktörlerden de etkilenir. Mikro hizmetlerin güvenilirlik tasarımı, aşağıdaki gibi özetlenen yukarıdaki kapsamlı faktörleri dikkate almalıdır:

Mikro hizmet güvenilirliği tasarım modeli

Eşzamansız G / Ç işlemi

Ağ G / Ç

Eşzamanlı engelleme G / Ç kullanma sorunu

Örnek olarak Java'yı alın. JAVA NIO1.0'ın JDK 1.4'te kullanılmasından önce, JAVA tabanlı tüm Soket iletişimleri eşzamanlı engelleme modunu (BIO) benimsemiştir. Bu tek istek yanıtlı iletişim modeli, üst düzey uygulama geliştirmeyi basitleştirir, ancak güvenilirdir Cinsiyet ve performans açısından çok büyük dezavantajlar var:

Geleneksel Java senkron engelleme G / Ç modeli

BIO iletişim modelini kullanan sunucu, genellikle istemci bağlantısını izlemekten sorumlu bağımsız bir Acceptor iş parçacığına sahiptir. İstemci bağlantısını aldıktan sonra, istek mesajını işlemek için istemci bağlantısı için yeni bir iş parçacığı oluşturulur ve işlem tamamlandıktan sonra yanıt iletisi istemciye döndürülür , İş parçacığı yok etme, bu tipik bir istek tek yanıt modelidir. Bu mimarinin en büyük problemi esnek ölçeklenebilirliğe sahip olmamasıdır.Eşzamanlı erişim sayısı arttığında sunucu tarafındaki iş parçacığı sayısı eşzamanlı erişim sayısı ile doğrusal orantılıdır.Çünkü iş parçacıkları, iş parçacığı sayısı arttığında JAVA sanal makinesinin çok değerli bir sistem kaynağıdır, Sistemin performansı keskin bir şekilde düşer. Eşzamanlılık miktarı artmaya devam ettikçe, tutamaç taşması ve iş parçacığı yığını taşması gibi sorunlar ortaya çıkabilir ve sonunda sunucu kapanacaktır.

Engellemeyen G / Ç iletişimini kullanın

Mikro hizmetler, engellemeyen G / Ç kullanarak uzaktan iletişim gerçekleştirdiğinde, büyük ağ gecikmelerinin ve yüksek eşzamanlı erişimin neden olduğu sunucu iş parçacığı genişletmesi veya iş parçacığı engellemesi gibi sorunlar çözülebilir.

Örnek olarak Java'yı ele alalım.JDK1.4'ten başlayarak, JDK, engellemesiz G / Ç'yi desteklemek için bir dizi özel sınıf kitaplığı sağlar. Java.nio paketi ve alt paketlerinde ilgili sınıfları ve arayüzleri bulabilirsiniz. JDK1.7'den sonra, eşzamansız G / Ç işlemlerini desteklemek için NIO2.0 kitaplığı sağlanmıştır.

JDK'nın eşzamansız, engellemeyen G / Ç'sini kullanarak, bir G / Ç iş parçacığı aynı anda birden fazla istemci bağlantısını işleyebilir, okuma ve yazma işlemleri ağ nedenlerinden dolayı engellenmez ve G / Ç iş parçacığı aynı anda birden çok istemciyi verimli bir şekilde işleyebilir Link, I / O çoğullamayı gerçekleştirin, çalışma prensibi aşağıdaki gibidir:

Java engellemeyen G / Ç modeli

İletişim için engellemesiz G / Ç kullanın. Java dilini örnek alırsak, önerilen strateji aşağıdaki gibidir:

TCP özel protokolü: Doğrudan Netty'ye dayalı olarak geliştirilmesi önerilir.

HTTP / Dinlendirici / SABUN, vb .: Engellemeyen G / Ç'yi destekleyen bir web çerçevesi seçin. Ayrıca, zaman uyumsuz Restful'u destekleyen RestExpress gibi Netty üzerine inşa edilmiş açık kaynaklı bir uygulama katmanı protokol yığını çerçevesi de seçebilirsiniz.

Disk G / Ç

Disk G / Ç üzerindeki mikro hizmet işlemleri iki kategoriye ayrılır:

Doğrudan dosya işlemleri: Örneğin, dosya işlemlerini gerçekleştirmek için Dosyanın açma, yazma ve okuma arayüzlerini çağırın.
Dolaylı dosya işlemleri: Örneğin, günlük kitaplığı, günlükleri yazmak için çağrılır.Microservis, günlük dosyalarını doğrudan değiştirmese de, günlük kitaplığının alt katmanı dosya okuma ve yazma gibi işlemleri gerçekleştirmeye devam eder.

Gerçek projede en kolay gözden kaçan log işlemidir. Farklı günlük kitaplıklarının farklı günlük yazma mekanizmaları vardır. Örnek olarak Log4j 1.2.X sürümünü alın. Günlük kuyruğu dolduğunda, birden çok strateji vardır:

Yeni günlük mesajı sıraya alınana kadar eşzamanlı olarak bekleyin, mevcut iş iş parçacığını bloke edecektir.
Mevcut iş parçacığını engellemeden mevcut günlük mesajını atın.
Kuyruğa girmeden, günlük G / Ç işlemi şu anda günlük yazmayı çağıran iş iş parçacığı tarafından gerçekleştirilir.Eğer disk G / Ç yazma hızı şu anda yavaşsa, mevcut iş iş parçacığı engellenecektir.

Gerçek üretim ortamında, benzer sorunlarla karşılaştık.Bazı dönemlerde, disk WIO birkaç saniye -10 saniye 10+ 'ye ulaştı ve sonra normale döndü. Yüksek WIO dönemlerinde, arabirim günlükleri, çağrı faturaları vb. Yazmak gerekir. Sistem varsayılan olarak senkronize bir bekleme stratejisine sahip olduğundan, iletişim G / Ç iş parçacığı, mikro hizmet zamanlama iş parçacığı vb. Engellenir ve son olarak kalp atışı zaman aşımı nedeniyle bağlantı zorlanır Kapatma, mikro hizmetler büyük ölçüde ileti kuyruğunda engellenir, bu da yüksek bellek ve yanıt zaman aşımlarına neden olur.

Bazen, yüksek WIO, eşzamanlı günlük yazmanın engellenmesine neden olur, bu da iletişim iş parçacığına ve mikro hizmet çağrısı iş parçacığı basamaklı hatasına neden olur, bu da bulunması çok zordur ve Kod İncelemesini fark etmek de zordur. Bu nedenle, örtük disk G / Ç işlemleri daha fazla dikkat gerektirir.

Yukarıdaki sorunları çözmek için üç strateji vardır:

Dosyalarda eşzamansız okuma ve yazma işlemleri gerçekleştirmek için engellemesiz G / Ç kullanın.
İş katmanı, eşzamansız bir G / Ç işlemini kapsüller En basit strateji, disk G / Ç işlemlerini ayrı bir iş parçacığı veya iş parçacığı havuzu ile gerçekleştirmektir.
Log4j'nin eşzamansız günlük API'sini kullanmak gibi engellemeyen çağrıları destekleyen bir G / Ç kitaplığı seçin.

JDK1.7'yi örnek olarak alırsak, eşzamansız bir dosya G / Ç işlem kitaplığı sağlar. Bu kitaplığa dayanarak, disk G / Ç işlemlerinin engellenmesi konusunda endişelenmenize gerek yoktur:

JDK1.7 asenkron engellemesiz dosya arayüzü

Eşzamansız G / Ç işlemlerini üst katmanda kapsüllemek nispeten basittir. Avantajı, disk G / Ç işlemleri ve mikro hizmetler arasında iş parçacığı yalıtımı gerçekleştirebilmesidir, ancak alt katman hala eşzamanlı engelleme G / Ç kullanır. Disk bu sırada ise G / Ç nispeten yüksektir ve G / Ç iş parçacığının diske yazılmasını yine de engelleyecektir. Prensibi aşağıdaki gibidir:

Uygulama katmanı tarafından kapsüllenen zaman uyumsuz dosya işlemleri

Dosya G / Ç işlemini bir Görev veya Olay olarak kapsülleyin ve bunu G / Ç iş parçacığı havuzunun ileti kuyruğuna teslim edin.Teslim sonucuna göre, mikro hizmet çağıran iş parçacığına G / Ç işlemi ile ilişkili Gelecek nesnesini oluşturun. Dinleyiciyi Gelecek nesnesiyle kaydettirerek ve geri arama arabirimini uygulayarak, zaman uyumsuz geri arama bildirimi gerçekleştirilebilir, böylece mikro hizmet ve dosya G / Ç işlemleri iş parçacığı yalıtımı sağlayabilir. Dosya G / Ç işlemleri zaman alıcıdır ve mikro hizmet zamanlama iş parçacığını engellemez.

Üçüncü taraf dosya G / Ç işlem kitaplıklarını kullanırken, ilgili API'lere dikkat etmeniz ve eşzamansız, engellemeyen arayüzleri destekleyen API'leri kullanmaya çalışmanız gerekir. Değilse, üst düzey eşzamansız kapsülleme yapıp yapmayacağınızı düşünmeniz gerekir.

Veritabanı işlemi

Veritabanı erişiminin bir kısmı, engellemesiz modu ve engelleme modunu destekleyen Oracle OCI gibi engellemesiz modu destekler: engelleme modu, OCI işlemi çağrıldığında, sunucu, karşılık gelen bilgileri istemciye göndermeden önce sunucunun OCI işleminin tamamlanmasını beklemesi gerekir. Başarı veya başarısızlık. Engellemesiz yöntem, istemci OCI işlemini sunucuya gönderdiğinde, sunucu, sunucu işleminin tamamlanmasını beklemeden hemen OCI_STILL_EXECUTING mesajını döndürür. Engellemesiz yöntem için, uygulama, dönüş değeri OCI_STILL_EXECUTING olan bir OCI işlevi alırsa, başarısını belirlemek için her OCI işlevinin dönüş değerini yeniden yargılamalıdır. Bu, sunucu özniteliğini OCI_ATTR_NONBLOCKING_MODE olarak ayarlayarak elde edilebilir.

Java dili için, JDK'nın kendisi veritabanı bağlantı sürücüsüyle ilgili arabirim tanımları sağladığından ve JDBC sürücüsünün kendisi eşzamanlı bir API arabirimi olduğundan, Java dilinin açık kaynaklı ORM çerçeveleri de MyBatis ve Hibernate gibi eşzamanlı olarak engellenir.

Çoğu veritabanı erişim arabirimi eşzamanlı olarak engellenmesine rağmen, veritabanı ara yazılımının zaman aşımı kontrol mekanizması nispeten olgunlaşmıştır, bu nedenle zaman aşımı süresini makul bir şekilde ayarlayarak, mikro hizmetlerin veritabanı erişiminin uzun süre askıya alınmasını önleyebilirsiniz.

Zaman uyumsuz veritabanı işlem katmanı, mikro hizmet planlaması ve veritabanı operasyonu arasında iş parçacığı düzeyinde izolasyonu gerçekleştirmek için uygulamanın üst katmanında da kapsüllenebilir. İlke, önceki makalede tanıtılmıştır.Bu yöntemde ayrıca iki dezavantaj vardır:

Kuyruklama olgusu: Bir veritabanı işlemi çok zaman alıyorsa ve zaman aşımı süresi nispeten büyük olacak şekilde yapılandırılmışsa (örneğin, 30S), sonraki veritabanı işlemleri kuyrukta sıraya alınacaktır.
Veritabanı performansına tam oyun verilemiyor: Temeldeki veritabanı erişimi eşzamanlı engellemeyi benimsediğinden, veritabanı performansı verimli bir şekilde kullanılamaz.

Arıza izolasyonu

Çoğu mikro hizmet eşzamanlı arabirim çağrıları kullandığından ve etki alanıyla ilgili birden çok mikro hizmet aynı işlemde dağıtılacağından, "çığ etkisi", yani mikro hizmet sağlayıcısının arızalanması, mikro hizmeti çağırmanın tüketilmesine neden olur. Diğer mikro hizmetlerin veya hatalı mikro hizmetle aynı işlemde bulunan diğer mikro hizmetlerin basamaklı arızaları, sonunda sistemin çökmesine neden olur.

"Çığ etkisinin" meydana gelmesini önlemek için, mikro hizmetlerde HA elde etmek için birden çok bağımlılık ve hata izolasyon boyutunu desteklemek gerekir.

İletişim bağlantısı izolasyonu

Ağ iletişiminin kendisi genellikle sistemin darboğazı olmadığından, çoğu hizmet çerçevesi iletişim için çok iş parçacıklı + tek iletişim bağlantısını kullanacaktır. İlke aşağıdaki gibidir:

Çok iş parçacıklı tek bağlantı P2P iletişim modu

Önceki bölümlerde belirtildiği gibi, mikro hizmetler eşzamansız engellemesiz iletişim kullandığından, tek bir G / Ç iş parçacığı aynı anda birden çok bağlantıdan gelen iletileri eşzamanlı olarak işleyebilir ve ağ okuma ve yazma işlemleri engellemez olduğundan, çok iş parçacıklı + tek bağlantı yaklaşımı benimsenir İletişim performansının kendisi büyük bir sorun değil. Ancak güvenilirlik açısından sadece tek bir bağlantının desteklenmesinin bazı güvenilirlik riskleri vardır, soruna aşağıdaki durumdan bakalım.

Bir İnternet tabanının mikro hizmet mimarisi piyasaya sürüldükten sonra, bazı dönemlerde genellikle iş zaman aşımlarının olduğu ve zaman aşımı işi için sabit bir kuralın olmadığı bulundu. Konumlandırmadan sonra, daha fazla toplu içerik senkronizasyonu, ses ve video mikro hizmet çağrıları olduğunda, sistemin genel gecikmesinin çok daha yüksek olduğu ve daha belirgin gecikme aksaklıklarının olduğu bulunmuştur. Bu işlemlerle elde edilen mesaj kodu akışları genellikle birkaç M ila onlarca megabayta ulaştığından ve tek bağlantı modu mikro hizmetler arasında P2P iletişimi için kullanıldığından, büyük kod akışlarının iletimi diğer mesajların okuma ve yazma verimliliğini etkiler ve artar Mikro hizmetlerin yanıt gecikmesi.

Sorun tespit edildikten sonra, mikro hizmetler arasındaki iletişim mekanizması optimize edilir.Düğümler, çoklu bağlantıların konfigürasyonunu destekler.Her bağlantı ayrıca, örneğin mesaj kodu akışının boyutuna ve mikro hizmetlere göre farklı izolasyon stratejileri elde edebilir. Öncelik seviyesi gibi stratejiler, bağlantı düzeyinde izolasyonu gerçekleştirir ve mikro hizmet iletişim mekanizmasını optimize eder:

Çoklu bağlantı izolasyonunu destekleyin

Kaynak izolasyonunu planlama

Mikro hizmetler arasında izolasyon

Aynı işlemde birden çok mikro hizmet çalışırken, farklı mikro hizmetleri izole etmek için iş parçacıkları kullanılabilir.

Çekirdek mikro hizmetler için, yayınlarken bir iş parçacığı / iş parçacığı havuzunu tekelleştirebilir ve çekirdek olmayan mikro hizmetler için aynı büyük iş parçacığı havuzunu paylaşabilirsiniz.Mikro hizmet yalıtımı uygularken, iş parçacığının aşırı yüklenmesini önleyebilirsiniz:

Mikro hizmetler arasında hata izolasyonu

Çekirdek olmayan hizmet 3 başarısız olursa ve iş parçacığı havuzu 1'in çalışan iş parçacığını uzun süre bloke ederse, iş parçacığı havuzu ileti kuyruğunu paylaşan diğer çekirdek olmayan hizmetler 1 ve hizmet 2 yalnızca kuyrukta bekleyebilir. Hizmet 3 iş parçacığını serbest bıraktığında, sıraya alınır Hizmet 1 ve Hizmet 2 zaman aşımına uğramış olabilir ve yalnızca iptal edilerek hizmet işleme hatasına neden olabilir.

İş parçacığı havuzu tarafından izole edilen çekirdek hizmet 1 ve hizmet 2, çünkü her özel iş parçacığı havuzu bağımsız bir ileti kuyruğuna sahip olduğundan yürütülmesi, hatalı çalışan çekirdek olmayan hizmetten 1 etkilenmez, bu nedenle normal şekilde çalışmaya devam edebilir. Temel hizmetlerin bağımsız bir iş parçacığı havuzu aracılığıyla dağıtılması, hataların yayılmasını önleyebilir ve temel hizmetlerin normal çalışmasını sağlayabilir.

Üçüncü taraf bağımlılık izolasyonu

Mikro hizmetlerde, dağıtılmış önbellek hizmetleri, dağıtılmış ileti kuyrukları ve NoSQL hizmetleri gibi üçüncü taraf ara yazılım hizmetleri genellikle çağrılır. Üçüncü taraf hizmet çağrıldığı sürece, ağlar arası işlemleri içerecektir. İstemci SDK API'sinin kapsüllenmesi nedeniyle, birçok hata gizlidir, bu nedenle güvenilirliği ek dikkat gerektirir.

Genel olarak, üçüncü taraf bağımlılık yalıtımı, iş parçacığı havuzu + reaktif programlama (RxJava gibi) ile sağlanabilir. Prensibi aşağıdaki gibidir:

Üçüncü taraf bağımlılıklarını sınıflandırın ve her bağımlılık bağımsız bir iş parçacığı / iş parçacığı havuzuna karşılık gelir.

Mikro hizmetler, üçüncü tarafların güvendiği API'leri doğrudan çağırmaz, bunun yerine eşzamansız kapsüllemeden sonra API arabirimlerini kullanır.

Eşzamansız olarak üçüncü taraf bağımlı API'yi çağırdıktan sonra, Gelecek nesnesini edinin. Reaktif programlama çerçevesini kullanarak, sonraki olaylara abone olabilir, yanıtlar alabilir ve yanıtlar için program yapabilirsiniz.

Netflix'in açık kaynak hystrix + RxJava'sını kullanarak, üçüncü taraf bağımlılıklarını hızlı bir şekilde izole edebilirsiniz.İlerleyen bölümlerde, nasıl kullanılacağını ayrıntılı olarak tanıtacağız.

Süreç düzeyinde izolasyon

Ürün satın alma, kullanıcı kaydı, faturalama vb. Gibi temel mikro hizmetler için bağımsız dağıtım, yüksek kullanılabilirlik elde etmek için kullanılabilir.

Konteyner izolasyonu

Mikro hizmetler, yazılım geliştiricilerin tüm yazılımı tek işlevli hizmetlere ayırmalarını teşvik eder ve bu hizmetler bağımsız olarak dağıtılabilir, yükseltilebilir ve genişletilebilir. Mikro hizmetlerin soyutlanması yeterince iyiyse, mikro hizmetlerin bu avantajı uygulamaların çevikliğini ve kendi kendini yönetmesini geliştirecektir. Mikro hizmetleri dağıtmak için Docker kapsayıcılarını kullanmak aşağıdaki avantajları sağlayabilir:

Verimli: Bir Docker konteynerini başlatmak ve durdurmak birkaç dakika sürmez, sadece birkaç yüz milisaniye yeterlidir. Mikro hizmetleri dağıtmak için Docker kullanmak, mikro hizmetlerin başlatma ve yok etme hızı çok hızlıdır ve yüksek basınç altında ikinci düzey esnek ölçeklendirme sağlayabilir.
Yüksek performans: Docker konteynerlerinin performansı, sanal makinelerden ortalama olarak% 20 + daha yüksek olan çıplak fiziksel makinelerin performansına yakındır.
İzolasyon: Docker ile 0.1 çekirdek izolasyonu sağlanabilir. İnce taneli kaynak izolasyon mekanizmasına dayalı olarak, mikro hizmetlerin yüksek yoğunluklu dağıtımı sağlanabilir ve mikro hizmetlerin güvenilirliğini sağlamak için bunlar arasında kaynak katmanı yalıtımı sağlanabilir.
Taşınabilirlik: Sanal makine tabanlı çözümlerde, uygulama taşınabilirliği genellikle bulut sağlayıcısı tarafından sağlanan sanal makine formatı ile sınırlıdır. Uygulamanın farklı türdeki sanal makinelere dağıtılması gerekiyorsa, belirli bir sanal makine formatı için bir görüntü dosyası oluşturmak ve çok sayıda ek geliştirme ve test iş yükü eklemek gerekir. Docker konteynerlerinin tasarım felsefesi, geliştiricilerin yukarıdaki kısıtlamalardan kaçınmasına olanak tanıyan "bir kez yaz, her yerde çalıştır" şeklindedir.

Fiziksel kaynak katmanı yalıtımı elde etmek için Docker konteynerlerine dayalı mikro hizmetleri dağıtmanın şematik diyagramı aşağıdaki gibidir:

Docker konteynerine dayalı mikro hizmet izolasyonu

Sanal makine izolasyonu

Docker kapsayıcı izolasyonuna ek olarak, sanal makineler mikro hizmetleri izole etmek için de kullanılabilir.Docker kapsayıcılarıyla karşılaştırıldığında, mikro hizmet yalıtımı için sanal makinelerin kullanılması aşağıdaki avantajlara sahiptir:

Mikro hizmetlerin daha iyi kaynak yalıtımı vardır; CPU, bellek, ağ vb. Tam kaynak yalıtımı sağlayabilir.

Donanım sanallaştırmasını tamamlamış eski sistemler için mevcut VM'ler, Docker konteynerlerini VM'de yeniden dağıtmaya gerek kalmadan doğrudan kullanılabilir.

Küme hata toleransı

Mikro hizmetler kullanılamadığında, hataya dayanıklı işlemlerin önceden belirlenmiş ilkelere göre gerçekleştirilmesi gerekir.Hata toleranslı özelliklerin ve ilkelerin çoğu herkese açıktır, bu nedenle hizmet çerçevesinde uygulanabilirler.

Hata toleransı yönlendirme

Mikro hizmet çağrısı küme ortamında başarısız olduğunda, hataya dayanıklı yönlendirme mekanizması, alt katmandaki mikro hizmetin otomatik hata toleranslı işlenmesini gerçekleştirmek ve sistemin güvenilirliğini artırmak için kullanılabilir.

Yaygın hata toleransı stratejileri şunları içerir:

Başarısız otomatik anahtarlama mekanizması: Mikro hizmet çağrısı başarısızlıkları için otomatik geçiş stratejisi, bir hizmet çağrısı istisnası oluştuğunda, yolun bir sonraki kullanılabilir mikro hizmet sağlayıcısını bulmak için yeniden seçildiğini ifade eder. Bir mikro hizmet serbest bırakıldığında, hizmetin küme hataya dayanıklılık stratejisi belirtilebilir. Tüketiciler, kişiselleştirilmiş bir hata toleransı stratejisi elde etmek için servis sağlayıcının genel yapılandırmasını geçersiz kılabilir.
Hata geri arama mekanizması: Mikro hizmet çağrısı başarısız olduktan sonra, mikro hizmet tüketicisi tarafından özelleştirilmiş hata işleme mantığını yürütmek için bir istisna geri arama arabirimi sağlanır.
Hızlı arıza mekanizması: İşin en yoğun döneminde, bazı temel olmayan hizmetler için, yalnızca bir kez aranacakları ve başarısız olurlarsa yeniden denenmeyecekleri, böylece önemli temel hizmetler için değerli işletim kaynaklarından tasarruf edecekleri umulmaktadır. Bu noktada hızlı başarısızlık iyi bir seçimdir. Hızlı arıza stratejisinin tasarımı nispeten basittir Servis çağrısı istisnası elde edildikten sonra istisna doğrudan yok sayılır ve istisna kaydı kaydedilir.

Hizmet bozulması

Büyük bir promosyon veya iş zirvesi sırasında, temel hizmetin SLA'sını sağlamak için genellikle ürün incelemeleri, forumlar veya hayran noktaları gibi daha az önemli bazı işletmeleri durdurmak gerekir.

Diğer bir senaryo, bazı hizmetlerin bir nedenle kullanılamaması, ancak işlemin doğrudan başarısız olamaması ve işlemi netleştirmek için yerel Mock sunucusunun uygulanması gerektiğidir. Örnek olarak kitap okumayı ele alırsak, kullanıcı oturum açma bakiyesi kimlik doğrulama servisi düzgün çalışmıyorsa, işin temizlenmesi gerekiyor, tüketim faturası kaydediliyor ve kullanıcıya hata vermek yerine okumaya devam etme izni veriliyor.

Hizmet yönetişiminin hizmet bozulması işlevi aracılığıyla, yukarıdaki iki senaryonun gereksinimleri karşılanabilir.

Zorunlu sürüm düşürme

Harici tetikleme koşulu belirli bir kritik değere ulaştığında, belirli bir türü veya belirli bir hizmeti düşürmeye zorlama kararı, işletme ve bakım personeli / geliştiricinin sorumluluğundadır.

Zorunlu düşürme için ortak stratejiler:

Uzaktan hizmet çağrısı başlatmayın ve doğrudan boş dönmeyin. Örneğin, mock = force: return.
Uzaktan hizmet çağrısı başlatmayın ve belirtilen istisnayı doğrudan atmayın. Örneğin, mock = force: throw Exception.
Uzaktan bir servis çağrısı başlatmayın, doğrudan yerel simülasyon arayüzü uygulama sınıfını yürütün. mock = force: Bean'i çalıştır:

Hata toleransı bozulması

Çekirdek olmayan hizmetler kullanılamadığında, temel hizmetlerin çalışmasını sağlamak için iş mantığı arıza hizmetlerine bırakılabilir.

Hata toleransı bozulması ve ekranlama bozulması arasındaki temel farklar şunlardır:

Tetikleme koşulları farklıdır: Hata toleransı açıklaması, servis çağrısının sonucuna göre otomatik eşleştirme ile tetiklenir ve ekranlama ve alçaltma genellikle sistem çalışma durumuna göre manuel işlemle tetiklenir.

Farklı işlevler: Hata toleransı bozulması, tüketicilerin hizmet sağlayıcı müsait olmadığında iş serbest bırakmasını gerçekleştirmesine olanak sağlamaktır; bozulmayı korumanın temel amacı, temel iş kullanımı için aslen bozulmuş işletmeye ait olan kaynakları tahsis etmektir.

Çağrı mekanizması farklıdır: biri uzak servis çağrılarını başlatır ve diğeri sadece yerel çağrılar yapar.

Hata toleransı bozulması için yaygın stratejiler aşağıdaki gibidir:

İstisna kaçış: mock = başarısız: İstisna fırlat.
Özel sürüm düşürme mantığı: mock = fail: Bean'i çalıştır:

Hizmet düşürme Portalı

Hizmet yönetişim portalını kullanarak, çevrimiçi mikro hizmetlerin sürüm düşürme stratejisini dinamik olarak değiştirebilir ve gerçek zamanlı olarak yürürlüğe girebilirsiniz.Arayüzü aşağıdaki gibidir:

Hizmet düşüşü yapılandırma arayüzü

Sigorta mekanizması

Otomatik süspansiyon mekanizması olarak da bilinen devre kesici, borsa tarafından hisse senedi endeksi oynaklığı belirlenen bir sigorta noktasına ulaştığında riskleri kontrol etmek için alınan alım satım askıya alma önlemlerini ifade eder.

Mikro hizmetler alanında, sigorta mekanizması, mikro hizmet sağlayıcısını tüketici tarafından korumak için bir önlemdir.Mikro hizmetin çalışma kalitesi belirli bir eşiğin altında olduğunda, sigorta mekanizması etkinleştirilir ve arka uç mikro hizmetini korumak için mikro hizmet çağrısı bir süre askıya alınır. Sürekli aşırı yük nedeniyle kesinti yok.

çalışma prensibi

Mikro hizmetlerin sigorta mekanizmasının prensibi aşağıdaki gibidir:

Mikro hizmet çağrıldığında sigorta şalterinin durumu yargılanır.Sigorta şalteri kapatıldığında, talebin sigortadan geçmesine izin verilir. Mevcut mikro hizmet durumu belirtilen eşikten yüksekse, anahtar kapalı kalmaya devam eder. Aksi takdirde, anahtar açık duruma geçer.

Sigorta anahtarı açıldığında, mikro hizmet çağrısı talebinin geçmesi engellenir. Çağrı başarısız olursa, yerel sürüm düşürme mantığı yürütülür Düşürme mantığı uygulanmazsa, varsayılan olarak bir istisna döndürülür.

Sigorta anahtarı açık durumda olduğunda, belirtilen T süresinden sonra sigorta otomatik olarak yarı açık duruma geçecek ve sigorta talebin geçmesine izin verecektir.İstek başarıyla arandığında sigorta kapalı duruma dönecektir. Başarısız olursa, açık kalmaya devam eder.

Çalışma prensibi aşağıdaki gibidir:

Mikro hizmet sigortasının çalışma prensibi

Sigorta mekanizması, mikro hizmet tüketicilerinin mikro hizmetler zayıf çalıştığında sonuçları hızlı bir şekilde döndürebilmelerini sağlayarak çok sayıda senkronizasyon beklemesini önleyebilir. Ve hata kurtarma sonrasında otomatik algılamayı gerçekleştirmek için mikro hizmetin belirtilen süre T'den sonra kullanılabilir olup olmadığını tespit etmeye devam edebilir.

Mikro hizmet sağlığı

Sigorta şalterinin durumu, mikro hizmetin çalışma kalitesine bağlıdır Mikro hizmetin işletim kalitesi genellikle birden fazla ölçüm faktörü ile çeşitli faktörler tarafından belirlenir. Mikro hizmetlerin sağlığını modelleyerek, mikro hizmetlerin kalitesine ilişkin 360 ° gerçek zamanlı bir değerlendirme elde edilebilir.

Mikro hizmet sağlık modeli aşağıdaki gibidir:

Mikro hizmet sağlık modeli

Mikro hizmet operasyon ve bakım sistemi, dağıtılmış günlük toplama sistemleri, alarm sistemleri, performans KPI veri toplama vb. Kullanır, çevrimiçi büyük veri gerçek zamanlı analiz teknolojisini kullanır ve mikro hizmetlerin durumunu döngüye göre gerçek zamanlı olarak puanlamak için bir sağlık modeli kullanır. Puan, ileti kuyruğu aboneliği aracılığıyla yayınlanır ve mikro hizmete abone olan her düğümün sağlık puanı, sigorta anahtarının durumunu değiştirmek için sigorta eşiğiyle karşılaştırılır.

akış kontrolü

Kaynaklar bir darboğaz haline geldiğinde, hizmet çerçevesinin tüketicilerin akışını sınırlaması ve akış kontrol koruma mekanizmasını etkinleştirmesi gerekir. Akış kontrolü için birçok strateji vardır, daha yaygın olarak kullanılanlar şunlardır: erişim hızı için statik akış kontrolü, kaynak kullanımı için dinamik akış kontrolü, vb.

Uygulamada, daha iyi sonuçlar elde etmek için çeşitli akış kontrol stratejilerinin kapsamlı bir şekilde kullanılması gerekir.

Dinamik akış kontrolü

Dinamik akış kontrolünün nihai amacı, trafiği veya erişim hızını hassas bir şekilde kontrol etmek değil, hayat kurtarmaktır. Sistem yük baskısı çok yüksek olduğunda, sistem bir aşırı yük durumuna girer. CPU ve bellek kaynakları aşırı yüklenmiş olabilir veya uygulama sürecindeki kaynaklar neredeyse tükenmiş olabilir. İşletmeyi tam olarak işlemeye devam ederseniz, ciddi bir birikmiş mesaj veya uygulama işlemine neden olabilir. Arıza süresi.

Dinamik akış kontrolü algılama kaynakları şunları içerir:

CPU kullanımı.
Bellek kullanımı (Java için, esas olarak JVM bellek kullanımı).
Kuyruk biriktirme oranı.

Ana bilgisayar CPU'su ve bellek kullanımı için birçok toplama algoritması vardır. Örneğin, sistem kaynak kullanımını elde etmek için top ve sar gibi harici komutları çalıştırmak için java.lang.Process'i kullanın ve ardından kaynak kullanımını analiz edip hesaplayın. İlgili verileri elde etmek için işletim sisteminin sistem dosyalarını doğrudan okumak da mümkündür.İşletim sisteminin yerel komutunu yürütmek veya işletim sisteminin kaynak kullanım dosyasını doğrudan okumak olsun, tümünün yerel olarak işletim sistemi ile ilgili olduğu unutulmamalıdır. İşletim sistemleri ve sunucular, komutlar ve çıktı biçimleri çok farklı olabilir. Hesaplama yaparken önce işletim sistemi tipini belirlemeniz ve daha sonra ilgili işletim sisteminin kaynak toplama arayüz uygulama sınıfını çağırmanız gerekir.Bu sayede platformlar arası destek verebilirsiniz.

Dinamik akış kontrolü seviyelere bölünmüştür ve farklı seviyeler tarafından reddedilen mesajların oranı, kaynakların yük kullanımına bağlı olarak farklıdır. Örneğin, birinci seviye akış kontrolü gerçekleştiğinde, mesajların 1 / 4'ü reddedilir; ikinci seviye akış kontrolü gerçekleştiğinde 1/2 mesaj reddedilir; üçüncü seviye akış kontrolü gerçekleştiğinde tüm mesajlar akış kontrollüdür.

Farklı seviyelerin farklı akış kontrol eşikleri vardır ve varsayılan olanlar sistem çevrim içi olduktan sonra sağlanacaktır; akış kontrol eşikleri, farklı akış kontrol faktörleri için akış kontrol eşikleri farklıdır, iş çevrimiçine geçtikten sonra eşik genellikle sahadaki fiili duruma göre ayarlanır, bu nedenle akış kontrolü Eşiğin çevrimiçi modifikasyonu ve dinamik etkiyi desteklemesi gerekir.

Sistem dalgalanmalarının neden olduğu kazara akış kontrolünü önlemek için, ister akış kontrol durumuna giriyor olsun ister akış kontrol durumundan düzeliyor olsun, sürekli olarak N kez toplanması ve ortalama değerin hesaplanması gerektiği belirtilmelidir.Ardı ardına N kez ortalama değer akış kontrol eşiğinden büyükse, Daha sonra akış kontrol durumuna girer; aynı şekilde, yalnızca ardışık N kez kaynak kullanım oranının ortalama değeri akış kontrol eşiğinden düşük olduğunda, akış kontrolünden çıkıp normale dönebilir.

Statik akış kontrolü

Statik akış kontrolü esas olarak müşterinin erişim oranını kontrol eder. Genellikle, Hizmet Kalite Seviyesi Anlaşmasında (SLA) kararlaştırılan QPS'ye dayalı olarak global akış kontrolü gerçekleştirir. Örneğin, faturalama hizmetleri için statik akış kontrol eşiği, kaç küme olduğuna bakılmaksızın 200 QPS'dir. Faturalama hizmeti örnekleri için, toplam işleme oranlarının toplamı 200 QPS'yi aşamaz.

Mikro hizmetler esnek ölçeklendirme, dinamik çevrimiçi ve çevrimdışı özelliklere sahip olduğundan, bir kümedeki mikro hizmet örneğinin düğüm sayısı dinamik olarak değişir ve geleneksel ortalama dağıtım sistemi hassas denetim sağlayamaz.

Uygulamada, daha olgun küme statik akış kontrol stratejisi dinamik kota uygulama sistemidir ve çalışma prensibi aşağıdaki gibidir:

Sistem dağıtıldığında, mikro hizmet düğümlerinin sayısına ve statik akış denetimi QPS eşiğine göre, ilk tahsis için kotanın belirli bir yüzdesi kullanılır ve kalan kota kota kaynak havuzuna yerleştirilir.

Bir mikro hizmet düğümünün kotası bittiğinde, kota için hizmet kayıt defterine etkin olarak uygulanır. Kota uygulama stratejisi: Akış kontrol periyodu T ise, T periyodu daha küçük T / N periyotlarına bölünür (N, ampirik değerdir ve varsayılan değer 10'dur). Mevcut servis düğümü sayısı M'dir ve uygulanan kota (Toplam QPS kotası-QPS kotası zaten tahsis edilmiştir) / M * T / N.

Toplam kota uygulanmışsa, kota için başvuran her hizmet düğümüne 0 kota döndürülür ve hizmet düğümü, yeni erişilen istek mesajlarında akış denetimi gerçekleştirir.

Kullanıcı tanımlı akış kontrol mekanizması

Farklı hizmetlerin, mikro hizmet önceliğine dayalı akış denetimi, tatillere dayalı akış denetimi, iş alanlarına dayalı akış denetimi vb. Gibi farklı akış denetimi stratejileri vardır. Temel hizmet çerçevesi, tüm iş düzeyinde özelleştirilmiş akış kontrol stratejilerini uygulayamaz Bu nedenle, çok iş odaklı olan akış kontrolü, genellikle özel bir akış kontrol mekanizması aracılığıyla iş tarafından uygulanır.

Hizmet çerçevesi, hizmet çağrısı girişinin durdurma noktasını ve yön arayüzünü sağlar ve işletme, özel akış kontrolünü gerçekleştirir. Ayrıca, işletme özelleştirme iş yükünü basitleştirmek için, akış kontrol koşulu yargısını, akış kontrol yürütme stratejisini vb. Gerçekleştirmek için işletmenin temel bir akış kontrol çerçevesi sağlayabilir.

Mikro hizmet güvenilirliğini artırmak için Hystrix'i kullanın

Hystrix'e Giriş

Hystrix, ağırlıklı olarak dağıtılmış bir ortamda bağımlılık ayrıştırması için kullanılan Netflix açık kaynağının bir güvenilirlik bileşenidir.Hystrix kitaplığı, gecikme toleransı ve hata toleransı mantığı ekleyerek ve hizmetler arasındaki erişimin izolasyon noktası aracılığıyla dağıtılmış hizmetler arasındaki etkileşimi kontrol eder. Basamaklı arızaları önleyin ve sistemin güvenilirliğini artırmak için bir arıza geri arama mekanizması sağlayın.

Hystrix, dağıtılmış sistemlerin güvenilirliğini artırmak için aşağıdaki mekanizmaları sağlar:

Üçüncü taraf istemci API'leri aracılığıyla bağımlı erişimi koruyun ve gecikmeleri ve arızaları kontrol edin
Basamaklı arızaları ve "çığ etkilerini" önleyin
Hızlı bir şekilde arızalanmak ve kurtarmak için bir sigorta mekanizması sağlayın
Arıza geri araması ve zarif bozulma mekanizması
Gerçek zamanlıya yakın algılama, alarm ve KPI gösterge ekranı

Hystrix'in temel işlevleri

Hystrix, farklı dağıtılmış sistemlerin entegrasyonunu ve kullanımını kolaylaştırmak için belirli mikro hizmet çerçevelerinin uygulanmasıyla hiçbir ilgisi olmayan bazı çok değerli özellikler sağlar.

Bağımlılık izolasyonu

Hystrix, bağımlı çağrı mantığını paketlemek için HystrixCommand (Command) komut modunu kullanır ve her komut ayrı bir iş parçacığı / sinyal yetkilendirmesi altında yürütülür. Bağımlı aramanın zaman aşımı süresi yapılandırılabilir.Zaman aşımına uğrarsa, başarısızlık durumuna dönecek veya geri dönüş mantığını çalıştıracaktır. Prensip aşağıdaki gibidir:

İş parçacığı / sinyal tabanlı bağımlılık yalıtımı

Sigorta

Hystrix önce sigortayı geçecektir.Bu anda, eğer sigorta açıksa, atmış demektir.Bu anda, doğrudan düşürülecek ve iş parçacığı havuzuna istek göndermeye devam etmeyecektir.

Sigortanın anahtarlama durumu, sigorta algoritması tarafından belirlenir ve ilkesi aşağıdaki gibidir:

Kaynaşıp kaynaşmadığına karar verin: kovaya kaydedilen sayıya göre hata oranını hesaplayın. Hata oranı sigorta ön ayar eşiğine ulaşırsa, sigorta anahtarı açılır.
Sigorta kurtarma: Sigorta isteği için, işlemi bir süre askıya aldıktan sonra (HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds ()), tek bir isteğin geçmesine izin verilir.İstek başarılı olursa, sigorta iptal edilir, aksi takdirde sigorta devam eder.

Hystrix