Volba výpočetní možnosti Azure pro mikroslužby
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. U architektury mikroslužeb jsou obzvláště oblíbené dva přístupy:
- Orchestrátor služeb, který spravuje služby běžící na vyhrazených uzlech (virtuálních počítačech).
- Architektura bez serveru využívající funkce jako službu (FaaS)
I když to nejsou jediné možnosti, jedná se o 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é není v pořádku, vyrovnávání zatížení síťového provozu napříč instancemi služby, 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řídí Kubernetes a zpřístupní 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 myslet jako na "rozhraní API Kubernetes jako službu".
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í Reliable Services programovacího modelu mohou služby přímo používat programovací rozhraní API k dotazování systému, hlášení stavu, přijímání oznámení o konfiguraci Service Fabric změnách kódu Service Fabric zjišťování dalších služeb. Klíčovým rozdílem u Service Fabric je jeho silné zaměření na vytváření stavových služeb pomocí Reliable Collections.
Další možnosti, například Docker edice Enterprise a Mesosphere DC/OS, mohou běžet v prostředí IaaS v Azure. Šablony nasazení najdete na webu Azure Marketplace.
Kontejnery
Někdy lidé mluví o kontejnerech a mikroslužbách, jako by byly stejné. I když to není pravda, k vytváření kontejnerů mikroslužeb nepotřebujete kontejnery, mají určité výhody, které jsou zvláště relevantní pro — — mikroslužby, například:
Přenositelnost: Image kontejneru je samostatný balíček, který běží bez nutnosti instalovat knihovny nebo jiné závislosti. To usnadňuje jejich nasazení. Kontejnery je možné rychle spustit a zastavit, takže můžete zúžením nových instancí zvládnout větší zatížení nebo zotavit se ze selhání uzlu.
Hustota. Kontejnery jsou zjednodušené v porovnání se spuštěním virtuálního počítače, 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 se aplikace skládá z mnoha malých služeb.
Izolace prostředků. Můžete omezit množství paměti a procesoru, které je k dispozici pro kontejner, což může pomoct zajistit, aby neschycený proces nevyčerpal prostředky hostitele. Další informace najdete v tématu Model Bulkhead.
Bez serveru (funkce jako služba)
S architekturou bez serveru nespravuje 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 nasadí do virtuálního počítače a jeho spuštění. Tento přístup obvykle upřednostňuje malé podrobné funkce, které jsou koordinované pomocí aktivačních událostí 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 výpočetní služba bez serveru, která podporuje různé triggery funkcí, včetně požadavků HTTP, Service Bus front a Event Hubs událostí. Úplný seznam najdete v tématu Azure Functions triggerya vazby. Zvažte také Azure Event Grid, což je spravovaná služba směrování událostí v Azure.
Orchestrator nebo bez serveru?
Tady je několik faktorů, které je třeba vzít v úvahu při volbě mezi přístupem orchestrátoru a bez serveru.
Možnosti správy Bez serveru se aplikace snadno spravuje, protože platforma spravuje všechny výpočetní prostředky za vás. Orchestrátor sice abstrahuje některé aspekty správy a konfigurace clusteru, ale neskrývá úplně základní virtuální počítače. S orchestrátorem budete muset přemýšlet o problémech, jako je vyrovnávání zatížení, využití procesoru a paměti a sítě.
Flexibilita a řízení. Orchestrátor poskytuje velkou kontrolu nad konfigurací a správou služeb a clusteru. Tento kompromis je složitější. S architekturou bez serveru se můžete trochu řídit, protože tyto podrobnosti jsou abstrahované.
Přenositelnost: Všechny orchestrátory uvedené tady (Kubernetes, DC/OS, Docker Swarm a Service Fabric) mohou běžet místně nebo v několika veřejných cloudech.
Integrace aplikací. Vytvoření komplexní aplikace pomocí bez serveru 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 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.
Cost (Náklady). S orchestrátorem platíte za virtuální počítače, které v clusteru běží. U aplikace bez serveru platíte jenom za skutečně spotřebované výpočetní prostředky. V obou případech musíte přihlížet k nákladům na 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 škálovat na více instancí zvýšením počtu instancí služeb spuštěných v clusteru. Můžete také škálovat přidáním dalších virtuálních počítače do clusteru.
Naše referenční implementace primárně používá Kubernetes, ale pro jednu Azure Functions, konkrétně pro službu Delivery History, jsme Azure Functions službu Delivery History. Azure Functions se pro tuto konkrétní službu dobře hodí, protože se jedná o úlohu řízenou událostmi. Pomocí triggeru Event Hubs k vyvolání funkce služba potřebovala minimální množství kódu. Služba Historie doručení navíc není součástí hlavního pracovního postupu, takže spuštění mimo cluster Kubernetes nemá vliv na koncovou latenci operací zahájených uživatelem.