Sdílet prostřednictvím

Architektura mikroslužeb

  • Článek

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.

Stáhnout PDF

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Jak už název napovídá, architektura mikroslužeb představuje přístup k vytvoření serverové aplikace jako sady malých služeb. To znamená, že architektura mikroslužeb je zaměřená hlavně na back-end, i když se tento přístup používá také pro front-end. Každá služba běží ve vlastním procesu a komunikuje s jinými procesy pomocí protokolů, jako jsou HTTP/HTTPS, WebSockets nebo AMQP. Každá mikroslužba implementuje konkrétní komplexní doménu nebo obchodní funkce v rámci určité kontextové hranice a každá z nich musí být vyvinuta samostatně a musí být nasaditelná nezávisle. Každá mikroslužba by měla mít svůj související doménový datový model a logiku domény (suverenitu a decentralizovanou správu dat) a může být založená na různých technologiích úložiště dat (SQL, NoSQL) a různých programovacích jazycích.

Jaká velikost by měla být mikroslužba? Při vývoji mikroslužby by velikost neměla být důležitým bodem. Důležité místo toho by mělo být vytvoření volně propojených služeb, abyste měli samostatnost vývoje, nasazení a škálování pro každou službu. Samozřejmě, když identifikujete a navrhujete mikroslužby, měli byste je zkusit co nejmenší, pokud nemáte příliš mnoho přímých závislostí s jinými mikroslužbami. Důležitější než velikost mikroslužby je vnitřní soudržnost, která musí mít a její nezávislost na jiných službách.

Proč architektura mikroslužeb? Stručně řečeno, poskytuje dlouhodobou flexibilitu. Mikroslužby umožňují lepší udržovatelnost ve složitých, rozsáhlých a vysoce škálovatelných systémech tím, že umožňují vytvářet aplikace založené na mnoha nezávisle nasazovatelných službách, které mají podrobné a autonomní životní cyklus.

Jako další výhodu můžou mikroslužby nezávisle škálovat kapacitu. Místo jediné monolitické aplikace, kterou musíte škálovat jako jednotku, můžete místo toho škálovat konkrétní mikroslužby. Tímto způsobem můžete škálovat pouze funkční oblast, která potřebuje větší výpočetní výkon nebo šířku pásma sítě, aby podporovala poptávku, a ne horizontální navýšení kapacity jiných oblastí aplikace, které není potřeba škálovat. To znamená úsporu nákladů, protože potřebujete méně hardwaru.

Diagram of the differences between the two deployment methods.

Obrázek 4–6 Monolitické nasazení versus přístup k mikroslužbám

Jak ukazuje obrázek 4 až 6, v tradičním monolitickém přístupu se aplikace škáluje klonováním celé aplikace na několika serverech nebo virtuálních počítačích. V přístupu k mikroslužbám se funkce oddělují v menších službách, takže každá služba může škálovat nezávisle. Přístup k mikroslužbám umožňuje agilní změny a rychlé iterace jednotlivých mikroslužeb, protože můžete měnit specifické, malé oblasti složitých, velkých a škálovatelných aplikací.

Navrhování jemně odstupňovaných aplikací založených na mikroslužbách umožňuje kontinuální integraci a postupy průběžného doručování. Také zrychluje doručování nových funkcí do aplikace. Jemně odstupňované složení aplikací také umožňuje spouštět a testovat mikroslužby izolovaně a vyvíjet je samostatně a přitom udržovat jasné kontrakty mezi nimi. Pokud rozhraní ani kontrakty nezměníte, můžete změnit interní implementaci jakékoli mikroslužby nebo přidat nové funkce bez přerušení jiných mikroslužeb.

Následující důležité aspekty, které umožňují úspěšné uvedení do produkčního prostředí se systémem založeným na mikroslužbách:

  • Monitorování a kontroly stavu služeb a infrastruktury

  • Škálovatelná infrastruktura pro služby (tj. cloudové a orchestrátory).

  • Návrh a implementace zabezpečení na více úrovních: ověřování, autorizace, správa tajných kódů, zabezpečená komunikace atd.

  • Rychlé doručování aplikací, obvykle s různými týmy, které se zaměřují na různé mikroslužby.

  • Postupy a infrastruktura pro DevOps a CI/CD

Z těchto možností se v této příručce probírá nebo zavádí pouze první tři. Poslední dva body, které souvisejí s životním cyklem aplikace, jsou popsány v dodatečném kontejnerizovaném životním cyklu aplikace Dockeru pomocí elektronické knihy Microsoft Platform and Tools .

Další materiály

PředchozíDalší