Migrace aplikace Azure Cloud Services do Azure Service Fabric

Vzorek kódu

Tento článek popisuje migraci aplikace z Azure Cloud Services do Azure Service Fabric. Zaměřuje se na rozhodování o architektuře a Doporučené postupy.

Pro tento projekt jsme začali s aplikací Cloud Services s názvem průzkumy a Service Fabric. Cílem bylo provést migraci aplikace s co možná nejmenší změnou. Dále v článku ukazujeme, jak optimalizovat aplikaci pro Service Fabric.

Před čtením tohoto článku bude užitečné pochopit základy Service Fabric. Další informace najdete v tématu Přehled služby Azure Service Fabric .

O aplikaci Průzkums

Fiktivní společnost s názvem Tailspin vytvořila aplikaci s názvem aplikace pro průzkumy, která zákazníkům umožňuje vytvářet průzkumy. Po zaregistrování zákazníka do aplikace můžou uživatelé vytvářet a publikovat průzkumy a shromažďovat výsledky pro analýzu. Aplikace obsahuje veřejný web, na kterém můžou lidé pořizovat průzkum. Přečtěte si další informace o původním scénáři Tailspin.

nyní Tailspin chce přesunout aplikaci průzkumů do architektury mikroslužeb pomocí Service Fabric běžícího v Azure. Vzhledem k tomu, že je aplikace už nasazená jako aplikace Cloud Services, Tailspin přijímá přístup ve více fázích:

1. Port cloud services, které se mají Service Fabric, a současně minimalizuje změny aplikace.
2. optimalizujte aplikaci pro Service Fabric tím, že přejdete na architekturu mikroslužeb.

V reálném projektu je pravděpodobnější, že se obě fáze překrývají. při přenosu do Service Fabric byste také měli začít architektovat aplikaci na mikroslužby. Později můžete tuto architekturu ještě podrobněji Upřesnit, případně rozdělit hrubě odstupňované služby na menší služby.

Kód aplikace je k dispozici na GitHub. toto úložiště obsahuje aplikaci Cloud Services i verzi Service Fabric.

Proč Service Fabric?

pro tento projekt je vhodná Service Fabric, protože většina funkcí potřebných v distribuovaném systému je integrovaná do Service Fabric, včetně:

• Správa clusteru. Service Fabric automaticky zpracovává převzetí služeb při selhání uzlů, monitorování stavu a další funkce správy clusteru.
• Horizontální škálování. když do clusteru Service Fabric přidáte uzly, aplikace se automaticky škáluje, protože služby jsou distribuovány mezi nové uzly.
• Zjišťování služby. Service Fabric poskytuje službu zjišťování, která může pro pojmenovanou službu vrátit koncový bod.
• Bezstavové a stavové služby. Stavové služby využívají spolehlivé kolekce, které můžou pobírat místo mezipaměti nebo fronty a můžou být rozdělené do oddílů.
• Správa životního cyklu aplikací. Služby je možné upgradovat nezávisle a bez výpadků aplikací.
• Orchestrace služby napříč clusterem počítačů.
• Vyšší hustota pro optimalizaci spotřeby prostředků Jeden uzel může hostovat několik služeb.

Service Fabric používá různé služby Microsoft, včetně Azure SQL Database, Cosmos DB, Azure Event Hubs a dalších, a díky tomu je prověřená platforma pro vytváření distribuovaných cloudových aplikací.

Porovnávání Cloud Services s Service Fabric

následující tabulka shrnuje některé důležité rozdíly mezi Cloud Services a Service Fabric aplikacemi. podrobnější diskuzi najdete v tématu informace o rozdílech mezi Cloud Services a Service Fabric před migrací aplikací.

* Stavové služby používají spolehlivé kolekce k ukládání stavu napříč replikami, aby všechny čtení byly místní pro uzly v clusteru. Zápisy jsou replikovány mezi uzly a jejich spolehlivost. Bezstavové služby můžou mít externí stav, a to s využitím databáze nebo jiného externího úložiště.

• • role pracovních procesů můžou být taky samoobslužně hostovat ASP.NET Web API pomocí OWIN.

Aplikace průzkumy na Cloud Services

Následující diagram znázorňuje architekturu aplikace průzkumů běžící na Cloud Services.

Aplikace se skládá ze dvou webových rolí a role pracovního procesu.

• webová role Tailspin. web hostuje web ASP.NET, který zákazníci Tailspin používají k vytváření a správě průzkumů. Zákazníci také používají tento web k registraci aplikace a ke správě jejich předplatných. Nakonec je můžou správci Tailspin použít k zobrazení seznamu tenantů a správě dat tenanta.

• webová role Tailspin. Web. Survey. Public hostuje web ASP.NET, kde mohou uživatelé provádět průzkumy, které zákazníci Tailspin zveřejňují.

• Role pracovního procesu Tailspin. Worker. Survey provádí zpracování na pozadí. Webové role umísťují pracovní položky do fronty a role pracovního procesu zpracovává položky. jsou definovány dvě úlohy na pozadí: export odpovědí na průzkum do Azure SQL Database a výpočet statistik pro odpovědi na průzkum.

Kromě Cloud Services používá aplikace průzkumy jiné služby Azure:

• Azure Storage ukládat průzkumy, odpovědi na průzkumy a informace o tenantovi.

• mezipaměť Azure pro Redis , která ukládá do mezipaměti některá data uložená v Azure Storage pro rychlejší přístup pro čtení.

• Azure Active Directory (Azure AD) k ověřování zákazníků a správců Tailspin.

• Azure SQL Database ukládat odpovědi na průzkum k analýze.

Přechod na Service Fabric

Jak už bylo zmíněno, cílem této fáze byla migrace na Service Fabric s minimálními nezbytnými změnami. Za tímto účelem jsme v původní aplikaci vytvořili bez stavové služby odpovídající jednotlivým rolím cloudové služby:

Záměrně je tato architektura podobná původní aplikaci. Diagram ale skryje některé důležité rozdíly. Ve zbývající části tohoto článku prozkoumáme tyto rozdíly.

Převod rolí cloudové služby na služby

Při počáteční migraci tailspin postupoval podle kroků uvedených v průvodci převodem webových rolí a rolí pracovních procesů na Service Fabric bez stavových služeb.

Vytvoření webových front-endových služeb

V Service Fabric se služba spouští uvnitř procesu vytvořeného Service Fabric runtime. U webového front-endu to znamená, že služba není spuštěná ve službě IIS. Místo toho musí služba hostovat webový server. Tento přístup se nazývá samoobslužné hostování, protože kód, který běží uvnitř procesu, funguje jako hostitel webového serveru.

Původní aplikace Surveys používá ASP.NET MVC. Vzhledem ASP.NET, že se MVC nemůže v Service Fabric hostovat, považuje Tailspin následující možnosti migrace:

• Portovat webové role do ASP.NET Core, které mohou být hostované v samostatném prostředí.
• Převeďte web na jedno stránkovou aplikaci (SPA), která volá webové rozhraní API implementované ASP.NET Webové rozhraní API. To by vyžadovalo kompletní přepracování webového front-endu.
• Uchovávejte stávající ASP.NET MVC a nasaďte službu IIS v kontejneru Windows Serveru, aby Service Fabric. Tento přístup by vyžadoval jen malou nebo žádnou změnu kódu.

První možnost, přenos do ASP.NET Core, umožnila tailspinu využívat nejnovější funkce v ASP.NET Core. Při převodu tailspin postupoval podle kroků popsaných v tématu Migrace z ASP.NET MVC na ASP.NET Core MVC.

Naslouchače HTTP

V Cloud Services webová role nebo role pracovního procesu zveřejňuje koncový bod HTTP tím, že ho deklaruje v definiční souboru služby. Webová role musí mít alespoň jeden koncový bod.

<!-- Cloud service endpoint -->
<Endpoints>
    <InputEndpoint name="HttpIn" protocol="http" port="80" />
</Endpoints>

Podobně Service Fabric koncové body deklarovány v manifestu služby:

<!-- Service Fabric endpoint -->
<Endpoints>
    <Endpoint Protocol="http" Name="ServiceEndpoint" Type="Input" Port="8002" />
</Endpoints>

Na rozdíl od role cloudové služby Service Fabric služby v rámci stejného uzlu. Proto musí každá služba naslouchat na odlišném portu. Dále v tomto článku probereme, jak se požadavky klientů na portu 80 nebo 443 směrují na správný port pro službu.

Služba musí explicitně vytvářet naslouchací objekty pro každý koncový bod. Důvodem je to, že Service Fabric na komunikačních zásobníkech agnostická. Další informace najdete v tématu Vytvoření front-endu webové služby pro vaši aplikaci pomocí ASP.NET Core.

Balení a konfigurace

Cloudová služba obsahuje následující konfigurační soubory a soubory balíčků:

Existuje jeden soubor .csdef pro celou aplikaci. Můžete mít více souborů .cscfg pro různá prostředí, jako je místní, testovací nebo produkční. Pokud je služba spuštěná, můžete aktualizovat .cscfg, ale ne .csdef. Další informace najdete v tématu Co je model cloudové služby a jak ho zabalit?

Service Fabric má podobné rozdělení mezi definici služby a nastavení služby, ale struktura je podrobnější. Abyste porozuměli Service Fabric modelu aplikace, pomůže vám to pochopit, jak je Service Fabric zabalená aplikace. Tady je struktura:

Application package
  - Service packages
    - Code package
    - Configuration package
    - Data package (optional)

Balíček aplikace je to, co nasadíte. Obsahuje jeden nebo více balíčků služeb. Balíček služby obsahuje kód, konfiguraci a datové balíčky. Balíček kódu obsahuje binární soubory pro služby a konfigurační balíček obsahuje nastavení konfigurace. Tento model umožňuje upgradovat jednotlivé služby bez opětovného nasazení celé aplikace. Umožňuje také aktualizovat jenom nastavení konfigurace bez opětovného nasazení kódu nebo restartování služby.

Aplikace Service Fabric obsahuje následující konfigurační soubory:

Další informace najdete v tématu Modelování aplikace v Service Fabric.

Pokud chcete podporovat různá nastavení konfigurace pro více prostředí, použijte následující přístup, který je popsaný v článku Správa parametrů aplikace pro více prostředí:

1. Definujte nastavení v Setting.xml souboru pro službu.
2. V manifestu aplikace definujte přepsání nastavení.
3. Nastavení specifická pro prostředí dejte do souborů parametrů aplikace.

Nasazení aplikace

Zatímco Azure Cloud Services je spravovaná služba, Service Fabric je modul runtime. Clustery s Service Fabric můžete vytvářet v mnoha prostředích, včetně Azure a místně. Následující diagram znázorňuje doporučené nasazení pro Azure:

Cluster Service Fabric se nasadí do škálovací sady virtuálních počítačů. Škálovací sady jsou Azure Compute, který je možné použít k nasazení a správě sady identických virtuálních počítačů.

Jak už bylo zmíněno, z bezpečnostních důvodů se doporučuje umístit webový server Kestrel za reverzní proxy server. Tento diagram znázorňuje Azure Application Gateway, což je služba Azure, která nabízí různé možnosti vyrovnávání zatížení vrstvy 7. Funguje jako služba reverzních proxy serverů, ukončuje připojení klienta a předává požadavky do back-endových koncových bodů. Můžete použít jiné řešení reverzního proxy serveru, například nginx.

Směrování vrstvy 7

V původní aplikaci Surveysjedna webová role naslouchá na portu 80 a druhá webová role naslouchá na portu 443.

Další možností je použít směrování vrstvy 7. Při tomto přístupu se různé cesty URL směruje na různá čísla portů na back-endu. Veřejný web může například používat cesty URL začínající na /public/ .

Mezi možnosti směrování vrstvy 7 patří:

• Použijte Application Gateway.
• Použijte síťové virtuální zařízení, například nginx.
• Napíšete vlastní bránu jako bez stavovou službu.

Zvažte tento přístup, pokud máte dvě nebo více služeb s veřejnými koncovými body HTTP, ale chcete, aby se zobrazily jako jedna lokalita s jedním názvem domény.

jedním z přístupů, které nedoporučujeme , je umožnit externím klientům odesílat požadavky prostřednictvím reverzního proxy serveruService Fabric. I když je to možné, reverzní proxy server je určený pro komunikaci mezi službami. Otevřením u externích klientů zpřístupníte jakoukoli službu spuštěnou v clusteru, která má koncový bod HTTP.

Typy uzlů a omezení umístění

V výše uvedeném nasazení jsou všechny služby spuštěné na všech uzlech. Můžete ale také seskupit služby, aby určité služby běžely jenom na konkrétních uzlech v rámci clusteru. Mezi důvody pro použití tohoto přístupu patří:

• Spouštějte některé služby na různých typech virtuálních počítačů. Například některé služby můžou být náročné na výpočetní výkon nebo vyžadují GPU. v clusteru Service Fabric můžete mít kombinaci typů virtuálních počítačů.
• Z bezpečnostních důvodů izolujte front-endové služby z back-endové služby. Všechny front-endové služby se spustí na jedné sadě uzlů a back-endové služby se spustí na různých uzlech ve stejném clusteru.
• Různé požadavky na škálování. Některé služby můžou být potřeba spustit na více uzlech než jiné služby. Například pokud definujete uzly front-end a back-endové uzly, jednotlivé sady lze škálovat nezávisle.

Následující diagram znázorňuje cluster, který odděluje front-end a back-endové služby:

Postup implementace tohoto přístupu:

1. Při vytváření clusteru definujte dva nebo více typů uzlů.
2. Pro každou službu použijte omezení umístění k přiřazení služby k typu uzlu.

Při nasazení do Azure se každý typ uzlu nasadí do samostatné sady škálování virtuálních počítačů. cluster Service Fabric zahrnuje všechny typy uzlů. další informace najdete v tématu vztah mezi Service Fabric typy uzlů a sady škálování virtuálních počítačů.

Pokud má cluster více typů uzlů, jeden typ uzlu je určen jako primární typ uzlu. služby Service Fabric runtime, jako je třeba služba pro správu clusteru, se spouštějí v primárním typu uzlu. V produkčním prostředí zřídí aspoň 5 uzlů pro typ primárního uzlu. Druhý typ uzlu by měl mít aspoň dva uzly.

Konfigurace a Správa clusteru

Clustery musí být zabezpečené, aby se zabránilo neautorizovaným uživatelům v připojení ke clusteru. Doporučuje se použít Azure AD k ověřování klientů a certifikátů X. 509 pro zabezpečení mezi uzly. Další informace najdete v tématu Scénáře zabezpečení clusteru Service Fabric.

Pokud chcete nakonfigurovat veřejný koncový bod HTTPS, přečtěte si téma určení prostředků v manifestu služby.

Kapacitu aplikace můžete škálovat přidáním virtuálních počítačů do clusteru. Sada škálování virtuálních počítačů podporuje automatické škálování pomocí pravidel automatického škálování založených na čítačích výkonu. další informace najdete v tématu horizontální navýšení nebo navýšení kapacity Service Fabric clusteru pomocí pravidel automatického škálování.

I když je cluster spuštěný, Shromážděte protokoly ze všech uzlů v centrálním umístění. Další informace najdete v tématu shromáždění protokolů pomocí Azure Diagnostics.

Refaktoring aplikace

po přepravení aplikace na Service Fabric je dalším krokem refaktorování na podrobnější architekturu. Motivace Tailspin pro refaktoring usnadňuje vývoj, sestavování a nasazování aplikací pro průzkumy. Díky deformování existující webové role a rolí pracovních procesů na podrobnější architekturu chce Tailspin odebrat existující úzce propojenou komunikaci a závislosti dat mezi těmito rolemi.

Tailspin se dohlíží na další výhody při přesunu aplikace průzkumů do podrobnější architektury:

• Každou službu lze zabalit do nezávislých projektů s rozsahem, který je dostatečně malý, aby je bylo možné spravovat malým týmem.
• Každá služba může mít nezávisle a nasazenou verzi.
• Každou službu je možné implementovat pomocí nejlepší technologie pro danou službu. Cluster Service Fabric může například zahrnovat služby sestavené pomocí různých verzí rozhraní .NET Framework, Java nebo jiných jazyků, jako je C nebo C++.
• Každou službu je možné nezávisle škálovat, aby odpovídala zvýšení a snížení zátěže.

Zdrojový kód pro refaktoring verze aplikace je k dispozici na GitHub.

Na co dát pozor při navrhování

Následující diagram znázorňuje architekturu aplikace Průzkums refaktored na podrobnější architekturu:

Tailspin. Web je bezstavová služba pro samoobslužnou hostování ASP.NET aplikace MVC, kterou zákazníci Tailspin navštíví k vytváření průzkumů a zobrazování výsledků průzkumu. tato služba sdílí většinu svého kódu s Tailspin. webové služby z portované Service Fabric aplikace. jak už bylo zmíněno dříve, tato služba používá ASP.NET core a přepínače z použití Kestrel jako webového front-endu k implementaci weblistenu.

Tailspin. Web. Survey. Public je bezstavová služba, která je také samoobslužně hostuje ASP.NET web MVC. Uživatelé navštíví tento web, aby vybrali průzkumy ze seznamu a pak je vyplnili. tato služba sdílí většinu svého kódu se službou Tailspin. Web. Survey. Public z portu Service Fabric. tato služba také používá ASP.NET Core a také přepne z použití Kestrel jako webového front-endu na implementaci weblistenu.

Tailspin. SurveyResponseService je stavová služba, která ukládá odpovědi na průzkum v Azure Blob Storage. Slučuje také odpovědi na data analýzy průzkumu. Služba je implementována jako stavová služba, protože používá ReliableConcurrentQueue ke zpracování odpovědí na průzkum v dávkách. tato funkce byla původně implementována ve službě Tailspin. AnswerAnalysisService v ported Service Fabric.

Tailspin. SurveyManagementService je Bezstavová služba, která ukládá a načítá průzkumy a otázky průzkumu. Služba využívá úložiště objektů BLOB v Azure. tato funkce byla také původně implementována v součástech pro přístup k datům aplikací Tailspin. web a Tailspin. web. Survey. Public services v portech Service Fabric. Tailspin Refaktorovat původní funkce do této služby, aby bylo možné nezávisle škálovat.

Tailspin. SurveyAnswerService je Bezstavová služba, která načte odpovědi na průzkum a analýzu průzkumu. Služba také využívá úložiště objektů BLOB v Azure. tato funkce byla také původně implementována v součástech pro přístup k datům služby Tailspin. Web v portech, které jsou ve Service Fabric. Tailspin Refaktorovat původní funkce do této služby, protože očekává menší zatížení a chce použít méně instancí k úspoře prostředků.

Tailspin. SurveyAnalysisService je Bezstavová služba, která uchovává souhrnná data odpovědí na průzkum v mezipaměti Redis pro rychlé načítání. Tato služba je volána rozhraním Tailspin. SurveyResponseService pokaždé, když je průzkum zodpovězený, a nová data odpovědi průzkumu se sloučí do souhrnných dat. tato služba zahrnuje funkce původně implementované ve službě Tailspin. AnswerAnalysisService z portované Service Fabric.

Bezstavově oproti stavovým službám

Azure Service Fabric podporuje následující programovací modely:

• hostující spustitelný model umožňuje, aby byl spustitelný soubor zabalen jako služba a nasazený do clusteru Service Fabric. Service Fabric orchestruje a spravuje spouštění hostovaného spustitelného souboru.
• Kontejnerový model umožňuje nasazení služeb v imagí kontejnerů. Service Fabric podporuje vytváření a správu kontejnerů nad kontejnery jádra systému Linux a také kontejnery Windows serveru.
• programovací model reliable services umožňuje vytvářet bezstavové nebo stavové služby, které se integrují se všemi funkcemi Service Fabric platformy. stavové služby umožňují uložit replikovaný stav do clusteru Service Fabric. Bezstavové služby se nepodporují.
• Programovací model Reliable Actors umožňuje vytváření služeb, které implementují vzor virtuálního objektu actor.

Všechny služby v aplikaci průzkumy jsou bezstavové služby spolehlivé, s výjimkou služby Tailspin. SurveyResponseService . Tato služba implementuje ReliableConcurrentQueue ke zpracování odpovědí na průzkum při jejich přijetí. odpovědi v ReliableConcurrentQueue se ukládají do Azure Blob Storage a předávají se do Tailspin. SurveyAnalysisService pro účely analýzy. Tailspin zvolí ReliableConcurrentQueue, protože odpovědi nevyžadují striktní Service Bus řazení FIFO (First-in-first-out-first-out-first-out-first-out-first-out-first-out-First- ReliableConcurrentQueue je také navržený tak, aby poskytoval vysokou propustnost a nízkou latenci pro operace front a requeue.

Operace trvalého uložení položek z ReliableConcurrentQueue do fronty by měly být v ideálním případě idempotentní. Pokud je při zpracování položky z fronty vyvolána výjimka, může být stejná položka zpracována více než jednou. V aplikaci Průzkums není operace sloučení odpovědí do Tailspin. SurveyAnalysisService idempotentní, protože Tailspin rozhodla, že data analýzy průzkumu jsou pouze aktuálním snímkem dat analýzy a nemusí být konzistentní. odpovědi na průzkum uložené do služby Azure Blob Storage jsou nakonec konzistentní, takže výsledná analýza dotazníku může být z těchto dat vždy přepočítána správně.

Komunikační rozhraní

Každá služba v aplikaci průzkumy komunikuje pomocí webového rozhraní API RESTful. Rozhraní API RESTful nabízejí následující výhody:

• snadné použití: každá služba je sestavená pomocí ASP.NET Core MVC, která nativně podporuje vytváření webových rozhraní api.
• Zabezpečení: i když každá služba nevyžaduje protokol SSL, Tailspin může vyžadovat, aby každá z těchto služeb mohla.
• Správa verzí: klienti se můžou zapisovat a testovat na konkrétní verzi webového rozhraní API.

Služby v aplikaci průzkumu používají reverzní proxy implementované pomocí Service Fabric. reverzní proxy je služba, která běží na každém uzlu v clusteru Service Fabric a poskytuje překlad koncových bodů, automatické opakování a zpracovává jiné typy selhání připojení. Pro použití reverzního proxy serveru se každé volání rozhraní API RESTful k určité službě provádí pomocí předdefinovaného portu reverzního proxy serveru. Pokud je například port reverzního proxy serveru nastaven na 19081, může být volání Tailspin. SurveyAnswerService provedeno takto:

static SurveyAnswerService()
{
    httpClient = new HttpClient
    {
        BaseAddress = new Uri("http://localhost:19081/Tailspin/SurveyAnswerService/")
    };
}

pokud chcete povolit reverzní proxy server, během vytváření clusteru Service Fabric zadejte port reverzního proxy serveru. Další informace najdete v tématu reverzní proxy server v Azure Service Fabric.

Otázky výkonu

Tailspin vytvořila služby ASP.NET Core services for Tailspin. web a Tailspin. web. prohlídky. Public pomocí šablon Visual Studio. Ve výchozím nastavení tyto šablony obsahují protokolování do konzoly nástroje. Protokolování do konzoly lze provést během vývoje a ladění, ale při nasazení aplikace do produkčního prostředí by se mělo odebrat veškeré protokolování do konzoly.

Například následující řádky v Startup. cs pro každou front-end služby by měly být zakomentovány:

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    //loggerFactory.AddConsole(Configuration.GetSection("Logging"));
    //loggerFactory.AddDebug();

    app.UseMvc();
}

nakonec, když Tailspin nasadí aplikaci Tailspin do produkčního prostředí, přepne Visual Studio do režimu vydání .

Aspekty nasazování

Aplikace refaktoringických průzkumů se skládá z pěti bezstavových služeb a jedné stavové služby, takže plánování clusteru je omezené na určení správné velikosti virtuálních počítačů a počtu uzlů. V souboru applicationmanifest.xml , který popisuje cluster, Tailspin nastaví atribut InstanceCount značky StatelessService na-1 pro každou ze služeb. hodnota-1 směřuje Service Fabric k vytvoření instance služby na každém uzlu v clusteru.

Tailspin nasadí cluster pomocí Azure Portal. typ prostředku Service Fabric clusteru nasadí veškerou nezbytnou infrastrukturu, včetně virtuálních počítačů scale sets a nástroje pro vyrovnávání zatížení. doporučené velikosti virtuálních počítačů se zobrazí v Azure Portal během procesu zřizování pro cluster Service Fabric. Vzhledem k tomu, že virtuální počítače jsou nasazené v rámci sady škálování virtuálních počítačů, můžou se při zvyšování zátěže uživatelů škálovat jak nahoru, tak i ven.

Další kroky

Kód aplikace průzkumy je k dispozici na GitHub.

pokud začínáte s Azure Service Fabric, nejdřív nastavte vývojové prostředí a pak stáhněte nejnovější sadu azure sdk a sadu azure Service Fabric SDK. Sada SDK zahrnuje Správce clusteru OneBox, abyste mohli místně nasadit a testovat aplikaci pro průzkum pomocí úplného ladění F5.