Mikroslužby zjednoduší firemní aplikace

Máte stovky tisíc řádků starého kódu v jazyce C++. To je šprým, že? Jsou to miliony řádků. Ale všichni to známe, pokud to funguje, tak..., že?

Výjimkou je, že to nefunguje. Kdykoli se někdo pokusí přidat do takto rozsáhlé aplikace další funkci, tak se věci mohou pokazit. Dokonce i pokus o opravu chyb vytváří další chyby. Ale když na nic nesaháte, tak to prostě dál funguje. Problémem ale je, že inovace vyžadují agilitu a rychlost.

Dobrou zprávou je, že nejste sami. Věřte tomu, nebo ne, dokonce i úžasné nové firmy mají podobné problémy. Netflix, eBay, Amazon, Twitter, PayPal a další nezačaly s úžasně navrženým škálovatelným kódem, který by byl rychlý a agilní.

Například společnost eBay v roce 2006 představila svou architekturu na tehdejším SD Foru. Oznámila, že vytvořila monolitickou knihovnu ISAPI.DLL v rozsahu 3,3 milionu řádků C++, kterou zkompilovala do 150MB binárního souboru. Tamější vývojáři dosáhli limitů kompilátoru v počtu metod pro některé třídy, zatímco se od nich očekává, že budou každý rok přidávat více než 1 200 nových funkcí při současné dostupnosti 99,94 %.

Jak se firmě eBay podařilo překonat její přetíženou zastaralou architekturu? Stejným způsobem, jako to udělaly firmy PayPal, Twitter, Amazon a Netflix: odstraněním monolitičnosti své aplikace. Přepracovali architekturu své infrastruktury pomocí mikroslužeb  –metody, která rozkládá velké aplikace na odlehčené aplikace, jež lze horizontálně škálovat.

Rozložení monolitů

Mikroslužby rozdělují funkce do různých aplikací, které jsou volně propojené pomocí rozhraní RESTful API. eBay například v roce 2006 vytvořila různé servletové aplikace Java, které obsluhovaly uživatele, položky a účty, zpětnou vazbu, transakce a více než 70 dalších prvků. Každá z těchto logických funkčních aplikací se nyní považuje za mikroslužbu. Nyní eBay pravděpodobně provozuje stovky mikroslužeb.

Každá z nich je soběstačná. Nesdílejí datovou vrstvu. Každá má svou vlastní databázi a vyvažování zátěže. Izolace je kritickou součástí architektury mikroslužeb – různé mikroslužby vyžadují různé metody škálování. Některé mohou například používat relační databáze, zatímco jiné databáze NoSQL.

Vytváření aplikací tímto způsobem zvyšuje škálovatelnost týmů vytvářejících aplikace. U monolitického kódu máte jeden velký tým lidí, kteří pracují na jednom velkém kusu kódu a neustále si vzájemně šlapou na nohy. Rychlost vývoje se exponenciálně zpomaluje s růstem monolitického kódu.

Při použití architektury mikroslužeb se ale aplikace vytvářejí pomocí malých decentralizovaných týmů vývojářů, kteří pracují a mění mikroslužby nezávisle. To usnadňuje upgrade služeb a přidávání funkcí. Jak software, tak i vývojový proces se stávají agilnějšími.

Ze všech těchto důvodů se mikroslužby těší rostoucí popularitě. Ale každá architektura má své silné a slabé stránky. Architektury mikroslužeb přinášejí celou řadu nových problémů, které je obtížné řešit.

Níže vám vysvětlíme výhody a nevýhody mikroslužeb a podíváme se, jak vytvořit blogovací aplikaci založenou na mikroslužbách, abyste viděli, jak fungují v reálném světě. A podíváme se i na některé nejčastější obavy týkající se mikroslužeb.

Výhody a nevýhody

Filozofií mikroslužeb je rozložení velkých monolitických aplikací s velmi složitými interními architekturami na menší, nezávisle škálovatelné aplikace. Pokud jste např. firma jako eBay, můžete očekávat, že bude mikroslužba pro hodnocení od uživatelů menší a méně složitá než mikroslužba pro nabídky.

Když se nad tím zamyslíte, proč by tyto funkce měly být vytvořené v rámci jedné aplikace? Minimálně teoreticky si můžete představit, že by mohly bez problémů fungovat v samostatných aplikačních a datových silech. Pokud například průměrná dražba dostala dvě nabídky, ale jen čtvrtina všech prodejů obdržela hodnocení, měla by být nabídková služba kdykoliv během dne minimálně osminásobně aktivnější než aplikace s hodnocením.

Oddělení různých skupin funkcí do samostatných aplikací dává takto intuitivně smysl. Výhoda, spočívající v možnosti vytvářet a měnit různé části vaší aplikace nezávisle se sebou, nese celou řadu nových aspektů – konkrétně protokolování, monitorování, testování a ladění vaší nově decentralizované a volně propojené aplikace.

Pokud existuje nějaká chyba, jaká mikroslužba ji způsobuje? Vzájemné závislosti mezi mikroslužbami mohou odpověď na takovou otázku značně ztížit. Mikroslužby komunikují navzájem, obecně prostřednictvím odlehčených rozhraní JSON REST API. Na rozdíl od svých předchůdců XML-RPC a SOAP mívají rozhraní REST volnější definici. Tato odlehčená rozhraní API jsou flexibilnější a snadněji se rozšiřují, ale přidávají také nové rozhraní, které se musí monitorovat, může se pokazit a být zdrojem chyb.

U monolitických aplikací jste mohli zadat do kódu ladicí sondy a mohli jste logicky postupně procházet každou prováděcí vrstvu, abyste zjistili problémové oblasti. Když čelíte síti desítek, nebo dokonce stovek samostatných aplikací, které vzájemně komunikují pomocí volně definovaných rozhraní API, tento luxus ztrácíte.

Pomocí pečlivého plánování však tyto obtíže můžete překonat. V současné době je na výběr relativně malé množství připravených nástrojů pro ladění mikroslužeb. Budete pravděpodobně muset postavit svá vlastní řešení na základě jiných, podle příslušných situací.

Při návrhu s využitím filozofie mikroslužeb však získáte skryté výhody, jako jsou například možnost využití nových technologií, např. PaaS, Docker a další linuxové kontejnery.

Mikroslužby, kontejnery a PaaS

V současné době se objevuje častý omyl, že k využití mikroslužeb musíte využívat PaaS nebo linuxové kontejnery či něco podobného. To jednoduše není pravda. Můžete používat PaaS a linuxové kontejnery bez mikroslužeb a můžete využívat mikroslužby bez PaaS a bez linuxových kontejnerů. Ani jedno nevyžaduje to druhé.

Tyto technologie se však dokážou mnoha způsoby dobře vzájemně doplňovat. Prostředí PaaS, ať už ve formě veřejných cloudů jako Heroku nebo privátních cloudů jako Cloud Foundry a OpenShift, optimalizují spouštění mnoha menších aplikací. Aplikace Portinga s 3,3 milionu řádků kódu C++  pro platformu PaaS nikdy nevznikne.

Když rozložíte svou aplikaci na menší aplikace, které jsou soběstačné a nezávisle škálovatelné, stanou se z těchto drobných aplikací dobří kandidáti pro prostředí PaaS.

Z tohoto důvodu mohou úvahy nad přijetím architektury mikroslužeb pomoci urychlit přijetí dalších technologií, které již mohou být součástí vašeho plánu. Stejně tak jsou linuxové kontejnery vhodnější pro malé bezestavové aplikace než pro velké monolitické.

Koneckonců jedním z největších a nejzřetelnějších rozdílů mezi virtuálním počítačem a linuxovým kontejnerem je absence stavu. Virtuální počítače lze nakonfigurovat tak, aby uchovávaly svůj stav, zatímco architektura linuxových kontejnerů svou podstatou zahazuje všechny odchylky od základní bitové kopie. V linuxových kontejnerech můžete připojit složky uchovávající nějaký stav, ale kontejner samotný se nezmění, dokud ho nezměníte sami.

Filozofie horizontálního škálování architektury mikroslužeb podporuje koncept sdílení ničeho a bezestavových aplikací. To znamená, že do základního souborového systému nic neukládají a nic v něm nemění. Zde můžete vidět, proč si lidé spojují mikroslužby s linuxovými kontejnery: Ani jedno řešení neuchovává svůj stav.

Mikroslužby nabízejí zdravý přístup k vývoji aplikací, pokud si uvědomujete problémy a nedostatky. Není to jen další technologický trend, který za rok zmizí. Je to způsob, jakým mnohé z největších firem a zvučných jmen v oblasti technologií řešily problémy velkého růstu za posledních deset let.

Aplikace jako mikroslužby

Pokud jste nikdy předtím nevytvořili architekturu mikroslužeb, bude to pro vás jiný způsob myšlení. Mnoho vývojářů nnejdříve navrhujeaplikace tak, že začíná rozvržením databáze. Vytvářejí celou řadu tabulek včetně komplikovaných tabulek JOIN. Logika aplikace je potom postavena nad databází. A nakonec uživatelské rozhraní, které je nad logikou aplikace. Tento přístup k vytváření aplikací je jako třívrstvý koláč a může zpočátku fungovat dobře.

Problém s touto architekturou spočívá v tom, že se při přidávání funkcí do aplikace přidávají do databáze nové tabulky a JOIN tabulky. Potom je nová funkce zapsána do kódu. Časem se z toho stane obrovský zašmodrchanec.

Nejjednodušším způsobem, jak přemýšlet o vytváření aplikace pomocí mikroslužeb, je začít uživatelským rozhraním a pracovat směrem zpět. Obraťte tradiční architektonickou praxi vzhůru nohama.

Abychom ilustrovali tento obrácený přístup, použijme k tomu jednoduchou aplikaci pro blogování. Tradičně byste mohli začít tvořit blogovou aplikaci vytvořením jedné databáze s tabulkou článků, tabulkou komentářů, tabulkou autorů atd. Článek může mít různé autory, takže možná budete chtít vytvořit JOIN tabulku pro články a autory.

Při využití mikroslužeb můžete začít tím, že uděláte maketu domovské stránky blogu a rozhodnete o použití odpovídajících prvků. Komentáře nejsou na domovské stránce blogu, takže je v tomto okamžiku není potřebné definovat. Dokonce ani nemusíte vytvářet databázi komentářů. Ta přijde na řadu později.

Nejprve můžete vytvořit soběstačnou REST API mikroslužbu s názvem Článek. Maketu uživatelského rozhraní oživíte integrováním javascriptového klienta, jako jsou například Backbone, Angular nebo Ember. Všichni tito tři javascriptoví klienti nativně pracují s jakýmkoli REST API a dokážou načítat data do návrhu, který byl předtím jen maketou.

Mikroslužba Článek REST API by mohla být odlehčenou aplikací, která se zaměřuje na jádro funkčnosti ukládání a načítání dat článku. V této fázi vývoje aplikace v podobě mikroslužby se nemusíte starat o modely autentizace a zabezpečení. Další mikroslužby lze přidat jako vrstvy později. Nepřetěžujte žádnou mikroslužbu více funkcemi, než je nutné – proto se používá předpona „mikro“ v označení druhu – mikroslužba.

Jednou z důležitých věcí, které je potřebné zmínit v této fázi, je to, že každá mikroslužba má omezený rozsah funkčnosti, takže máte mnohem větší flexibilitu pro možnosti ukládání dat.

Bez velkých a komplikovaných návrhů databází jsou relační databáze méně relevantní a lépe se mohou hodit databáze NoSQL, jako jsou MongoDB, Couchbase, Cassandra, Redis a Riak. Teoreticky by každá mikroslužba mohla používat jiný mechanismus ukládání dat, který se nejlépe hodí pro danou mikroslužbu.

Jakmile jste vytvořili Článek REST API předávající dynamická data do uživatelského rozhraní klienta, můžete chtít řešit funkci komentářů. Můžete vytvořit novou soběstačnou mikroslužbu Komentář REST API, která bude obsahovat antispamové filtry a unikátní technologii pro práci s identitami komentářů.

Mikroslužba Komentář plně zapouzdřuje veškerý úžasný kód pro komentáře. Váš klient uživatelského rozhraní nyní může podle potřeby načítat dynamická data z tohoto nového rozhraní API.

Nakonec byste mohli promyslet vytvoření mikroslužby Autor, která zajistí autentizaci a oprávnění k vytváření nových článků. Služba Autor bude mít pravděpodobně uživatelské rozhraní řídicího panelu. Umožní autorům blogu přihlášení a napsání nových blogových příspěvků.

Mikroslužbu Autor bude potřebné integrovat jak do klienta uživatelského rozhraní, tak i do mikroslužby Článek. Mikroslužba Článek by mohla volat rozhraní API mikroslužby Autor během procesu vytváření článku, aby se zajistilo, že autor má oprávnění ke psaní nových blogových příspěvků.

V minulosti bylo možné vykonávat kontrolu oprávnění pomocí tabulky JOIN v relační databázi. Volání rozhraní API odlehčené propojovací služby může někdy nahradit tabulky JOIN.

Aplikace rozhraní v podobě mikroslužeb nyní načítá data ze tří samostatných mikroslužeb, z nichž dvě komunikují navzájem. Vše je v této aplikaci decentralizované. Namísto jedné velké relační databáze má každá mikroslužba svou vlastní databázi.

Každou mikroslužbu lze nezávisle škálovat. Můžete nakonfigurovat vyrovnávání zátěže s desítkami aplikačních serverů pro mikroslužbu Článek, ale potřebujete jen jednu instanci mikroslužby Autor bez vyrovnávání zátěže.

Filozofie decentralizace mikroslužeb s jejich volným spojením se dobře hodí pro využití služeb třetích stran. Například namísto vytváření vaší mikroslužby Komentář můžete použít Disqus. Namísto tvorby vaší vlastní autentizační mikroslužby můžete využít službu Janrain.

Vytváření aplikací v podobě mikroslužeb se může zpočátku zdát divné. Architektura mikroslužeb se však ukázala jako životaschopná alternativa ke starým monolitickým obludám. Pokud se rozhodnete jít touto cestou, budete stát na ramenou obrů.

Pro koho jsou?

Odpověď na otázku, zda byste měli využívat mikroslužby, vás možná překvapí – ne vždy. Jak říká Chris Richardson, konzultant pro oblast mikroslužeb: „Není to jednoduché, ale důvodem k používání mikroslužeb je odstranění složitosti.“

Je důležité si uvědomit, že mikroslužby jsou reakcí na dosažení limitu, přes který se nelze dostat. V určitém okamžiku již tradiční monolitické aplikační architektury nelze více škálovat. To se stává každému úspěšnému softwarovému projektu. Buď databáze narůstá příliš, nebo existuje příliš mnoho milionů řádků kódu, či už nemůžete přidávat další funkce dostatečně rychle.

Pokud jste ještě dosud nedosáhli limitu, tj. když vaše stará aplikace stále dobře funguje a nemusíte ji moc měnit, potom by použití mikroslužeb pro ně samotné nepřineslo nic více než starosti.

Koneckonců mikroslužby přinášejí do vývojového procesu zvláštnosti a některé těžkosti. Udržování všech těchto nových služeb v provozu může někdy vypadat jako žonglování s desítkami koulí. Přijetí deklarativních orchestračních nástrojů, jako je např. Kubernetes, může také vyžadovat určité přizpůsobení. Komplexní architektury mikroslužeb mají vlastní lexikon, který pokrývá všechny nové softwarové vzory, které budete potřebovat přijmout.

Mikroslužby však zatím nejsou ani zdaleka tak skličující, jako bývala kdysi technologie SOA. Ve skutečnosti lze postupy mikroslužeb implementovat i v nejmenších softwarových projektech a nemusíte zahazovat veškerý svůj kód, abyste mohli začít. Můžete začít tím, že vytvoříte napodobené mikroslužby.

Máte-li rozsáhlou aplikaci, která se dostává mimo kontrolu, s dlouhými životními cykly softwaru, které trvají příliš dlouho, a tempo inovací se zastavuje, mohou být mikroslužby řešením, které potřebujete. Případně pokud právě začínáte, bylo by rozumné uvážit vytváření aplikace s pomocí mikroslužeb už od samotného počátku.

Firma eBay uvedla, že jim architektura mikroslužeb umožnila výrazně růst, rozšířit škálovatelnost a spravovatelnost kódu, podpořit rychlé podnikové inovace, zajistit rychlejší dodávku produktů, a dokonce zvýšit bezpečnost. Google, Amazon, Twitter, PayPal a Netflix mají všechny podobné zkušenosti. Mnoho z těchto společností také vytvořilo nástroje, které přijímání mikroslužeb ulehčují.

Ať už trpíte problémy s udržováním staršího kódu a nevíte, jak můžete postupovat kupředu, nebo začínáte nově vyvíjet aplikaci zcela od základu, může být nyní vhodný čas na posouzení vývoje aplikací s využitím mikroslužeb.

Tento příspěvek vyšel v Computerworldu 10/2017. Časopis (starší čísla i předplatné těch nadcházejících) si můžete objednat na adrese našeho vydavatelství.