Přečtěte si o rozdílech mezi Cloud Services a Service Fabric před migrací aplikací.
Microsoft Azure Service Fabric je cloudová aplikační platforma nové generace pro vysoce škálovatelné a vysoce spolehlivé distribuované aplikace. Zavádí mnoho nových funkcí pro balení, nasazování, upgrade a správu distribuovaných cloudových aplikací.
Toto je úvodní příručka k migraci aplikací z Cloud Services do Service Fabric. Zaměřuje se především na rozdíly v architektuře a návrhu mezi Cloud Services a Service Fabric.
Aplikace a infrastruktura
Základním rozdílem mezi Cloud Services a Service Fabric je vztah mezi virtuálními počítači, úlohami a aplikacemi. Úloha je zde definována jako kód, který napíšete pro provedení konkrétní úlohy nebo poskytnutí služby.
- Cloud Services se týká nasazení aplikací jako virtuálních počítačů. Kód, který napíšete, je úzce propojený s instancí virtuálního počítače, například s webovou rolí nebo rolí pracovního procesu. Pokud chcete nasadit úlohu v Cloud Services je nasadit jednu nebo více instancí virtuálních počítačů, na kterých se úloha spouští. Neexistuje oddělení aplikací a virtuálních počítačů, a proto neexistuje žádná formální definice aplikace. Aplikaci si můžete představit jako sadu instancí webových rolí nebo rolí pracovního procesu v rámci nasazení Cloud Services nebo jako celé nasazení Cloud Services. V tomto příkladu se aplikace zobrazuje jako sada instancí rolí.
- Service Fabric se týká nasazování aplikací do stávajících virtuálních počítačů nebo počítačů se službou Service Fabric ve Windows nebo Linuxu. Služby, které napíšete, jsou zcela oddělené od základní infrastruktury, která je abstrahována aplikační platformou Service Fabric, takže aplikace může být nasazena do více prostředí. Úloha v Service Fabric se nazývá "služba" a jedna nebo více služeb se seskupuje v formálně definované aplikaci, která běží na aplikační platformě Service Fabric. Do jednoho clusteru Service Fabric je možné nasadit více aplikací.
Service Fabric je samotná vrstva aplikační platformy, která běží ve Windows nebo Linuxu, zatímco Cloud Services je systém pro nasazování virtuálních počítačů spravovaných Azure s připojenými úlohami. Aplikační model Service Fabric má řadu výhod:
- Rychlé časy nasazení. Vytváření instancí virtuálních počítačů může být časově náročné. V Service Fabric se virtuální počítače nasazují jenom jednou, aby vytvořily cluster, který hostuje aplikační platformu Service Fabric. Od tohoto okamžiku je možné balíčky aplikací nasadit do clusteru velmi rychle.
- Hostování s vysokou hustotou. V Cloud Services hostuje virtuální počítač role pracovního procesu jednu úlohu. V Service Fabric jsou aplikace oddělené od virtuálních počítačů, které je spouštějí, což znamená, že můžete nasadit velký počet aplikací na malý počet virtuálních počítačů, což může snížit celkové náklady na větší nasazení.
- Platforma Service Fabric může běžet kdekoli na počítačích s Windows Serverem nebo Linuxem, ať už se jedná o Azure nebo místní prostředí. Platforma poskytuje abstrakční vrstvu nad základní infrastrukturou, aby vaše aplikace běžela v různých prostředích.
- Správa distribuovaných aplikací. Service Fabric je platforma, která nejen hostuje distribuované aplikace, ale také pomáhá spravovat jejich životní cyklus nezávisle na životním cyklu hostitelského virtuálního počítače nebo počítače.
Architektura aplikace
Architektura aplikace Cloud Services obvykle zahrnuje řadu závislostí externích služeb, jako jsou Service Bus, Azure Table a Blob Storage, SQL, Redis a další, které spravují stav a data aplikace a komunikaci mezi webovými rolemi a rolemi pracovního procesu v Cloud Services nasazení. Příklad úplné aplikace Cloud Services může vypadat takto:
Aplikace Service Fabric se také můžou rozhodnout používat stejné externí služby v kompletní aplikaci. Při použití tohoto příkladu Cloud Services architektuře je nejjednodušším způsobem migrace z Cloud Services do Service Fabric nahradit pouze nasazení Cloud Services aplikací Service Fabric, přičemž celková architektura bude stejná. Webové role a role pracovního procesu je možné přenést do bezstavových služeb Service Fabric s minimálními změnami kódu.
V této fázi by měl systém dál fungovat stejně jako předtím. S využitím stavových funkcí Service Fabric je možné externí úložiště stavu internalizovat jako stavové služby tam, kde je to možné. Týká se to více než jednoduché migrace webových rolí a rolí pracovního procesu do bezstavových služeb Service Fabric, protože vyžaduje psaní vlastních služeb, které poskytují ekvivalentní funkce vaší aplikaci jako předtím externí služby. Mezi výhody tohoto postupu patří:
- Odebrání externích závislostí
- Sjednocení modelů nasazení, správy a upgradu
Příklad výsledné architektury internalizace těchto služeb může vypadat takto:
Komunikace a pracovní postup
Většina aplikací cloudové služby se skládá z více než jedné úrovně. Podobně se aplikace Service Fabric skládá z více než jedné služby (obvykle mnoho služeb). Dva běžné komunikační modely jsou přímá komunikace a prostřednictvím externího odolného úložiště.
Přímá komunikace
Díky přímé komunikaci můžou úrovně komunikovat přímo prostřednictvím koncového bodu zveřejněného jednotlivými vrstvami. V bezstavových prostředích, jako je Cloud Services, to znamená výběr instance role virtuálního počítače, ať už náhodně, nebo kruhovým dotazováním, aby se vyrovnává zatížení, a přímé připojení ke koncovému bodu.
Přímá komunikace je v Service Fabric běžným modelem komunikace. Hlavní rozdíl mezi Service Fabric a Cloud Services spočívá v tom, že v Cloud Services se připojujete k virtuálnímu počítači, zatímco ve Službě Service Fabric se připojujete ke službě. Toto je důležitý rozdíl z několika důvodů:
- Služby v Service Fabric nejsou vázané na virtuální počítače, které je hostují. služby se mohou v clusteru pohybovat a ve skutečnosti se očekává, že se přesunou z různých důvodů: vyrovnávání prostředků, převzetí služeb při selhání, upgrady aplikací a infrastruktury a omezení umístění nebo zatížení. To znamená, že adresa instance služby se může kdykoli změnit.
- Virtuální počítač v Service Fabric může hostovat více služeb, z nichž každá má jedinečné koncové body.
Service Fabric poskytuje mechanismus zjišťování služeb označovaný jako služba pojmenování, který se dá použít k překladu adres koncových bodů služeb.
Fronty
Běžným komunikačním mechanismem mezi vrstvami v bezstavových prostředích, jako je Cloud Services, je použití fronty externího úložiště k odolnému ukládání pracovních úkolů z jedné vrstvy do druhé. Běžným scénářem je webová vrstva, která odesílá úlohy do fronty Azure nebo služby Service Bus, kde instance rolí pracovního procesu můžou úlohy zrušit a zpracovat.
Stejný komunikační model je možné použít i v Service Fabric. To může být užitečné při migraci existující aplikace Cloud Services do Service Fabric.
Parity
Cloud Services se podobá Service Fabricu v míře řízení a snadném používání, ale teď je to starší služba a Service Fabric se doporučuje pro nový vývoj. Toto je porovnání rozhraní API:
| Rozhraní API cloudové služby | Service Fabric API | Poznámky |
|---|---|---|
| RoleInstance.GetID | FabricRuntime.GetNodeContext.NodeId nebo . Název uzlu | ID je vlastnost NodeName. |
| RoleInstance.GetFaultDomain | FabricClient.QueryManager.GetNodeList | Vyfiltrujte NodeName a použijte vlastnost FD. |
| RoleInstance.GetUpgradeDomain | FabricClient.QueryManager.GetNodeList | Vyfiltrujte NodeName a použijte vlastnost Upgrade. |
| RoleInstance.GetInstanceEndpoints | FabricRuntime.GetActivationContext nebo pojmenování (ResolveService) | CodePackageActivationContext, který poskytuje FabricRuntime.GetActivationContext a v rámci replik prostřednictvím ServiceInitializationParameters.CodePackageActivationContext poskytnuté během . Inicializovat |
| RoleEnvironment.GetRoles | FabricClient.QueryManager.GetNodeList | Pokud chcete provést stejný druh filtrování podle typu, můžete získat seznam typů uzlů z manifestu clusteru prostřednictvím FabricClient.ClusterManager.GetClusterManifest a získat odsud typy rolí a uzlů. |
| RoleEnvironment.GetIsAvailable | Connect-WindowsFabricCluster nebo vytvoření objektu FabricRuntime ukazující na konkrétní uzel | * |
| RoleEnvironment.GetLocalResource | CodePackageActivationContext.Log/Temp/Work | * |
| RoleEnvironment.GetCurrentRoleInstance | CodePackageActivationContext.Log/Temp/Work | * |
| LocalResource.GetRootPath | CodePackageActivationContext.Log/Temp/Work | * |
| Role.GetInstances | FabricClient.QueryManager.GetNodeList nebo ResolveService | * |
| RoleInstanceEndpoint.GetIPEndpoint | FabricRuntime.GetActivationContext nebo pojmenování (ResolveService) | * |
Další kroky
Nejjednodušším způsobem migrace z Cloud Services na Service Fabric je nahradit pouze nasazení Cloud Services aplikací Service Fabric, přičemž celková architektura aplikace bude přibližně stejná. Následující článek obsahuje průvodce, který vám pomůže převést webovou roli nebo roli pracovního procesu na bezstavovou službu Service Fabric.