Hlavní navigace

Mikroslužby: moderní aplikace využívající známých konceptů

16. 5. 2019
Doba čtení: 18 minut

Sdílet

V dnešním článku se seznámíme se základními principy, na nichž jsou postaveny takzvané mikroslužby (microservices). Může se zdát, že jde o „Next Great Thing“ v IT, ale jejich koncept postaven na známých myšlenkách.

Obsah

1. Mikroslužby

2. Od klasických monolitických služeb k mikroslužbám

3. Reálně provozované monolitické služby a jejich škálování

4. Koncepty, na nichž jsou postaveny mikroslužby

5. Myšlenka ze světa Unixu: smart endpoints and dumb pipes

6. Decentralizace na všech úrovních, škálování

7. Automatizace při nasazování, testování a provozování mikroslužeb

8. Další vybrané přednosti mikroslužeb

9. A pochopitelně i některé zápory

10. Synchronní vs. asynchronní volání

11. Message brokery

12. Časté omyly, kterých se vývojáři dopouští (nejenom) při tvorbě mikroslužeb

13. Síť jakožto problematický prvek

14. Špatné uplatnění konceptu mikroslužeb

15. Sdílení databáze mezi mikroslužbami

16. SOA versus mikroslužby

17. Rozdíly v přístupu SOA a MSA

18. Odkazy na Internetu

1. Mikroslužby

V dnešním článku se seznámíme se základními principy, na nichž je postaven koncept takzvaných mikroslužeb (microservice). Jedná se o poměrně často skloňovaný termín, kterým se v informatice označuje nový (či spíše přesněji řečeno staronový) způsob realizace služeb (service), tj. implementací nějaké funkcionality, která je typicky nabízena servery, ať již na Internetu či „pouze“v rámci Intranetu. Mezi typické služby patří například správa uživatelů (zaměstnanců), správa tiskových úloh, docházkový či skladový systém, CMS či dokonce celý publikační systém, mapové portály, dále služby typu Google Drive apod. Podle způsobu návrhu architektury takových služeb dnes rozlišujeme mezi monolitickými službami na straně jedné a právě mikroslužbami na straně druhé. A pochopitelně můžeme nalézt i mnohé návrhy architektury, které leží mezi těmito dvěma v podstatě extrémními kategoriemi (viz například dále zmíněnou metodologii SOA).

V souvislosti s mikroslužbami se často mluví i o různých nástrojích a technologiích, mezi něž patří například Ansible, Docker, Kubernetes, Knative, OpenShift atd. Ty se skutečně pro projekty založené na mikroslužbách používají, ovšem pro samotné pochopení principů, na nichž jsou mikroslužby postaveny, se prozatím těmito nástroji nemusíme podrobněji zabývat (alespoň nikoli v úvodním článku).

Poznámka: podobně jako v mnoha dalších oblastech IT není vlastní koncept mikroslužeb vlastně nijak nový, protože se podobné myšlenky (i když možná ne v té nejčistší podobě) aplikovaly již dříve; ostatně filozofie Unixu je založena na podobných myšlenkách. Samotný vznik a rozšíření používání termínu mikroslužba však ukazuje na to, že celá problematika před několika roky uzrála do takové míry, aby se staronový koncept přímo pojmenoval (navíc se nejedná o tak marketingový termín, jako například pojem Web 2.0).

2. Architektura klasických monolitických služeb

Pravděpodobně každý čtenář Roota se již setkal s nějakou monolitickou aplikací či s monolitickou webovou službou (ostatně i samotný Root je s poměrně velkou pravděpodobností postaven podobným způsobem). Typicky je taková aplikace rozdělena na tři části: vrstvu zajišťující uživatelské rozhraní, vrstvu s vlastní implementací business logiky a konečně většina služeb používá i nějaké datové úložiště, do něhož se vstupuje přes datovou vrstvu. V tom nejtypičtějším případě může být služba realizována na základě čistě třívrstvé architektury:

Obrázek 1: Klasická (stále poměrně často používaná) třívrstvá architektura.

Mezi typické znaky takto navržených a provozovaných služeb patří především:

  1. Samotný programový kód, i když může být vnitřně velmi dobře strukturovaný a modularizovaný (knihovny, jmenné prostory, třídy, funkce, programové bloky), je většinou napsán v jednom programovacím jazyku, uložen v jediném repositáři a spravován jako monolit.
  2. Podobně i datové úložiště (databáze) bývá monolitická – jedno úložiště pro celou aplikaci/službu.
  3. Moduly, z nichž se případně aplikace skládá, jsou těsně svázány a případné změny v rozhraních modulů mohou mít velký dopad na celou aplikaci (její nasaditelnost, stabilitu atd.).
  4. Aplikace se typicky nasazuje a testuje jako celek; při každém nasazení bývá (v tom lepším případě :-) kompletně otestována, což může být časově náročná operace.
  5. Samotná aplikace většinou závisí na mnoha knihovnách, které mají tranzitivní závislosti (tedy „závislosti závislostí“). Jakékoli zvýšení verze závislých knihoven (například v důsledku nalezené CVE) je opět nutné otestovat v kontextu celé aplikace; chyba v knihovně může celou aplikaci znepřístupnit, v případě CVE pak způsobit například únik dat.

3. Reálně provozované monolitické služby a jejich škálování

Ve skutečnosti je však reálná aplikace či služba realizována ještě poněkud komplikovanějším způsobem, protože vlastní realizace frontendu a business logiky bývá „schována“ za mezivrstvu realizovanou HTTP serverem (například Apache či Nginx), který dokáže kromě jiného zajistit i posílání statického obsahu atd. Frontend a business logika může v tomto případě běžet například v nějakém aplikačním serveru, servlet kontejneru, může se jednat o aplikaci napsanou v Pythonu založenou na knihovně Flask, samostatnou aplikaci vyvinutou v programovacím jazyce Go pomocí standardního balíčku net/http:, aplikaci pro Node.js atd.:

Obrázek 2: Služba v reálném provozu při použití HTTP serveru, k němuž se připojují klienti.

V případě, že je takovou službu nutné naškálovat, je to pochopitelně možné, i když v poněkud omezeném rozsahu (této problematice se budeme podrobněji věnovat v navazujících kapitolách):

Obrázek 3: Jedna z možností škálování monolitické služby, kdy HTTP server současně zajišťuje load balancing.

Jeden z problémů při škálování monolitických služeb je jejich příliš velká granularita a z toho plynoucí větší náklady na HW či na prostředky dostupné v cloudu. Taktéž bývá obtížné či prakticky nemožné vybalancovat požadavky na potřebnou kapacitu operační paměti, výpočetní výkon mikroprocesoru, rychlost vstupně-výstupních operací a kapacitu síťového připojení. Totéž lze říci o případu, kdy aplikace využívá jedinou databázi a potřebuje ji horizontálně či vertikálně naškálovat.

Poznámka: sice se většinou nejedná o neřešitelné problémy, ale obecně bývá řešení složitější a někdy též křehčí.

4. Koncepty, na nichž jsou postaveny mikroslužby

Monolitické služby se v praxi používají už několik desítek let a vývojáři i administrátoři v tomto období postupně zjišťovali, jaké jsou limity této architektury, a to jak z hlediska rychlosti vývoje, kvality služby, její udržovatelnosti a rychlosti, tak i s ohledem na dostupnost takových služeb. Postupně rostoucí složitost aplikací vedla ke vzniku nových konceptů architektury služeb, které by (pochopitelně v ideálním případě) měly odstranit největší problémy klasických monolitických služeb a současně nepřinést mnoho problémů nových. Výsledný koncept, či možná lepe řečeno sada konceptů, principů a idiomů, byl pojmenován mikroslužby; někdy se též setkáme s označením MOA (Microservice Oriented Architecture), což je vtípek vycházející ze zkratky SOA (Service Oriented Architecture)).

Obrázek 4: Mnoho monolitických služeb se snaží nabídnout funkce, které spolu prakticky vůbec nesouvisí.

Samotná základní myšlenka, na níž jsou mikroslužby postaveny, vlastně není nijak objevná – celá aplikace se skládá z obecně většího počtu několika služeb či dokonce několika desítek takzvaných mikroslužeb, přičemž každá taková mikroslužba má přesně definovanou roli (většinou pouze jednu!), běží v samostatném procesu (procesech) a komunikuje buď přímo či nepřímo s ostatními mikroslužbami, typicky s využitím nějakého standardního protokolu (REST API přes HTTP a HTTPS popř. nějaký protokol pro messaging). Povšimněte si, že tato myšlenka skutečně není nijak nová, protože na velmi podobných principech je založen i celý Unix s mnoha nástroji, z nichž každý má přísně omezenou roli, ovšem tuto roli zvládá velmi dobře. I samotná myšlenka komunikace mikroslužeb mezi sebou není nová – opět ji podporuje Unix se svými rourami, pojmenovanými rourami, sockety a frontami zpráv. Mikroslužby tento lety prověřený koncept rozšiřují do systému s větším množstvím počítačů a systémů (popř. kontejnerizovaných systémů).

Partner seriálu o mikroslužbách

V IGNUM mají rádi technologie a staví na nich vlastní mikroslužby, díky kterým je registrace a správa domén, hostingů a e-mailů pro zákazníky hračka. Vymýšlet jednoduchá řešení pro obsluhu složitých systémů a uvádět je v život je výzva. Společnost IGNUM miluje mikroslužby a je proto hrdým partnerem tohoto seriálu.

Důležité je, že každou z takto navržených mikroslužeb je možné vyvíjet, nasazovat, aktualizovat a pochopitelně i restartovat samostatně, v ideálním případě takovým způsobem, aby to nezasáhlo ostatní součásti vyvíjené aplikace. I možnosti škálování jsou lepší díky jemné granularitě jednotlivých mikroslužeb.

Dále se u mikroslužeb velmi často setkáme s použitím systémů pro automatizaci jejich nasazení a aktualizaci, protože s rostoucím počtem mikroslužeb se stává velmi neefektivní či dokonce nemožná jejich manuální správa. Automatizace se pochopitelně týká i testování mikroslužeb, samotnému vývoji integračních testů atd. Tomuto velmi důležitému tématu se budeme věnovat v dalších částech tohoto seriálu.

5. Myšlenka ze světa Unixu: smart endpoints and dumb pipes

V předchozí kapitole jsme se zmínili o tom, že koncept mikroslužeb má mnoho společného s filozofií Unixových nástrojů. Z Unixu pochází i další princip, který se uplatnil v mikroslužbách. Martin Fowler tento princip nazval „smart endpoints and dumb pipes“. Ve stručnosti se jedná o to, že jednotlivé mikroslužby se samy interně starají o validaci vstupních dat, aplikaci transformací dat, atd. Z pohledu uživatelů takto navržených mikroslužeb se jedná o operace prováděné uvnitř mikroslužeb (ty jsou, nebo by alespoň při jejich správném návrhu měly být, zapouzdřeny). Na druhé straně zvolený komunikační mechanismus (pipe), což může být například protokol HTTP, žádné podobné operace, jakými jsou validace či transformace dat, neprovádí, podobně jako je v Unixu NEprovádí klasická roura (taktéž pipe), která pouze zajišťuje přenos dat mezi dvojicí procesů. Díky tomu jsou z celé architektury aplikace odstraněny zbytečně složité věci, které se týkají jak používaných nástrojů, tak i knihoven, způsobů nasazení mikroslužeb atd.

Obrázek 5: Jednotlivé mikroslužby mezi sebou mohou komunikovat například s využitím protokolu HTTP (REST API), STOMP atd.

Poznámka: jako příklad zbytečně „chytrého“ a tím pádem složitého komunikačního mechanismu uvádí Martin Fowler Enterprise service bus, ovšem můžeme si představit například i CORBA a podobné technologie. Ve skutečnosti se aplikace využívající ESB svým principem nachází na půlce cesty mezi aplikacemi monolitickými na jedné straně a mikroslužbami na straně druhé.

6. Decentralizace na všech úrovních, škálování

Při použití mikroslužeb se taktéž do značné míry využívá konceptu decentralizace. Samozřejmě se to týká především samotných mikroslužeb, ovšem nesmíme zapomenout ani na ty mikroslužby, které potřebují využít nějakou databázi. V ideálním případě jsou i databáze rozděleny a decentralizovány, což ovšem není vždy lehký úkol, protože je nutné zajistit validitu i dostupnost dat pro další mikroslužby.

Velkou předností mikroslužeb je jejich dobrá škálovatelnost, která plyne z toho, že mikroslužby mají oproti monolitické aplikaci jemnější granularitu. Rozdíly mezi naškálováním monolitické aplikace a aplikace založené na mikroslužbách jsou znázorněny na následující dvojici obrázků.

Obrázek 6: V levé polovině je znázorněna monolitická služba, v pravé polovině pak aplikace složená z několika mikroslužeb. Plocha jednotlivých obrazců může například znázorňovat paměťové požadavky, potřebný výpočetní výkon atd. atd.

Obrázek 7: V případě, že se nám podaří získat výkonnější počítač, můžeme v případě monolitické služby provést její naškálování, ovšem jen 2× pro celou službu. Bílá plocha (výkon, paměť) zůstane nevyužita. Naproti tomu mikroslužby můžeme „naskládat“ s větší svobodou; můžeme se například rozhodnout, která mikroslužba bude naškálována vícekrát a kterou postačí mít v systému pouze jedenkrát. Bílá plocha je zde pochopitelně menší.

7. Automatizace při nasazování, testování a provozování mikroslužeb

U mikroslužeb hrají velkou roli nástroje určené pro jejich nasazování, testování, provozování a v neposlední řadě taktéž pro monitoring jejich činnosti. Toto téma je velmi rozsáhlé a nabídka nástrojů velká (a jedná se mnohdy o komplexní nástroje), proto se tomuto tématu budeme podrobněji věnovat v dalších částech tohoto seriálu.

8. Další vybrané přednosti mikroslužeb

Mezi další vybrané přednosti mikroslužeb patří například:

  1. Možnost souběžného vývoje jednotlivých částí aplikace různými týmy.
  2. V podstatě automatické přijetí myšlenek, na nichž stojí CI/CD.
  3. Samotné API mikroslužeb je většinou tak jednoduché, že ho vývojář dokáže udržet v hlavě.
  4. Taktéž je možné jednotlivé služby vyvíjet v různých programovacích jazycích, což může být výhodné v případě, že aplikaci vyvíjí několik týmů.
  5. Samozřejmě sem spadá i mnohem lepší možnosti distribuce mikroslužeb mezi více servery s možností replikace.
  6. Nesmíme zapomenout ani na testování mikroslužeb, které může probíhat na několika úrovních testování mikroslužeb sice není snadnější, než je tomu v případě monolitické aplikace, ovšem může být (podobně jako samotný vývoj mikroslužeb) vhodným způsobem škálováno.
Replikace a škálování lze samozřejmě provádět i u monolitické služby, ovšem mnohdy se zbytečně mrhá systémovými prostředky i na ty části monolitické služby, které jsou málo zatíženy a naškálování nepotřebují. U mikroslužeb – pochopitelně pokud jsou správně navrženy – je škálování, replikace, load balancing atd. možné provádět s menšími softwarovými celky a tedy s větší flexibilitou.

9. A pochopitelně i některé zápory

V IT, ostatně podobně jako i v dalších oborech, platí Heinleinovo pravidlo nejízda („není jídlo zdarma“), proto mají i mikroslužby mnoho záporů:

  1. Nemusí se jednat o dobré řešení pro menší vývojové týmy, protože se vyžadují větší znalosti a více rolí, než při nasazení monolitických služeb na (aplikační) servery.
  2. Celý systém je fragmentovaný a je nutné zajistit spojení jednotlivých částí, vytvořit systém pro vyhledávání služeb, jejich monitoringu atd.
  3. Prozatím neexistence jednotných návrhových vzorů popř. standardů.
  4. Pokud je systém špatně navržen, bude výpadek jedné mikroslužby znamenat výpadek celého systému.
  5. Úpravy a změny v rozhraní jednotlivých mikroslužeb je nutné nějakým způsobem plánovat, verzovat atd., protože opět může dojít k velkým výpadkům aplikace.
  6. Komunikace mezi procesy (každá mikroslužba je jeden proces), které mnohdy běží na jiném počítači, je pochopitelně pomalejší, než interprocesová komunikace (což je přímé volání funkcí a metod).
  7. Celý systém je nutné monitorovat, aby se předcházelo nežádoucím výpadkům, zejména pokud je nějaká část systému kritická (SFoF – single point of failure).

Příklad výpadku systému založeného na mikroslužbách a současně i na cloudovém řešení: A Closer Look at the Christmas Eve Outage.

10. Synchronní vs. asynchronní volání

„Since cloud-based applications are also Internet-based applications, many developers new to the cloud scene are intrinsically approaching each service design as simply micro-web-servers. Since the public interface for an API level service uses REST with JSON packets, it’s reasonable to utilize this format for each of the internal services, too.“

Ne vždy je vhodné používat REST API pro komunikaci mezi všemi mikroslužbami. Typicky například message brokery používají vlastní efektivnější protokoly, ovšem i v dalších situacích je dobré se zamyslet, zda protokol založený na principu dotaz-odpověď je to nejlepší v daném okamžiku a pro daný problém. Podobně je možné JSON nahradit například BSONem, protocol buffers atd., podle konkrétní situace.

11. Message brokery

V souvislosti s asynchronním voláním popř. vůbec s asynchronním zpracováním úloh, se musíme zmínit i o message brokerech, které se v architektuře s mikroslužbami pochopitelně taktéž uplatní. Tomuto tématu se podrobněji věnujeme v samostatném seriálu, v němž jsme si již popsali některé často používané implementace message brokerů, zejména projekty Redis Queue, Celery, RabbitMQ a ApacheMQ (popř. jeho novější variantu Artemis). Kromě klasických message brokerů se setkáme i s použitím tzv. streamingu podporovaného systémem NATS a pravděpodobně nejpopulárnějším nástrojem v této oblasti – Apache Kafkou.

Obrázek 8: Interní konfigurovatelná struktura systému RabbitMQ. Jak producenti, tak i konzumenti mohou být realizováni formou mikroslužeb.

S message brokery se komunikuje s využitím několika široce podporovaných protokolů, zejména protokolu STOMP (Streaming Text Oriented Messaging Protocol), MQTT (MQTT is a machine-to-machine connectivity protocol) a AMQP (Advanced Message Queuing Protocol).

Obrázek 9: Jedna z možných konfigurací rozvětvení. První směrovač (exchange) zkopíruje přijatou zprávu do tří front. Poslední (čtvrtá) fronta není v tomto případě nijak využita – rozvětvení se provádí jen do předem vybraných front.

12. Časté omyly, kterých se vývojáři dopouští (nejenom) při tvorbě mikroslužeb

Při vývoji mikroslužeb se samozřejmě nevyhneme mnoha omylům, které mohou zapříčinit například problémy s výkonností popř. dokonce nekonzistencí dat či časté výpadky celé aplikace. Velmi pěkně jsou některé omyly shrnuty ve videu 10 Tips for failing badly at Microservices by David Schmitz a postupně se jimi budeme zabývat v navazujících částech tohoto seriálu. V dalších kapitolách se zmíním o některých základních problémech, s nimiž se setkáme již na samotném začátku návrhu architektury aplikace. Tyto problémy souvisí se dvěma důležitými prvky, bez nichž se aplikace většinou neobejdou – počítačová síť a databáze (či obecněji datová úložiště).

13. Síť jakožto problematický prvek

Mnoho omylů při návrhu a nasazování (nejenom) mikroslužeb vychází ze samotného principu konstrukce a fungování počítačových sítí. Z hlediska návrhu aplikace je síť – a velká (kritická) závislost celé architektury na síti – skutečně velmi problematická, protože architektura aplikace založené na mikroslužbách spadá do kategorie distribuovaných aplikací. Mezi velmi časté omyly patří například následující předpoklady, které shrnul L. Peter Deutsch ještě v dobách existence společnosti Sun Microsystems (ani jeden z těchto předpokladů pochopitelně neplatí):

  1. Síť je spolehlivá
  2. Zpoždění při přenosu zpráv je nulové či velmi nízké
  3. Přenosová kapacita je nekonečná či dostatečně vysoká
  4. Síť je bezpečná
  5. Topologie sítě se nemění
  6. O síť se stará pouze jeden (dohledatelný) administrátor
  7. Cena přenosu dat je nulová či prakticky nulová
  8. Síť je homogenní

Největší problém – alespoň podle mého názoru – spočívá v tom, že výše uvedená (chybná) tvrzení někdy mohou (částečně) platit, typicky ve chvíli, kdy vývojáři mají k dispozici kvalitní vybavení a vyvíjí aplikaci na lokální síti. Ovšem v reálném provozu se dříve či později všechny nepěkné vlastnosti sítě ukážou (většinou v ten nejnevhodnější okamžik).

14. Špatné uplatnění konceptu mikroslužeb

Někdy se setkáme i s kombinací komplexnosti architektury založené na mikroslužbách s nepružností a „křehkostí“ monolitických služeb. Ve výše zmíněném videu je ukázán možná velmi typický příklad – aplikace sice používá mikroslužby, ale samotné UI je monolitické; v podstatě jediná dynamicky generovaná stránka (dnes populární SPA). Problémem zde je především fakt, že mnoho požadavků na změnu v UI (přidání nějakého atributu) je nutné nějakým způsobem reflektovat i v mikroslužbách, ale nemusí být zcela patrné, ve kterých.

15. Sdílení databáze mezi mikroslužbami

V případě, že je v aplikaci založené na mikroslužbách použita databáze, která je sdílená mezi jednotlivými mikroslužbami, může se stát, že tento návrh povede ke špatné funkci aplikace jako celku, a to například z hlediska škálovatelnosti, dostupnosti či stability. Jádro problému tohoto návrhu totiž spočívá v tom, že se porušil jeden z principů mikroslužeb – zajistit co nejmenší závislosti mezi jednotlivými mikroslužbami. A to, že dvě či více mikroslužeb přistupuje ke stejné databázi, je pochopitelně velká závislost. Při snaze o rozdělení databáze na menší celky je vždy důležité si uvědomit, která mikroslužba je skutečným vlastníkem onoho menšího celku (zákazníci, prodávané výrobky, sklad, logy, B2B transakce atd.)

Poznámka: zajímavé je, že někteří autoři dokonce uvádí shared-database jako jeden z návrhových vzorů mikroslužeb. Obecně se však skutečně nejedná o dobrý návrh.
Poznámka 2: termínem databáze zde nejsou myšleny jen relační databáze, ale i dokumentové či objektové databáze, služby typu S3 atd. atd.

16. SOA versus mikroslužby

Ještě před vznikem konceptu mikroslužeb se začaly používat aplikace navržené s využitím metodologie SOA neboli Service Oriented Architecture. I metodologie SOA je založena na rozložení aplikace na jednotlivé komponenty, které by měly být na sobě nezávislé a měly by spolu komunikovat. A i zde se doporučuje jednotlivé komponenty navrhovat tak, aby byly v ideálním případě bezstavové, což zjednodušuje například škálování, náhradu komponenty při jejím výpadku apod. Na mikroslužby – někdo je v tomto kontextu nazývá MOA (Microservices Oriented Architecture) – se můžeme dívat jako na jednu z extrémnějších (v pozitivním slova smyslu) variant metodologie SOA, kdy se klade ještě větší důraz na rozdělení architektury na menší části a taktéž na to, aby bylo možné jednotlivé části vyvíjet, nasazovat a testovat nezávisle na ostatních částech.

Navíc se zjednodušila i samotná metodika, protože v SOA jsou definovány čtyři typy služeb (business, enterprise, application a infrastructure), zatímco u mikroslužeb se většinou rozlišují jen dva typy služeb (functional a infrastructure), popř. se takové rozlišení ani nepoužívá.

root_podpora

Poznámka: názvy jednotlivých typů služeb nepřekládám schválně, protože ne všichni autoři a programátoři se shodnou na stejných českých termínech.

Pokud se podíváme na architekturu typické SOA aplikace a aplikace založené na mikroslužbách, můžeme vidět několik rozdílů ve způsobu nasazení jednotlivých komponent. U mikroslužeb typicky odpadá použití aplikačního serveru, protože je to zbytečně „těžkotonážní“ nástroj:

SOA Mikroslužby
Služba a její API  
Aplikace  
Aplikační server Služba a její API
Prostředí pro běh (JVM atd.) Prostředí pro běh
Operační systém Operační systém
Hypervisor Hypervisor
Datové úložiště Datové úložiště
Síťové rozhraní Síťové rozhraní

17. Rozdíly v přístupu SOA a MSA

Největší rozdíly mezi koncepty SOA a MSA však nalezneme v přístupu (možná můžeme říci že dokonce v ideologii), které jsou vývojovými týmy dodržovány. Ostatně to je patrné i z následující tabulky, v níž jsou některé rozdíly vypsány:

SOA MSA
spíše hrubší granularita služeb („mikromonolity“) jemnější granularita služeb
zaměření na standardizaci procesů, nástrojů atd. zaměření na spolupráci lidí a možnost svobodného výběru technologií
použití ESB (Enterprise Service Bus) jednoduché systémy pro posílání zpráv
podpora většího množství protokolů pro přenos zpráv zaměření na použití jednoduchých protokolů (HTTP, STOMP, …)
založeno na jednom programovacím jazyku a sadě knihoven volnost výběru jazyka i knihoven podle potřeby
běh ve více vláknech typicky běh v jednom vláknu s non-locking I/O, použití zelených vláken
služby dělené podle business požadavků dělení spíše podle kontextu
jediná databáze pro celou aplikaci každá mikroslužba používá vlastní datové úložiště
požadavek na změnu: úprava (mikro)monolitu požadavek na změnu: vytvoření nové mikroslužby
Poznámka: ve skutečnosti se postupně mění i svět SOA, který se tak pomalu (alespoň v některých oblastech) přibližuje konceptu mikroslužeb.

18. Odkazy na Internetu

  1. Vision of a microservice revolution
    https://www.jolie-lang.org/vision.html
  2. Microservices : a definition of this new architectural term
    https://martinfowler.com/ar­ticles/microservices.html
  3. Mikroslužby
    http://voho.eu/wiki/mikrosluzba/
  4. Microservice Prerequisites
    https://martinfowler.com/bli­ki/MicroservicePrerequisi­tes.html
  5. Microservices in Practice, Part 1: Reality Check and Service Design (vyžaduje registraci)
    https://ieeexplore.ieee.or­g/document/7819415
  6. Microservice Trade-Offs
    https://www.martinfowler.com/ar­ticles/microservice-trade-offs.html
  7. What is a microservice? (from a linguistic point of view)
    http://claudioguidi.blogspot­.com/2017/03/what-microservice-from-linguisitc.html
  8. Microservices (Wikipedia)
    https://en.wikipedia.org/wi­ki/Microservices
  9. Fallacies of distributed computing (Wikipedia)
    https://en.wikipedia.org/wi­ki/Fallacies_of_distributed_com­puting
  10. Service (systems architecture)
    https://en.wikipedia.org/wi­ki/Service_(systems_archi­tecture)
  11. Microservices in a Nutshell
    https://www.thoughtworks.com/in­sights/blog/microservices-nutshell
  12. What is Microservices?
    https://smartbear.com/solu­tions/microservices/
  13. Mastering Chaos – A Netflix Guide to Microservices
    https://www.youtube.com/wat­ch?v=CZ3wIuvmHeM&t=17s
  14. Messaging in Microservice Architecture
    https://www.youtube.com/wat­ch?v=MkQWQ5f-SEY
  15. Pattern: Messaging
    https://microservices.io/pat­terns/communication-style/messaging.html
  16. Microservices Messaging: Why REST Isn’t Always the Best Choice
    https://blog.codeship.com/mi­croservices-messaging-rest-isnt-always-best-choice/
  17. Protocol buffers
    https://developers.google.com/protocol-buffers/
  18. BSON
    http://bsonspec.org/
  19. Apache Avro!
    https://avro.apache.org/
  20. REST vs Messaging for Microservices – Which One is Best?
    https://solace.com/blog/experience-awesomeness-event-driven-microservices/
  21. How did we end up here?
    https://gotocon.com/dl/goto-chicago-2015/slides/MartinThompson_an­d_ToddMontgomery_HowDidWe­EndUpHere.pdf
  22. Scaling microservices with message queues to handle data bursts
    https://read.acloud.guru/scaling-microservices-with-message-queue-2d389be5b139
  23. Microservices: What are smart endpoints and dumb pipes?
    https://stackoverflow.com/qu­estions/26616962/microser­vices-what-are-smart-endpoints-and-dumb-pipes
  24. Common Object Request Broker Architecture
    https://en.wikipedia.org/wi­ki/Common_Object_Request_Bro­ker_Architecture
  25. Enterprise service bus
    https://en.wikipedia.org/wi­ki/Enterprise_service_bus
  26. Microservices vs SOA : What’s the Difference
    https://www.edureka.co/blog/mi­croservices-vs-soa/
  27. Pravda o SOA
    https://businessworld.cz/reseni-a-realizace/pravda-o-soa-2980
  28. Is it a good idea for Microservices to share a common database?
    https://www.quora.com/Is-it-a-good-idea-for-Microservices-to-share-a-common-database
  29. Pattern: Shared database
    https://microservices.io/pat­terns/data/shared-database.html
  30. Is a Shared Database in Microservices Actually an Anti-pattern?
    https://hackernoon.com/is-shared-database-in-microservices-actually-anti-pattern-8cc2536adfe4
  31. Shared database in microservices is a problem, yep
    https://ayende.com/blog/186914-A/shared-database-in-microservices-is-a-problem-yep
  32. Microservices with shared database? using multiple ORM's?
    https://stackoverflow.com/qu­estions/43612866/microser­vices-with-shared-database-using-multiple-orms

Byl pro vás článek přínosný?