Geçici Hata İşleme (Azure ile Real-World Cloud Apps Oluşturma)

  • Makale

Tarafından Rick Anderson, Tom Dykstra

Fix It Project'i indirin veya E-kitap indirin

Azure ile Gerçek Dünya Bulut Uygulamaları Oluşturma e-kitabı, Scott Guthrie tarafından geliştirilen bir sunuyu temel alır. Bulut için web uygulamalarını başarıyla geliştirmenize yardımcı olabilecek 13 desen ve uygulama açıklanmaktadır. E-kitap hakkında bilgi için ilk bölüme bakın.

Gerçek bir bulut uygulaması tasarlarken, düşünmeniz gereken şeylerden biri de geçici hizmet kesintilerini nasıl ele alacağınızdır. Ağ bağlantılarına ve dış hizmetlere çok bağımlı olduğunuzdan bu sorun bulut uygulamalarında benzersiz olarak önemlidir. Genellikle kendi kendini iyileştiren küçük hatalar alabilirsiniz ve bunları akıllıca işlemeye hazır değilseniz, müşterileriniz için kötü bir deneyime neden olur.

Geçici hataların nedenleri

Bulut ortamında, başarısız ve bırakılan veritabanı bağlantıları düzenli aralıklarla gerçekleştiğini göreceksiniz. Bunun bir nedeni, web sunucunuzun ve veritabanı sunucunuzun doğrudan fiziksel bağlantıya sahip olduğu şirket içi ortama kıyasla daha fazla yük dengeleyiciden geçmenizdir. Ayrıca, bazen çok kiracılı bir hizmete bağımlı olduğunuzda, hizmeti kullanan başka biri ağır bir şekilde bastığından hizmete yönelik çağrıların yavaşladığını veya zaman aşımına uğradığını görürsünüz. Diğer durumlarda, hizmetle çok sık karşılaşan kullanıcı olabilirsiniz ve hizmet, hizmetin diğer kiracılarını olumsuz yönde etkilemenizi önlemek için sizi kasten kısıtlar, bağlantıları reddeder.

Geçici hataların etkisini azaltmak için akıllı yeniden deneme/geri alma mantığını kullanma

Bir özel durum oluşturup müşterinize kullanılamayan veya hata sayfası görüntülemek yerine, genellikle geçici olan hataları tanıyabilir ve hatayla sonuçlanan işlemi otomatik olarak yeniden deneyebilir ve çok geçmeden başarılı olacağınızı umabilirsiniz. Çoğu zaman işlem ikinci denemede başarılı olur ve müşterinin bir sorun olduğunu fark etmeden hatadan kurtarmanız gerekir.

Akıllı yeniden deneme mantığını uygulamanın birkaç yolu vardır.

  • Microsoft Patterns & Practices grubu, SQL Veritabanı erişimi için ADO.NET kullanıyorsanız (Entity Framework aracılığıyla değil) sizin için her şeyi sağlayan Geçici Hata İşleme Uygulama Bloğuna sahiptir. Yeniden denemeler için bir ilke ayarlamanız (sorguyu veya komutu kaç kez yeniden deneyecek ve denemeler arasında ne kadar bekleneceği) ve SQL kodunuzu bir using bloğuna sarmalamanız gerekir.

    public void HandleTransients()
{
    var connStr = "some database";
    var _policy = RetryPolicy.Create < SqlAzureTransientErrorDetectionStrategy(
        retryCount: 3,
        retryInterval: TimeSpan.FromSeconds(5));

    using (var conn = new ReliableSqlConnection(connStr, _policy))
    {
        // Do SQL stuff here.
    }
}

    TFH, Azure In-Role Önbelleği ve Service Bus'ı da destekler.

  • Entity Framework kullandığınızda genellikle doğrudan SQL bağlantılarıyla çalışmazsınız, bu nedenle bu Desenler ve Uygulamalar paketini kullanamazsınız, ancak Entity Framework 6 bu tür bir yeniden deneme mantığını doğrudan çerçevede oluşturur. Benzer şekilde yeniden deneme stratejisini belirtirsiniz ve ardından EF veritabanına her eriştiğinde bu stratejiyi kullanır.

    Bu özelliği Düzelt uygulamasında kullanmak için tek yapmamız gereken DbConfiguration'dan türetilen bir sınıf eklemek ve yeniden deneme mantığını açmaktır.

    // EF follows a Code based Configuration model and will look for a class that
// derives from DbConfiguration for executing any Connection Resiliency strategies
public class EFConfiguration : DbConfiguration
{
    public EFConfiguration()
    {
        AddExecutionStrategy(() => new SqlAzureExecutionStrategy());
    }
}

    Çerçevenin genellikle geçici hatalar olarak tanımladığını SQL Veritabanı özel durumlar için, gösterilen kod EF'ye işlemi yeniden denemeler arasında üstel geri alma gecikmesi ve en fazla 5 saniyelik gecikme süresiyle 3 kez yeniden denemesini bildirir. Üstel geri alma, her başarısız yeniden denemeden sonra yeniden denemeden önce daha uzun bir süre bekleyeceği anlamına gelir. Bir satırda üç deneme başarısız olursa, bir özel durum oluşturur. Devre kesiciler hakkında aşağıdaki bölümde neden üstel geri çekilme ve sınırlı sayıda yeniden deneme istediğinizi açıklanmaktadır.

    Azure Depolama hizmetini kullanırken, Düzelt uygulamasının Bloblar için yaptığı ve .NET depolama istemcisi API'sinin aynı mantık türünü zaten uyguladığı gibi benzer sorunlarla karşılaşabilirsiniz. Yalnızca yeniden deneme ilkesini belirtirsiniz veya varsayılan ayarlardan memnunsanız bunu yapmanız bile gerekmez.

Devre kesiciler

Çok uzun bir süre boyunca çok fazla kez yeniden denemek istememek için birkaç neden vardır:

  • Başarısız istekleri kalıcı olarak yeniden deneyen çok fazla kullanıcı diğer kullanıcıların deneyimini düşürebilir. Milyonlarca kişi yinelenen yeniden deneme isteklerinde bulunursa IIS dağıtım kuyruklarını bağlayıp uygulamanızın aksi takdirde başarılı bir şekilde işleyebileceği isteklere hizmet vermesini engelleyebilirsiniz.
  • Bir hizmet hatası nedeniyle herkes yeniden denerse, o kadar çok istek kuyruğa alınmış olabilir ki hizmet kurtarılmaya başladığında su basabilir.
  • Hata azaltmadan kaynaklanıyorsa ve hizmetin azaltma için kullandığı bir zaman penceresi varsa, devam eden yeniden denemeler söz konusu pencereyi dışarı taşıyabilir ve azaltmanın devam etmesini sağlayabilir.
  • Web sayfasının işlenmesini bekleyen bir kullanıcınız olabilir. İnsanları çok uzun süre bekletmek, daha sonra yeniden denemelerini nispeten hızlı bir şekilde tavsiye eden daha rahatsız edici olabilir.

Üstel geri alma, bir hizmetin uygulamanızdan alabildiği yeniden deneme sıklığını sınırlayarak bu sorunlardan bazılarını giderir. Ancak devre kesicileriniz de olması gerekir: Bu, belirli bir yeniden deneme eşiğinde uygulamanızın yeniden denemeyi durdurup aşağıdakilerden biri gibi başka bir işlem yaptığı anlamına gelir:

  • Özel geri dönüş. Reuters'ten hisse senedi fiyatı alamazsanız, belki Bloomberg'den alabilirsiniz; veya veritabanından veri alamıyorsanız, verileri önbellekten alabilirsiniz.
  • Sessiz başarısız. Bir hizmetten ihtiyacınız olan şey uygulamanız için tamamen veya hiçbir şey değilse, verileri alamıyorsanız null değerini döndürmeniz yeterlidir. Bir Düzelt görevi görüntülüyorsanız ve Blob hizmeti yanıt vermiyorsa, görev ayrıntılarını görüntü olmadan görüntüleyebilirsiniz.
  • Hızlı başarısız olur. Hizmette başka kullanıcılar için hizmet kesintisine neden olabilecek veya azaltma penceresini genişletebilecek yeniden deneme istekleriyle dolup taşmasını önlemek için kullanıcıyı hataya uğratır. Kolay bir "daha sonra yeniden deneyin" iletisi görüntüleyebilirsiniz.

Tümüne uyan tek bir yeniden deneme ilkesi yoktur. Zaman uyumsuz bir arka plan çalışanı işleminde, kullanıcının yanıt beklediği zaman uyumlu bir web uygulamasındakinden daha fazla kez yeniden deneyebilir ve daha uzun süre bekleyebilirsiniz. İlişkisel veritabanı hizmeti için yeniden denemeler arasında önbellek hizmetinde beklediğinize göre daha uzun süre bekleyebilirsiniz. Aşağıda, sayıların nasıl değişebileceğine ilişkin bir fikir vermek için önerilen bazı örnek yeniden deneme ilkeleri yer alır. ("Önce Hızlı", ilk yeniden denemeden önce gecikme olmaması anlamına gelir.

Örnek yeniden deneme ilkeleri

SQL Veritabanı yeniden deneme ilkesi kılavuzu için bkz. SQL Veritabanı geçici hataları ve bağlantı hatalarını giderme.

Özet

Yeniden deneme/geri alma stratejisi, geçici hataların çoğu zaman müşteriye görünmez olmasına yardımcı olabilir ve Microsoft, ADO.NET, Entity Framework veya Azure Depolama hizmetini kullanırken strateji uygulayan çalışmanızı en aza indirmek için kullanabileceğiniz çerçeveler sağlar.

Sonraki bölümde, dağıtılmış önbelleğe alma özelliğini kullanarak performansı ve güvenilirliği nasıl geliştirebileceğimizi inceleyeceğiz.

Kaynaklar

Daha fazla bilgi için aşağıdaki kaynaklara bakın:

Belgeler

Videolar

Kod örneği

ÖncekiSonraki