Dobrý den znovu!.. Před začátkem kurzu jsme připravili další užitečný překlad.
Service Mesh je konfigurovatelná nízko-latentní infrastrukturní vrstva potřebná k zpracování velkého objemu síťové meziprocesní komunikace mezi aplikačními programovými rozhraními (API). Service Mesh zajišťuje rychlou, spolehlivou a bezpečnou komunikaci mezi kontejnerizovanými a často efemérními službami aplikační infrastruktury. Service Mesh nabízí takové možnosti, jako je objevování služeb, vyvažování zátěže, šifrování, transparentnost, sledovatelnost, autentizaci a autorizaci, stejně jako podporu vzoru automatického vypadnutí (circuit breaker).
Service Mesh se obvykle implementuje poskytnutím instance proxy každému exempláři služby, která se nazývá Sidecar. Sidecar zpracovávají komunikaci mezi službami, monitorují a řeší problémy se zabezpečením, tedy vše, co může být abstrakováno od jednotlivých služeb. Tímto způsobem mohou vývojáři psát, udržovat a spravovat kód aplikace v službách, zatímco systémoví administrátoři mohou pracovat se Service Mesh a spouštět aplikaci.
Istio od Googlu, IBM a Lyftu je v současnosti nejznámější architekturou Service Mesh. Kubernetes, který byl původně vyvinut v Googlu, je nyní jediným rámcem pro orchestraci kontejnerů, který Istio podporuje. Dodavatelé se snaží vytvořit komerčně podporované verze Istio. Je zajímavé, co nového by mohli přinést do projektu s otevřeným zdrojovým kódem.
Nicméně Istio není jedinou možností, neboť se vyvíjejí i další implementace Service Mesh. Vzor sidecar proxy je nejpopulárnější implementací, jak lze usuzovat podle projektů Buoyant, HashiCorp, Solo.io a dalších. Existují také alternativní architektury: technologický nástroj Netflix je jedním z přístupů, kde je funkčnost Service Mesh implementována pomocí knihoven Ribbon, Hystrix, Eureka, Archaius a také pomocí platforem jako Azure Service Fabric.
Service Mesh má také svou vlastní terminologii pro komponenty služeb a funkce:
- Rámec pro orchestraci kontejnerů. Jak se do infrastruktury aplikace přidává stále více a více kontejnerů, vzniká potřeba po samostatném nástroji pro monitorování a správu kontejnerů – frameworku pro orchestraci kontejnerů. Kubernetes si tuto oblast pevně zajišťuje, a to natolik, že i jeho hlavní konkurenti Docker Swarm a Mesosphere DC/OS nabízejí jako alternativu integraci s Kubernetes.
- Služby a instance (Kubernetes pody). Instance je jediná spuštěná kopie mikroservisu. Někdy je jedna instance jedním kontejnerem. V Kubernetes se instance skládá z malé skupiny nezávislých kontejnerů, které se nazývá pod. Klienti se zřídka obrací přímo na instanci nebo pod, častěji se obrací na službu, která představuje sadu identických škálovatelných a vysoce dostupných instancí nebo podů (replik).
- Sidecar Proxy. Sidecar Proxy pracuje s jednou instancí nebo pod. Smyslem Sidecar Proxy je směrovat nebo proxy-tovat provoz, který přichází z kontejneru, se kterým pracuje, a zpětný provoz. Sidecar interaguje s jinými Sidecar Proxy a je řízen frameworkem pro orchestraci. Mnoho implementací Service Mesh používá Sidecar Proxy k zachycení a správě veškerého příchozího a odchozího provozu instance nebo podu.
- Objevování služeb. Když instance potřebuje interagovat s jinou službou, musí najít (objevit) opravenou a dostupnou instanci jiné služby. Obvykle instance provádí vyhledávání pomocí DNS. Framework pro orchestraci kontejnerů uchovává seznam instancí, které jsou připraveny přijímat požadavky, a poskytuje rozhraní pro DNS dotazy.
- Vyvažování zátěže. Většina frameworků pro orchestraci kontejnerů zajišťuje vyvažování zátěže na 4. úrovni (transportní). Service Mesh implementuje složitější vyvažování zátěže na 7. úrovni (aplikace), které je bohaté na algoritmy a efektivnější v řízení provozu. Parametry vyvažování zátěže mohou být měněny pomocí API, což umožňuje orchestraci blue-green nebo canary nasazení.
- Šifrování. Service Mesh může šifrovat a dešifrovat požadavky a odpovědi, což snímá tuto zátěž ze služeb. Service Mesh také může zvýšit výkon prioritizací nebo opětovným využitím stávajících stálých připojení, což snižuje potřebu drahých výpočtů pro vytváření nových připojení. Nejrozšířenější implementací šifrování provozu je vzájemné TLS (mTLS), kde infrastruktura veřejných klíčů (PKI) generuje a distribuuje certifikáty a klíče pro použití v Sidecar Proxy.
- Autentizace a autorizace. Service Mesh může autorizovat a autentizovat požadavky provedené zvenčí nebo zevnitř aplikace, a to tím, že instancím posílá pouze validované požadavky.
- Podpora vzoru automatického vypnutí. Service Mesh podporuje , který izuluje nezdravé instance a poté je postupně vrací do fondu zdravých instancí podle potřeby.
Ta část aplikace Service Mesh, která spravuje síťový provoz mezi instancemi, se nazývá Data Plane. Vytváření a nasazování konfigurace, která ovládá chování Data Plane, se provádí pomocí samostatného Control Plane. Control Plane obvykle zahrnuje nebo je navržena tak, aby se připojila k API, CLI nebo GUI pro správu aplikace.
Control Plane v Service Mesh distribuuje konfiguraci mezi Sidecar Proxy a Data Plane.
Často je architektura Service Mesh aplikována k řešení složitých operačních úloh s využitím kontejnerů a mikroslužeb. Příkladem v této oblasti jsou společnosti jako Lyft, Netflix a Twitter, které poskytují stabilně fungující služby milionům uživatelů po celém světě. ( Zde se můžete seznámit s podrobným popisem některých architektonických problémů, se kterými se Netflix setkalArchitektura Service Mesh pravděpodobně nikdy nebude odpovědí na všechny problémy spojené s provozováním aplikací a jejich dodávkou. Architekti a vývojáři mají obrovský arzenál nástrojů, přičemž jen jeden z nich je kladivo, které musí řešit pouze jednu z mnoha úloh – zatloukat hřebíky.
Reference architektury mikroslužeb od NGINX , například, zahrnuje několik různých modelů, které poskytují nepřetržitou škálu přístupů k řešení problémů pomocí mikroservisů.
Elementy, které se spojují v architektuře Service Mesh, jako jsou NGINX, kontejnery, Kubernetes a mikroservisy jako architektonický přístup, mohou být stejně efektivně využívány i v realizacích bez Service Mesh. Například, Istio byl navržen jako plnohodnotná architektura Service Mesh, ale modularita naznačuje, že vývojáři mohou vybírat a aplikovat pouze nezbytné komponenty technologií. Mějte to na paměti, je důležité vytvořit jasné pochopení konceptu Service Mesh, i když si nejste jisti, zda jej někdy budete schopni plně implementovat do aplikace.
Zdroj: habr.com
