Service Fabric se službou Azure API Management – Přehled

Cloudové aplikace obvykle potřebují front-end bránu, která poskytuje jediný bod příjmu příchozího přenosu od uživatelů, zařízení nebo dalších aplikací. V Service Fabric může být brána libovolná bezstavová služba, jako je aplikace ASP.NET Core nebo jiná služba navržená pro příchozí přenos dat, jako jsou Event Hubs, IoT Hub nebo Azure API Management.

Tento článek představuje úvod do používání služby Azure API Management jako brány pro aplikace Service Fabric. Služba API Management se integruje přímo se Service Fabric a umožňuje publikovat rozhraní API s bohatou sadou pravidel směrování do back-endových služeb Service Fabric.

Dostupnost

Důležité

Tato funkce je dostupná na úrovních Premium a Developer služby API Management kvůli požadované podpoře virtuální sítě.

Architektura

Běžná architektura Service Fabric používá jednostránkovou webovou aplikaci, která provádí volání HTTP do back-endových služeb, které zpřístupňují rozhraní HTTP API. Ukázková aplikace Service Fabric začínáme ukazuje příklad této architektury.

V tomto scénáři slouží bezstavová webová služba jako brána do aplikace Service Fabric. Tento přístup vyžaduje, abyste napsali webovou službu, která může proxy požadavky HTTP na back-endové služby, jak je znázorněno v následujícím diagramu:

S tím, jak se aplikace zkompilují, tak dělají brány, které musí prezentovat rozhraní API před myriad back-endovými službami. Azure API Management je navržený tak, aby zpracovával složitá rozhraní API pomocí pravidel směrování, řízení přístupu, omezování rychlosti, monitorování, protokolování událostí a ukládání odpovědí do mezipaměti s minimální prací na vaší straně. Azure API Management podporuje zjišťování služeb Service Fabric, rozlišení oddílů a výběr repliky pro inteligentní směrování požadavků přímo do back-endových služeb v Service Fabric, takže nemusíte psát vlastní bezstavovou bránu rozhraní API.

V tomto scénáři se webové uživatelské rozhraní pořád obsluhuje prostřednictvím webové služby, zatímco volání rozhraní API HTTP se spravují a směrují přes Azure API Management, jak je znázorněno v následujícím diagramu:

Scénáře aplikací

Služby v Service Fabric můžou být bezstavové nebo stavové a můžou být dělené pomocí jednoho ze tří schémat: singleton, int-64 range a pojmenované. Řešení koncového bodu služby vyžaduje identifikaci konkrétního oddílu konkrétní instance služby. Při překladu koncového bodu služby musí být zadán název instance služby (například fabric:/myapp/myservice) i konkrétní oddíl služby s výjimkou jednoho oddílu.

Azure API Management je možné použít s libovolnou kombinací bezstavových služeb, stavových služeb a jakéhokoli schématu dělení.

Odesílání provozu do bezstavové služby

V nejjednodušším případě se provoz přesměruje do instance bezstavové služby. K dosažení tohoto cíle obsahuje operace služby API Management zásadu příchozího zpracování s back-endem Service Fabric, která se mapuje na konkrétní instanci bezstavové služby v back-endu Service Fabric. Požadavky odeslané do této služby se odesílají do náhodné instance služby.

Příklad

V následujícím scénáři obsahuje aplikace Service Fabric bezstavovou službu s názvem fabric:/app/fooservice , která zveřejňuje interní rozhraní HTTP API. Název instance služby je dobře známý a může být pevně zakódován přímo v zásadách příchozího zpracování služby API Management.

Odeslání provozu do stavové služby

Podobně jako ve scénáři bezstavové služby je možné provoz předávat do instance stavové služby. V tomto případě operace služby API Management obsahuje zásadu příchozího zpracování s back-endem Service Fabric, která mapuje požadavek na konkrétní oddíl konkrétní instance stavové služby. Oddíl, na který se má namapovat na každý požadavek, se vypočítá pomocí metody lambda pomocí některého vstupu z příchozího požadavku HTTP, například hodnoty v cestě URL. Tato zásada může být nakonfigurovaná tak, aby odesílala požadavky pouze na primární repliku nebo na náhodnou repliku pro operace čtení.

Příklad

V následujícím scénáři obsahuje aplikace Service Fabric dělenou stavovou službu s názvem fabric:/app/userservice , která zveřejňuje interní rozhraní HTTP API. Název instance služby je dobře známý a může být pevně zakódován přímo v zásadách příchozího zpracování služby API Management.

Služba je rozdělena pomocí schématu oddílů Int64 se dvěma oddíly a rozsahem klíčů, který zahrnuje Int64.MinValue Int64.MaxValue. Back-endová zásada vypočítá klíč oddílu v daném rozsahu tím id , že převede hodnotu uvedenou v cestě požadavku URL na 64bitové celé číslo, i když se zde dá použít jakýkoli algoritmus k výpočtu klíče oddílu.

Odesílání provozu do několika bezstavových služeb

V pokročilejších scénářích můžete definovat operaci služby API Management, která mapuje požadavky na více než jednu instanci služby. V tomto případě každá operace obsahuje zásadu, která mapuje požadavky na konkrétní instanci služby na základě hodnot z příchozího požadavku HTTP, například cesty URL nebo řetězce dotazu, a v případě stavových služeb oddíl v instanci služby.

K dosažení tohoto cíle obsahuje operace SLUŽBY API Management zásadu příchozího zpracování s back-endem Service Fabric, která se mapuje na instanci bezstavové služby v back-endu Service Fabric na základě hodnot načtených z příchozího požadavku HTTP. Požadavky na službu se odesílají do náhodné instance služby.

Příklad

V tomto příkladu se vytvoří nová bezstavová instance služby pro každého uživatele aplikace s dynamicky vygenerovaným názvem pomocí následujícího vzorce:

• fabric:/app/users/<username>

  Každá služba má jedinečný název, ale názvy nejsou předem známé, protože služby se vytvářejí v reakci na vstup uživatele nebo správce, a proto není možné pevně zakódovat do zásad APIM ani pravidel směrování. Místo toho se název služby, do které se má odeslat požadavek, vygeneruje v definici back-endové zásady z name hodnoty zadané v cestě požadavku ADRESY URL. Příklad:

  • Požadavek na /api/users/foo směrování do instance služby fabric:/app/users/foo
  • Požadavek na /api/users/bar směrování do instance služby fabric:/app/users/bar

Odesílání provozu do několika stavových služeb

Podobně jako v příkladu bezstavové služby může operace služby API Management mapovat požadavky na více než jednu instanci stavové služby, v takovém případě může být také potřeba provést překlad oddílů pro každou instanci stavové služby.

Operace SLUŽBY API Management obsahuje zásadu příchozího zpracování s back-endem Service Fabric, která se mapuje na instanci stavové služby v back-endu Service Fabric na základě hodnot načtených z příchozího požadavku HTTP. Kromě mapování požadavku na konkrétní instanci služby je možné požadavek také namapovat na konkrétní oddíl v rámci instance služby a volitelně na primární repliku nebo náhodnou sekundární repliku v rámci oddílu.

Příklad

V tomto příkladu se vytvoří nová instance stavové služby pro každého uživatele aplikace s dynamicky vygenerovaným názvem pomocí následujícího vzorce:

• fabric:/app/users/<username>

  Každá služba má jedinečný název, ale názvy nejsou předem známé, protože služby se vytvářejí v reakci na vstup uživatele nebo správce, a proto není možné pevně zakódovat do zásad APIM ani pravidel směrování. Místo toho se název služby, do které se má odeslat požadavek, vygeneruje v definici back-endové zásady z name hodnoty poskytnuté cestou požadavku URL. Příklad:

  • Požadavek na /api/users/foo směrování do instance služby fabric:/app/users/foo
  • Požadavek na /api/users/bar směrování do instance služby fabric:/app/users/bar

Každá instance služby je také rozdělena pomocí schématu oddílů Int64 se dvěma oddíly a rozsahem klíčů, který zahrnuje Int64.MinValue Int64.MaxValue. Back-endová zásada vypočítá klíč oddílu v daném rozsahu tím id , že převede hodnotu uvedenou v cestě požadavku URL na 64bitové celé číslo, i když se zde dá použít jakýkoli algoritmus k výpočtu klíče oddílu.

Další kroky

Postupujte podle kurzu a nastavte svůj první cluster Service Fabric se službou API Management a požadavky na toky prostřednictvím služby API Management.