Styl architektury mikroslužeb
Architektura mikroslužeb se skládá z kolekce malých, autonomních služeb. Každá služba je samostatná a měla by implementovat jednu obchodní funkci v rámci omezeného kontextu. Ohraničený kontext je přirozené rozdělení v rámci firmy a poskytuje explicitní hranici, ve které existuje doménový model.
Co jsou mikroslužby?
Mikroslužby jsou malé, nezávislé a volně propojené. Službu může napsat a udržovat jeden malý tým vývojářů.
Každá služba představuje samostatný kód, který může spravovat malý vývojový tým.
Služby se dají nasadit nezávisle. Tým může aktualizovat existující službu bez nového sestavení a nového nasazení celé aplikace.
Služby jsou zodpovědné za trvalost vlastních dat nebo externího stavu. To se liší od tradičního modelu, kde trvalost dat zpracovává samostatná datová vrstva.
Služby vzájemně komunikují pomocí dobře definovaných rozhraní API. Podrobnosti interní implementace každé služby jsou ostatním službám skryté.
Podporuje polyglotní programování. Například služby nemusí sdílet stejnou technologickou sadu, knihovny nebo architektury.
Mimo vlastních služeb se v typické architektuře mikroslužeb objevují některé další komponenty:
Správa/orchestrace Tato komponenta je odpovědná za umístění služeb na uzlech, identifikaci chyb, vyrovnává zatížení služeb mezi uzly a tak dále. Touto komponentou je obvykle předem připravená technologie, jako je Kubernetes (obvykle se nevytváří vlastní).
Brána rozhraní API. Brána rozhraní API je vstupním bodem pro klienty. Místo přímého volání služeb klienti volají bránu rozhraní API, která předává volání příslušným službám v back-endu.
Výhody použití brány rozhraní API:
Odděluje klienty od služeb. Služby můžou být označené verzí nebo refaktorované, aniž by bylo potřeba aktualizovat všechny klienty.
Služby můžou používat protokoly zasílání zpráv, které nejsou vhodné pro webové prostředí, jako je například AMQP.
Brána rozhraní API může společné funkce, jako je například ověřování, protokolování, ukončování protokolu SSL a vyrovnávání zatížení.
Předefinované zásady, jako jsou omezení, ukládání do mezipaměti, transformace nebo ověřování.
Výhody
Agilnost Vzhledem k tomu, že mikroslužby se nasazují nezávisle, je jednodušší spravovat opravy chyb a vydané verze 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, pokud se v jedné části aplikace najde chyba, může blokovat celý proces vydání. Nové funkce můžou čekat na integraci, otestování a publikování opravy chyb.
Malé a soustředěné týmy. Mikroslužba by měla být dostatečně malá, aby ji mohl sestavit, otestovat a nasadit jeden tým funkcí. Malá velikost týmu znamená větší flexibilitu. Velké týmy mají tendenci k nižší produktivitě, protože komunikace je pomalejší, zvyšují se režijní náklady a snižuje se flexibilita.
Malý základ kódu. V monolitické aplikaci existuje v průběhu času tendenci, aby se závislosti kódu zapletily. Přidání nové funkce vyžaduje dotykové ovládání kódu na mnoha místech. Architektura mikroslužeb díky tomu, že nesdílí kód ani úložiště dat, minimalizuje závislosti a tím usnadňuje přidávání nových funkcí.
Kombinace technologií. Týmy si můžou vybrat technologie, které jsou pro příslušnou službu nejvhodnější, a můžou podle potřeby využívat kombinaci technologií.
Izolace chyb. Pokud se individuální mikroslužba stane nedostupnou, nenaruší celou aplikaci, pokud jsou všechny nadřazené mikroslužby navržené tak, aby správně zpracovávaly chyby. Můžete například implementovat model Jistič nebo navrhnout řešení tak, aby mezi sebou mikroslužby komunikovaly pomocí asynchronních vzorů zasílání zpráv.
škálovatelnost. Služby se mohou škálovat nezávisle. Díky tomu můžete škálovat na více instancí subsystémy, které vyžadují více prostředků, a není nutné škálovat na více instancí celou aplikaci. Pomocí orchestrátoru, jako je Kubernetes, můžete zabalit vyšší hustotu služeb na jednoho hostitele, což umožňuje efektivnější využití prostředků.
Izolace dat. Je mnohem jednodušší provádět aktualizace schémat, protože ovlivňují jenom jednu mikroslužbu. V monolitické aplikaci se aktualizace schématu můžou stát velmi náročné, protože různé části aplikace se můžou dotýkat stejných dat, takže všechny změny schématu riskují.
Výzvy
Výhody mikroslužeb ale nejsou zadarmo. Tady jsou některé výzvy, které je potřeba před rozhodnutím pro architekturu mikroslužeb vzít v úvahu.
Složitost: 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ší.
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ž psaní 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 mezi službami 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 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ů. To platí hlavně pro společné funkce, jako je protokolování.
Latence a zahlcení sítě. Použití mnoha malých podrobných služeb může vést k větší komunikaci mezi službami. Navíc pokud řetěz závislostí služby je příliš dlouhý (služba A volá B, která volá C...), může se další latence stát problémem. Je potřeba navrhovat rozhraní API pečlivě. Vyhněte se příliš chatovacím rozhraním API, zamyslete se nad formáty serializace a hledejte místa pro použití asynchronních komunikačních vzorů, jako je vyrovnávání zatížení na základě fronty.
Integrita dat. Každá mikroslužba zodpovědná za trvalost vlastních dat. V důsledku toho může být konzistence dat napříč více službami výzvou. Různé služby uchovávají data v různých časech, používají různé technologie a potenciálně různé úrovně úspěchu. Pokud se do zachování nového nebo změně data podílí více než jedna mikroslužba, je nepravděpodobné, že by se úplná změna dat mohla považovat za transakci ACID. Místo toho je technika více zarovnaná se základnou (v podstatě dostupný, měkký stav a nakonec konzistentní). Pokud je to možné, přijměte konečnou konzistenci.
Správa Úspěšné zavedení mikroslužeb 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.
správa verzí. Aktualizace služby nesmí přerušit služby, které na ní závisejí. V jednom okamžiku je možná aktualizace více služeb, takže bez pečlivého návrhu můžete mít problémy se zpětnou nebo dopřednou kompatibilitou.
Sada dovedností: Mikroslužby jsou vysoce distribuované systémy. Pečlivě vyhodnoťte, jestli má tým dovednosti a zkušenosti, které mají být úspěšné.
Osvědčené postupy
Modelujte služby kolem obchodní domény.
Decentralizované všechno. Jednotlivé týmy zodpovídají za navrhování a sestavování služeb. Vyhněte se sdílení kódu nebo schémat dat.
Úložiště dat by mělo být privátní pro službu, která vlastní data. Pro každou službu a datový typ použijte nejlepší úložiště.
Služby komunikují prostřednictvím dobře navržených rozhraní API. Vyhněte se úniku podrobností implementace. Rozhraní API by měla modelovat doménu, ne interní implementaci služby.
Vyhněte se párování mezi službami. Příčiny párování zahrnují schémata sdílených databází a pevné komunikační protokoly.
Přesměrujte do brány křížové aspekty, jako je například ověřování a ukončení protokolu SSL.
Udržujte znalosti domény mimo bránu. Brána by měla zpracovávat a směrovat požadavky klientů bez znalostí obchodních pravidel nebo logiky domény. Jinak se brána stane závislostí a může způsobit párování mezi službami.
Služby by měly mít volné spojení a vysokou funkční soudržnost. Funkce, které se pravděpodobně změní společně, by se měly zabalit a nasadit společně. Pokud se nacházejí v samostatných službách, tyto služby jsou úzce propojené, protože změna v jedné službě bude vyžadovat aktualizaci druhé služby. Příliš chatty komunikace mezi dvěma službami může být příznakem úzké vazby a nízké soudržnosti.
Izolace selhání Použijte strategie odolnosti, abyste zabránili selháním ve službě v kaskádovém vytváření. Viz vzory odolnosti a navrhování spolehlivých aplikací.
Další kroky
Podrobné pokyny k vytvoření architektury mikroslužeb v Azure najdete v tématu Návrh, sestavování a provoz mikroslužeb v Azure.