Monolitická architektura a architektura mikroslužeb

Dokončeno

Společnost Fabrikam integruje svou novou službu dronů do své stávající aplikace. Uvědomuje si, že toto řešení nepředstavuje vhodný dlouhodobý plán pro jejich aplikaci. Stávající systém představuje monolitickou architekturu, ale co přesně to znamená?

Co je monolitická architektura?

Monolitická architektura je taková architektura, ve které jsou všechny komponenty příslušné aplikace umístěné společně v jedné jednotce. Tato jednotka je obvykle omezená na jednu instanci modulu runtime dané aplikace. Tradiční aplikace jsou často tvořeny webovým rozhraním, vrstvou služeb a datovou vrstvou. V monolitické architektuře jsou tyto vrstvy kombinovány v instanci dané aplikace.

Monolitické architektury jsou často vhodným řešením pro malé aplikace, ale při zvětšování aplikace se můžou stát těžkopádnými. Z původně malé aplikace se může rychle stát složitý systém, který se obtížně škáluje, nasazuje a inovuje.

Všechny služby se nacházejí v jedné jednotce. K problémům, které je potřeba řešit, dochází zejména při růstu firmy a následném zvyšování zatížení systému. Příklady problémů, které je potřeba řešit:

• Obtížné škálování služeb nezávisle na sobě
• Složitost vývoje a správy nasazení při nárůstu základu kódu, což zpomaluje vydávání verzí a implementaci nových funkcí
• Architektura je svázaná s jednou technologií, která omezuje inovace v nových platformách a sadách SDK.
• Aktualizace schémat dat můžou být stále obtížnější

Tyto problémy se dají řešit pomocí alternativních architektur, jako je například architektura mikroslužeb.

Co je architektura mikroslužeb?

Architektura mikroslužeb se skládá ze služeb, které jsou malé, nezávislé a volně na sebe navazují. Každou službu je možné nasadit a škálovat nezávisle.

Mikroslužba je dostatečně malá, aby ji mohl napsat a udržovat jeden malý tým vývojářů. Vzhledem k tomu, že služby je možné nasazovat nezávisle, může tým aktualizovat existující službu bez nového sestavení a opětovného nasazení celé aplikace.

Každá služba je obvykle za svoje vlastní data zodpovědná. Data mají izolovanou strukturu, takže upgrady nebo změny schématu nezávisejí na jiných službách. Požadavky na data jsou obvykle zpracovávány prostřednictvím rozhraní API. Podrobnosti interní implementace jsou příjemcům služby skryté.

Vzhledem k tomu, že je každá služba nezávislá, můžou služby využívat různé technologie, rozhraní a sady SDK. Služby se běžně spoléhají na volání REST pro komunikaci mezi službami pomocí dobře definovaných rozhraní API místo vzdálených volání procedur (RPC) nebo jiných vlastních komunikačních metod.

Architektury mikroslužeb jsou nezávislé na technologii, ale při jejich implementaci se často používají kontejnery nebo bezserverové technologie. Ke zvýšení rychlosti a kvality vývojových aktivit se často používají průběžné nasazování a kontinuální integrace (CI/CD).

Výhody architektury mikroslužeb

Proč byste měli zvolit architekturu mikroslužeb? Architektura mikroslužeb má několik hlavních výhod:

• Agilnost
• Malý kód, malé týmy
• Kombinace technologií
• Odolnost
• Škálovatelnost
• Izolace dat

Agilnost

Vzhledem k tomu, že mikroslužby se nasazují samostatně, mají jednodušší správu oprav chyb a vydávání funkcí. Můžete aktualizovat službu bez opětovného nasazení celá aplikace a pokud se něco nepovede, zase aktualizaci vrátit zpět. V mnoha tradičních aplikacích platí, že pokud se najde chyba v jedné části aplikace, může to blokovat celý proces vydání. V důsledku toho se může stát, že nové funkce se pozastaví a bude se čekat na integraci, otestování a publikování opravy chyb.

Malý kód, malé týmy

Mikroslužba by měla být dostatečně malá, aby ji mohl sestavit, testovat a nasadit jeden tým. Pochopení malého základu kódu je jednodušší. U rozsáhlých monolitických aplikací existuje určitá tendence k vytváření komplikovaných závislostí kódu. Přidání nových funkcí vyžaduje úpravy kódu na mnoha místech. Architektura mikroslužeb minimalizuje závislosti tím, že nesdílí kód nebo úložiště dat. Tím usnadňuje přidávání nových funkcí.

Malá velikost týmu také znamená větší flexibilitu. Pravidlo dvou pizz říká, že tým by měl být tak malý, aby se ze dvou pizz najedli všichni. Není to samozřejmě žádná přesná metrika a také závisí na apetitu týmu! Skutečností ale zůstává, že velké skupiny mají tendenci k nižší produktivitě, protože komunikace je pomalejší, zvyšují se režijní náklady a snižuje se flexibilita.

Kombinace technologií

Týmy si můžou vybrat technologie, které budou nejlépe vyhovovat jejich službě. Podle potřeby mohou využívat kombinaci technologií. Každý tým může nezávisle vyvíjet technologie, které příslušnou službu podporují. Vzhledem k této nezávislosti můžou služby používat různé vývojářské jazyky, cloudové služby, sady SDK a další možnosti. Týmy si můžou vybrat nejlepší možnosti pro svou službu a současně minimalizovat jakýkoli externí vliv na uživatele služby.

Odolnost

Pokud se jednotlivá mikroslužba stane nedostupnou, nenaruší celou aplikaci, pokud jsou všechny nadřazené mikroslužby navržené tak, aby správně zpracovávaly chyby (například implementací přerušení okruhu). Výhodou pro uživatele nebo uživatele služeb je pro vaši aplikaci nepřetržité prostředí.

Škálovatelnost

Architektura mikroslužeb umožňuje škálovat jednotlivé mikroslužby nezávisle na ostatních. Můžete horizontálně navýšit kapacitu subsystémů, které vyžadují více prostředků, a není nutné horizontálně navyšovat kapacitu celé aplikace. Toto uspořádání vylepšuje celkový výkon aplikace. Také pomáhá minimalizovat náklady. Další prostředky můžete přidávat pouze do služeb, které je potřebují, a nemusíte vertikálně navyšovat kapacitu celé aplikace.

Izolace dat

Architektura mikroslužeb zlepšuje možnost provádět aktualizace schémat dat, protože ovlivňuje jenom jednu mikroslužbu. V monolitické aplikaci můžou být aktualizace schémat náročné. Se stejnými daty můžou pracovat různé části aplikace, což pro jakoukoli změnu schématu představuje velké riziko. Můžete aktualizovat schéma, ale ponechat rozsah rozhraní API beze změny. Příjemci služeb tak budou mít stejné prostředí bez ohledu na architekturu podkladových dat.

Potenciální problémy architektury mikroslužeb

Architektura mikroslužeb má řadu výhod, ale nepředstavuje univerzální řešení. Má vlastní skupinu možných problémů:

• Složitost
• Vývoj a testování
• Nedostatečné zásady správného řízení
• Latence a zahlcení sítě
• Integrita dat
• Správa
• Vytváření verzí
• Sada dovedností

Složitost

Aplikace mikroslužeb má více pohyblivých částí než ekvivalentní monolitická aplikace. Každá služba je jednodušší, ale systém je jako celek složitější. Díky nástrojům pro zjišťování, orchestraci a automatizaci služeb se v celé aplikaci může spravovat více součástí.

Vývoj a testování

Napsání malé služby, která využívá jiné závislé služby, vyžaduje jiný přístup než napsání tradiční monolitické nebo vrstvené aplikace. Stávající nástroje nemusí být vždycky navržené pro práci se závislostmi služeb. Refaktoring přes hranice služeb může být obtížný. Je také náročné provádět testování závislostí služeb, zejména v případě, že aplikace je vyvíjená rychle.

Nedostatečné zásady správného řízení

Decentralizovaný přístup k vytváření mikroslužeb má výhody, ale může také vést k problémům. Můžete skončit s tolika různými jazyky a architekturami, že aplikaci bude obtížné spravovat. Může být užitečné zavést některé standardy na úrovni projektu bez přílišného omezování flexibility týmů. Potřeba jednotných standardů platí hlavně pro obecně se vyskytující funkce, jako jsou protokolování a metriky.

Latence a zahlcení sítě

Použití mnoha malých granulárních služeb může způsobit zvětšení objemu komunikace mezi službami. Pokud je řetěz závislostí služeb příliš dlouhý, například služba A volá B, která volá C..., může se stát problém s další latencí těchto síťových volání. Rozhraní API navrhujte pečlivě. Nepoužívejte rozhraní API se zbytečně rozsáhlou komunikací, zamyslete se nad formáty serializace a vyhledejte místa pro použití vzorů asynchronní komunikace.

Integrita dat

Každá mikroslužba je zodpovědná za trvalost vlastních dat. V důsledku toho může být problémem konzistence dat. Kde je to možné, zapojte konečnou konzistenci. Můžete také skončit s duplicitními daty a architekturou s narůstajícími objemy dat. Tato situace může zvýšit náklady na úložiště nezpracovaných dat a náklady na službu datové platformy v důsledku duplikace služeb a dat.

Správa

Klíčem k úspěchu mikroslužeb je vyspělá kultura DevOps. Problémem může být korelované protokolování mezi službami. Protokolování obvykle musí korelovat více volání služeb pro jedinou operaci uživatele.

Vytváření verzí

Aktualizace služby nesmí přerušit funkci služeb, které na ní závisí. V jednom okamžiku je možná aktualizace více služeb. Bez pečlivého návrhu můžete mít problémy se zpětnou nebo dopřednou kompatibilitou. Služby přijímající nové verze rozhraní API se zpožděním můžou zvyšovat potřebu prostředků a údržby pro starší rozhraní API.

Sada dovedností

Mikroslužby jsou vysoce distribuované systémy. Tyto distribuované systémy často vyžadují jinou sadu dovedností pro náležitý vývoj, správu a údržbu. Pečlivě vyhodnoťte, jestli má tým dostatečné znalosti a zkušenosti potřebné k úspěchu. Zohledněte čas a plánování, které vaše týmy potřebují pro rozvíjení svých dovedností.

Kdy byste měli zvolit architekturu mikroslužeb?

Vezmete-li v úvahu všechny tyto rozšiřující informace, v jakých situacích je pro vás architektura mikroslužeb nejvhodnější?

• Rozsáhlé aplikace, které vyžadují vysokou rychlost vydávání verzí
• Komplexní aplikace, které musí být vysoce škálovatelné
• Aplikace s rozsáhlými doménami nebo mnoha subdoménami
• Organizace, která se skládá z malých vývojových týmů