Seznamte se s rozdíly mezi Cloud Services a Service Fabric před migrací aplikací.
Microsoft Azure Service Fabric je platforma cloudových aplikací nové generace pro vysoce škálovatelné a vysoce spolehlivé distribuované aplikace. Představuje mnoho nových funkcí pro balení, nasazování, upgrade a správu distribuovaných cloudových aplikací.
Toto je úvodní příručka pro 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 zde je definována jako kód, který napíšete k provedení konkrétní úlohy nebo poskytování služby.
- Cloud Services se týká nasazování aplikací jako virtuálních počítačů. Kód, který napíšete, je úzce propojený s instancí virtuálního počítače, jako je například webová role nebo role pracovního procesu. Nasazení úlohy v Cloud Services spočívá v nasazení jedné nebo více instancí virtuálních počítačů, na kterých se úloha spouští. Neexistuje žádné 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 nebo pracovních rolí v rámci nasazení cloudových služeb nebo jako celé nasazení cloudových služeb. V tomto příkladu se aplikace zobrazí jako sada instancí rolí.
- Service Fabric se zaměřuje na nasazování aplikací do stávajících virtuálních počítačů nebo počítačů se systémem Service Fabric ve Windows nebo Linuxu. Služby, které napíšete, jsou zcela oddělené od základní infrastruktury, která je abstrahována platformou aplikace Service Fabric, aby se aplikace dala nasadit do více prostředí. Úloha v Service Fabric se nazývá "služba" a jedna nebo více služeb se seskupí do formálně definované aplikace, která běží na aplikační platformě Service Fabric. Do jednoho clusteru Service Fabric je možné nasadit více aplikací.
Service Fabric je 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ý je hostitelem aplikační platformy 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í, 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, kde má počítače s Windows Serverem nebo Linuxem, ať už je to Azure nebo místní prostředí. Platforma poskytuje abstrakci vrstvy 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á hostuje nejen distribuované aplikace, ale také pomáhá spravovat životní cyklus nezávisle na hostitelském virtuálním počítači nebo životním cyklu počítače.
Architektura aplikace
Architektura aplikace Cloud Services obvykle zahrnuje celou řadu závislostí externích služeb, jako jsou Service Bus, Azure Table a Blob Storage, SQL, Redis a další, které umožňují spravovat stav a data aplikace a komunikaci mezi webovými a pracovními rolemi v nasazení cloudových služeb. Příklad kompletní aplikace Cloud Services může vypadat takto:
Aplikace Service Fabric se také můžou rozhodnout používat stejné externí služby v celé aplikaci. V tomto příkladu architektury cloudových služeb je nejjednodušším způsobem migrace z Cloud Services do Service Fabric nahradit pouze nasazení cloudových služeb aplikací Service Fabric a zachovat tak celkovou architekturu 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 systém měl dál fungovat stejně jako předtím. S využitím stavových funkcí Service Fabric je možné externí úložiště stavů interně inicializovat jako stavové služby, pokud je to možné. To je více než jednoduchá migrace webových rolí a rolí pracovních procesů do bezstavových služeb Service Fabric, protože vyžaduje psaní vlastních služeb, které poskytují ekvivalentní funkce vaší aplikaci jako externí služby dříve. Mezi výhody tohoto použití 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ých služeb se skládá z více než jedné vrstvy. Podobně se aplikace Service Fabric skládá z více než jedné služby (obvykle mnoha 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 vrstvy komunikovat přímo přes koncový bod vystavený každou vrstvou. V bezstavových prostředích, jako je cloudová služba, to znamená, že vyberete instanci role virtuálního počítače, ať už náhodně, nebo kruhovým dotazováním, abyste vyrovnáli zatížení a připojili se přímo ke svému koncovému bodu.
Přímá komunikace je běžný komunikační model v Service Fabric. Klíčovým rozdílem mezi Service Fabric a Cloud Services je to, že se v Cloud Services připojujete k virtuálnímu počítači, zatímco v Service Fabric se připojujete ke službě. Toto je důležité rozlišení 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 pohybovat v clusteru a ve skutečnosti se očekává, že se budou pohybovat 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, který se označuje 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 například Cloud Services, je použití externí fronty úložiště k stálosti ukládání pracovních úloh 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 dekadovat a zpracovávat úlohy.
Stejný komunikační model je možné použít ve službě Service Fabric. To může být užitečné při migraci existující aplikace Cloud Services do Service Fabric.
Parita
Cloud Services se podobá Service Fabric ve stupních kontroly a snadnému použití, ale pro nový vývoj se teď doporučuje starší verze služby a Service Fabric. 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 | Filtrování podle NodeName a použití vlastnosti FD |
RoleInstance.GetUpgradeDomain | FabricClient.QueryManager.GetNodeList | Filtrování podle NodeName a použití vlastnosti Upgrade |
RoleInstance.GetInstanceEndpoints | FabricRuntime.GetActivationContext nebo Pojmenování (ResolveService) | CodePackageActivationContext, který poskytuje FabricRuntime.GetActivationContext i v replikách 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 typy rolí/uzlů odtud. |
RoleEnvironment.GetIsAvailable | Connect-WindowsFabricCluster nebo vytvořte FabricRuntime odkazovaný 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 do Service Fabric je nahradit pouze nasazení cloudových služeb aplikací Service Fabric, přičemž celková architektura vaší aplikace bude přibližně stejná. Následující článek obsahuje průvodce, který vám pomůže převést webovou nebo pracovní roli na bezstavovou službu Service Fabric.