Share via

Osvědčené postupy pro návrhy aplikace Azure Service Fabric

  • Článek

Tento článek obsahuje osvědčené postupy pro vytváření aplikací a služeb v Azure Service Fabric.

Seznámení s Service Fabric

Pokyny k návrhu aplikací

Seznamte se s obecnou architekturou aplikací Service Fabric a jejich aspekty návrhu.

Volba brány rozhraní API

Použijte službu brány rozhraní API, která komunikuje s back-endovými službami, které je pak možné škálovat na více instancí. Nejběžnější používané služby brány rozhraní API jsou:

Bezstavové služby

Doporučujeme, abyste vždy začali vytvářením bezstavových služeb pomocí Reliable Services a uložením stavu do databáze Azure, Azure Cosmos DB nebo Azure Storage. Externalizovaný stav je pro většinu vývojářů známý přístup. Tento přístup také umožňuje využívat možnosti dotazů v úložišti.

Kdy používat stavové služby

Zvažte stavové služby, pokud máte scénář pro nízkou latenci a potřebujete zachovat data blízko výpočetních prostředků. Mezi příklady scénářů patří zařízení digitálního dvojčete IoT, stav hry, stav relace, ukládání dat do mezipaměti z databáze a dlouhotrvající pracovní postupy pro sledování volání do jiných služeb.

Rozhodnutí o časovém rámci uchovávání dat:

  • Data uložená v mezipaměti. Ukládání do mezipaměti se používá v případech, kdy dochází k problému s latencí externích úložišť. Použijte stavovou službu jako vlastní mezipaměť dat nebo zvažte použití opensourcové služby SoCreate Service Fabric Distributed Cache. V tomto scénáři nemusíte mít obavy, pokud ztratíte všechna data v mezipaměti.
  • Časová data. V tomto scénáři potřebujete uchovávat data v blízkosti výpočetních prostředků po dobu latence, ale můžete si dovolit ztratit data v havárii. Například v mnoha řešeních IoT se data musí blížit výpočetním prostředkům, například při výpočtu průměrné teploty za posledních pár dnů, ale pokud se tato data ztratí, konkrétní datové body zaznamenané nejsou tak důležité. V tomto scénáři se také obvykle nezajímáte o zálohování jednotlivých datových bodů. Zálohujete pouze vypočítané průměrné hodnoty, které se pravidelně zapisují do externího úložiště.
  • Dlouhodobá data. Spolehlivé kolekce můžou trvale ukládat vaše data. V tomto případě se ale potřebujete připravit na zotavení po havárii, včetně konfigurace pravidelných zásad zálohování pro vaše clustery. V důsledku toho nakonfigurujete, co se stane, když dojde ke zničení clusteru v havárii, kde byste museli vytvořit nový cluster a jak nasadit nové instance aplikací a obnovit z nejnovější zálohy.

Úspora nákladů a zlepšení dostupnosti:

  • Náklady můžete snížit pomocí stavových služeb, protože vám neúčtují náklady na přístup k datům a transakce ze vzdáleného úložiště a protože nepotřebujete používat jinou službu, jako je Azure Cache for Redis.
  • Použití stavových služeb primárně pro úložiště a ne pro výpočetní prostředky je nákladné a nedoporučujeme ho. Stavové služby si můžete představit jako výpočetní prostředky s levným místním úložištěm.
  • Odebráním závislostí na jiných službách můžete zlepšit dostupnost služby. Správa stavu s vysokou dostupností v clusteru vás izoluje od jiných výpadků služeb nebo problémů s latencí.

Jak pracovat s Reliable Services

Service Fabric Reliable Services umožňuje snadno vytvářet bezstavové a stavové služby. Další informace najdete v úvodu do Reliable Services.

  • Vždy respektujte token zrušení v RunAsync() metodě pro bezstavové a stavové služby a metodu ChangeRole() stavových služeb. Pokud ne, Service Fabric neví, jestli je možné službu zavřít. Pokud například token zrušení nedotknete, může dojít k mnohem delší době upgradu aplikace.
  • Včas otevřete a zavřete naslouchací procesy komunikace a respektujte tokeny zrušení.
  • Nikdy nekombinujte synchronizační kód s asynchronním kódem. Například nepoužívejte .GetAwaiter().GetResult() v asynchronních voláních. Asynchronní použití celého zásobníku volání.

Jak pracovat s Reliable Actors

Service Fabric Reliable Actors umožňuje snadno vytvářet stavové virtuální aktéry. Další informace najdete v úvodu do Reliable Actors.

  • Vážně zvažte použití pub/sub messaging mezi vašimi aktéry pro škálování aplikace. Mezi nástroje, které tuto službu poskytují, patří opensourcová služba SoCreate Service Fabric Pub/Sub a Azure Service Bus.
  • Co nejpodrobnější stav objektu actor.
  • Spravujte životní cyklus herce. Odstraňte aktéry, pokud je nebudete znovu používat. Odstranění nepotřebných objektů actor je zvlášť důležité, když používáte poskytovatele nestálého stavu, protože veškerý stav je uložený v paměti.
  • Vzhledem k jejich souběžnosti založené na turn jsou aktéři nejvhodnější použít jako nezávislé objekty. Nevytvádějte grafy multi-actor, synchronní volání metod (z nichž každá se pravděpodobně stane samostatným síťovým voláním) nebo vytvářet požadavky cyklického objektu actor. To výrazně ovlivní výkon a škálování.
  • Nekombinujte synchronizační kód s asynchronním kódem. Používejte asynchronní konzistentně, abyste zabránili problémům s výkonem.
  • Nevytvávejte dlouhotrvající hovory v aktérech. Dlouhotrvající volání budou blokovat další volání stejného objektu actor kvůli souběžnosti na základě turn.
  • Pokud komunikujete s jinými službami pomocí vzdálené komunikace Service Fabric a vytváříte objekt pro ServiceProxyFactoryvytváření objektů na úrovni služby actor a ne na úrovni objektu actor.

Diagnostika aplikací

Důkladně si promyslete přidání protokolování aplikace do volání služeb. Pomůže vám diagnostikovat scénáře, ve kterých se služby vzájemně volají. Například když A volá B volání jazyka C, volání může selhat kdekoli. Pokud nemáte dostatek protokolování, je obtížné diagnostikovat selhání. Pokud služby protokolují příliš mnoho kvůli svazkům volání, nezapomeňte alespoň protokolovat chyby a upozornění.

Pokyny k návrhu v Azure