Volba možnosti výpočetních prostředků Azure pro mikroslužby

  • Článek

Pojem výpočetní prostředí odkazuje na model hostingu pro výpočetní prostředky, na kterých se bude vaše aplikace spouštět. Pro architekturu mikroslužeb jsou obzvláště oblíbené dva přístupy:

  • Orchestrátor služeb, který spravuje služby spuštěné na vyhrazených uzlech (virtuálních počítačích).
  • Bezserverová architektura využívající funkce jako službu (FaaS).

I když to nejsou jediné možnosti, oba jsou to osvědčené přístupy k vytváření mikroslužeb. Aplikace může zahrnovat oba přístupy.

Orchestrátory služeb

Orchestrátor zpracovává úlohy související s nasazením a správou sady služeb. Mezi tyto úlohy patří umístění služeb na uzly, monitorování stavu služeb, restartování služeb, které nejsou v pořádku, vyrovnávání zatížení síťového provozu mezi instancemi služeb, zjišťování služeb, škálování počtu instancí služby a použití aktualizací konfigurace. Mezi oblíbené orchestrátory patří Kubernetes, Service Fabric, DC/OS a Docker Swarm.

Na platformě Azure zvažte následující možnosti:

  • Azure Kubernetes Service (AKS) je spravovaná služba prostředí Kubernetes. AKS zřizuje Kubernetes a zveřejňuje koncové body rozhraní Kubernetes API, ale hostuje a spravuje řídicí rovinu Kubernetes, provádí automatizované upgrady, automatizované opravy, automatické škálování a další úlohy správy. AKS si můžete představit jako "rozhraní API Kubernetes jako služba".

  • Azure Container Apps je spravovaná služba založená na Kubernetes, která abstrahuje složitost orchestrace kontejnerů a dalších úloh správy. Container Apps zjednodušuje nasazení a správu kontejnerizovaných aplikací a mikroslužeb v bezserverovém prostředí a současně poskytuje funkce Kubernetes.

  • Service Fabric je platforma distribuovaných systémů pro balení, nasazování a správu mikroslužeb. Mikroslužby je možné nasadit do Service Fabric jako kontejnery, jako binární spustitelné soubory nebo jako Reliable Services. Pomocí programovacího modelu Reliable Services můžou služby přímo používat rozhraní API pro programování Service Fabric k dotazování systému, hlášení stavu, přijímání oznámení o změnách konfigurace a kódu a zjišťování dalších služeb. Klíčovou diferenciací ve službě Service Fabric je silné zaměření na vytváření stavových služeb pomocí reliable collections.

  • Další možnosti, jako je Docker edice Enterprise, můžou běžet v prostředí IaaS v Azure. Šablony nasazení najdete na Azure Marketplace.

Kontejnery

Někdy lidé mluví o kontejnerech a mikroslužbách, jako by šlo o totéž. I když to není pravda – k vytváření mikroslužeb nepotřebujete kontejnery – kontejnery mají některé výhody, které jsou pro mikroslužby obzvláště důležité, například:

  • Přenositelnost. Image kontejneru je samostatný balíček, který běží bez nutnosti instalovat knihovny nebo jiné závislosti. Díky tomu se snadno nasazují. Kontejnery je možné rychle spustit a zastavit, takže můžete aktivovat nové instance, abyste zvládli větší zatížení nebo se zotavili z selhání uzlů.

  • Hustota. Kontejnery jsou ve srovnání se spuštěním virtuálního počítače zjednodušené, protože sdílejí prostředky operačního systému. To umožňuje zabalit více kontejnerů do jednoho uzlu, což je užitečné zejména v případě, že aplikace sestává z mnoha malých služeb.

  • Izolace prostředků. Můžete omezit množství paměti a procesoru, které je pro kontejner k dispozici, což může pomoct zajistit, že běhový proces nevyčerpá prostředky hostitele. Další informace najdete v modelu Přepážky .

Bezserverová služba (funkce jako služba)

S bezserverovou architekturou nespravujete virtuální počítače ani infrastrukturu virtuální sítě. Místo toho nasadíte kód a hostitelská služba tento kód vloží do virtuálního počítače a spustí ho. Tento přístup má tendenci upřednostňovat malé podrobné funkce, které jsou koordinovány pomocí triggerů založených na událostech. Například zpráva umístěná do fronty může aktivovat funkci, která čte z fronty a zpracovává zprávu.

Azure Functions je bezserverová výpočetní služba, která podporuje různé triggery funkcí, včetně požadavků HTTP, front služby Service Bus a událostí služby Event Hubs. Úplný seznam najdete v tématu Azure Functions konceptů triggerů a vazeb. Zvažte také Azure Event Grid, což je spravovaná služba směrování událostí v Azure.

Orchestrator nebo bezserverový?

Tady jsou některé faktory, které je potřeba vzít v úvahu při volbě mezi přístupem orchestrátoru a bezserverovým přístupem.

Správy Bezserverová aplikace se snadno spravuje, protože platforma spravuje všechny výpočetní prostředky za vás. I když orchestrátor abstrahuje některé aspekty správy a konfigurace clusteru, zcela neskrývá základní virtuální počítače. U orchestrátoru budete muset myslet na problémy, jako je vyrovnávání zatížení, využití procesoru a paměti a sítě.

Flexibilita a řízení. Orchestrátor vám poskytuje velkou kontrolu nad konfigurací a správou služeb a clusteru. Kompromisem je další složitost. S architekturou bez serveru se vzdáte určitého stupně kontroly, protože tyto podrobnosti jsou abstrahované.

Přenositelnost. Všechny zde uvedené orchestrátory (Kubernetes, DC/OS, Docker Swarm a Service Fabric) můžou běžet místně nebo ve více veřejných cloudech.

Integrace aplikací. Vytvoření složité aplikace s využitím bezserverové architektury může být náročné, protože je potřeba koordinovat, nasazovat a spravovat mnoho malých nezávislých funkcí. Jednou z možností v Azure je použít Azure Logic Apps ke koordinaci sady Azure Functions. Příklad tohoto přístupu najdete v tématu Vytvoření funkce, která se integruje s Azure Logic Apps.

Náklady. Pomocí orchestrátoru platíte za virtuální počítače, které běží v clusteru. U bezserverové aplikace platíte jenom za skutečně spotřebované výpočetní prostředky. V obou případech musíte zohlednit náklady na všechny další služby, jako jsou úložiště, databáze a služby zasílání zpráv.

Škálovatelnost: Azure Functions se automaticky škáluje podle poptávky na základě počtu příchozích událostí. S orchestrátorem můžete vertikálně navýšit kapacitu zvýšením počtu instancí služeb spuštěných v clusteru. Škálování můžete také provést přidáním dalších virtuálních počítačů do clusteru.

Naše referenční implementace primárně používá Kubernetes, ale Azure Functions jsme použili pro jednu službu, konkrétně službu Historie doručení. Azure Functions byla vhodná pro tuto konkrétní službu, protože se jedná o úlohu řízenou událostmi. K vyvolání funkce pomocí triggeru služby Event Hubs potřebovala služba minimální množství kódu. Služba Historie doručení také není součástí hlavního pracovního postupu, takže její spuštění mimo cluster Kubernetes nemá vliv na latenci operací iniciovaných uživatelem.

Další kroky

Komunikace mezi službami