Monolitické architektury a architektury 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í není dobrým dlouhodobým plánem pro svou aplikaci. Stávající systém je monolitická architektura, ale co přesně znamená?

Co je monolitická architektura?

Monolitická architektura je architektura, ve které jsou všechny komponenty aplikace umístěny v rámci jedné jednotky. Tato jednotka je obvykle omezena v rámci jedné instance modulu runtime aplikace. Tradiční aplikace se často skládají z webového rozhraní, vrstvy služeb a datové vrstvy. V monolitické architektuře se tyto vrstvy kombinují v instanci aplikace.

Monolitické architektury jsou často vhodná řešení pro malé aplikace, ale s rostoucím růstem aplikace se můžou stát nepraktické. Původně se malá aplikace může rychle stát složitým systémem, který se obtížně škáluje, obtížně nasazuje a obtížně inovuje.

Všechny služby jsou obsaženy v jedné jednotce. Toto uspořádání přináší problémy s tím, jak jejich podnikání a následné zatížení systému roste. Mezi tyto výzvy patří:

• Obtížné škálovat služby nezávisle.
• Složité pro vývoj a správu nasazení s růstem 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ématu dat můžou být stále obtížnější.

Tyto výzvy je možné řešit pohledem na alternativní architektury, jako je architektura mikroslužeb.

Co je architektura mikroslužeb?

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

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é nasadit nezávisle, tým může aktualizovat existující službu bez opětovného sestavení a opětovného nasazení celé aplikace.

Každá služba je obvykle zodpovědná za vlastní data. Jeho datová struktura je izolovaná, takže upgrady nebo změny schématu nejsou závislé na jiných službách. Žádosti o data se obvykle zpracovávají prostřednictvím rozhraní API a poskytují dobře definovaný a konzistentní model přístupu. Interní podrobnosti implementace jsou pro příjemce služeb skryté.

Vzhledem k tomu, že každá služba je nezávislá, můžou používat různé technologické zásobníky, architektury 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 technologiích, ale často se zobrazují kontejnery nebo bezserverové technologie používané pro jejich implementaci. Průběžné nasazování a kontinuální integrace (CI/CD) se často používají ke zvýšení rychlosti a kvality vývojových aktivit.

Výhody architektury mikroslužeb

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

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

Hbitost

Vzhledem k tomu, že mikroslužby se nasazují nezávisle, je jednodušší spravovat opravy chyb a vydané verze funkcí. Službu můžete aktualizovat bez opětovného nasazení celé aplikace a vrácení aktualizace zpět, pokud se něco nepovede. V mnoha tradičních aplikacích, pokud se v jedné části aplikace najde chyba, může blokovat celý proces vydání. V důsledku toho můžou být nové funkce zdrženy kvůli čekání na integraci, otestování a publikování opravy chyby.

Malý kód, malé týmy

Mikroslužba by měla být dostatečně malá, aby ji mohl sestavit, otestovat a nasadit jeden tým funkcí. Malé základy kódu jsou srozumitelnější. Ve velké monolitické aplikaci se závislosti kódu často zamotávají v průběhu času. Přidání nové funkce vyžaduje dotykové ovládání kódu na mnoha místech. Architektura mikroslužeb minimalizuje závislosti tím, že nesdílí kód nebo úložiště dat. To usnadňuje přidávání nových funkcí.

Malé týmy také podporují větší flexibilitu. Pravidlo "dvou pizz" říká, že tým by měl být dostatečně malý, aby dva pizzy tým nasytily. Očividně to není přesná metrika a závisí na chuti týmu! Ale důvodem je, že velké skupiny mají tendenci být méně produktivní, protože komunikace je pomalejší, režie na správu roste a flexibilita se snižuje.

Kombinace technologií

Týmy si můžou vybrat technologii, která nejlépe vyhovuje jejich službám. Mohou používat kombinaci technologických stacků podle potřeby. Každý tým může vyvíjet technologie, které podporují svou službu nezávisle. Služby můžou kvůli této nezávislosti používat různé vývojové jazyky, cloudové služby, sady SDK a další. 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 spotřebitele vašich služeb je nepřetržitý provoz vaší aplikace.

Škálovatelnost

Architektura mikroslužeb umožňuje škálování jednotlivých mikroslužeb nezávisle na ostatních. Subsystémy, které vyžadují více prostředků, můžete škálovat bez horizontálního navýšení kapacity celé aplikace. Toto uspořádání zlepšuje celkový výkon vaší aplikace. Pomáhá také minimalizovat náklady. Můžete přidat další prostředky jenom ke službám, které je potřebují, a ne vertikálně navýšit kapacitu celé aplikace.

Izolace dat

Architektura mikroslužeb zlepšuje schopnost provádět aktualizace schématu dat, protože to má vliv jenom na jednu mikroslužbu. V monolitické aplikaci můžou být aktualizace schématu náročné. Různé části aplikace se můžou dotýkat stejných dat, což způsobí, že změny schématu budou rizikové. S architekturou mikroslužeb můžete aktualizovat schéma, ale zachovat povrch rozhraní API beze změny. Příjemci služeb pak mají stejné prostředí bez ohledu na základní architekturu dat.

Potenciální výzvy architektury mikroslužeb

Architektura mikroslužeb má mnoho výhod, ale není to všelék. Architektura mikroslužeb má svou vlastní sadu výzev:

• Komplexnost
• Vývoj a testování
• Nedostatek zásad správného řízení
• Zahlcení sítě a zpoždění
• Integrita dat
• Řízení
• Verzování
• Sada dovedností

Komplexnost

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

Vývoj a testování

Vytvoření malé služby, která závisí na jiných závislých službách, vyžaduje jiný přístup než zápis pro tradiční monolitickou nebo vrstvenou aplikaci. Existující nástroje nejsou vždy navržené tak, aby fungovaly se závislostmi služeb. Refaktoring mezi službami může být obtížný. Testování závislostí služeb je také náročné, zejména když se aplikace rychle vyvíjí.

Nedostatek zásad 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 aplikace se obtížně udržuje. Může být užitečné zavést některé standardy pro celý projekt bez nadměrného omezení flexibility týmů. Potřeba jednotných standardů platí zejména pro průřezové funkce, jako je protokolování a metriky.

Zahlcení sítě a zpoždění

Použití mnoha malých podrobných služeb může vést k větší komunikaci 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í. Pečlivě navrhněte rozhraní API. Vyhněte se příliš upovídaným rozhraním API, zamyslete se nad formáty serializace a hledejte místa pro využití asynchronních komunikačních vzorů.

Integrita dat

Každá mikroslužba zodpovídá za trvalost vlastních dat. V důsledku toho může být konzistence dat výzvou. Pokud je to možné, přijměte konečnou konzistenci. Můžete také skončit s duplicitními daty a rozrůstající se architekturou dat. Tato situace může zvýšit náklady na základní úložiště a náklady na služby datové platformy v důsledku duplikace služeb a dat.

Řízení

Úspěch s mikroslužbami vyžaduje vyspělou kulturu DevOps. Korelované protokolování napříč službami může být náročné. Protokolování obvykle musí korelovat více služebních volání pro jednu uživatelskou operaci.

Verzování

Aktualizace služby nesmí přerušit služby, které na ní závisejí. V daném okamžiku může být aktualizováno více služeb. Bez pečlivého návrhu můžete mít problémy s zpětnou nebo dopředu kompatibilitou. Služby, které prodlevou při zavádění nových verzí rozhraní API můžou zvýšit prostředky a údržbu vyžadované pro starší rozhraní API.

Sada dovedností

Mikroslužby jsou vysoce distribuované systémy. Tyto distribuované systémy často vyžadují jinou sadu dovedností pro správný vývoj, správu a údržbu. Pečlivě vyhodnoťte, jestli má tým dovednosti a zkušenosti, které mají být úspěšné. Dejte vašim týmům čas a plánování, které potřebují k rozvoji svých schopností.

Kdy byste měli zvolit architekturu mikroslužeb?

Na základě těchto informací na pozadí, pro jaké situace je architektura mikroslužeb nejvhodnější?

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