Sdílet prostřednictvím

Zpracování přechodných chyb (vytváření Real-World Cloud Apps v Azure)

  • Článek

Rick Anderson, Tom Dykstra

Stáhnout projekt Fix It nebo Stáhnout elektronickou knihu

Elektronická kniha Building Real World Cloud Apps with Azure vychází z prezentace scotta Guthrieho. Vysvětluje 13 vzorů a postupů, které vám můžou pomoct s úspěšným vývojem webových aplikací pro cloud. Informace o elektronické knize najdete v první kapitole.

Při navrhování cloudové aplikace z reálného světa je jednou z věcí, na kterou musíte myslet, jak zvládnout dočasná přerušení služeb. Tento problém je v cloudových aplikacích jedinečný, protože jste závislí na síťových připojeních a externích službách. Často můžete mít malé závady, které se obvykle samy opravují, a pokud nejste připraveni je inteligentně zpracovat, budou mít za následek špatné prostředí pro vaše zákazníky.

Příčiny přechodných selhání

V cloudovém prostředí zjistíte, že k selhání a vyřazení databázová připojení dochází pravidelně. Částečně je to proto, že v porovnání s místním prostředím, kde váš webový a databázový server mají přímé fyzické připojení, procházíte více nástroji pro vyrovnávání zatížení. V některých případech, když jste závislí na službě s více tenanty, se volání této služby zpomalí nebo vyprší časový limit, protože někdo jiný, kdo tuto službu používá, ji výrazně zasáhne. V jiných případech můžete být uživatelem, který službu využívá příliš často, a služba vás záměrně omezuje – zamítá připojení – aby se zabránilo nežádoucímu ovlivnění jiných tenantů služby.

Použití inteligentní logiky opakování/re-off ke zmírnění dopadu přechodných selhání

Místo vyvolání výjimky a zobrazení nedostupné nebo chybové stránky zákazníkovi můžete rozpoznat chyby, které jsou obvykle přechodné, a automaticky opakovat operaci, která způsobila chybu, v naději, že za chvíli budete úspěšní. Ve většině případů bude operace při druhém pokusu úspěšná a z chyby se zotavíte, aniž by zákazník věděl, že došlo k problému.

Logiku inteligentního opakování můžete implementovat několika způsoby.

  • Skupina Microsoft Patterns & Practices má blok aplikací pro zpracování přechodných chyb, který udělá všechno za vás, pokud pro přístup k SQL Database používáte ADO.NET (ne prostřednictvím Entity Frameworku). Stačí nastavit zásadu pro opakování – kolikrát se má dotaz nebo příkaz opakovat a jak dlouho se má čekat mezi pokusy – a zabalíte kód SQL do bloku using .

    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 také podporuje azure In-Role Cache a Service Bus.

  • Když používáte Entity Framework, obvykle nepracuje přímo s připojeními SQL, takže tento balíček Patterns and Practices nemůžete použít, ale Entity Framework 6 tento druh logiky opakování sestaví přímo do architektury. Podobným způsobem zadáte strategii opakování a EF ji použije při každém přístupu k databázi.

    Abychom mohli tuto funkci použít v aplikaci Fix It, stačí přidat třídu odvozenou z DbConfiguration a zapnout logiku opakování.

    // 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());
    }
}

    U SQL Database výjimek, které architektura identifikuje jako obvykle přechodné chyby, dává zobrazený kód EF pokyn, aby operaci zkusil opakovat až 3krát s exponenciální prodlevou mezi opakováním a maximálním zpožděním 5 sekund. Exponenciální re-off znamená, že po každém neúspěšném opakování bude čekat delší dobu, než to zkusí znovu. Pokud tři pokusy v řadě selžou, dojde k výjimce. Následující část o jističech vysvětluje, proč chcete exponenciální rekoncenci a omezený počet opakování.

    Při používání služby Azure Storage můžete mít podobné problémy jako aplikace Fix It pro objekty blob a rozhraní API klienta úložiště .NET už implementuje stejný druh logiky. Stačí zadat zásadu opakování, nebo to ani nemusíte dělat, pokud jste spokojeni s výchozím nastavením.

Jističe

Existuje několik důvodů, proč nechcete opakovat příliš mnohokrát za příliš dlouhou dobu:

  • Příliš mnoho uživatelů, kteří neustále opakují neúspěšné požadavky, může snížit možnosti ostatních uživatelů. Pokud všechny miliony lidí vytvářejí opakované žádosti o opakování, můžete vázat fronty volání služby IIS a bránit aplikaci v poskytování služeb, které by jinak mohla úspěšně zpracovat.
  • Pokud to všichni opakují kvůli selhání služby, může být ve frontě tolik požadavků, že se služba při zahájení obnovy zahlcená.
  • Pokud je příčinou chyby omezování a existuje časové období, které služba používá k omezování, další opakování by mohlo toto okno přesunout a způsobit pokračování omezování.
  • Je možné, že uživatel čeká na vykreslení webové stránky. To, že lidé budou čekat příliš dlouho, může být obtěžující, než relativně rychle jim radí, aby to zkusili znovu později.

Exponenciální rekonvence řeší některé z těchto problémů omezením frekvence opakovaných pokusů, které služba může z vaší aplikace získat. Potřebujete ale také jističe: To znamená, že při určité prahové hodnotě opakování vaše aplikace zastaví opakování a provede nějakou jinou akci, například jednu z následujících akcí:

  • Vlastní záložní řešení. Pokud nemůžete získat cenu akcií z Reuters, možná ji můžete získat od Bloomberg; nebo pokud nemůžete získat data z databáze, možná je můžete získat z mezipaměti.
  • Selhání je tiché. Pokud ze služby potřebujete pro vaši aplikaci všechno nebo nic, stačí vrátit hodnotu null, když data nemůžete získat. Pokud zobrazujete úlohu Opravit a služba Blob Service nereaguje, můžete podrobnosti úlohy zobrazit bez obrázku.
  • Selhání rychle. Chyba uživatele, aby se zabránilo zahltění služby opakovanými požadavky, které by mohly způsobit přerušení služby pro ostatní uživatele nebo prodloužit časové období omezování. Můžete zobrazit popisnou zprávu "zkuste to znovu později".

Neexistují žádné zásady opakování pro jednu velikost, která by vyhovovala všem. V asynchronním pracovním procesu na pozadí můžete opakovat vícekrát a čekat déle než v synchronní webové aplikaci, kde uživatel čeká na odpověď. Mezi opakováními pro relační databázovou službu můžete čekat déle než u služby mezipaměti. Tady je několik ukázkových doporučených zásad opakování, které vám poskytnou představu o tom, jak se můžou čísla lišit. ("Fast First" znamená, že před prvním opakováním nedojde ke zpoždění.

Ukázkové zásady opakování

Pokyny k SQL Database zásadám opakování najdete v tématu Řešení přechodných chyb a chyb připojení k SQL Database.

Souhrn

Strategie opakování/re-off může pomoct, aby dočasné chyby ve většině případů nebyly pro zákazníka neviditelné. Microsoft poskytuje architektury, které můžete použít k minimalizaci práce při implementaci strategie bez ohledu na to, jestli používáte ADO.NET, Entity Framework nebo službu Azure Storage.

V další kapitole se podíváme na to, jak zlepšit výkon a spolehlivost pomocí distribuovaného ukládání do mezipaměti.

Zdroje informací

Další informace naleznete v následujících zdrojích:

Dokumentace

Videa

Ukázka kódu

PředchozíDalší