Fault Tolerance ve Resiliency İçin Bazı Yazılım Çözümleri (Design Pattern)

Giriş
Bu yazıdaki kavramlar
 1. Fault Tolerance - Arızaya Dayanıklılık
 2. Resiliency - Dirençlilik
için kullanılabilir.

1. Cache Pattern

Açıklaması şöyle. Yavaş bir sistemi daha da yavaşlatmamak için bazı cevaplar önbelleğe alınabilir.

Slow backend systems are often misunderstood beasts, a bit like Ogres. The reason for their slowness or unavailability is often down to their business criticalness. These systems are bombarded with requests more than they are provisioned to handle, resulting in these systems being slow or unavailable. The solutions I’ve proposed here are based on two factors. 

- One, reduce the number of requests hitting the backend. 

- Two, avoid loading the backend service when it’s already overloaded (avoid peak times).

Although you might not be able to get rid of the beast, you might learn to live with it.

Bir backend sisteme önbellek ilave ederken izlenebilecek akışlar farkı farklı olabilir.

1. 1 Soru Soran Sadece Cache Sistemi Bilir

Açıklaması şöyle.

The first option would be the simplest and has no dependency on the backend service. When the cache node is requested for information it does not have, it will fetch it from the slow backend, update the cache and return it to the requester.

1. 2 Soru Soran Hem Cache Hem de Backend Sistemi Bilir

Bu akışta soru soran istediği cevabı cache sistemde bulamazsa, backend sisteme sorar.

1.3 Her iki akışta da şuna dikkat etmek lazım

Açıklaması şöyle. Yani backend ise cache arasında bir bağlantı olmalı

... the cache gets updated whenever the backend data gets updated. This requires an integration with the backend service, and the backend service should be equipped to either call an API on the cache node or should have logs that could be processed to extract the required information.

2. Retry Design Pattern
Retry Design Pattern yazısına taşıdım

3. Timeout Yöntemi

Timeout Pattern yazısına taşıdım

4. Load Balancing and Failover

Bu konuyu High Availability - Yüksek Süreklilik yazısına taşıdım

5. Circuit Breaker Pattern
Circuit Breaker Pattern yazısına taşıdım

6. Dead Letter Channel Yöntemi

Dead-Letter Channel Örüntüsü yazısına taşıdım.

7. Saga Yöntemi
Saga Örüntüsü yazısına taşıdım.

8. Bulkhead Yöntemi

Şeklen şöyle. Burada geminin bölmelere ayrıldığı görülebilir. Bölme duvarlarına bulkhead deniliyor. Böylece eğer gemi bir bölmeden yara alsa bilebölmeler sayesinde batmıyor.

Gemideki bu kullanıcımı yazılım dünyasına taşıyan bir örnek şöyle. A servisi hem kendi başına çalışabilen hem B'yi kullanan servisler sunuyor. Eğer B yavaşlarsa, tüm A'nın yavaşlamaması gerekir. Bu yüzden B'ye ayrılan kaynaklar sınırlandırılıyor.

let's assume that there are 2 services A and B. Some of the APIs of A depends on B. For some reason, B is very slow. So, When we get multiple concurrent requests to A which depends on B, A’s performance will also get affected. It could block A’s threads. Due to that A might not be able to serve other requests which do NOT depend on B. So, the idea here is to isolate resources / allocate some threads in A for B. So that We do not consume all the threads of A and prevent A from hanging for all the requests!

Bulkhead için Resilience4j @BulkHead Anotasyonu, Hystrix kullanılabilir.

Örnek

Resilience4j kullanan bir örnek burada

9. Rate Limiter Yöntemi

Resilience4j @RateLimiter Anotasyonu yazısına taşıdım