Více než rok navrhování a přesunu několika služeb z Azure Cloud Service do Service Fabric mě naučil několik věcí, které je důležité mít na paměti při vytváření nebo refaktoringu mikroslužeb hostovaných v prostředí Service Fabric. Nezapomeňte, že vzory Service Fabric jsou úzce propojeny s rozhraním .NET, které prošlo masivní změnou paradigmatu. Abyste mohli kódovat solidní služby, musíte mít aktuální informace alespoň o asynchronním programování.
Jedno selhání celého clusteru jsem zažil, protože jsem podcenil důležitost jednoho detailu. Služba běžela půl roku bez výpadků. Pak najednou začal oscilovat (zpomalení jedné části systému a následný dominový efekt) a nakonec se vypnul (logování indikovalo, že se kód neprovádí). Portál Azure mě informoval, že Your cluster version has expired. Go to ‘Fabric upgrades’ to upgrade to a supported version.
Bylo to překvapení, protože můj cluster byl nastavený na režim upgradu automatic. Moje verze clusteru se zasekla na verzi 5.5.216.0, i když poslední dostupná verze v té době byla 5.7.198.9494.
Můj pokus o upgrade na nejnovější verzi přepnutím do režimu manual nebyl úspěšný.
Později jsem zjistil, že každý pokus o upgrade byl kvůli tomuto selhání vrácen zpět:
Toto upozornění znamená, že CancellationToken zadaný jako argument metody RunAsync je ignorován. (Toto upozornění se týká stavových nebo bezstavových spolehlivých služeb. Služba actor se řídí vzorem jedné položky.) Důvodem, proč je zrušení tak důležité, je to, že Service Fabric přesouvá vaše služby z uzlu, který se připravuje na upgrade. Pokud zrušení trvá velmi dlouho, může doba zrušení vynásobená počtem upgradovacích domén překročit časový limit pro upgrade prostředí. To způsobí selhání pokusu o upgrade.
Service Fabric dynamicky vyvažuje vaše služby mezi uzly clusteru podle paměťových a výpočetních charakteristik. Tento mechanismus je také paralyzován, když služba zamrzne na uzlu. Dalším důsledkem je blokování monitorovaného upgradu . Pokud aktuální verzi služby nelze vypnout, nelze ji nahradit vyšší verzí.
Úkolem programátora je naprogramovat program tak, aby se CancellationToken rozšířilo do každého možného očekávaného volání. (Pokud komunikujete přes protokol HTTP, měli byste použít HttpClient, protože HttpWebRequest i WebClient nepřijímají CancellationToken jako parametr.)
Někdy se vám metoda CancellationToken.ThrowIfCancellationRequested může hodit například v těle dlouhotrvajících smyček. Nezáleží na tom, zda je služba ukončena vyvoláním výjimky nebo ukončením metody RunAsync. Obě možnosti jsou správné.
Když je požadováno zrušení, je hozen OperationCanceledException. Pokud protokolujete výjimky v klauzuli catch, můžete chtít vyloučit tento druh výjimky. Můžete to udělat mnoha způsoby, například takto:
try {
...
cancellationToken.ThrowIfCancellationRequested();
...
} catch (Exception ex) when (!cancellationToken.IsCancellationRequested) {
...
}