Mikroslužby jsou oblíbeným stylem architektury pro vytváření aplikací, které jsou odolné, vysoce škálovatelné a umožňují nezávislé nasazení a rychlý rozvoj. Ale úspěšná architektura mikroslužeb vyžaduje při navrhování a sestavování aplikací jiný přístup.
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 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.
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.
Proces sestavení architektury mikroslužeb
Uvedené články představují strukturovaný přístup pro návrh, sestavování a provoz architektury mikroslužeb.
Analýza domény Abyste se vyhnuli některým obvyklým nástrahám při návrhu mikroslužeb, použijte k definování hranic vašich mikroslužeb analýzu domény. Postupujte následovně:
- Použití analýzy domény k modelování mikroslužeb
- Použití taktické technologie DDD k návrhu mikroslužeb
- Identifikace hranic mikroslužeb
Návrh služeb Mikroslužby vyžadují jiný přístup k návrhu a sestavování aplikací. Další informace najdete v článku Návrh architektury mikroslužeb.
Provoz v produkčním prostředí Vzhledem k tomu, že architektury mikroslužeb jsou distribuované, musíte mít robustní operace pro nasazení a monitorování.
- CI/CD pro architektury mikroslužeb
- Sestavení kanálu CI/CD pro mikroslužby na platformě Kubernetes
- Monitorování mikroslužeb spuštěných v Azure Kubernetes Service (AKS)