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í.
Zaměstnanecké výhody
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í. 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, testovat a nasadit jeden tým. 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 systém je jako celek 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 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ů. To platí hlavně pro společné funkce, jako je protokolování.
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. 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í). Kde je to možné, zapojte konečnou konzistenci.
Správa Úspěšné zavedení mikroslužeb vyžaduje vyspělou kulturu 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.
Správa 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, 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 dostatečné znalosti a zkušenosti potřebné k úspěchu.
Osvědčené postupy
Modelujte služby kolem obchodní domény.
Decentralizujte všechno. Jednotlivé týmy odpovídají za návrh a vytváření služeb. Vyhněte se sdílení kódu nebo datových schémat.
Úložiště dat by mělo být pro službu, která vlastní data, privátní. Používejte pro každý typ služby a dat nejlepší úložiště.
Služby komunikují prostřednictvím dobře navržených rozhraní API. Vyhněte se úniku podrobností o implementaci. Rozhraní API by měla modelovat doménu, ne interní implementaci služby.
Vyhněte se vazbám mezi službami. Příčinami vazeb jsou sdílená databázová schémata a rigidní komunikační protokoly.
Převeďte společné aspekty, jako je ověřování a ukončení protokolu SSL, na bránu.
Držte znalosti domény mimo bránu. Brána by měl zpracovávat a směrovat požadavky klientů bez znalosti obchodních pravidel nebo logiky domény. Jinak se brána stane závislostí a může způsobit vazbu mezi službami.
Služby by měly mít volné vazby a vysoce funkční soudržnost. Funkce, které se budou pravděpodobně měnit společně, by měl být zabalené a nasazované společně. Pokud jsou umístěné v samostatných službách, můžou se tyto služby stát úzce svázané, protože změna v jedné službě bude vyžadovat aktualizaci jiné služby. Příliš košatá komunikace mezi dvěma službami může být příznakem úzké vazby a nízké soudržnosti.
Izolujte chyby. Pomocí strategií odolnost proti chybám zabraňte kaskádovému šíření chyb služby. Viz vzory odolnosti a navrhování spolehlivých aplikací.
Další kroky
Podrobné pokyny týkající se vytváření architektury mikroslužeb v Azure najdete v tématu Navrhování, sestavování a provoz mikroslužeb v Azure.