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 určená pro příchozí přenosy dat, jako jsou Event Hubs, IoT Hub nebo Azure API Management.

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

Dostupnost

Důležité

Tato funkce je dostupná v Premium a vývojářských úrovních 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á volá http back-endové služby, 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 napsat 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:

Diagram that shows how a stateless web service serves as the gateway into the Service Fabric application.

Vzhledem k tomu, že se aplikace zvětšují složitostí, musí 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 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í služby Service Fabric, rozlišení oddílů a výběr repliky, aby inteligentně směrovaly požadavky 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í 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 v následujícím diagramu:

Diagram that shows how the web UI is still served through a web service, while HTTP API calls are managed and routed through Azure API Management.

Scénáře aplikací

Služby v Service Fabric mohou být bezstavové nebo stavové a můžou být rozděleny pomocí jednoho ze tří schémat: singleton, int-64 rozsah 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 lze 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ředá do bezstavové instance služby. K tomu API Management operace obsahuje zásadu příchozího zpracování se Service Fabric back-endem, 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 API Management příchozího zpracování.

Diagram that shows a Service Fabric application contains a stateless service that exposes an internal HTTP API.

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

Podobně jako ve scénáři bezstavové služby je možné provoz předat do stavové instance služby. V tomto případě operace 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í stavové instance služby. Oddíl, na který se má namapovat 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. Zásada může být nakonfigurovaná tak, aby odesílala požadavky pouze primární replice, nebo na náhodnou repliku pro operace čtení.

Příklad

V následujícím scénáři aplikace Service Fabric obsahuje dělenou stavovou službu s názvemfabric:/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 API Management příchozího zpracování.

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

Service Fabric with Azure API Management topology overview

Odesílání provozu do více 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 cesta url nebo řetězec dotazu, a v případě stavových služeb oddíl v instanci služby.

K tomu API Management operace obsahuje zásadu příchozího zpracování s Service Fabric back-endem, která se mapuje na instanci bezstavové služby v Service Fabric back-endu 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 známé předem, 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 nebo 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

Diagram that shows an example where a new stateless service instance is created for each user of an application with a dynamically generated name.

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 stavovou instanci služby, v takovém případě možná budete muset provést překlad oddílů pro každou stavovou instanci služby.

K tomu API Management operace obsahuje zásadu příchozího zpracování s Service Fabric back-endem, která se mapuje na stavovou instanci služby v Service Fabric back-endu 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á stavová 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 známé předem, 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 nebo 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é cesty k 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

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

Diagram that shows that each service instance is also partitioned using the Int64 partition scheme with two partitions and a key range that spans Int64.MinValue to Int64.MaxValue.

Další kroky

Postupujte podle kurzu a nastavte svůj první cluster Service Fabric s API Management a požadavky toku prostřednictvím API Management do služeb.