Jedním z posunů v IT pod hlavičkou digitální transformace je rozdělení velkých monolitických aplikací na mikroslužby—malé, diskrétní jednotky funkčnosti - které běží v kontejnerech—softwarové balíčky, které obsahují veškerý kód služby a závislosti, které lze izolovat a snadno přesouvat z jednoho serveru na druhý.
Kontejnerizované architektury, jako jsou tyto, lze snadno škálovat a provozovat v cloudu a jednotlivé mikroslužby lze rychle zavádět a iterovat. Komunikace mezi těmito mikroslužbami se však stává stále složitější, protože aplikace se zvětšují a běží více instancí stejné služby současně. Síť služeb je rozvíjející se architektonická forma, která si klade za cíl dynamicky propojit tyto mikroslužby způsobem, který snižuje režii správy a programování.
Co je síť služeb?
V nejširším smyslu je síť služeb, jak ji Red Hat popisuje, „způsob, jak řídit, jak různé části aplikace navzájem sdílejí data.“ Tento popis by však mohl zahrnovat spoustu různých věcí. Ve skutečnosti to zní strašně jako middleware, který většina vývojářů zná z aplikací klient-server.
Co dělá síť mesh jedinečnou, je to, že je postavena tak, aby vyhovovala jedinečné povaze prostředí distribuovaných mikroslužeb. V rozsáhlé aplikaci vytvořené z mikroslužeb může existovat více instancí dané služby spuštěných na různých místních nebo cloudových serverech. Všechny tyto pohyblivé části samozřejmě ztěžují jednotlivým mikroslužbám najít další služby, se kterými potřebují komunikovat. Síť služeb se automaticky postará o objevování a propojování služeb od okamžiku k okamžiku, aby to nemuseli dělat ani lidští vývojáři, ani jednotlivé mikroslužby.
Představte si síť služeb jako ekvivalent softwarově definovaných sítí (SDN) pro úroveň 7 síťového modelu OSI. Stejně jako SDN vytváří vrstvu abstrakce, takže správci sítě se nemusí zabývat fyzickými síťovými připojeními, síť služeb odděluje základní infrastrukturu aplikace od abstraktní architektury, se kterou komunikujete.
Myšlenka sítě služeb vznikla organicky, když se vývojáři začali potýkat s problémy skutečně obrovských distribuovaných architektur. Linkerd, první projekt v této oblasti, se zrodil jako odnož interního projektu na Twitteru. Istio, další populární síť služeb s významnou firemní podporou, vznikla v Lyftu. (Oba tyto projekty se za chvíli podrobněji podíváme.)
Vyrovnávání zatížení sítě služeb
Jednou z klíčových funkcí, kterou síť služeb poskytuje, je vyrovnávání zatížení. Vyvažování zátěže obvykle považujeme za síťovou funkci - chcete zabránit tomu, aby kterýkoli server nebo síťové spojení bylo zahlceno přenosem, a proto odpovídajícím způsobem směrujete své pakety. Servisní sítě dělají něco podobného na úrovni aplikace, jak popisuje Twain Taylor, a porozumění, které vám dává dobrý pocit z toho, co máme na mysli, když říkáme, že síť služeb je jako softwarově definované síťování pro aplikační vrstvu.
V podstatě je jednou z úloh servisní sítě sledovat, které instance různých mikroslužeb distribuovaných napříč infrastrukturou jsou „nejzdravější“. Mohlo by se jich dotazovat, aby zjistili, jak se jim daří, nebo sledovat, které instance pomalu reagují na požadavky na služby, a posílat následné žádosti do dalších instancí. Síť služeb může dělat podobné práce pro síťové trasy, všimne si, když zprávy trvají příliš dlouho, než se dostanou na místo určení, a provede další trasy, aby to kompenzovala. Tato zpomalení mohou být způsobena problémy se základním hardwarem nebo jednoduše přetížením služeb požadavky nebo prací na jejich kapacitě zpracování. Důležité je, že síť služeb může najít jinou instanci stejné služby a místo toho k ní nasměrovat, čímž nejefektivněji využije kapacitu celé aplikace.
Servisní síť vs. Kubernetes
Pokud jste trochu obeznámeni s architekturami založenými na kontejnerech, možná vás zajímá, kam se na tento obrázek hodí Kubernetes, populární platforma pro orchestraci kontejnerů s otevřeným zdrojovým kódem. Koneckonců, není to celý smysl Kubernetes, že řídí, jak vaše kontejnery spolu komunikují? Jak upozorňuje tým Kublr na svém firemním blogu, můžete si představit „servisní“ prostředek Kubernetes jako velmi základní druh sítě služeb, protože poskytuje zjišťování služeb a vyvážení požadavků každý s každým. Ale plně vybavené sítě služeb poskytují mnohem více funkcí, jako je správa bezpečnostních zásad a šifrování, „přerušení okruhu“ pro pozastavení požadavků na pomalé instance, vyvažování zátěže, jak je popsáno výše, a mnoho dalšího.
Mějte na paměti, že většina sítí služeb ve skutečnosti vyžaduje, aby byl na místě orchestrační systém, jako je Kubernetes. Servisní sítě nabízejí rozšířenou funkčnost, nikoli náhradu.
Service mesh vs. API brány
Každá mikroslužba bude poskytovat aplikační programovací rozhraní (API), které slouží jako prostředek, kterým s ním ostatní služby komunikují. To vyvolává otázku rozdílů mezi sítí služeb a dalšími tradičnějšími formami správy API, jako jsou brány API. Jak vysvětluje IBM, brána API stojí mezi skupinou mikroslužeb a „vnějším“ světem a podle potřeby směruje požadavky na služby, takže žadatel nemusí vědět, že jedná s aplikací založenou na mikroslužbách. Síť služeb naopak zprostředkovává požadavky „uvnitř“ aplikace mikroslužeb, přičemž různé komponenty si plně uvědomují své prostředí.
Další způsob, jak o tom přemýšlet, jak píše Justin Warren Forbes, je, že síť služeb je pro provoz na východ-západ v klastru a brána API je pro provoz na sever-jih do a z klastru. Celá myšlenka sítě služeb je ale stále brzy a v pohybu. Mnoho služebních sítí - včetně Linkerd a Istio - nyní také nabízí funkce sever-jih.
Architektura sítě služeb
Myšlenka sítě služeb se objevila až v posledních několika letech a existuje řada různých přístupů k řešení problému „sítě služeb“, tj. Správa komunikace pro mikroslužby. Andrew Jenkins z Aspen Mesh identifikuje tři možné volby týkající se toho, kde by mohla žít komunikační vrstva vytvořená sítí služeb:
- V knihovna které každá vaše mikroslužba importuje
- V agent uzlu který poskytuje služby všem kontejnerům v určitém uzlu
- V postranní vozík kontejner, který běží vedle vašeho kontejneru aplikace
Model založený na postranním vozíku je jedním z nejoblíbenějších vzorů síťových služeb - natolik, že se v některých ohledech stal synonymem pro servisní sítě obecně. I když to není přesně řečeno pravda, přístup sajdkáře získal tolik trakce, že se jedná o architekturu, na kterou se podíváme podrobněji.
Postranní vozy v servisní síti
Co to znamená říci, že kontejner postranního vozíku „běží vedle“ vašeho kontejneru aplikace? Red Hat má docela dobré vysvětlení. Každý kontejner mikroslužeb v síti služeb tohoto typu má jiný kontejner proxy, který mu odpovídá. Všechna logika vyžadovaná pro komunikaci mezi službami je vyňata z mikroslužby a vložena do postranního vozíku.
To se může zdát komplikované - koneckonců, ve své aplikaci efektivně zdvojnásobujete počet kontejnerů! Používáte však také návrhový vzor, který je klíčem ke zjednodušení distribuovaných aplikací. Tím, že vložíte veškerý síťový a komunikační kód do samostatného kontejneru, udělali jste z něj součást infrastruktury a zbavili vývojáře jeho implementace jako součásti aplikace.
V podstatě vám zbývá mikroslužba, kterou lze laserově zaměřit na její obchodní logiku. Mikroslužba nemusí vědět, jak komunikovat se všemi ostatními službami v divokém a šíleném prostředí, kde působí. Potřebuje jen vědět, jak komunikovat s postranním vozíkem, který se postará o zbytek.
Servisní sítě: Linkerd, Envio, Istio, Consul
Jaké jsou servisní sítě k dispozici pro použití? No, nejsou tam úplně běžné komerční produkty. Většina sítí služeb jsou projekty s otevřeným zdrojovým kódem, jejichž implementace vyžaduje finagling. Velká jména jsou:
- Linkerd (vyslovuje se „linker-dee“) - Vydáno v roce 2016, a je tedy nejstarší z těchto nabídek, Linkerd byl vyčleněn z knihovny vyvinuté na Twitteru. Další těžký hitter v tomto prostoru, Conduit, byl zaveden do projektu Linkerd a tvoří základ pro Linkerd 2.0.
- Vyslanec - vytvořený v Lyftu, vyslanec zabírá část „datové roviny“ sítě služeb. Chcete-li poskytnout síť plných služeb, je třeba ji spárovat s „řídicí rovinou“, jako je ...
- Istio - vyvinutý ve spolupráci společností Lyft, IBM a Google. Istio je kontrolní plán pro poskytování služeb proxy, jako je Envoy. Zatímco Istio a Envoy jsou výchozí dvojice, každou lze spárovat s jinými platformami.
- HashiCorp Consul - představen s Consul 1.2, funkcí nazvanou Connect, která přidala šifrování služeb a autorizaci založenou na identitě k distribuovanému systému HashiCorp pro zjišťování a konfiguraci služeb, čímž se proměnila v síť plný služeb.
Která síť služeb je pro vás ta pravá? Srovnání je nad rámec tohoto článku, ale stojí za zmínku, že všechny výše uvedené produkty byly prokázány ve velkých a náročných prostředích. Linkerd a Istio mají nejrozsáhlejší sady funkcí, ale všechny se rychle vyvíjejí. Možná si budete chtít prohlédnout rozpis funkcí Linkerda, Envoye a Istia od Georga Mirandy, i když mějte na paměti, že jeho článek byl napsán před spojením Conduit a Linkerd.
Pamatujte také, že tento prostor je nový a kdykoli se mohou objevit noví konkurenti. Například v listopadu 2018 začal Amazon nabízet veřejný náhled sítě služeb AWS. Vzhledem k tomu, kolik obchodů používá veřejný cloud společnosti Amazon, by AWS App Mesh měla mít zásadní dopad.
