Model hostování Azure Service Fabric

Tento článek obsahuje přehled modelů hostování aplikací poskytovaných službou Azure Service Fabric a popisuje rozdíly mezi modely sdíleného procesu a exkluzivního procesu. Popisuje, jak nasazená aplikace vypadá na uzlu Service Fabric, a vztah mezi replikami (nebo instancemi) služby a hostitelským procesem služby.

Než budete pokračovat, ujistěte se, že rozumíte různým konceptům a relacím vysvětleným v modelu aplikace v Service Fabric.

Poznámka:

V tomto článku není výslovně uvedeno, že se jedná o něco jiného:

• Replika odkazuje jak na repliku stavové služby, tak na instanci bezstavové služby.
• CodePackage se považuje za ekvivalent procesu ServiceHost, který zaregistruje ServiceType a hostuje repliky služeb tohoto typu ServiceType.

Abychom porozuměli modelu hostování, projdeme si příklad. Řekněme, že máme ApplicationType MyAppType, který má ServiceType MyServiceType. ServicePackage MyServicePackage poskytuje MyServiceType, který má Balíček CodePackage MyCodePackage. MyCodePackage při spuštění registruje ServiceType MyServiceType.

Řekněme, že máme cluster se třemi uzly a vytvoříme prostředek infrastruktury aplikace:/App1 typu MyAppType. Uvnitř této aplikace fabric:/App1 vytvoříme service fabric:/App1/ServiceA typu MyServiceType. Tato služba má dva oddíly (například P1 a P2) a tři repliky na oddíl. Následující diagram znázorňuje zobrazení této aplikace, protože končí nasazenou na uzlu.

Service Fabric aktivoval Balíček MyServicePackage, který spustil MyCodePackage, který hostuje repliky z obou oddílů. Všechny uzly v clusteru mají stejné zobrazení, protože jsme zvolili počet replik na oddíl, který se má rovnat počtu uzlů v clusteru. Pojďme vytvořit další službu Fabric :/App1/ServiceB v prostředcích infrastruktury aplikace :/App1. Tato služba má jeden oddíl (například P3) a tři repliky na oddíl. Následující diagram znázorňuje nové zobrazení na uzlu:

Service Fabric umístila novou repliku pro oddíl P3 service fabric:/App1/ServiceB do existující aktivace balíčku MyServicePackage. Teď. Pojďme vytvořit další prostředky infrastruktury aplikace :/App2 typu MyAppType. Uvnitř prostředků infrastruktury:/App2 vytvořte service fabric:/App2/ServiceA. Tato služba má dva oddíly (P4 a P5) a tři repliky na oddíl. Následující diagram znázorňuje nové zobrazení uzlu:

Service Fabric aktivuje novou kopii MyServicePackage, která spustí novou kopii MyCodePackage. Repliky z obou oddílů service fabric:/App2/ServiceA (P4 a P5) se umístí do této nové kopie MyCodePackage.

Model sdíleného procesu

Předchozí část popisuje výchozí model hostování, který poskytuje Service Fabric, označovaný jako model sdíleného procesu. V tomto modelu je pro danou aplikaci aktivována pouze jedna kopie daného balíčku ServicePackage na uzlu (který spustí všechny balíčky CodePackage obsažené v ní). Všechny repliky všech služeb daného typu služby se umístí do balíčku CodePackage, který zaregistruje tento typ služby. Jinými slovy, všechny repliky všech služeb na uzlu daného serviceType sdílejí stejný proces.

Model exkluzivního procesu

Druhým modelem hostování, který poskytuje Service Fabric, je model exkluzivního procesu. V tomto modelu na daném uzlu každá replika žije ve vlastním vyhrazeném procesu. Service Fabric aktivuje novou kopii balíčku ServicePackage (která spustí všechny balíčky CodePackage obsažené v tomto balíčku). Repliky se umístí do balíčku CodePackage , který zaregistroval serviceType služby, do které replika patří.

Pokud používáte Service Fabric verze 5.6 nebo novější, můžete zvolit model exkluzivního procesu při vytváření služby (pomocí PowerShellu, REST nebo FabricClient). Zadejte ServicePackageActivationMode jako ExclusiveProcess.

PS C:\>New-ServiceFabricService -ApplicationName "fabric:/App1" -ServiceName "fabric:/App1/ServiceA" -ServiceTypeName "MyServiceType" -Stateless -PartitionSchemeSingleton -InstanceCount -1 -ServicePackageActivationMode "ExclusiveProcess"

var serviceDescription = new StatelessServiceDescription
{
    ApplicationName = new Uri("fabric:/App1"),
    ServiceName = new Uri("fabric:/App1/ServiceA"),
    ServiceTypeName = "MyServiceType",
    PartitionSchemeDescription = new SingletonPartitionSchemeDescription(),
    InstanceCount = -1,
    ServicePackageActivationMode = ServicePackageActivationMode.ExclusiveProcess
};

var fabricClient = new FabricClient(clusterEndpoints);
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

Pokud máte v manifestu aplikace výchozí službu, můžete zvolit model Exclusive Process zadáním atributu ServicePackageActivationMode :

<DefaultServices>
  <Service Name="MyService" ServicePackageActivationMode="ExclusiveProcess">
    <StatelessService ServiceTypeName="MyServiceType" InstanceCount="1">
      <SingletonPartition/>
    </StatelessService>
  </Service>
</DefaultServices>

Teď vytvoříme další službu, fabric:/App1/ServiceC, v aplikačních prostředcích infrastruktury:/App1. Tato služba má dva oddíly (například P6 a P7) a tři repliky na oddíl. ServicePackageActivationMode nastavíte na ExclusiveProcess. Následující diagram znázorňuje nové zobrazení na uzlu:

Jak vidíte, Service Fabric aktivoval dvě nové kopie MyServicePackage (jednu pro každou repliku z oddílu P6 a P7). Service Fabric umístila každou repliku do své vyhrazené kopie balíčku CodePackage. Pokud pro danou aplikaci použijete model exkluzivního procesu, může být na uzlu aktivní více kopií daného balíčku ServicePackage . V předchozím příkladu jsou pro prostředky infrastruktury:/App1 aktivní tři kopie balíčku MyServicePackage. Každá z těchto aktivních kopií myServicePackage má přidruženou id ServicePackageActivationId . Toto ID identifikuje kopii v rámci prostředků infrastruktury aplikace :/App1.

Pokud pro aplikaci používáte pouze model sdíleného procesu, existuje na uzlu pouze jedna aktivní kopie balíčku ServicePackage . ServicePackageActivationId pro tuto aktivaci balíčku ServicePackage je prázdný řetězec. Jedná se například o prostředky infrastruktury:/App2.

Poznámka:

• Model hostování sdíleného procesu odpovídá ServicePackageActivationMode se rovná SharedProcess. Toto je výchozí model hostování a ServicePackageActivationMode není nutné zadávat v době vytváření služby.

• Model hostování výhradního procesu odpovídá ServicePackageActivationMode se rovná ExclusiveProcess. Pokud chcete toto nastavení použít, měli byste ho explicitně zadat při vytváření služby.

• Pokud chcete zobrazit model hostování služby, zadejte dotaz na popis služby a podívejte se na hodnotu ServicePackageActivationMode.

Práce s nasazeným balíčkem služby

Aktivní kopie balíčku ServicePackage na uzlu se označuje jako nasazený balíček služby. Pokud pro danou aplikaci použijete model exkluzivního procesu pro vytváření služeb, může existovat více nasazených balíčků služby pro stejnou sadu ServicePackage. Pokud provádíte operace specifické pro nasazený balíček služby, měli byste poskytnout ServicePackageActivationId k identifikaci konkrétního nasazeného balíčku služby. Zadejte id, pokud například hlásíte stav nasazeného balíčku služby nebo restartujete balíček kódu nasazeného balíčku služby.

Id ServicePackageActivationId nasazeného balíčku služby můžete zjistit dotazem na seznam nasazených balíčků služeb na uzlu. Při dotazování na nasazené typy služeb, nasazené repliky a nasazené balíčky kódu na uzlu obsahuje výsledek dotazu také ServicePackageActivationId nadřazeného nasazeného balíčku služby.

Poznámka:

• V rámci modelu hostování sdíleného procesu je v daném uzlu pro danou aplikaci aktivována pouze jedna kopie balíčku ServicePackage . Má Hodnotu ServicePackageActivationId rovnou prázdnému řetězci a při provádění operací souvisejících s nasazeným balíčkem služby není nutné zadávat.

• V rámci modelu hostování výhradního procesu může být v daném uzlu pro danou aplikaci aktivní jedna nebo více kopií balíčku ServicePackage . Každá aktivace má neprázdný ServicePackageActivationId zadaný při provádění operací souvisejících s nasazeným balíčkem služby.

• Pokud je parametr ServicePackageActivationId vynechán, výchozí hodnota je prázdný řetězec. Pokud existuje nasazený balíček služby aktivovaný v rámci modelu sdíleného procesu, provede se s ní operace. Jinak se operace nezdaří.

• Dotazujte se jednou a neuložte do mezipaměti ServicePackageActivationId. ID se dynamicky generuje a může se měnit z různých důvodů. Před provedením operace, která vyžaduje ServicePackageActivationId, byste měli nejprve zadat dotaz na seznam nasazených balíčků služeb na uzlu. Potom pomocí ServicePackageActivationId z výsledku dotazu proveďte původní operaci.

Spustitelné soubory hosta a kontejnerové aplikace

Service Fabric považuje spustitelné soubory hosta a kontejnerové aplikace za bezstavové služby, které jsou samostatně obsažené. ServiceHost (proces nebo kontejner) neobsahuje žádný modul runtime Service Fabric. Vzhledem k tomu, že tyto služby jsou samostatné, počet replik na ServiceHost se pro tyto služby nevztahuje. Nejběžnější konfigurace používaná s těmito službami je jeden oddíl, přičemž InstanceCount je rovno -1 (jedna kopie kódu služby spuštěného na každém uzlu clusteru).

Výchozí ServicePackageActivationMode pro tyto služby je SharedProcess, v takovém případě Service Fabric aktivuje pouze jednu kopii ServicePackage na uzlu pro danou aplikaci. To znamená, že uzel spustí pouze jedna kopie kódu služby. Pokud chcete, aby se na uzlu spustilo více kopií kódu služby, zadejte ServicePackageActivationMode jako ExclusiveProcess při vytváření služby. Můžete to například provést při vytváření více služeb (Service1 to ServiceN) serviceType (zadaných v ServiceManifest) nebo při více oddílů služby.

Změna modelu hostování existující služby

V současné době nemůžete změnit model hostování existující služby ze sdíleného procesu na exkluzivní proces (nebo naopak).

Volba mezi modely hostování

Měli byste vyhodnotit, který model hostování nejlépe vyhovuje vašim požadavkům. Model sdíleného procesu používá prostředky operačního systému lépe, protože se vytváří méně procesů a několik replik ve stejném procesu může sdílet porty. Pokud ale některá z replik obsahuje chybu, kdy potřebuje snížit hostitele služby, ovlivní to všechny ostatní repliky ve stejném procesu.

Model exkluzivního procesu poskytuje lepší izolaci s každou replikou ve vlastním procesu. Pokud některá z replik obsahuje chybu, nemá to vliv na jiné repliky. Tento model je užitečný pro případy, kdy komunikační protokol nepodporuje sdílení portů. Usnadňuje možnost aplikovat zásady správného řízení prostředků na úrovni repliky. Exkluzivní proces však využívá více prostředků operačního systému, protože vytváří jeden proces pro každou repliku na uzlu.

Aspekty modelu exkluzivního procesu a aplikačního modelu

U většiny aplikací můžete modelovat aplikaci ve službě Service Fabric tak, že necháte jeden serviceType na servicepackage.

V některých případech service Fabric také umožňuje více než jeden typ služby na ServicePackage (a jeden Balíček CodePackage může zaregistrovat více než jeden typ služby). Tady jsou některé scénáře, ve kterých můžou být tyto konfigurace užitečné:

• Chcete optimalizovat využití prostředků tak, že vytvoříte méně procesů a budete mít vyšší hustotu repliky na proces.
• Repliky z různých typů služeb musí sdílet některá běžná data s vysokými náklady na inicializaci nebo paměť.
• Máte nabídku bezplatných služeb a chcete omezit využití prostředků tak, že všechny repliky služby umístíte do stejného procesu.

Model hostování exkluzivních procesů není koherentní s aplikačním modelem, který má více typů služeb na balíček ServicePackage. Důvodem je to, že pro dosažení vyššího sdílení prostředků mezi replikami je navrženo více typů ServiceTypes na ServicePackage a umožňuje vyšší hustotu replik na proces. Model exkluzivního procesu je navržený tak, aby dosáhl různých výsledků.

Vezměte v úvahu případ více typů ServiceType na ServicePackage s jinou sadou CodePackage, která registruje jednotlivé typy ServiceType. Řekněme, že máme Balíček ServicePackage MultiTypeServicePackage, který má dva balíčky CodePackage:

• MyCodePackageA, který zaregistruje ServiceType MyServiceTypeA.
• MyCodePackageB, který registruje ServiceType 'MyServiceTypeB'.

Teď řekněme, že vytvoříme aplikaci, prostředky infrastruktury:/SpecialApp. Uvnitř prostředků infrastruktury:/SpecialApp vytvoříme následující dvě služby s modelem exkluzivního procesu:

• Service Fabric:/SpecialApp/ServiceA typu MyServiceTypeA se dvěma oddíly (například P1 a P2) a třemi replikami na oddíl.
• Service Fabric:/SpecialApp/ServiceB typu MyServiceTypeB se dvěma oddíly (P3 a P4) a třemi replikami na oddíl.

Na daném uzlu mají obě služby dvě repliky. Vzhledem k tomu, že jsme k vytvoření služeb použili model exkluzivního procesu, Service Fabric aktivuje novou kopii MyServicePackage pro každou repliku. Každá aktivace MultiTypeServicePackage spustí kopii MyCodePackageA a MyCodePackageB. Repliku, pro kterou byl aktivován MultiTypeServicePackage, však hostuje pouze jeden z myCodePackageA nebo MyCodePackageB. Následující diagram znázorňuje zobrazení uzlu:

Při aktivaci MultiTypeServicePackage pro repliku oddílu P1 service fabric:/SpecialApp/ServiceA hostuje repliku myCodePackageA. Je spuštěný myCodePackageB. Podobně při aktivaci MultiTypeServicePackage pro repliku oddílu P3 service fabric:/SpecialApp/ServiceB hostuje repliku myCodePackageB. Je spuštěný myCodePackageA. Čím vyšší je tedy počet balíčků CodePackage (registrace různých typů ServiceTypes) na ServicePackage, tím vyšší je využití redundantních prostředků.

Pokud však vytvoříme prostředky infrastruktury služeb :/SpecialApp/ServiceA a fabric:/SpecialApp/ServiceB s modelem sdíleného procesu, Service Fabric aktivuje pouze jednu kopii MultiTypeServicePackage pro aplikační prostředky infrastruktury:/SpecialApp. MyCodePackageA hostuje všechny repliky pro service fabric:/SpecialApp/ServiceA. MyCodePackageB hostuje všechny repliky pro service fabric:/SpecialApp/ServiceB. Následující diagram znázorňuje zobrazení uzlu v tomto nastavení:

V předchozím příkladu si možná myslíte, že pokud MyCodePackageA zaregistruje MyServiceTypeA i MyServiceTypeB a neexistuje žádný MyCodePackageB, pak není spuštěn žádný redundantní CodePackage . I když je to správné, tento aplikační model neodpovídá modelu hostování výhradního procesu. Pokud je cílem umístit každou repliku do vlastního vyhrazeného procesu, nemusíte registrovat obě serviceTypes ze stejného balíčku CodePackage. Místo toho jednoduše dáte každý typ služby do vlastního balíčku ServicePackage.

Reliable Services a actor forking subprocesses

Service Fabric nepodporuje spolehlivé služby a následně spolehlivé aktéry pro podprocesy. Příkladem toho, proč není podporován, je CodePackageActivationContext nelze použít k registraci nepodporovaného podprocesu a tokeny zrušení se odesílají pouze do registrovaných procesů. Výsledkem jsou nejrůznější problémy, jako jsou selhání upgradu, když se podprocesy nezavřou po přijetí tokenu zrušení nadřazeného procesu.

Další kroky

Zabalte aplikaci a připravte ji k nasazení.

Nasaďte a odeberte aplikace. Tento článek popisuje, jak pomocí PowerShellu spravovat instance aplikací.