Není gateway jako gateway

Petr Jůza
May 18 · 5 min read

Jak se mění architektonické přístupy k návrhu aplikací resp. celých řešení, tak se mění i potřeba kladená na jednotlivé komponenty. Před cca 15 lety, v době kdy SOA dobývalo svět, tak největší byla poptávka po Enteprise Service Bus (ESB) řešeních. V té době často zastoupenými velkými, drahými a neflexibilními produkty od firem jako IBM (WebSphere ESB), Oracle (Oracle Enterprise Service Bus), Tibco nebo Miscrosoft (BizTalk). Naštěstí v průběhu času se objevilo dostatek lightweight open-source řešení, převážně programátorsky zaměřených, nikoliv jen klikacích, jako např. MuleESB, Apache Camel nebo Spring Integration.

Před necelými 10 lety, s nástupem používání RESTu, oddělením frontendových částí aplikací od backendu nebo obecně s potřebou vystavování “kvalitních” API (contract/design-first přístup), se objevila poptávka po komponentě API gateway.

V dnešní době, kdy mikroservisní architektura mění pohled na návrh aplikací, kdy je potřeba primárně řešit komunikaci mezi samotnými mikroservisními službami a zároveň se vypořádávat se složitostmi distribuovaného světa, tak je poptávka po service mesh řešeních.

Ve zbývajících částech článku se zaměřím na bližší popisy jednotlivých integračních přístupů.


Úkolem ESB je nahradit přímé komunikace mezi jednotlivými aplikacemi (point-to-point) tak, že se zbaví závislostí aplikací mezi sebou a odstíní rozdílnosti každé z aplikací. Rozdílnosti mohou být na úrovni:

  • komunikačního protokolu
  • datových struktur
  • zpracování vstupních požadavků (synchronní vs asynchronní komunikace, garantované zpracování zpráv dle určitého pořadí, max. počet souběžně zpracovávaných požadavků za určitý čas apod.)

ESB slouží primárně k datové transformaci a orchestraci volání cílových systémů.

Enterprise Service Bus

Řešeních v této oblasti je opravdu hodně a více než podporované funkce bude rozhodovat přístup k implementaci integračních scénářů (programování vs DSL vs klikání) a licenční politika. Osobně nevidím výrazné rozdíly ve většině podporovaných funkcí jednotlivých ESB řešení, rozdíly jsou pouze v přístupu k implementaci konkrétních integračních patternů. Kde je nicméně možné vidět výrazný rozdíl z pohledu funkčnosti, tak to je podpora asynchronního zpracování zpráv — nemyslím nyní asynchronní způsob komunikace např. pomocí message queue, ale pattern, kdy ESB přijme zprávu, potvrdí její přijetí volajícímu systému a následně se stará o její úspěšné zpracování a doručení cílovým systémům. Základní podporu lze najít snad u všech open-source řešení, nicméně reálné potřeby, aspoň takové jsou naše zkušenosti, jsou často někde jinde — proto je nutné se porozhlédnout po nějakém komerčním řešení a nebo zkusit naší vlastní integrační platformu OpenHub, kde jsme tento způsob komunikace implementovali a ladili na několika projektech.

V mikroservisní architektuře je také potřeba data transformovat nebo orchestrovat volání přes více (mikro)služeb, nicméně z povahy běhového prostředí (nejčastěji Kubernetes) je potřeba mít ESB řešení velmi malé (zabírající málo paměti) a velice rychlé, jak na start, tak na samotný processing. Zde lze doporučit samotné integrační enginy jako Apache Camel nebo Spring Integration. Zajímavou iniciativou z poslední doby je Apache Camel K (malá video ukázka):

Apache Camel K is a lightweight cloud integration platform based on the Apache Camel framework. It runs natively on Kubernetes and Openshift and it’s specifically designed for serverless and microservice architectures

OpenHub je ideální volbou pro ty, kdo chtějí používat Apache Camel (preferují programátorský přístup k implementaci integrací, nikoliv klikací) a ocení odladěný aplikační stack včetně spousty rozšíření a fixů — např. nové Camel komponenty, podpora běhu v clusteru, administrační konzole. OpenHub používáme jako lightweight ESB řešení nebo v roli API (mobilní) gateway.


API gateway tvoří rozhraní mezi systémy a jejich konzumenty. Rozhraní definuje možné chování pro konzumenty služeb (dnes nejčastěji v podobě OpenAPI specifikace), odstiňuje komplexitu vnitřní implementace a stanovuje pravidla komunikace (např. bezpečnostní politika nebo omezení na počty volaní). Použití je jak v rámci interního prostředí nebo zejména ve vztahu k externím subjektům.

Kromě toho je potřeba mít možnost monitorovat (a zpětně analyzovat z reportingu) všechny volání, definici rozhraní správně zdokumentovat a zpřístupnit potenciálním konzumentům včetně možnosti mockování odpovědí pro usnadnění napojení na API. V poslední době začíná být i čím dál častější požadavek na monetizaci vystavených API — schopnost API gateway umět napočítávat počty volání per klient. V základní podobě si lze vystačit s funkcionalitou, která dnes začíná být součástí samotných API gateways, pro složitější účtování je potřeba využít samostatnou monetizační platformu, napr. Qubefy.

API gateway lze úspěšně využít i k základní datové transformaci, ale není to její primární úkol.

Zdroj RedHat

Několik představitelů “klasické” API gateway:

Doposud jsme se bavili o “klasické” API gateway a její použití je opravdu široké, nicméně asi nejčastěji se používá k odstínění interní infrastruktury a vystrčení rozhraní služeb pro třetí strany. Svět mikroservisních aplikací má velice podobné funkční požadavky jako “klasická” API gateway, ale jedná se více o “engine” (knihovnu) než o plnohodné aplikace včetně GUI na monitoring a dokumentaci.

Jedná se o řešení neutrální k cílovému běhovému prostředí (Spring Cloud Gateway nebo Zuul) nebo naopak jsou s ním úzce spojeny — nejčastěji s Kubernetes, implementující ingress controller:


Pojem service mesh nebude asi všem známý, proto ho nejdříve vysvětlím:

Service Mesh is a network communication infrastructure which allows your to decouple and offload most of the application network functions from your service code.

Service mesh is a new architectural paradigm that delivers services such as traffic management, security, and observability to container-based microservices applications directly within the compute cluster. A service mesh provides monitoring, scalability, and high availability services through software components controlled by APIs instead of using discrete hardware appliances. This flexible framework reduces the operational complexity associated with modern, disaggregated applications.

API Gateways and service mesh in action

Service mesh je převážně “infrastrukturní” záležitost a slouží k řízení interní komunikace mezi službami (pozn. API gateway slouží primárně ke komunikaci s okolím). Service mesh je reakcí na nutnost řešení problémů distribuovaných systémů, které se doposud řešily skoro výhradně na aplikační úrovni, např.:

Díky service mesh je možné se v samotné aplikaci soustředit na vlastní aplikaci a tyto “infrastrukturní” věci pořešit v rámci běhového prostředí.

Mezi hlavní představitele patří:

(pozn. v tomto článku je jejich porovnání)


Zdroj RedHat

Jak je vidět z obrázku, tak někde se schopnosti/možnosti API gateway resp. ESB resp. Service mesh trochu překrývají, ale obecně každá oblast má svá specifika podle kterých se jednotlivá řešení odlišují a tedy mají různou cílovou skupinu problémů, které umí snadno a rychle implementovat. Správnou volbou vhodného řešení pro vaše očekávané případy použití si usnadníte svůj “vývojářský” život.

OpenWise Tech blog

Stories from our development

Thanks to Tomáš Hanus

Petr Jůza

Written by

OpenWise Solutions | http://www.openhub.cz | http://www.vyvojarska-plzen.cz

OpenWise Tech blog

Stories from our development

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade