Mikroslužby

Mikroslužby (případně i jako mikroservisy) je pojem z oblasti vývoje software. Jedná se o jednu z variant softwarové architektury orientované na služby (SOA), kde jsou aplikace definovány jako soubor volně provázaných služeb. V mikroservisní architektuře (MSA) se vyskytují tzv. „fine-grained“ služby a „lightweight“ protokoly.

Úvod

Pro mikroslužby neexistuje žádná přesná definice. Postupem času došlo ke shodě na tom, co jsou mikroslužby nebo co si pod nimi představovat. Často se citují tyto charakteristiky:

* podle [url=, * služby v MSA lze nasadit nezávisle na sobě, * služby v MSA jsou seskupeny podle business funkčností, které poskytují, * služby v MSA mohou být implementovány pomocí různých [[Programovací jazyk|programovacích jazyků][Martin Fowler|Martina Fowlera]] a dalších odborníků jsou služby v MSA procesy, které pro dosažení svého cíle komunikují po síti pomocí technologicky nezávislých protokolů, jako je[/url]], databází, hardwarového a softwarového prostředí - podle toho, co se nejvíc hodí, * služby v MSA jsou malé, umožňují zasílání zpráv, jsou ohraničeny svým kontextem, autonomně vyvíjené, nezávisle nasaditelné, decentralizované a sestavené a nasazené do produkce pomocí automatizovaných procesů.

Mikroslužby nelze chápat jako jednu z vrstev v monolitické aplikaci (na rozdíl od například web controlleru nebo třeba backendu pro frontendovou aplikaci apod. ). +more Jedná se spíše o samostatnou business funkčnost, která má jasná rozhraní a která v sobě může (ale nemusí) implementovat více vrstev. Ve své podstatě se tedy jedná o aplikaci filozofie Unixu: „Dělej jednu věc a dělej ji dobře“.

Martin Fowler popisuje architekturu založenou na mikroslužbách takto:

* umožňuje vývoj softwaru s využitím „continuous delivery“; to znamená, že změna malé části aplikace vyžaduje změnu a nasazení pouze malé části - jedné služby nebo malého počtu služeb, * dodržuje principy jako jsou fine-grained rozhraní (pro nezávisle nasaditelné služby), vývoj řízený business potřebami (např. domain-driven design), atd.

MSA se často používá pro cloud nativní aplikace a aplikace využívající nasazení s pomocí „lightweight“ kontejnerů. Podle Fowlera, vzhledem k velkému počtu mikroslužeb (ve srovnání s implementací pomocí monolitických aplikací) je potřeba zavést decentralizovaný „Continuous Delivery“ a mít DevOps s uceleným monitorováním služeb, aby bylo možné efektivně vyvíjet, udržovat a provozovat mikroservisní aplikace. +more Díky tomu pak mohou být jednotlivé mikroslužby např. snadno individuálně škálovány ve srovnání se službami v monolitické aplikaci. V monolitickém přístupu by např. aplikace podporující tři funkce musela být škálována jako celek, i kdyby pouze jedna z těchto funkcí měla vysoké nároky na zdroje. U mikroslužeb je potřeba škálovat pouze konkrétní mikroslužby, které mají vyšší nároky na zdroje, což poskytuje výhodu optimalizace zdrojů a nákladů.

Historie

Na workshopu softwarových architektů, který se konal v květnu 2011 poblíž Benátek, byl použitý termín „microservice“ k popisu architektonického stylu, se kterým se účastníci workshopu potkávali v praxi a který mnozí z nich právě zkoumali. V květnu 2012 stejná skupina architektů rozhodla o pojmu „microservices“ jako o nejvhodnějším názvu pro tuto architekturu. +more James Lewis prezentoval některé z myšlenek v případové studii v březnu 2012 na 33rd Degree v Krakově, „Micro services - Java, Unix Way“ stejně jako Fred George přibližně v tu samou dobu. Adrian Cockcroft, bývalý ředitel cloudových systémů v Netflixu popsal tento přístup jako „fine grained SOA“ a propagoval tento styl na webu, stejně jako mnoho dalších - Joe Walnes, Dan North, Evan Bottcher a Graham Tackley.

Mikroslužby jsou jednou z mnoha možností, jak vytvořit servisně orientovanou architekturu (SOA) - architekturu pro vytvoření flexibilních a nezávisle nasaditelných softwarových systémů. Ale mikroslužby byly první realizací SOA, která plně využila DevOps a budování tzv. +more continuously deployed systémů.

Granularita služby

Klíčovou otázkou při definování MSA je, jak velká má být jednotlivá mikroslužba. Na to ale není jednoduchá odpověď, protože záleží na fungování dané organizace a taky na business kontextu služeb, pro které se má používat mikroservisní architektura. +more Například přístup Amazonu je, že tým vytvářející mikroslužby by měl být tak malý, aby ho nakrmily dvě pizzy. Další organizace si prostě vytvoří malé „jednotky“ vývojářů (squads) - obvykle 6 až 8 vývojářů, kteří tvoří mikroslužby. I tak ale musí vždy řešit otázku, jak velkou business oblast by měla obsáhnout jedna mikroslužba a kde je „hranice“ mezi business oblastmi jednotlivých týmů.

V čem existuje shoda je to, že mikroslužby by neměly být příliš malé, protože vysoké režijní náklady na jejich provoz pak převáží výhody mikroservisního přístupu. Místo rozdrobení na velmi malé služby jsou možné alternativní přístupy - například zabalení funkce do knihovny, přemístění funkce do jiných mikroslužeb nebo snížení nároků na provoz mnoha malých mikroslužeb pomocí Istio a Kubernetes.

Lingvistická definice

Lingvistická definice zavádí pojem „mikroslužba“ ve vztahu ke službám takto: „Pro každou službu může existovat více než jedna mikroslužba, ale každá mikroslužba je pouze běžící instancí služby“.

Pojem „služba“ pak definuje takto: „Služba je jednotka programovatelného softwaru schopná vyměňovat si zprávy s jinými službami, jejichž chování je vyvoláno příchozími zprávami, a je definována sadou konečných výpočtových logik nazývaných operace, které jsou deklarovány v strojově čitelném rozhraní. Běhající instance služby se nazývají mikroslužby a jejich vnitřní instance spuštěných operací se nazývají relace. +more Relace jsou prováděny nezávisle a jejich proměnné jsou nezávisle určovány. “.

Výhody

Výhody rozpadu aplikace na menší služby jsou:

* Modulárnost: Díky tomu je aplikace srozumitelnější, snazší na vývoj, snazší na testování a odolnější proti zastarání architektury. Tato výhoda se často používá jako hlavní argument při srovnání se složitostí monolitických architektur.

* Škálovatelnost: Mikroslužby jsou implementovány a nasazovány nezávisle na sobě, tj. běží v nezávislých procesech, a proto je lze nezávisle na sobě sledovat a škálovat.

* Integrace heterogenních a zastaralých systémů: Mikroslužby mohou být jednou z možností, jak modernizovat existující monolitické softwarové aplikace. Existuje několik společností, které už úspěšně nahradily (části) svého existujícího softwaru mikroslužbami, nebo se o to snaží. +more Pro tuto modernizaci používají taky inkrementální přístup. * Distribuovaný rozvoj: Umožňuje paralelní vývoj, kde malé autonomní týmy mohou vyvíjet, nasazovat a škálovat své služby nezávisle na sobě. Umožňuje taky průběžný refaktoring jednotlivých služeb dle potřeby. A jak už je asi patrné, architektury založené na mikroslužbách umožňují naplno využívat Continuous delivery a Continuous deployment.

Kritika

Mikroservisní přístup je předmětem kritiky v několika oblastech:

* Služby vytváří informační bariéry (jedna služba čeká na zpracování jiné služby, která ji tím blokuje). * Vzájemné volání mezi službami klade vyšší nároky na síť (latence sítě, doba zpracování zpráv), než je tomu u volání v rámci monolitického procesu. +more * Testování a nasazení je komplikovanější (viz distribuovaný rozvoj). * Přesun odpovědnosti mezi službami je obtížnější. Může dojít k přesunu služby do jiného týmu a to může znamenat např. : zvýšenou komunikaci pro hladké předání různými týmy; přepsání funkčnosti do jiného jazyka; umístění do jiné infrastruktury apod. Není to ale tak složité jako přesun u monolitické aplikace, protože mikroslužby mohou být nasazeny nezávisle na zbytku aplikace, zatímco týmy pracující na monolitech musí být synchronizovány, aby mohly být aplikace nasazeny společně.

* Při rozdělení monolitického systému na mikroslužby může dojít k vytvoření příliš velkého počtu služeb tam, kde by lepším řešením byla vnitřní modularizace. Správa tak velkého počtu služeb pak může vyžadovat zavedení dalších systémů pro přehled o celkové architektuře aplikací a vzájemné závislosti mezi komponentami. +more * Nedoporučuje se dělat dvou-fázové commity transakcí u mikroslužeb, protože by to vedlo k úzkému propojení všech účastníků na transakci (commit napříč týmy, které mají být nezávislé). To ale znamená, že je potřeba se domluvit se všemi účastníky, kteří implementují transakci (komunikace napříč týmy), aby se zachovala konzistence dat (jsou potřeba commity v každém ze zúčastněných týmů). * Vývoj a podpora služeb je náročnější, pokud se používají různé nástroje a technologie - to může být problém zvlášť při častém přesunu vývojářů mezi projekty.

Kognitivní zatížení

Mikroservisní architektura zvyšuje komplexnost a přináší nové výzvy k řešení, jako je latence sítě, návrh formátu zprávy, zálohování / dostupnost / konzistence (BAC), vyvažování zátěže a odolnost proti chybám. Všechny tyto problémy je navíc potřeba řešit ve větším měřítku (ve srovnání s monolitickými aplikacemi).

Komplexnost monolitické aplikace se nesníží jen tím, že bude znovu implementována jako sada mikroslužeb. Částečně se totiž zvýší složitost na provozování mikroslužeb. +more Taky se projeví zvýšený síťový provoz díky komunikaci mezi mikroslužbami a z toho plynoucí pomalejší výkon mikroslužeb. Důležité je taky zvýšení počtu přístupových bodů k jednotlivým mikroslužbám, což zase zvyšuje architektonickou složitost. Pro snížení těchto dopadů mikroservisní architektury je proto potřeba aplikovat další organizační principy (jako jsou HATEOAS, dokumentace rozhraní a datového modelu pomocí Swagger atd. ).

Technologie

Počítačové mikroslužby mohou být implementovány pomocí různých programovacích jazyků a mohou používat různou infrastrukturu. Nejdůležitější technologickou volbou je proto způsob, jakým spolu budou mikroslužby komunikovat (synchronní / asynchronní komunikace, případně rovnou integrace uživatelského rozhraní) a jaké protokoly budou používat pro komunikaci (RESTful HTTP, messaging, …). +more Ve srovnání s tradičním systémem, kde např. volba programovacího jazyka ovlivní celý systém, je tedy přístup k výběru technologií u mikroslužeb zcela odlišný.

Servisní síť (síť služeb)

V servisní síti je každá instance služby spárována s instancí reverzního proxy serveru, který se nazývá „service proxy“, „sidecar proxy“ nebo jen „sidecar“ (postranní vozík). Instance služby a její „sidecar proxy“ spolu sdílejí kontejner, který je spravován nástrojem pro správu kontejnerů jako jsou Kubernetes, Docker Swarm nebo DC / OS. +more „Sidecar proxy“ zodpovídá za komunikaci s jinými instancemi služeb a umožňuje funkce, jako je vyhledávání služeb (instance), vyvažování zátěže, autentizace a autorizace, zabezpečená komunikace a další.

V servisní síti tvoří instance služeb a jejich „sidecar proxy“ datovou úroveň („data plane“), což zahrnuje nejen správu dat, ale také zpracování žádostí a odpovědí (request a response). Servisní síť ale potřebuje taky nějakou „kontrolní úroveň“, tzn. +more řízení interakce mezi službami zprostředkovanou přes jejich „sidecar proxy“. Existuje několik řešení pro servisní sítě, jako např. : Istio (společný projekt společností Google, IBM a Lyft), Linkerd (projekt CNCF vedený Buoyant) a další.

Porovnání platforem

Implementace architektury mikroslužeb je obtížná. Existuje mnoho oblastí (viz tabulka níže), které je potřeba řešit, ale naštěstí už existují platformy/frameworky, které lze použít.

Netflix Open Source Software (OSS)

Netflix vyvinul vlastní framework pro mikroslužby, který používal ve svých interních aplikacích, a později ho dal částečně k dispozici jako open source.

Spring Cloud

Mnoho z nástrojů Netflix OSS bylo popularizováno prostřednictvím Spring frameworku - kde byly tyto nástroje znovu implementované na základě Springu a pod záštitou projektu Spring Cloud.

Srovnání Spring Cloud / Netflix OSS a Kubernetes

Níže uvedená tabulka ukazuje srovnání ekosystému Kubernetes s ekvivalentem ze světa Spring Cloud. Jedním z pozoruhodných aspektů ekosystému Spring Cloud je to, že se jedná o technologie založené pouze na Javě, zatímco Kubernetes je více-jazyčná runtime platforma. +more

Související články

DevOps * Representational State Transfer (REST) * Architektura orientovaná na služby (SOA) * Modernizace softwaru * Filozofie unixu * Samostatný systém (software) * Výpočet bez serverů * Webově orientovaná architektura (WOA)

Odkazy

Reference

Literatura

Special theme issue on microservice, software IEEE 35 (3), květen / červen 2018, https://ieeexplore. ieee. +moreorg/xpl/tocresult. jsp. isnumber=8354413 * I. Nadareishvili et al. , [url=https://www. ca. com/content/dam/ca/us/files/ebook/microservice-architecture-aligning-principles-practices-and-culture. pdf]Microservices Architecture - Aligning Principles, Practices and Culture[/url], O'Reilly, 2016, * S. Newman, Building Microservices - Designing Fine-Grained Systems, O'Reilly, 2015 * Wijesuriya, Viraj Brian (2016-08-29) [url=http://www. slideshare. net/tyrantbrian/microservice-architecture-65505794]Microservice Architecture, Lecture Notes[/url] - University of Colombo School of Computing, Srí Lanka * Christudas Binildas (27. června 2019). Practical Microservices Architectural Patterns: Event-Based Java Microservices with Spring Boot and Spring Cloud. Apress.

Kategorie:Softwarová architektura