Škálování v Service Fabric

  • Článek

Azure Service Fabric usnadňuje vytváření škálovatelných aplikací tím, že spravuje služby, oddíly a repliky na uzlech clusteru. Spouštění mnoha úloh na stejném hardwaru umožňuje maximální využití prostředků, ale zároveň poskytuje flexibilitu, pokud jde o to, jak se rozhodnete škálovat úlohy. Toto video channel 9 popisuje, jak můžete vytvářet škálovatelné aplikace mikroslužeb:

Škálování v Service Fabric se provádí několika různými způsoby:

  1. Škálování vytvořením nebo odebráním instancí bezstavové služby
  2. Škálování vytvořením nebo odebráním nových pojmenovaných služeb
  3. Škálování vytvořením nebo odebráním nových pojmenovaných instancí aplikací
  4. Škálování pomocí dělených služeb
  5. Škálování přidáním a odebráním uzlů z clusteru
  6. Škálování pomocí metrik Resource Manager clusteru

Škálování vytvořením nebo odebráním instancí bezstavové služby

Jeden z nejjednodušších způsobů škálování v rámci Service Fabric funguje s bezstavovými službami. Když vytvoříte bezstavovou službu, získáte možnost definovat InstanceCount. InstanceCount definuje, kolik spuštěných kopií kódu této služby se vytvoří při spuštění služby. Řekněme například, že v clusteru je 100 uzlů. Řekněme také, že služba je vytvořená s InstanceCount 10. Během běhu může být všech těchto 10 spuštěných kopií kódu příliš zaneprázdněných (nebo nebylo dostatečně zaneprázdněno). Jedním ze způsobů, jak škálovat úlohu, je změnit počet instancí. Například některá část kódu monitorování nebo správy může změnit stávající počet instancí na 50 nebo 5 v závislosti na tom, jestli je potřeba škálovat nebo snížit kapacitu úloh na základě zatížení.

C#:

StatelessServiceUpdateDescription updateDescription = new StatelessServiceUpdateDescription(); 
updateDescription.InstanceCount = 50;
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/app/service"), updateDescription);

PowerShell:

Update-ServiceFabricService -Stateless -ServiceName $serviceName -InstanceCount 50

Použití dynamického počtu instancí

Konkrétně pro bezstavové služby nabízí Service Fabric automatický způsob, jak změnit počet instancí. To umožňuje službě dynamicky škálovat s počtem uzlů, které jsou k dispozici. Způsob, jak se k tomuto chování vyjádřit, je nastavit počet instancí = -1. InstanceCount = -1 je instrukce pro Service Fabric, která říká "Spustit tuto bezstavovou službu na každém uzlu". Pokud se počet uzlů změní, Service Fabric automaticky změní počet instancí tak, aby se shodovaly, a zajistí, aby služba běžela na všech platných uzlech.

C#:

StatelessServiceDescription serviceDescription = new StatelessServiceDescription();
//Set other service properties necessary for creation....
serviceDescription.InstanceCount = -1;
await fc.ServiceManager.CreateServiceAsync(serviceDescription);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName -Stateless -PartitionSchemeSingleton -InstanceCount "-1"

Škálování vytvořením nebo odebráním nových pojmenovaných služeb

Pojmenovaná instance služby je konkrétní instance typu služby (viz životní cyklus aplikace Service Fabric) v rámci některé pojmenované instance aplikace v clusteru.

Nové pojmenované instance služby je možné vytvořit (nebo odebrat) s tím, jak jsou služby více nebo méně zaneprázdněné. To umožňuje rozprostřít požadavky do více instancí služeb, což obvykle umožňuje snížit zatížení stávajících služeb. Při vytváření služeb Resource Manager cluster Service Fabric umístí služby do clusteru distribuovaným způsobem. Konkrétní rozhodnutí se řídí metrikami v clusteru a dalšími pravidly umístění. Služby je možné vytvořit několika různými způsoby, ale nejběžnější jsou buď prostřednictvím akcí správy, jako je volání New-ServiceFabricService, nebo voláním CreateServiceAsynckódu . CreateServiceAsync může být dokonce volána z jiných služeb spuštěných v clusteru.

Dynamické vytváření služeb je možné použít v nejrůznějších scénářích a je to běžný vzor. Představte si například stavovou službu, která představuje konkrétní pracovní postup. Volání představující práci se budou zobrazovat této službě a tato služba provede kroky pro tento pracovní postup a zaznamenává průběh.

Jak byste mohli tuto konkrétní službu škálovat? Služba může mít v nějaké podobě více tenantů a přijímat volání a zahajovat kroky pro mnoho různých instancí stejného pracovního postupu najednou. To ale může kód zkompilovat, protože teď se musí starat o mnoho různých instancí stejného pracovního postupu, a to vše v různých fázích a od různých zákazníků. Zpracování více pracovních postupů současně také nevyřeší problém se škálováním. Důvodem je to, že v určitém okamžiku bude tato služba spotřebovávat příliš mnoho prostředků, aby se vešla na konkrétní počítač. U mnoha služeb, které nejsou vytvořené pro tento model, dochází také k potížím kvůli určitému kritickému bodu nebo zpomalení v kódu. Tyto typy problémů způsobují, že služba nebude fungovat, když se zvětší počet souběžných pracovních postupů, které sleduje.

Řešením je vytvořit instanci této služby pro každou jinou instanci pracovního postupu, který chcete sledovat. Toto je skvělý vzor a funguje bez ohledu na to, jestli je služba bezstavová nebo stavová. Aby tento model fungoval, obvykle existuje jiná služba, která funguje jako služba Správce úloh. Úkolem této služby je přijímat žádosti a směrovat je do jiných služeb. Správce může dynamicky vytvořit instanci služby úloh, když obdrží zprávu, a pak těmto službám předat požadavky. Služba správce může také přijímat zpětná volání, když daná služba pracovního postupu dokončí svoji úlohu. Když správce obdrží tato zpětná volání, může odstranit tuto instanci služby pracovního postupu, nebo ji nechat, pokud se očekává více volání.

Pokročilé verze tohoto typu manažera můžou dokonce vytvářet fondy služeb, které spravuje. Fond pomáhá zajistit, aby při přijetí nové žádosti nemusel čekat na spuštění služby. Místo toho může manažer jednoduše vybrat službu pracovního postupu, která není momentálně zaneprázdněná, z fondu, nebo může trasu směrovat náhodně. Když necháte fond dostupných služeb, bude zpracování nových požadavků rychlejší, protože je méně pravděpodobné, že požadavek bude muset počkat na vytvoření nové služby. Vytváření nových služeb je rychlé, ale není bezplatné ani okamžité. Fond pomáhá minimalizovat dobu, po kterou musí požadavek čekat, než bude obsluhován. Tento vzor správce a fondu se často zobrazí, když je doba odezvy nejdůležitější. Oblíbeným vzorem správce je také řazení do fronty a vytvoření služby na pozadí a následné předání služby, stejně jako vytváření a odstraňování služeb na základě sledování množství práce, kterou služba aktuálně čeká na vyřízení.

Škálování vytvořením nebo odebráním nových pojmenovaných instancí aplikací

Vytváření a odstraňování celých instancí aplikací je podobné vzoru vytváření a odstraňování služeb. Pro tento model existuje nějaká služba správce, která rozhoduje na základě požadavků, které se jí zobrazují, a informací, které přijímá od ostatních služeb v clusteru.

Kdy byste měli místo vytváření nových pojmenovaných instancí služby v některé již existující aplikaci vytvořit novou pojmenovanou instanci aplikace? Existuje několik případů:

  • Nová instance aplikace je pro zákazníka, jehož kód musí běžet pod určitým nastavením identity nebo zabezpečení.
    • Service Fabric umožňuje definovat různé balíčky kódu, které se mají spouštět pod konkrétními identitami. Aby bylo možné spustit stejný balíček kódu pod různými identitami, musí k aktivaci dojít v různých instancích aplikací. Představte si případ, kdy máte nasazené úlohy existujícího zákazníka. Ty můžou běžet pod konkrétní identitou, abyste mohli monitorovat a řídit jejich přístup k jiným prostředkům, jako jsou vzdálené databáze nebo jiné systémy. V takovém případě, když se zaregistruje nový zákazník, pravděpodobně nebudete chtít aktivovat jeho kód ve stejném kontextu (prostor procesu). I když byste to mohli, ztěžuje to pro váš kód služby jednat v kontextu konkrétní identity. Obvykle musíte mít větší zabezpečení, izolaci a kód pro správu identit. Místo použití různých pojmenovaných instancí služby v rámci stejné instance aplikace, a tedy stejného prostoru procesu, můžete použít různé pojmenované instance aplikací Service Fabric. To usnadňuje definování různých kontextů identit.
  • Nová instance aplikace slouží také jako prostředek konfigurace.
    • Ve výchozím nastavení budou všechny pojmenované instance služby konkrétního typu služby v instanci aplikace spuštěny ve stejném procesu na daném uzlu. To znamená, že i když můžete nakonfigurovat každou instanci služby jinak, je to složité. Služby musí mít token, který používají k vyhledání konfigurace v rámci konfiguračního balíčku. Obvykle se jedná pouze o název služby. Funguje to bez problémů, ale konfigurace se páruje s názvy jednotlivých pojmenovaných instancí služby v této instanci aplikace. To může být matoucí a obtížně spravovatelné, protože konfigurace je obvykle artefaktem v době návrhu s hodnotami specifickými pro instanci aplikace. Vytváření dalších služeb vždy znamená, že se při upgradu aplikací změní informace v rámci konfiguračních balíčků nebo nasadí nové, aby nové služby mohly vyhledat své konkrétní informace. Vytvoření zcela nové pojmenované instance aplikace je často jednodušší. Pak můžete použít parametry aplikace k nastavení jakékoli konfigurace, která je pro služby nezbytná. Tímto způsobem můžou všechny služby vytvořené v rámci této pojmenované instance aplikace dědit konkrétní nastavení konfigurace. Například místo jediného konfiguračního souboru s nastavením a přizpůsobením pro každého zákazníka, jako jsou limity tajných kódů nebo prostředků na zákazníka, byste místo toho měli pro každého zákazníka jinou instanci aplikace s přepsáním těchto nastavení.
  • Nová aplikace slouží jako hranice upgradu.
    • V rámci Service Fabric slouží jako hranice pro upgrade různé pojmenované instance aplikací. Upgrade jedné pojmenované instance aplikace nebude mít vliv na kód spuštěné jiné pojmenované instance aplikace. Různé aplikace nakonec poběží různé verze stejného kódu na stejných uzlech. To může být faktorem, když potřebujete udělat rozhodnutí o škálování, protože můžete zvolit, jestli má nový kód provádět stejné upgrady jako jiná služba, nebo ne. Řekněme například, že volání dorazí do služby správce, která zodpovídá za škálování úloh konkrétního zákazníka dynamickým vytvářením a odstraňováním služeb. V tomto případě se ale jedná o volání pro úlohu přidruženou k novému zákazníkovi. Většina zákazníků je ráda, že jsou od sebe izolovaní nejen z důvodů zabezpečení a konfigurace uvedených výše, ale také proto, že poskytuje větší flexibilitu, pokud jde o spouštění konkrétních verzí softwaru a volbu, kdy se upgradují. Můžete také vytvořit novou instanci aplikace a vytvořit službu tam jednoduše kvůli dalšímu rozdělení počtu služeb, na které se bude jakýkoli upgrade dotýkat. Samostatné instance aplikací poskytují větší členitost při upgradech aplikací a také umožňují testování A/B a nasazení modrá/zelená.
  • Stávající instance aplikace je plná.
    • V Service Fabric je kapacita aplikace koncept, který můžete použít k řízení množství prostředků dostupných pro konkrétní instance aplikace. Můžete se například rozhodnout, že daná služba musí mít vytvořenou další instanci, aby se mohla škálovat. Tato instance aplikace je však pro určitou metriku mimo kapacitu. Pokud by tomuto konkrétnímu zákazníkovi nebo úloze mělo být stále přiděleno více prostředků, můžete buď zvýšit stávající kapacitu pro danou aplikaci, nebo vytvořit novou aplikaci.

Škálování na úrovni oddílu

Service Fabric podporuje dělení. Dělení rozdělí službu na několik logických a fyzických částí, z nichž každá funguje nezávisle. To je užitečné u stavových služeb, protože žádná sada replik musí zpracovávat všechna volání a manipulovat se všemi stavy najednou. Přehled dělení obsahuje informace o podporovaných typech schémat dělení. Repliky jednotlivých oddílů jsou rozložené mezi uzly v clusteru, rozdělují zatížení dané služby a zajišťují, že ani služba jako celek, ani žádný oddíl nemají jediný bod selhání.

Představte si službu, která používá schéma dělení na rozsahy s nízkým klíčem 0, vysokým klíčem 99 a počtem oddílů 4. V clusteru se třemi uzly může být služba rozložená se čtyřmi replikami, které sdílejí prostředky na každém uzlu, jak je znázorněno tady:

Rozložení oddílů se třemi uzly

Pokud zvýšíte počet uzlů, Service Fabric tam přesune některé existující repliky. Řekněme například, že počet uzlů se zvýší na čtyři a repliky se redistribuují. Služba teď má na každém uzlu spuštěné tři repliky, z nichž každá patří do různých oddílů. To umožňuje lepší využití prostředků, protože nový uzel není studený. Obvykle také zvyšuje výkon, protože každá služba má k dispozici více prostředků.

Rozložení oddílů se čtyřmi uzly

Škálování pomocí Resource Manager a metrik clusteru Service Fabric

Metriky představují způsob, jakým služby vyjadřují spotřebu prostředků do Service Fabric. Použití metrik dává clusteru Resource Manager příležitost přeuspořádat a optimalizovat rozložení clusteru. V clusteru může být například spousta prostředků, ale nemusí být přiděleny službám, které právě pracují. Použití metrik umožňuje Resource Manager clusteru změnit uspořádání clusteru, aby se zajistilo, že služby budou mít přístup k dostupným prostředkům.

Škálování přidáním a odebráním uzlů z clusteru

Další možností škálování pomocí Service Fabric je změnit velikost clusteru. Změna velikosti clusteru znamená přidání nebo odebrání uzlů pro jeden nebo více typů uzlů v clusteru. Představte si například případ, kdy jsou všechny uzly v clusteru horké. To znamená, že prostředky clusteru se spotřebovávají téměř všechny. V tomto případě je nejlepším způsobem škálování přidání dalších uzlů do clusteru. Jakmile se nové uzly připojí ke clusteru, cluster Service Fabric Resource Manager do nich přesune služby, což vede k menšímu celkovému zatížení stávajících uzlů. Pro bezstavové služby s počtem instancí = -1 se automaticky vytvoří další instance služby. To umožňuje, aby se některá volání přesunula z existujících uzlů do nových uzlů.

Další informace najdete v tématu Škálování clusteru.

Volba platformy

Vzhledem k rozdílům v implementaci mezi operačními systémy může být volba použití Service Fabric s Windows nebo Linuxem zásadní součástí škálování aplikace. Jednou z potenciálních překážek je způsob, jakým se provádí fázované protokolování. Service Fabric ve Windows používá ovladač jádra pro protokol 1 na počítač, který se sdílí mezi replikami stavových služeb. Tento protokol váží přibližně 8 GB. Linux na druhou stranu používá pro každou repliku pracovní protokol o velikosti 256 MB, což je méně ideální pro aplikace, které chtějí maximalizovat počet jednoduchých replik služby spuštěných na daném uzlu. Tyto rozdíly v požadavcích na dočasné úložiště můžou potenciálně informovat požadovanou platformu pro nasazení clusteru Service Fabric.

Spojení všech součástí dohromady

Pojďme se podívat na všechny nápady, které jsme zde probrali, a probereme si příklad. Představte si následující službu: Pokoušíte se vytvořit službu, která funguje jako adresář a bude se držet jmen a kontaktních informací.

Přímo na první pohled máte spoustu otázek týkajících se škálování: Kolik uživatelů budete mít? Kolik kontaktů bude každý uživatel ukládat? Snažit se to všechno zjistit, když stojíte ve službě poprvé, je obtížné. Řekněme, že jste chtěli použít jednu statickou službu s konkrétním počtem oddílů. Důsledky výběru nesprávného počtu oddílů můžou způsobit problémy se škálováním později. Podobně platí, že i když vyberete správný počet, nemusíte mít všechny potřebné informace. Například musíte předem rozhodnout o velikosti clusteru, a to jak z hlediska počtu uzlů, tak z hlediska jejich velikosti. Obvykle je těžké předpovědět, kolik prostředků bude služba během své životnosti spotřebovávat. Může být také obtížné předem zjistit, jaký způsob provozu služba skutečně vidí. Lidé třeba přidávají a odebírají svoje kontakty jenom ráno, nebo se rozdělí rovnoměrně v průběhu dne. Na základě toho možná budete muset dynamicky škálovat kapacitu. Možná se naučíte předpovědět, kdy budete potřebovat horizontální navýšení a snížení kapacity, ale v obou případech budete pravděpodobně muset reagovat na měnící se spotřebu prostředků ve vaší službě. To může zahrnovat změnu velikosti clusteru, aby bylo k dispozici více prostředků, když změna uspořádání stávajících prostředků nestačí.

Ale proč se dokonce snažit vybrat schéma jednoho oddílu pro všechny uživatele? Proč se omezit na jednu službu a jeden statický cluster? Skutečná situace je obvykle dynamičtější.

Při sestavování pro škálování zvažte následující dynamický vzor. Možná ho budete muset přizpůsobit své situaci:

  1. Místo toho, abyste se snažili vybrat schéma dělení pro všechny předem, vytvořte "službu správce".
  2. Úkolem služby manažera je podívat se na informace o zákazních, když se zaregistrují k vaší službě. V závislosti na těchto informacích pak služba správce vytvoří instanci vaší skutečné služby úložiště kontaktů jen pro tohoto zákazníka. Pokud vyžadují konkrétní konfiguraci, izolaci nebo upgrady, můžete se také rozhodnout pro tohoto zákazníka spustit instanci aplikace.

Tento dynamický model vytváření má mnoho výhod:

  • Nesnažíte se předem odhadnout správný počet oddílů pro všechny uživatele ani vytvořit jednu službu, která je sama o sobě nekonečně škálovatelná.
  • Různí uživatelé nemusí mít stejný počet oddílů, počet replik, omezení umístění, metriky, výchozí načtení, názvy služeb, nastavení DNS ani žádné další vlastnosti zadané na úrovni služby nebo aplikace.
  • Získáte další segmentaci dat. Každý zákazník má vlastní kopii služby.
    • Každou zákaznickou službu je možné nakonfigurovat odlišně a udělit více nebo méně prostředků s více nebo méně oddíly nebo replikami podle potřeby na základě jejich očekávaného škálování.
      • Řekněme například, že zákazník zaplatil za úroveň Gold – mohl by získat více replik nebo vyšší počet oddílů a potenciálně prostředky vyhrazené pro své služby prostřednictvím metrik a kapacit aplikací.
      • Nebo řekněme, že poskytli informace o tom, že počet kontaktů, které potřebovali, byl "Malý" – získali by jenom několik oddílů nebo by je mohli dokonce umístit do sdíleného fondu služeb s jinými zákazníky.
  • Během čekání na zobrazení zákazníků nepoužíváte řadu instancí nebo replik služeb.
  • Pokud zákazník někdy odejde, pak odebrání jeho informací z vaší služby je stejně jednoduché, jako když správce odstraní službu nebo aplikaci, kterou vytvořil.

Další kroky

Další informace o konceptech Service Fabric najdete v následujících článcích: