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. Pro architekturu mikroslužeb jsou zvláště oblíbené dva přístupy:
- Orchestrátor služeb, který spravuje služby spuštěné na vyhrazených uzlech (VM).
- Bezserverová architektura využívající funkce jako službu (FaaS).
I když se nejedná o jediné možnosti, jsou to oba 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, vyrovnávání zatížení síťového provozu mezi 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ř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í service Fabric je silné zaměření na vytváření stavových služeb pomocí Reliable Collections.
Další možnosti, jako je Docker edice Enterprise, se můžou spouštět 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 stejnou věc. I když to není pravda – ke sestavování mikroslužeb nepotřebujete kontejnery – 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ý se spouští bez nutnosti instalovat knihovny nebo jiné závislosti. Díky tomu se dají snadno nasadit. Kontejnery je možné rychle spustit a zastavit, takže můžete zahajovat nové instance pro zpracování většího zatížení nebo zotavení při selhání uzlů.
Hustota. Kontejnery jsou ve srovnání se spuštěním virtuálního počítače odlehčené, protože sdílejí prostředky operačního systému. To umožňuje zabalit více kontejnerů do jednoho uzlu, což je zvlášť užitečné, když 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 proces spuštění nevyčerpal hostitelské prostředky. Další informace najdete v modelu Bulkhead.
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 umístí na virtuální počítač a spustí ho. Tento přístup obvykle upřednostňuje malé podrobné funkce, které jsou koordinované 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 zpracuje zprávu.
Azure Functions je bezserverová výpočetní služba, která podporuje různé triggery funkcí, včetně požadavků HTTP, front Service Bus a událostí služby Event Hubs. Úplný seznam najdete v tématu Koncepty triggerů a vazeb Azure Functions. Zvažte také Azure Event Grid, což je spravovaná služba směrování událostí v Azure.
Orchestrator nebo bezserverová?
Tady je několik faktorů, které je potřeba zvážit při výběru mezi přístupem orchestrátoru a bezserverovým přístupem.
Spravovatelnost bezserverové aplikace je snadná správa, protože platforma spravuje všechny výpočetní prostředky za vás. Zatímco orchestrátor abstrahuje některé aspekty správy a konfigurace clusteru, neskryje ú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. Kompromis je další složitost. Díky bezserverové architektuře se vzdáte určitého stupně kontroly, protože tyto podrobnosti jsou abstrahovány.
Přenositelnost: Všechny orchestrátory uvedené zde (Kubernetes, DC/OS, Docker Swarm a Service Fabric) můžou spouštět místně nebo v několika veřejných cloudech.
Integrace aplikací. Sestavení složité aplikace pomocí 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žití 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: S orchestrátorem platíte za virtuální počítače spuštěné v clusteru. S bezserverovou aplikací platíte jenom za skutečné výpočetní prostředky spotřebované. V oboupřípadechch
Škálovatelnost: Azure Functions se škáluje automaticky tak, aby splňovala poptávku na základě počtu příchozích událostí. Pomocí orchestrátoru můžete vertikálně navýšit kapacitu 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čů do clusteru.
Naše referenční implementace primárně používá Kubernetes, ale službu Azure Functions jsme použili pro jednu službu, konkrétně službu Historie doručení. Služba Azure Functions byla vhodná pro tuto konkrétní službu, protože se jedná o úlohu řízenou událostmi. Pomocí triggeru služby Event Hubs k vyvolání funkce 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 koncovou latenci operací iniciovaných uživatelem.