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í, upgradování a správu distribuovaných cloudových aplikací.
Toto je úvodní příručka pro migraci aplikací z Cloud Services na Service Fabric. Zaměřuje se především na strukturální a návrh rozdílů mezi Cloud Services a Service Fabric.
Aplikace a infrastruktura
Základní rozdíl mezi Cloud Services a Service Fabric je vztah mezi virtuálními počítači, úlohami a aplikacemi. Úloha, kterou napíšete, se definuje jako kód, který zapisujete k provedení konkrétního úkolu nebo poskytnutí služby.
- Cloud Services o nasazení aplikací jako virtuálních počítačů. Kód, který zapisujete, je pevně spojený s instancí virtuálního počítače, jako je například webová role nebo role pracovního procesu. K nasazení úlohy v Cloud Services slouží k nasazení jedné nebo více instancí virtuálních počítačů, které spouštějí úlohu. Neexistují žádné oddělené aplikace a virtuální počítače, takže není k dispozici žádná formální definice aplikace. Aplikaci si můžete představit jako sadu instancí webové role nebo role 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 o nasazení aplikací do stávajících virtuálních počítačů nebo počítačů se systémem Service Fabric v systému Windows nebo Linux. Služby, které zapisujete, jsou zcela oddělené od základní infrastruktury, která je abstraktní Service Fabric aplikační platformou, takže je možné aplikaci nasadit do více prostředí. Zatížení v Service Fabric se nazývá "služba" a jedna nebo více služeb se seskupují ve formě uživatelsky definované aplikace, která běží na platformě Service Fabric aplikace. Do jednoho clusteru Service Fabric lze nasadit více aplikací.

Service Fabric sám je vrstva aplikační platformy, která běží na Windows nebo Linux, zatímco Cloud Services je systém pro nasazení virtuálních počítačů spravovaných Azure s připojenými úlohami. Model aplikace Service Fabric má několik výhod:
- Doba rychlého nasazení. Vytváření instancí virtuálních počítačů může být časově náročné. V Service Fabric jsou virtuální počítače nasazené jenom jednou, aby tvořily cluster, který je hostitelem platformy Service Fabric aplikace. Od tohoto okamžiku je možné balíčky aplikací nasadit do clusteru velmi rychle.
- Hostování s vysokou hustotou. V Cloud Services virtuální počítač role pracovního procesu hostuje 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 pro větší nasazení.
- Platforma Service Fabric může běžet kdekoli s počítači s Windows serverem nebo Linux, ať už se jedná o Azure, nebo v místním prostředí. Platforma poskytuje abstrakci vrstvy nad základní infrastrukturou, takže vaše aplikace může běžet 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 životní cyklus nezávisle na hostitelském VIRTUÁLNÍm počítači nebo v životním cyklu počítače.
Architektura aplikace
Architektura Cloud Services aplikace obvykle zahrnuje řadu externích závislostí služby, jako je například Service Bus, tabulka Azure a Blob Storage, SQL, Redis a další pro správu stavu a dat aplikace a komunikace mezi webovými a pracovními rolemi v nasazení Cloud Services. Příklad kompletní Cloud Services aplikace může vypadat takto:

Service Fabric aplikace se také můžou rozhodnout použít stejné externí služby v úplné aplikaci. Pomocí tohoto ukázkového Cloud Services architektury je nejjednodušší cesta migrace z Cloud Services na Service Fabric nahradit pouze Cloud Services nasazení pomocí Service Fabric aplikace, přičemž celková architektura zůstane stejná. Webové a pracovní role lze přenést do Service Fabric bezstavových služeb s minimálními změnami kódu.

V této fázi by měl systém dál fungovat stejně jako dřív. Využitím stavových funkcí Service Fabric můžete v případě potřeby vytvářet externí úložiště stavu jako stavové služby. To je víc, než jednoduchá migrace webových a pracovních rolí do Service Fabric bezstavových služeb, protože to vyžaduje psaní vlastních služeb, které v rámci vaší aplikace poskytují ekvivalentní funkce jako externí služby. K těmto výhodám patří:
- Odebírají se externí závislosti.
- Sjednocení modelů nasazení, správy a upgradu.
Příklad výsledné architektury internalizing tyto služby by mohl vypadat takto:

Komunikace a pracovní postup
Většina aplikací cloudových služeb se skládá z více než jedné úrovně. Podobně Service Fabric aplikace se 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 trvalého úložiště.
Přímá komunikace
Díky přímé komunikaci můžou vrstvy komunikovat přímo prostřednictvím koncového bodu vystaveného každou vrstvou. V bezstavových prostředích, jako je například Cloud Services, to znamená výběr instance role virtuálního počítače, buď náhodným, nebo kruhovým dotazem, Vyrovnávání zatížení a přímé připojení ke koncovému bodu.

Přímá komunikace je běžným komunikačním modelem v Service Fabric. Hlavním rozdílem mezi Service Fabric a Cloud Services je to, že se v Cloud Services připojíte k virtuálnímu počítači, zatímco v Service Fabric se připojíte ke službě. Toto je důležitý rozdíl z několika důvodů:
- Služby v Service Fabric nejsou vázány na virtuální počítače, které je hostují. služby se můžou v clusteru pohybovat a ve skutečnosti se očekává, že se budou pohybovat z různých důvodů: Vyrovnávání zatížení, převzetí služeb při selhání, upgradování aplikací a infrastruktury a omezení umístění nebo zatížení. To znamená, že se adresa instance služby může kdykoli změnit.
- Virtuální počítač v Service Fabric může hostovat několik služeb, každý s jedinečnými koncovými body.
Service Fabric poskytuje mechanismus zjišťování služeb nazvaný Naming Service, 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 trvaleí pracovních úloh z jedné úrovně do druhé. Běžným scénářem je webová vrstva, která odesílá úlohy do fronty Azure nebo Service Bus, kde můžou instance rolí pracovních procesů vyřadit z fronty a zpracovat úlohy.

Stejný komunikační model lze použít 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 je podobná Service Fabric ve stupni řízení a jednoduchosti použití, 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 | Rozhraní API pro Service Fabric | Poznámky |
|---|---|---|
| RoleInstance. getId – | FabricRuntime. GetNodeContext. NodeId nebo. NodeName | ID je vlastnost Node. |
| RoleInstance. GetFaultDomain | FabricClient. QueryManager. GetNodeList | Filtrovat podle node a použít vlastnost FD |
| RoleInstance. GetUpgradeDomain | FabricClient. QueryManager. GetNodeList | Filtrovat podle node a použít vlastnost upgrade |
| RoleInstance. GetInstanceEndpoints | FabricRuntime. GetActivationContext nebo pojmenování (ResolveService) | CodePackageActivationContext, která je poskytována v rámci FabricRuntime. GetActivationContext a v replikách prostřednictvím ServiceInitializationParameters. CodePackageActivationContext poskytovaných během. Spuštění |
| RoleEnvironment. GetRole | FabricClient. QueryManager. GetNodeList | Chcete-li 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 něj převzít typy rolí nebo uzlů. |
| RoleEnvironment. GetIsAvailable | Connect-WindowsFabricCluster nebo vytvoření FabricRuntime ukazatele 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šší cesta migrace z Cloud Services do Service Fabric je nahrazení pouze Cloud Servicesho nasazení s využitím aplikace Service Fabric a udržování celé architektury aplikace přibližně stejně. Následující článek popisuje Průvodce převodem webové role nebo role pracovního procesu na bezstavovou službu Service Fabric.