Logická architektura vs. fyzická architektura
Tip
Tento obsah je výňatek z eBooku, architektury mikroslužeb .NET pro kontejnerizované aplikace .NET, které jsou k dispozici na .NET Docs nebo jako zdarma ke stažení PDF, které lze číst offline.
V tomto okamžiku je užitečné zastavit a prodiskutovat rozdíl mezi logickou architekturou a fyzickou architekturou a jak to platí pro návrh aplikací založených na mikroslužbách.
Začněme tím, že vytváření mikroslužeb nevyžaduje použití žádné konkrétní technologie. Kontejnery Dockeru například nejsou povinné k vytvoření architektury založené na mikroslužbách. Tyto mikroslužby se můžou spouštět také jako prosté procesy. Mikroslužby jsou logickou architekturou.
Navíc i v případě, že by mikroslužba mohla být fyzicky implementována jako jedna služba, proces nebo kontejner (kvůli jednoduchosti, to je přístup přijatý v počáteční verzi eShopOnContainers), tato parita mezi obchodními mikroslužbami a fyzickými službami nebo kontejnery nemusí nutně vyžadovat ve všech případech, když vytváříte velkou a složitou aplikaci složenou z mnoha desítek nebo dokonce stovek služeb.
Tady je rozdíl mezi logickou architekturou aplikace a fyzickou architekturou. Logická architektura a logické hranice systému nemusí nutně mapovat 1:1 na architekturu fyzického nebo nasazení. Může se to stát, ale často ne.
I když jste možná identifikovali určité obchodní mikroslužby nebo ohraničené kontexty, neznamená to, že nejlepším způsobem jejich implementace je vždy vytvoření jedné služby (například webového rozhraní API ASP.NET) nebo jednoho kontejneru Dockeru pro každou obchodní mikroslužbu. Pravidlo, které říká, že každá obchodní mikroslužba musí být implementována pomocí jedné služby nebo kontejneru, je příliš pevná.
Obchodní mikroslužba nebo ohraničený kontext je tedy logická architektura, která se může shodovat (nebo ne) s fyzickou architekturou. Důležitým bodem je to, že obchodní mikroslužba nebo ohraničený kontext musí být autonomní tím, že umožní, aby kód a stav byly nezávisle na verzích, nasazené a škálované.
Jak ukazuje obrázek 4–8, obchodní mikroslužba katalogu se může skládat z několika služeb nebo procesů. Může se jednat o více služeb webového rozhraní API ASP.NET nebo jakéhokoli jiného typu služeb používajících protokol HTTP nebo jiný protokol. Důležitější je, že služby můžou sdílet stejná data, pokud jsou tyto služby soudržné s ohledem na stejnou obchodní doménu.
Obrázek 4–8 Firemní mikroslužba s několika fyzickými službami
Služby v příkladu sdílejí stejný datový model, protože služba webového rozhraní API cílí na stejná data jako Search. Ve fyzické implementaci obchodní mikroslužby tedy tuto funkci rozdělíte, abyste mohli podle potřeby škálovat každou z těchto interních služeb nahoru nebo dolů. Možná služba webového rozhraní API obvykle potřebuje více instancí než Search nebo naopak.
Stručně řečeno, logická architektura mikroslužeb se nemusí vždy shodovat s architekturou fyzického nasazení. V této příručce vždy, když zmíníme mikroslužbu, znamenáme obchodní nebo logickou mikroslužbu, která by se mohla mapovat na jednu nebo více (fyzických) služeb. Ve většině případů to bude jedna služba, ale může to být více.
