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ánou jakákoli bezstavová služba, například aplikace ASP.NET Core, nebo jiná služba určená pro příchozí přenos dat, jako je Event Hubs, IoT Hub nebo Azure API Management.

Tento článek představuje úvod do používání Azure API Management jako brány pro aplikace Service Fabric. 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 k dispozici na úrovních Premium a Developer 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 getting-started ukazuje příklad této architektury.

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

S rostoucí složitostí aplikací se zvětšují i brány, které musí prezentovat rozhraní API před nesčetným back-endovým službám. Služba Azure API Management je navržená tak, aby zvládla složitá rozhraní API s pravidly směrování, řízením přístupu, omezováním rychlosti, monitorováním, protokolováním událostí a ukládáním odpovědí do mezipaměti s minimální prací na vaší straně. Azure API Management podporuje zjišťování, překlad oddílů a výběr repliky služby Service Fabric k inteligentnímu směrování požadavků přímo do back-endových služeb v Service Fabric, abyste nemuseli psát vlastní bránu bezstavového rozhraní API.

V tomto scénáři se webové uživatelské rozhraní stále obsluhuje prostřednictvím webové služby, zatímco volání rozhraní HTTP API se spravují a směrují přes Azure API Management, jak je znázorněno na 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 rozdělené pomocí jednoho ze tří schémat: singleton, int-64 range a pojmenované. Řešení koncových bodů 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žívat s libovolnou kombinací bezstavových služeb, stavových služeb a libovolného schématu dělení.

Odeslání provozu do bezstavové služby

V nejjednodušším případě se provoz přesměruje do instance bezstavové služby. Za tímto účelem operace API Management obsahuje zásady zpracování příchozích dat s back-endem Service Fabric, které se mapuje na konkrétní instanci bezstavové služby v back-endu Service Fabric. Požadavky odeslané této službě 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 je možné ho pevně zakódovat přímo v zásadách API Management příchozího zpracování.

Odeslání provozu do stavové služby

Podobně jako ve scénáři bezstavové služby je možné provoz přesměrovat do instance stavové služby. V tomto případě operace API Management obsahuje příchozí zásady 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 každý požadavek, se vypočítá pomocí metody lambda pomocí určitého vstupu z příchozího požadavku HTTP, například hodnoty v cestě URL. Zásady mohou být nakonfigurované tak, aby odesílaly požadavky pouze do primární repliky 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 je možné ho pevně zakódovat přímo v zásadách API Management příchozího zpracování.

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

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

V pokročilejších scénářích můžete definovat operaci 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, jako je například cesta url nebo řetězec dotazu, a v případě stavových služeb oddíl v rámci instance služby.

Aby toho bylo možné dosáhnout, operace API Management obsahuje příchozí zásady 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á instance bezstavové 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í jako reakce na vstup uživatele nebo správce, a proto je nelze pevně zakódovat do zásad APIM nebo pravidel směrování. Místo toho se v definici zásad back-endu vygeneruje název služby, do které se má odeslat požadavek, z name hodnoty zadané v cestě k požadavku adresy URL. Příklad:

  • Požadavek se /api/users/foo směruje do instance služby. fabric:/app/users/foo
  • Požadavek se /api/users/bar směruje do instance služby. fabric:/app/users/bar

Odesílání provozu do více stavových služeb

Podobně jako v příkladu bezstavové služby může operace 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.

Aby toho bylo možné dosáhnout, API Management operace obsahuje příchozí zásady 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 namapovat také na konkrétní oddíl v instanci služby a volitelně na primární repliku nebo na 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í jako reakce na vstup uživatele nebo správce, a proto je nelze pevně zakódovat do zásad APIM nebo pravidel směrování. Místo toho se v definici back-endové zásady vygeneruje název služby, do které se má odeslat požadavek, z name hodnoty zadané v cestě k požadavku adresy URL. Příklad:

  • Požadavek se /api/users/foo směruje do instance služby. fabric:/app/users/foo
  • Požadavek se /api/users/bar směruje do instance služby. fabric:/app/users/bar

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

Další kroky

Postupujte podle tohoto kurzu a nastavte svůj první cluster Service Fabric s API Management a tokem požadavků přes API Management do vašich služeb.