Téměř každý počítačový systém provádí více úkolů pomocí sdílených prostředků a jednou z otázek počítačového programování je, jak úzce by měly být kousky kódu, které tyto úkoly provádějí, navzájem spojeny. Stále populárnější odpovědí je koncept mikroslužby—malá, diskrétní část funkcí, která interaguje s jinými mikroslužbami a vytváří větší systém.
Ačkoli základní myšlenka mít takové diskrétní komponenty není nová, způsob implementace mikroslužeb z nich dělá přirozený základ pro obě moderní cloudové aplikace. Microservices také zapadají do filozofie devops, která podporuje rychlé a nepřetržité zavádění nových funkcí.
Co jsou mikroslužby?
„Mikro“ v mikroslužbách znamená, že se jedná o malé aplikace. To je někdy pravda, ale lepší způsob, jak o nich přemýšlet, je, že by měli být jen tak velcí, jak je potřeba, aby dokázali udělat jednu konkrétní věc nebo vyřešit konkrétní problém. Tento problém by měl být koncepční, nikoli technický. Jak uvádí Microsoft, „Microservices by měly být navrženy kolem obchodních schopností, nikoli horizontálních vrstev, jako je přístup k datům nebo zasílání zpráv.“ Komunikují s jinými mikroslužbami a externími uživateli prostřednictvím relativně stabilních rozhraní API, aby vytvořili větší aplikaci.
Interní funkčnost jednotlivých mikroslužeb lze tedy vylepšit nebo radikálně upgradovat, aniž by to ovlivnilo zbytek systému. To zase souvisí s tím, jak se obchody devops snaží fungovat: Pokud jsou specifické funkce větší aplikace segmentovány do samostatných, nezávisle fungujících částí kódu, je snazší žít devops mantru CI / CD (nepřetržitá integrace a nepřetržité doručování) . Dobře definované rozhraní API také usnadňuje automatické testování mikroslužeb.
Architektura mikroslužeb vs. monolitická architektura
Mikroslužby budete často slyšet ve smyslu „architektury mikroslužeb.” Tato fráze zahrnuje nejen samotné mikroslužby, ale také komponenty pro správu a zjišťování služeb, stejně jako bránu API, která zpracovává komunikaci mezi mikroslužbami a vnějším světem.
„Monolitická aplikace“ je opakem toho, co jsou mikroslužby. Je to retronym pro aplikaci, kde je celý kód v jednom velkém binárním spustitelném souboru. Jak vysvětluje TechTarget, monolitická aplikace je těžší škálovat a těžší se vylepšuje. Ale protože je postaven jako jediná soudržná aplikace, nevyžaduje tolik správy jako architektura mikroslužeb.
Ohraničené koncepty: Jak definovat mikroslužbu
Vraťme se na chvíli k našemu dřívějšímu přikázání, že mikroslužby by měly dělat jednu konkrétní věc. To se dá snadno říci, ale v praxi se funkčnost často zaměňuje a kreslení divizí je těžší, než vypadá. Analýza domény a návrh řízený doménou jsou teoretické přístupy, které vám pomohou rozdělovat váš úkol ve velkém na jednotlivé problémy, které může mikroslužba vyřešit. V tomto procesu, načrtnutém v osvětlovací sérii blogových příspěvků od společnosti Microsoft, vytvoříte abstraktní model vaší obchodní domény a v tomto procesu objevíte ohraničené kontexty, které seskupují funkce, které konkrétním způsobem interagují se světem.
Můžete mít například jeden ohraničený kontext pro přepravu a druhý pro účty. Skutečný fyzický objekt by měl samozřejmě cenu i místo, kam musí jít, ale ohraničené kontexty představují konkrétní způsoby, jak o nich vaše aplikace myslí a interaguje s nimi. Každá mikroslužba by měla existovat zcela v rámci jednoho ohraničeného kontextu, ačkoli některé ohraničené kontexty mohou zahrnovat více než jednu mikroslužbu.
Mikroslužby vs. architektura orientovaná na služby vs. webové služby
V tomto okamžiku, pokud jste profesionálem v oblasti IT, který už nějakou dobu působí v tomto odvětví, možná vám to bude připadat povědomé. Myšlenka spolupráce jednotlivých jednotlivých programů vám může připomínat jak SOA (architektura orientovaná na služby), tak webové služby, dvě módní slova z opojného webu 2.0 dnů 2000. Zatímco v jednom smyslu pod sluncem skutečně není nic nového, mezi těmito pojmy a mikroslužbami existují důležité rozdíly. Datamation má dobré rozdělení rozdílů, ale tady je krátká verze:
- V architektuře orientované na služby jsou jednotlivé komponenty relativně těsně spojené, často sdílejí aktiva, jako je úložiště, a komunikují prostřednictvím specializovaného softwaru zvaného podniková sběrnice úložiště.. Mikroslužby jsou nezávislejší, sdílejí méně zdrojů a komunikují prostřednictvím lehčích protokolů. Stojí za zmínku, že mikroslužby vznikly z prostředí SOA a jsou někdy považovány za druh SOA nebo nástupce konceptu.
- Webová služba je veřejně přístupná sada funkcí, ke kterým mohou ostatní aplikace přistupovat prostřednictvím webu; pravděpodobně nejrozšířenějším příkladem jsou Mapy Google, které může web restaurace vložit, aby poskytoval pokyny zákazníkům. Jedná se o mnohem volnější připojení, než byste viděli v architektuře mikroslužeb.
Komunikace mikroslužeb
Klíčovou frází, kterou často používáte u architektur mikroslužeb, je to, že by měly obsahovat „inteligentní koncové body a hloupé kanály“. Jinými slovy, mikroslužby by se měly zaměřovat spíše na používání základních a dobře zavedených komunikačních metod než na komplexní a těsnou integraci. Jak již bylo uvedeno, jedná se o další věc, která odlišuje mikroslužby od SOA.
Obecně by komunikace mezi mikroslužbami měla být asynchronní, v tom smyslu, že vlákna kódu nejsou blokována čekáním na odpovědi. (Je stále v pořádku používat synchronní komunikační protokoly, jako je HTTP, ačkoli asynchronní protokoly, jako je AMQP (Advanced Message Queuing Protocol), jsou také běžné v architekturách mikroslužeb.) Tento druh volné vazby činí architekturu mikroslužeb flexibilnější tváří v tvář selhání jednotlivých komponent nebo částí sítě, což je klíčová výhoda.
Microservices, Java a Spring Boot a Spring Cloud
Některé z prvních prací v mikroslužbách vznikly v komunitě Java; Martin Fowler byl jedním z prvních zastánců. Konference Java v Polsku, která se konala v roce 2012, představovala jednu z nejdůležitějších raných prezentací na toto téma s názvem „Mikroslužby - Java, cesta Unixu.“ Doporučila uplatnit zásady, kterými se řídil vývoj prvních aplikací Unix v 70. letech („Write programy, které dělají jednu věc a dělají to dobře. Napište programy, které budou spolupracovat “) na vývoj Java.
V důsledku této historie existuje spousta rámců Java, které vám umožňují vytvářet mikroslužby. Jedním z nejpopulárnějších je Spring Boot, který je speciálně navržen pro mikroslužby; Boot je rozšířen o Spring Cloud, který, jak název napovídá, umožňuje nasadit tyto služby i do cloudu. Pivotal Software, vývojář Spring, má dobrý návod, jak začít s vývojem mikroslužeb pomocí těchto frameworků.
Mikroslužby a kontejnery: Docker, Kubernetes a další
Základní technologií, která šla nejdále směrem k získání mikroslužeb do hlavního proudu, jsou kontejnery. Kontejner je podobný instanci virtuálního počítače, ale místo toho, aby zahrnoval celý samostatný OS, je kontejner pouze izolovaným uživatelským prostorem, který využívá jádro hostitelského operačního systému, ale jinak udržuje kód, který se v něm provádí, samostatný. Kontejnery jsou mnohem menší než instance virtuálních počítačů a lze je snadno rychle nasadit, ať už lokálně nebo v cloudu, a lze je roztočit nahoru nebo dolů, aby odpovídaly poptávce a dostupným prostředkům.
Odvolání kontejnerů pro mikroslužby by mělo být zřejmé: Každá jednotlivá mikroslužba může běžet ve svém vlastním kontejneru, což výrazně snižuje režii správy služeb. Většina implementací kontejnerů má doplňkové nástroje pro orchestraci, které automatizují nasazení, správu, škálování, síťování a dostupnost kontejnerových aplikací. Filozofie devops umožňuje kombinaci malých, snadno sestavitelných mikroslužeb a snadno nasaditelných kontejnerů. Existuje několik implementací konceptu kontejneru, ale zdaleka nejoblíbenější je Docker, který je obecně spárován s Kubernetes jako orchestrační platformou.
Jaro, i když je populární, je svázáno s platformou Java. Systémy založené na kontejnerech jsou na druhé straně polyglotové: Libovolný programovací jazyk, který OS podporuje, může běžet v kontejneru, což dává programátorům větší flexibilitu. Velkou výhodou mikroslužeb je, že každá jednotlivá služba může být napsána v jakémkoli jazyce, který má největší smysl, nebo pro které je vývojářům nejvhodnější. Službu lze skutečně kompletně přestavět v novém jazyce, aniž by to ovlivnilo systém jako celek, pokud jeho rozhraní API zůstanou stabilní. DZone má článek pojednávající o výhodách a nevýhodách Spring Cloud vs. Kubernetes pro mikroslužby.
Návrhové vzory mikroslužeb
Bez ohledu na to, jaký jazyk používáte k vývoji mikroslužeb, budete čelit problémům, s nimiž se ostatní vývojáři setkali dříve. Formáty návrhu jsou formalizovány, abstraktní řešení opakujících se problémů v informatice a řada z nich je speciálně pro mikroslužby. Devopedia má skvělý seznam, který zahrnuje:
- Registr služeb: pro připojení klientů k dostupným instancím mikroslužeb
- Jistič: aby se zabránilo opakovanému volání neúspěšných služeb
- Záloha: za poskytnutí alternativy k neúspěšné službě
- Postranní vozík: pro poskytování pomocné služby k hlavnímu kontejneru, například pro protokolování, synchronizaci služeb nebo monitorování
- Adaptér: pro standardizaci nebo normalizaci rozhraní mezi hlavním kontejnerem a vnějším světem
- Ambassador: pro připojení hlavního kontejneru k vnějšímu světu, například pro proxy připojení localhost k vnějším připojením
Mikroslužby a cloud: AWS a Azure
Jak je uvedeno výše, jednou z výhod používání kontejnerů je, že je lze snadno nasadit do cloudu, kde jsou k dispozici flexibilní výpočetní prostředky, abyste mohli maximalizovat efektivitu své aplikace. Jak si možná dokážete představit, všichni hlavní dodavatelé veřejného cloudu touží po tom, abyste mohli používat své platformy ke spouštění aplikací založených na mikroslužbách. Další informace najdete ve zdrojích Amazon, Microsoft a Google.
