6 dk okuma
Giriş
gRPC Polly dayanıklılık mimarisi, .NET 8 mikroservislerinde servisler arası iletişim kesintilerinin kullanıcıya yansımasını azaltmayı amaçlar. Bir servis hızlı yanıt veriyor olabilir; ancak ağ gecikmesi, geçici erişim kaybı veya aşırı yük altında aynı davranışı sürdüremeyebilir. Bu rehber, gRPC istemcisine zaman aşımı, yeniden deneme, devre kesici ve ölçümleme eklerken sık yapılan tasarım hatalarını ele alır.
gRPC istemcisi ve dayanıklılık politikaları için örnek uygulamayı inceleyin.
GitHub Projesini İncele →
İçindekiler
- 1. gRPC ve dayanıklılık ihtiyacı
- 2. İstemci sözleşmesi ve süre sınırları
- 3. Polly stratejileri
- 4. Tekrarlanabilir işlemler
- 5. Ölçümleme ve yük testi
- 6. Üretime geçiş kontrolü
- Sonuç
- Güvenilir Araştırma Kaynakları
1. gRPC ve dayanıklılık ihtiyacı
gRPC, Protocol Buffers ile tanımlanan sözleşmeler üzerinden HTTP/2 tabanlı uzaktan prosedür çağrılarını destekler. İç ağdaki düşük gecikmeli servis iletişimi için uygundur. Bununla birlikte hızlı protokol seçmek, servis kesintilerini otomatik olarak çözmez. Çağrı süresi uzadığında istemci kaynakları dolabilir; eşzamanlı istek sayısı arttıkça sistem genelinde kuyruklanma oluşabilir.
Dayanıklılık tasarımının hedefi her hatayı gizlemek değildir. Beklenebilir geçici hataları kontrollü biçimde karşılamak, kalıcı hatalarda ise erken ve açıklanabilir şekilde başarısız olmaktır. Bu ayrım hem kullanıcı deneyimi hem de kapasite planlaması için kritiktir.
2. İstemci sözleşmesi ve süre sınırları
Önce proto sözleşmesindeki işlemleri salt okuma, durum değiştirme ve uzun süren akış olarak sınıflandırın. Her çağrı türünün gecikme bütçesi farklıdır. Örneğin kısa bir katalog sorgusuyla büyük bir rapor üretimini aynı zaman aşımı altında çalıştırmak doğru değildir.
gRPC deadline, çağrının tamamlanması için üst süre sınırını belirtir. İstemcide timeout stratejisiyle birlikte kullanıldığında iç içe süre sınırlarının hangisinin önce devreye gireceği açıkça tasarlanmalıdır. İptal belirtecini alt katmanlara taşıyın. İstemci çağrıyı bıraktığında sunucunun gereksiz işlem yapmasını önlemek de dayanıklılığın parçasıdır.
3. Polly stratejileri
Polly ile retry, timeout ve circuit breaker stratejileri tanımlanabilir. Yeniden deneme yalnızca geçici olarak düzelebilecek durumlarda kullanılmalıdır. Exponential backoff ve jitter, aynı anda başarısız olan istemcilerin tekrar aynı anda sunucuya yüklenmesini azaltır.
Circuit breaker, belirli başarısızlık örüntülerinde yeni çağrıları geçici olarak durdurarak arızalı bağımlılığa baskıyı sınırlar. Devre açıkken kullanıcıya uygun bir hata dönmek, bekleme süresini belirsiz biçimde uzatmaktan iyidir. Fallback ise yalnızca anlamlı bir alternatif veri veya iş davranışı varsa kullanılmalıdır; eski veya eksik veriyi güncelmiş gibi göstermek hatalıdır.
Stratejilerin sıralaması önemlidir: toplam zaman bütçesi, tek deneme süresi ve tekrar sayısı birlikte değerlendirilmelidir. Üç denemelik bir yapı, her denemede uzun süre beklerse uçtan uca gecikmeyi beklenmedik biçimde büyütebilir.
4. Tekrarlanabilir işlemler
Bir çağrı başarısız göründüğünde sunucu işlemi tamamlamış olabilir. Bu nedenle ödeme, sipariş oluşturma veya stok düşme gibi durum değiştiren işlemlere körlemesine retry eklenmemelidir. İstek kimliği ve sunucu tarafında idempotency yaklaşımı olmadan yinelenen işlemler veri tutarsızlığı doğurabilir.
Salt okuma çağrılarında yeniden deneme çoğu zaman daha güvenlidir; yine de sunucu kapasitesine ve hata türüne göre sınırlandırılmalıdır. İstemci ve sunucu ekiplerinin hangi gRPC durum kodlarında yeniden deneme yapılacağını ortak sözleşmeyle belirlemesi gerekir.
5. Ölçümleme ve yük testi
Başarılı çağrı oranını tek başına izlemek yeterli değildir. p50, p95 ve p99 gecikme değerleri; retry sayısı; circuit breaker açık kalma süresi; iptal edilen çağrılar ve sunucu tarafındaki kaynak tüketimi birlikte değerlendirilmelidir.
Normal koşullarda hızlı çalışan bir servis, bağımlılık gecikmesi eklendiğinde tamamen farklı davranabilir. Kontrollü hata enjeksiyonuyla ağ gecikmesi, kısa süreli bağlantı kaybı ve yüksek eşzamanlılık senaryolarını sınayın. Test sonuçlarını dağıtımdan önce kabul kriterlerine bağlayın.
6. Üretime geçiş kontrolü
Üretimde varsayılan politika yerine her bağımlılık için ayrı dayanıklılık profili oluşturun. Servis kritikliği, beklenen yanıt süresi ve çağrı hacmi politika değerlerini belirlemelidir. Yapılandırmaları merkezi tutun ancak tek değişiklikle tüm bağımlılıkların aynı anda etkilenmesini önleyin.
Kademeli dağıtımda hata oranı ve gecikme eğilimini gözleyin. Gerektiğinde politikayı geri alma planı hazırlayın. Bu yaklaşım, <https://www.mehmet-ozdemir.com.tr/asp-net-core-health-checks-kubernetes-icin-7-uretim-kurali/> adresindeki sağlık kontrolü yaklaşımını tamamlar; ancak sağlık kontrolü, çağrı dayanıklılığının yerine geçmez.
Sonuç
gRPC Polly dayanıklılık mimarisi, tek bir kütüphane eklemekten çok daha fazlasıdır. Doğru zaman bütçesi, sınırlı yeniden deneme, devre kesici, işlem güvenliği ve ölçümleme birlikte çalıştığında
sistem arıza anlarında daha öngörülebilir hale gelir. Başarı ölçütü hiç hata görmemek değil, hatanın etkisini kontrol edebilmek ve sistemin toparlanmasını hızlandırmaktır.
Güvenilir Araştırma Kaynakları
Microsoft Learn — gRPC in ASP.NET Core: https://learn.microsoft.com/aspnet/core/grpc/
Microsoft Learn — gRPC client factory: https://learn.microsoft.com/aspnet/core/grpc/clientfactory
Polly resmi dokümantasyon: https://www.pollydocs.org/
gRPC resmi rehber: https://grpc.io/docs/