Hystrix

• Hystrix, dağınık sistemlerde, servisler arasında oluşabilecek gecikme ve hata durumlarında sistemin bu olaylara karşı toleransını arttırmak amacıyla bazı stratejilerin uygulanabilirliğine imkan sağlar. Bunu hizmetler arasındaki erişim noktalarını izole ederek, bunlar arasında kademeli arızaları durdurarak ve dönüş seçenekleri sunarak yapar ve genel esnekliği arttırır.

• İstenmeyen bir durum oluştuğunda, bu durumun zincirleme şekilde başka durumlara yol açmadan bir an önce kontrol edilmesi, olabildiğince hızlı tespit ve kurtarma yapılmasını amaçlar ve bu seri kontrol eğilimi ile de gerçek zamana yakın bir monitörleme imkanı sunar.

• Dağıtık mimaride çok fazla bağımlılık bulunur ve bunlar bir aşamada mutlaka hatalı duruma düşerler. Hystrix bu bağımlılıklar arasında bir izolasyon yaratarak 'loose coupling' hedefler.

https://github.com/Netflix/Hystrix

Örneğin 10 servisten oluşan ve her servisin has 99.99% uptime sahip olduğu bir uygulamada,

99.99¹⁰ = 99.9% uptime

0.3% of 1 billion requests = 3,000,000 failures

2+ hours downtime/month even if all dependencies have excellent uptime.

• Herhangi bir üçüncü parti bağımlılığında oluşan bir gecikme, artan talep ile sistemin bütün kaynaklarını kullanmaya başlayıp, sistem genelinde bir duraksamaya sebep olacaktır.

İçerdiği Tasarım Prensipleri

• Bir bağımlılığın kaynakların kullanımını domine etmemesi.
• En kısa sürede sistemi hata durumuna düşürerek, cevap oluşturup yükten kurtulmak.
• Hata durumunda en uygun yerde bir geri dönüş(fallback) mantığı gerçekleştirerek, kullanıcıyı korumak.
• Çeşitli izolasyon teknikleri(bulkhead, swimlane, ve circuit breaker) ile bağımlılığı azaltmak.
• Hatanın keşfinde ve kurtarılmasında optimizasyon.

Nasıl Gerçekleştiriliyor?

• Harici sistemlere (veya "bağımlılıklara") yapılan tüm çağrıları, tipik olarak ayrı bir thread içinde yürütülen bir HystrixCommand veya HystrixObservableCommand nesnesine sarmak (Bu açıdan Command Pattern benzerliği vardır).

• Bir isteğe cevap geciktiğinde, belli bir eşik değerin üzerinde gecikme oluşursa time-out atılması sağlanır.

• Her dependency için bir thread-pool oluşturulur ve eğer bu pool gelen istekler ile dolarsa istek anında reddedilir ve gereksiz bekleme ve kaynak harcanması engellenir.

• Bir servisin hata yüzdesi bir eşiği geçerse, belirli bir servise yönelik tüm istekleri belirli bir süre boyunca manuel olarak veya otomatik olarak durdurmak için bir circuit breaker kullanır.

• Çağrıları sarmalayan yapılar içerisinde olası hatalı durumlarda izlenecek mantık gerçekleştirilerek sağlam ve kullanışlı bir sistem oluşturulur.

Bulkhead

• Her bir tipteki istek için bir thread pool oluşturup, bir istek tipinin bütün kaynakları kullanıp diğer requestlerin de gecikmesine engel olmasını engeller.

Circuit Breaker

• Bir thread pool içerisinde, request sayısı ve thread-pool boyutu oranı artarak belli bir eşik değeri üzerine çıkarsa, servise giden bağlantının kesilip(circuit-open) isteklerin anında cevaplanması ve gecikmenin engellenmesini sağlar.

• Aynı mantık geciken cevaplardan ziyade, hata oluşan isteklerde de uygulanabilir. Belli bir değerin üzerinde hata oluştuğunda bağlantı kırılarak, fazla sayıda hatanın oluşması engellenir ve gerekli aksiyonların alınabilmesi için imkan oluşturulur.

    @SyncCallLogger
    @Override
    @HystrixCommand(fallbackMethod = "sorgulaTahakkukFallbackMethod",
            commandProperties = {@HystrixProperty(name = "execution.isolation.strategy", value = "SEMAPHORE")})
    public GumrukEttnSorgulaResponseDTO sorgulaTahakkukGumrukten(GumrukEttnSorgulaRequestDTO gumrukEttnSorgulaRequestDTO) {
        return restTemplate.postForObject(gumrukConfiguration.getMaliyews().getSorgulaTahakkuk(), gumrukEttnSorgulaRequestDTO, GumrukEttnSorgulaResponseDTO.class);
    }

Hytrix sistemlerde gereksiz işlemlerin önlenmesi için iyi bir çözüm ancak artık bakımı yapılmadığı için yakın zamanda benzerlerinin arkasında kalması ve talepleri yerine getirememesi durumu da olası. Kullanımı durumunda bu durum göz önünde bulundurulmalı.