Sdílet prostřednictvím

Model brány rozhraní API versus přímá komunikace mezi klientem a mikroslužbou

  • Článek

Tip

Tento obsah je výňatek z eBooku, architektury mikroslužeb .NET pro kontejnerizované aplikace .NET, které jsou k dispozici na .NET Docs nebo jako zdarma ke stažení PDF, které lze číst offline.

Stáhnout PDF

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

V architektuře mikroslužeb každá mikroslužba zveřejňuje sadu (obvykle) jemně odstupňovaných koncových bodů. Tato skutečnost může mít vliv na komunikaci mezi klientem a mikroslužbou, jak je vysvětleno v této části.

Přímá komunikace mezi klientem a mikroslužbou

Možným přístupem je použití přímé architektury komunikace mezi klientem a mikroslužbou. V tomto přístupu může klientská aplikace provádět požadavky přímo na některé z mikroslužeb, jak je znázorněno na obrázku 4–12.

Diagram showing client-to-microservice communication architecture.

Obrázek 4–12 Použití přímé architektury komunikace mezi klientem a mikroslužbou

V tomto přístupu má každá mikroslužba veřejný koncový bod, někdy s jiným portem TCP pro každou mikroslužbu. Příkladem adresy URL konkrétní služby může být následující adresa URL v Azure:

http://eshoponcontainers.westus.cloudapp.azure.com:88/

V produkčním prostředí založeném na clusteru by se tato adresa URL namapovala na nástroj pro vyrovnávání zatížení používaný v clusteru, který zase distribuuje požadavky mezi mikroslužby. V produkčníchprostředích Aplikace Azure ch Tato vrstva funguje jako transparentní úroveň, která nejen provádí vyrovnávání zatížení, ale zabezpečuje vaše služby tím, že nabízí ukončení protokolu SSL. Tento přístup zlepšuje zatížení hostitelů tím, že přesměruje ukončení protokolu SSL náročné na procesor a další povinnosti směrování do brány Aplikace Azure. V každém případě je nástroj pro vyrovnávání zatížení a ADC transparentní z hlediska architektury logické aplikace.

Pro malou aplikaci založenou na mikroslužbách může být vhodná přímá architektura komunikace mezi klienty a mikroslužbami, zejména pokud je klientská aplikace webová aplikace na straně serveru, jako je aplikace ASP.NET MVC. Při vytváření rozsáhlých a složitých aplikací založených na mikroslužbách (například při zpracování desítek typů mikroslužeb) a zejména v případě, že jsou klientské aplikace vzdálené mobilní aplikace nebo webové aplikace SPA, dochází k několika problémům.

Při vývoji velké aplikace založené na mikroslužbách zvažte následující otázky:

  • Jak můžou klientské aplikace minimalizovat počet požadavků na back-end a snížit chatty komunikaci s několika mikroslužbami?

Interakce s několika mikroslužbami za účelem vytvoření jedné obrazovky uživatelského rozhraní zvyšuje počet cest po internetu. Tento přístup zvyšuje latenci a složitost na straně uživatelského rozhraní. V ideálním případě by se odpovědi měly efektivně agregovat na straně serveru. Tento přístup snižuje latenci, protože se paralelně vrací několik částí dat a některé uživatelské rozhraní můžou zobrazovat data hned, jak je připravené.

  • Jak můžete řešit průřezové aspekty, jako je autorizace, transformace dat a dynamické odesílání žádostí?

Implementace zabezpečení a průřezových obav, jako je zabezpečení a autorizace v každé mikroslužbě, může vyžadovat značné úsilí o vývoj. Možným přístupem je mít tyto služby v rámci hostitele Dockeru nebo interního clusteru, abyste omezili přímý přístup k nim zvenčí a implementovali tyto průřezové obavy na centralizované místo, jako je brána rozhraní API.

  • Jak můžou klientské aplikace komunikovat se službami, které používají jiné než internetové protokoly?

Klientské aplikace nepodporují protokoly používané na straně serveru (například AMQP nebo binární protokoly). Proto je nutné požadavky provádět prostřednictvím protokolů, jako je HTTP/HTTPS, a následně je přeložit na ostatní protokoly. V této situaci může pomoct man-in-the-middle přístup.

  • Jak můžete tvarovat fasádu speciálně pro mobilní aplikace?

Rozhraní API několika mikroslužeb nemusí být vhodné pro potřeby různých klientských aplikací. Například potřeby mobilní aplikace se můžou lišit od potřeb webové aplikace. U mobilních aplikací možná budete muset ještě více optimalizovat, aby odpovědi na data mohly být efektivnější. Tuto funkci můžete provést tak, že agregujete data z více mikroslužeb a vrátíte jednu sadu dat a někdy odstraníte všechna data v odpovědi, která mobilní aplikace nepotřebuje. A samozřejmě můžete tato data komprimovat. Pro tento scénář je opět vhodné použít fasádu nebo rozhraní API mezi mobilní aplikací a mikroslužbami.

Proč zvažovat brány rozhraní API místo přímé komunikace mezi klientem a mikroslužbou

Klientské aplikace v architektuře mikroslužeb obvykle potřebují využívat funkce z více než jedné mikroslužby. Pokud se tato spotřeba provádí přímo, klient musí zpracovávat více volání koncových bodů mikroslužeb. Co se stane, když se aplikace vyvíjí a nové mikroslužby se zavádějí nebo se aktualizují stávající mikroslužby? Pokud má vaše aplikace mnoho mikroslužeb, zpracování tolik koncových bodů z klientských aplikací může být noční můrou. Vzhledem k tomu, že klientská aplikace by byla svázána s těmito interními koncovými body, může vývoj mikroslužeb v budoucnu způsobit vysoký dopad na klientské aplikace.

Z tohoto důvodu může být pro aplikace založené na mikroslužbách vhodné mít středně pokročilou úroveň nebo úroveň indirection (Gateway). Pokud nemáte brány rozhraní API, klientské aplikace musí odesílat požadavky přímo do mikroslužeb a vyvolají problémy, jako jsou například následující problémy:

  • Párování: Bez vzoru brány rozhraní API jsou klientské aplikace svázané s interními mikroslužbami. Klientské aplikace potřebují vědět, jak se v mikroslužbách rozloží více oblastí aplikace. Při vývoji a refaktoringu interních mikroslužeb mají tyto akce vliv na údržbu, protože způsobují zásadní změny klientských aplikací kvůli přímému odkazu na interní mikroslužby z klientských aplikací. Klientské aplikace je potřeba aktualizovat často, což ztěžuje vývoj řešení.

  • Příliš mnoho zpátečních cest: Jedna stránka nebo obrazovka v klientské aplikaci může vyžadovat několik volání více služeb. Výsledkem tohoto přístupu může být několik síťových odezv mezi klientem a serverem a tím se zvýší významná latence. Agregace zpracovávaná na středně pokročilé úrovni by mohla zlepšit výkon a uživatelské prostředí klientské aplikace.

  • Problémy se zabezpečením: Bez brány musí být všechny mikroslužby vystavené "externímu světu", což zvětší prostor pro útoky, než když skryjete interní mikroslužby, které přímo nepoužívají klientské aplikace. Čím menší prostor pro útoky je, tím bezpečnější může být vaše aplikace.

  • Průřezové aspekty: Každá veřejně publikovaná mikroslužba musí zpracovávat obavy, jako je autorizace a SSL. V mnoha situacích je možné tyto obavy zpracovat v jedné vrstvě, aby byly interní mikroslužby zjednodušené.

Co je model brány rozhraní API?

Při navrhování a sestavování rozsáhlých nebo složitých aplikací založených na mikroslužbách s více klientskými aplikacemi může být vhodným přístupem brána rozhraní API. Tento model je služba, která poskytuje jeden vstupní bod pro určité skupiny mikroslužeb. Podobá se vzoru Fasáda z objektově orientovaného návrhu, ale v tomto případě je součástí distribuovaného systému. Model brány rozhraní API se také někdy označuje jako "back-end pro front-end" (BFF), protože ho sestavíte při úvahách o potřebách klientské aplikace.

Brána rozhraní API proto leží mezi klientskými aplikacemi a mikroslužbami. Funguje jako reverzní proxy server a směruje požadavky klientů na služby. Může také poskytovat další průřezové funkce, jako je ověřování, ukončení protokolu SSL a mezipaměť.

Obrázek 4–13 ukazuje, jak se vlastní brána rozhraní API může vejít do zjednodušené architektury založené na mikroslužbách s několika mikroslužbami.

Diagram showing an API Gateway implemented as a custom service.

Obrázek 4–13 Použití brány rozhraní API implementované jako vlastní služba

Aplikace se připojují k jednomu koncovému bodu, bráně rozhraní API, která je nakonfigurovaná tak, aby předávala požadavky jednotlivým mikroslužbám. V tomto příkladu by se brána rozhraní API implementovala jako vlastní služba ASP.NET Core WebHost spuštěná jako kontejner.

Je důležité zdůraznit, že v diagramu byste používali jednu vlastní službu API Gateway, která čelí více a různým klientským aplikacím. Tento fakt může být důležitým rizikem, protože vaše služba API Gateway bude růst a vyvíjet se na základě mnoha různých požadavků z klientských aplikací. Nakonec se bude chýlit kvůli těmto různým potřebám a efektivně se může podobat monolitické aplikaci nebo monolitické službě. Proto se velmi doporučuje rozdělit bránu rozhraní API do více služeb nebo několika menších bran API, například jednu na typ form-factor klientské aplikace.

Při implementaci vzoru brány rozhraní API musíte být opatrní. Obvykle není vhodné mít jedinou bránu rozhraní API, která agreguje všechny interní mikroslužby vaší aplikace. Pokud ano, funguje jako monolitický agregátor nebo orchestrátor a porušuje autonomii mikroslužeb propojením všech mikroslužeb.

Brány rozhraní API by proto měly být odděleny na základě obchodních hranic a klientských aplikací a neměly by fungovat jako jediný agregátor pro všechny interní mikroslužby.

Pokud má vaše aplikace více klientských aplikací, může být při rozdělení vrstvy služby API Gateway na několik bran rozhraní API primární pivot, abyste mohli mít jinou fasádu pro potřeby každé klientské aplikace. Tento případ je vzor s názvem "Back-end pro front-end" (BFF), kde každá brána rozhraní API může poskytovat jiné rozhraní API přizpůsobené jednotlivým typům klientských aplikací, a to i na základě faktoru formuláře klienta implementací konkrétního kódu adaptéru, který pod voláním několika interních mikroslužeb, jak je znázorněno na následujícím obrázku:

Diagram showing multiple custom API Gateways.

Obrázek 4–13.1 Použití několika vlastních bran rozhraní API

Obrázek 4-13.1 ukazuje brány rozhraní API, které jsou oddělené podle typu klienta; jeden pro mobilní klienty a jeden pro webové klienty. Tradiční webová aplikace se připojuje k mikroslužbě MVC, která používá bránu webového rozhraní API. Příklad znázorňuje zjednodušenou architekturu s několika jemně odstupňovanými bránami rozhraní API. V tomto případě jsou hranice identifikované pro každou bránu rozhraní API založeny čistě na vzoru "Back-end pro front-end" (BFF), a to na základě rozhraní API potřebného pro každou klientskou aplikaci. Ve větších aplikacích byste ale měli pokračovat a vytvářet další brány rozhraní API založené na obchodních hranicích jako druhý pivot návrhu.

Hlavní funkce ve vzoru brány rozhraní API

Brána rozhraní API může nabízet více funkcí. V závislosti na produktu, který může nabízet bohatší nebo jednodušší funkce, jsou ale nejdůležitější a základní funkce pro libovolnou bránu rozhraní API následující vzory návrhu:

Směrování reverzního proxy serveru nebo brány Brána rozhraní API nabízí reverzní proxy server pro přesměrování nebo směrování požadavků (směrování vrstvy 7, obvykle požadavků HTTP) na koncové body interních mikroslužeb. Brána poskytuje jeden koncový bod nebo adresu URL klientských aplikací a pak interně mapuje požadavky na skupinu interních mikroslužeb. Tato funkce směrování pomáhá oddělit klientské aplikace od mikroslužeb, ale je také vhodné při modernizaci monolitického rozhraní API tak, že se nachází ve službě API Gateway mezi monolitickým rozhraním API a klientskými aplikacemi, pak můžete přidat nová rozhraní API jako nové mikroslužby a současně používat starší monolitické rozhraní API, dokud se v budoucnu nerozdělí na mnoho mikroslužeb. Vzhledem ke službě API Gateway si klientské aplikace nevšimnou, jestli se použitá rozhraní API implementují jako interní mikroslužby nebo monolitické rozhraní API a důležitější je, že při vývoji a refaktoringu monolitického rozhraní API na mikroslužby díky směrování služby API Gateway nebudou mít klientské aplikace vliv na žádnou změnu identifikátoru URI.

Další informace najdete v tématu Model směrování brány.

Agregace požadavků Jako součást vzoru brány můžete agregovat více požadavků klientů (obvykle požadavků HTTP), které cílí na více interních mikroslužeb, do jednoho požadavku klienta. Tento model je vhodný zejména v případě, že klientská stránka nebo obrazovka potřebuje informace z několika mikroslužeb. Díky tomuto přístupu klientská aplikace odešle do služby API Gateway jeden požadavek, který odešle několik požadavků do interních mikroslužeb a pak agreguje výsledky a odešle vše zpět do klientské aplikace. Hlavním přínosem a cílem tohoto vzoru návrhu je snížit chattivost mezi klientskými aplikacemi a back-endovým rozhraním API, což je zvlášť důležité pro vzdálené aplikace mimo datacentrum, kde mikroslužby žijí, jako jsou mobilní aplikace nebo požadavky přicházející z aplikací SPA, které pocházejí z JavaScriptu v klientských vzdálených prohlížečích. U běžných webových aplikací provádějících požadavky v serverovém prostředí (jako je webová aplikace ASP.NET Core MVC) tento vzor není tak důležitý, protože latence je mnohem menší než u vzdálených klientských aplikací.

V závislosti na používaném produktu SLUŽBY API Gateway může být možné tuto agregaci provést. V mnoha případech je ale flexibilnější vytvářet agregační mikroslužby v rámci služby API Gateway, takže agregaci definujete v kódu (to znamená kód jazyka C#):

Další informace najdete v tématu Vzor agregace brány.

Průřezové obavy nebo snižování zátěže brány V závislosti na funkcích nabízených jednotlivými produkty služby API Gateway můžete přesměrovat funkce z jednotlivých mikroslužeb na bránu, což zjednodušuje implementaci jednotlivých mikroslužeb sloučením křížových obav do jedné vrstvy. Tento přístup je zvláště vhodný pro specializované funkce, které mohou být složité správně implementovat v každé interní mikroslužbě, například následující funkce:

  • Ověřování a autorizace
  • Integrace zjišťování služeb
  • Ukládání odpovědí do mezipaměti
  • Zásady opakování, jistič a QoS
  • Omezování rychlosti a omezování
  • Vyrovnávání zatížení
  • Protokolování, trasování, korelace
  • Hlavičky, řetězce dotazů a transformace deklarací identity
  • Seznam povolených IP adres

Další informace najdete v tématu Model snižování zátěže brány.

Používání produktů s funkcemi služby API Gateway

V závislosti na každé implementaci může existovat mnoho dalších problémů, které nabízí produkty API Gateway. Prozkoumáme tady:

Azure API Management

Azure API Management (jak je znázorněno na obrázku 4–14) nejen řeší potřeby brány rozhraní API, ale poskytuje funkce, jako je shromažďování přehledů z vašich rozhraní API. Pokud používáte řešení API Management, brána ROZHRANÍ API je pouze komponentou v rámci celého řešení služby API Management.

Diagram showing how to use Azure API Management as your API gateway.

Obrázek 4–14 Použití služby Azure API Management pro bránu rozhraní API

Azure API Management řeší požadavky služby API Gateway i Management, jako je protokolování, zabezpečení, měření atd. V tomto případě při použití produktu, jako je Azure API Management, není skutečnost, že byste mohli mít jedinou bránu rozhraní API, tak riziková, protože tyto druhy bran rozhraní API jsou "tenčí", což znamená, že neimplementujete vlastní kód C#, který by se mohl vyvíjet směrem k monolitické komponentě.

Produkty služby API Gateway obvykle fungují jako reverzní proxy pro komunikaci příchozího přenosu dat, kde můžete také filtrovat rozhraní API z interních mikroslužeb a použít autorizaci na publikovaná rozhraní API v této jednoúrovňové úrovni.

Přehledy dostupné ze systému API Management vám pomůžou pochopit, jak se vaše rozhraní API používají a jak fungují. Tuto aktivitu dělají tak, že vám umožní zobrazit sestavy analýzy téměř v reálném čase a identifikovat trendy, které můžou mít vliv na vaši firmu. Navíc můžete mít protokoly o aktivitě požadavků a odpovědí pro další online a offline analýzu.

Pomocí služby Azure API Management můžete svá rozhraní API zabezpečit pomocí klíče, tokenu a filtrování IP adres. Tyto funkce umožňují vynucovat flexibilní a jemně odstupňované kvóty a omezení rychlosti, upravit tvar a chování rozhraní API pomocí zásad a zlepšit výkon ukládáním odpovědí do mezipaměti.

V této příručce a referenční ukázkové aplikaci (eShopOnContainers) je architektura omezená na jednodušší a vlastní kontejnerizovanou architekturu, aby se zaměřila na prosté kontejnery bez použití produktů PaaS, jako je Azure API Management. U rozsáhlých aplikací založených na mikroslužbách, které jsou nasazené v Microsoft Azure, ale doporučujeme vyhodnotit službu Azure API Management jako základ pro brány rozhraní API v produkčním prostředí.

Ocelot

Ocelot je zjednodušená služba API Gateway, která se doporučuje pro jednodušší přístupy. Ocelot je opensourcová brána rozhraní API založená na .NET Core, zejména určená pro architektury mikroslužeb, které potřebují jednotné vstupní body do svých systémů. Je odlehčená, rychlá a škálovatelná a poskytuje směrování a ověřování mezi mnoha dalšími funkcemi.

Hlavním důvodem, proč zvolit Ocelot pro referenční aplikaci eShopOnContainers 2.0 , je to, že Ocelot je zjednodušená brána rozhraní API .NET Core, kterou můžete nasadit do stejného prostředí pro nasazení aplikací, ve kterém nasazujete mikroslužby/kontejnery, jako je Docker Host, Kubernetes atd. A protože je založená na .NET Core, je to multiplatformní, která umožňuje nasazení v Linuxu nebo Windows.

Předchozí diagramy znázorňující vlastní brány rozhraní API běžící v kontejnerech jsou přesně to, jak můžete ocelot spustit v kontejneru a aplikaci založené na mikroslužbách.

Na trhu je také mnoho dalších produktů, které nabízejí funkce rozhraní API Gateway, jako jsou Apigee, Kong, MuleSoft, WSO2 a další produkty, jako jsou Linkerd a Istio pro funkce kontroleru příchozího přenosu dat služby.

Po úvodních částech s vysvětlením architektury a vzorů se v dalších částech dozvíte, jak implementovat brány rozhraní API s Ocelotem.

Nevýhody vzoru brány rozhraní API

  • Nejdůležitější nevýhodou je, že když implementujete bránu rozhraní API, připojujete tuto vrstvu s interními mikroslužbami. Podobné spojení může způsobit vážné potíže s vaší aplikací. Clemens Vaster, architekt týmu Služby Azure Service Bus, odkazuje na tento potenciální problém jako "nový ESB" v relaci zasílání zpráv a mikroslužeb v GOTO 2016.

  • Použití brány rozhraní API mikroslužeb vytvoří další možný kritický bod selhání.

  • Brána rozhraní API může kvůli dalšímu síťovému volání zavést zvýšenou dobu odezvy. Toto dodatečné volání ale obvykle má menší dopad než použití klientského rozhraní, které je příliš chatty přímo volány interní mikroslužby.

  • Pokud není správně škálováno na více instancí, může se brána rozhraní API stát kritickým bodem.

  • Brána rozhraní API vyžaduje další náklady na vývoj a budoucí údržbu, pokud zahrnuje vlastní logiku a agregaci dat. Vývojáři musí aktualizovat bránu rozhraní API, aby mohli vystavit koncové body jednotlivých mikroslužeb. Změny implementace v interních mikroslužbách navíc můžou způsobit změny kódu na úrovni brány rozhraní API. Pokud ale brána rozhraní API používá pouze zabezpečení, protokolování a správu verzí (jako při používání služby Azure API Management), nemusí se tyto další náklady na vývoj vztahovat.

  • Pokud je brána rozhraní API vyvinutá jedním týmem, může dojít k kritickému bodu vývoje. Tento aspekt je dalším důvodem, proč lepším přístupem je mít několik jemně odstupňovaných bran rozhraní API, které reagují na různé potřeby klientů. Bránu rozhraní API můžete také interně oddělit do několika oblastí nebo vrstev, které vlastní různé týmy pracující na interních mikroslužbách.

Další materiály

PředchozíDalší