Tato referenční architektura používá službu Azure Integration Services k orchestraci volání podnikových back-endových systémů. Back-endové systémy mohou zahrnovat systémy SaaS (software jako služba), služby Azure a existující webové služby ve vašem podniku.
Azure Integration Services je kolekce služeb pro integraci aplikací a dat. Tato architektura používá dvě z těchto služeb: Logic Apps k orchestraci pracovních postupů a API Management vytváření katalogů rozhraní API. Tato architektura je dostatečná pro základní scénáře integrace, kdy se pracovní postup aktivuje synchronními voláními back-endových služeb. Sofistikovanější architektura využívající fronty a události vychází z této základní architektury.
Architektura
Tato architektura se skládá z následujících komponent:
Back-endové systémy. Pravá strana diagramu znázorňuje různé back-endové systémy, které podnik nasadil nebo na které spoléhá. Ty můžou zahrnovat systémy SaaS, další služby Azure nebo webové služby, které zpřístupňuje koncové body REST nebo SOAP.
Azure Logic Apps. Logic Apps bez serveru pro vytváření podnikových pracovních postupů, které integrují aplikace, data a služby. V této architektuře se aplikace logiky spouštějí požadavky HTTP. Můžete také vnořit pracovní postupy pro složitější orchestraci. Logic Apps používá konektory k integraci s běžně používanými službami. Logic Apps nabízí stovky konektorů a můžete vytvářet vlastní konektory.
Azure API Management. API Management je spravovaná služba pro publikování katalogů rozhraní HTTP API, která podporuje opakované použití a zjistitelnost. API Management se skládá ze dvou souvisejících komponent:
Brána rozhraní API. Brána rozhraní API přijímá volání HTTP a směruje je do back-endu.
Portál pro vývojáře. Každá instance služby Azure API Management přístup k portálu pro vývojáře. Tento portál poskytuje vývojářům přístup k dokumentaci a ukázkám kódu pro volání rozhraní API. Rozhraní API můžete testovat také na portálu pro vývojáře.
V této architektuře se složená rozhraní API se sestavují importem aplikací logiky jako rozhraní API. Existující webové služby můžete importovat také importem specifikací OpenAPI (Swagger) nebo importem rozhraní SOAP API ze specifikací WSDL.
Brána rozhraní API pomáhá oddělení front-end klientů od back-endu. Může například přepsat adresy URL nebo transformovat požadavky předtím, než se dostanou do back-endu. Zabývá se také mnoha průřezy, jako je ověřování, podpora sdílení prostředků mezi zdroji (CORS) a ukládání odpovědí do mezipaměti.
Azure DNS. Azure DNS je hostitelská služba pro domény DNS. Azure DNS poskytuje překlad adres IP pomocí Microsoft Azure infrastruktury. Hostování domén v Azure vám umožňuje spravovat záznamy DNS pomocí stejných přihlašovacích údajů, rozhraní API, nástrojů a fakturace, které používáte pro ostatní služby Azure. Pokud chcete použít vlastní název domény, například contoso.com, vytvořte záznamy DNS, které mapovat název vlastní domény na IP adresu. Další informace najdete v tématu Konfigurace vlastního názvu domény v API Management.
Azure Active Directory (Azure AD). K ověřování klientů, kteří volají bránu rozhraní API, použijte Azure AD. Azure AD podporuje protokol OpenID Připojení (OIDC). Klienti žádají o přístupový token z Azure AD a služba API Gateway ověří token pro autorizaci požadavku. Při použití úrovně Standard nebo Premium úrovně API Management může Azure AD také zabezpečit přístup k portálu pro vývojáře.
Doporučení
Vaše konkrétní požadavky se můžou lišit od obecné architektury uvedené tady. Jako výchozí bod použijte doporučení uvedená v této části.
API Management
Použijte API Management Basic, Standard nebo Premium. Tyto úrovně nabízejí smlouvu o úrovni služeb (SLA) pro produkční prostředí a podporu horizontálního navýšení velikosti v rámci oblasti Azure. Kapacita propustnosti pro API Management se měří v jednotkách. Každá cenová úroveň má maximální horizontální navýšení velikosti. Úroveň Premium podporuje horizontální navýšení velikosti napříč několika oblastmi Azure. Zvolte úroveň na základě vaší sady funkcí a požadované propustnosti. Další informace najdete v tématu API Management a Kapacita instance azure API Management.
Každá instance API Management Azure má výchozí název domény, což je subdoména azure-api.net , například contoso.azure-api.net . Zvažte konfiguraci vlastní domény pro vaši organizaci.
Logic Apps
Logic Apps funguje nejlépe ve scénářích, které nevyžadují nízkou latenci odpovědi, jako jsou asynchronní nebo částečně dlouhotrací volání rozhraní API. Pokud se vyžaduje nízká latence, například ve volání, které blokuje uživatelské rozhraní, použijte jinou technologii. Můžete například použít Azure Functions webové rozhraní API nasazené do Azure App Service. Pomocí API Management rozhraní API před spotřebiteli rozhraní API.
Oblast
Pokud chcete minimalizovat latenci sítě, API Management a Logic Apps do stejné oblasti. Obecně zvolte oblast, která je nejblíže vašim uživatelům (nebo co nejblíže vašim back-end službám).
Skupina prostředků má také oblast. Tato oblast určuje, kam se budou ukládat metadata nasazení a kde se má šablona nasazení spustit. Pokud chcete zlepšit dostupnost během nasazování, umístěte skupinu prostředků a prostředky do stejné oblasti.
Aspekty zabezpečení
Pokud chcete zvýšit škálovatelnost API Management, podle potřeby přidejte zásady ukládání do mezipaměti. Ukládání do mezipaměti také snižuje zatížení back-endových služeb.
Pokud chcete nabídnout větší kapacitu, můžete škálovat azure API Management úrovně Basic, Standard a Premium úrovně v oblasti Azure. Pokud chcete analyzovat využití vaší služby, vyberte v nabídce Metriky možnost Capacity Metric (Metrika kapacity) a pak podle potřeby podle potřeby škálujte nahoru nebo dolů. Proces upgradu nebo škálování může trvat 15 až 45 minut.
Recommendations škálování služby API Management:
Při škálování zvažte vzory provozu. Zákazníci s nestálějšími vzorci provozu potřebují větší kapacitu.
Konzistentní kapacita, která je větší než 66 %, může naznačovat potřebu škálování na více než 66 %.
Konzistentní kapacita, která je nižší než 20 %, může znamenat příležitost k horizontálnímu navýšení kapacity.
Před povolením zatížení v produkčním prostředí vždy otestujte zatížení API Management s reprezentativní zátěží.
S úrovní Premium můžete škálovat instanci API Management napříč několika oblastmi Azure. Díky tomu API Management nárok na vyšší sla a umožňuje zřídit služby v blízkosti uživatelů ve více oblastech.
Model Logic Apps bez serveru znamená, že správci nemusí plánovat škálovatelnost služby. Služba se automaticky škáluje podle poptávky.
Aspekty dostupnosti
Projděte si sla pro jednotlivé služby:
Pokud nasadíte API Management ve dvou nebo více oblastech s úrovní Premium, má nárok na vyšší sla. Viz API Management ceny .
Zálohování
Pravidelně zálohujte konfiguraci API Management počítače. Soubory záloh uložte do umístění nebo oblasti Azure, které se liší od oblasti, ve které je služba nasazená. Na základě RTO zvolte strategii zotavení po havárii:
V případě události zotavení po havárii API Management novou instanci úložiště, obnovte zálohu do nové instance a znovu nasapište záznamy DNS.
Pasivní instanci této služby API Management v jiné oblasti Azure. Pravidelně obnovujte zálohy do této instance, aby byla synchronizovaná s aktivní službou. Pokud chcete službu obnovit během události zotavení po havárii, potřebujete pouze znovu určit záznamy DNS. Tento přístup má další náklady, protože platíte za pasivní instanci, ale zkracuje čas na obnovení.
Pro aplikace logiky doporučujeme použít konfiguraci jako kód k zálohování a obnovení. Protože aplikace logiky jsou bez serveru, můžete je rychle znovu vytvořit z Azure Resource Manager šablon. Uložte šablony do správy zdrojového kódu a integrujte šablony s vaším procesem kontinuální integrace nebo průběžného nasazování (CI/CD). V události zotavení po havárii nasaďte šablonu do nové oblasti.
Pokud nasadíte aplikaci logiky do jiné oblasti, aktualizujte konfiguraci v API Management. Vlastnost back-endu rozhraní API můžete aktualizovat pomocí základního skriptu PowerShellu.
Důležité informace o DevOps
Vytvořte samostatné skupiny prostředků pro produkční, vývojové a testovací prostředí. Samostatné skupiny prostředků usnadňují správu nasazení, odstraňování testovacích nasazení a přiřazování přístupových práv.
Při přiřazování prostředků do skupin prostředků Vezměte v úvahu tyto faktory:
Životní cyklus. Prostředky se stejným životním cyklem umístěte do stejné skupiny prostředků.
Přístup. Pokud chcete použít zásady přístupu u prostředků ve skupině, můžete použít řízení přístupu na základě role Azure (RBAC).
Fakturace. Můžete zobrazit souhrnné náklady pro skupinu prostředků.
Cenová úroveň pro API Management. Pro vývojová a testovací prostředí použijte úroveň Developer. Pokud chcete minimalizovat náklady v předprodukční fázi, nasaďte repliku produkčního prostředí, spusťte testy a pak repliku vypněte.
Nasazení
Pomocí Azure Resource Manager šablon nasaďte prostředky Azure, postupujte podle procesu infrastruktura jako Code (IAC). šablony usnadňují automatizaci nasazení pomocí Azure DevOps Servicesnebo jiných řešení CI/CD.
Příprava
Zvažte přípravu zátěže, což znamená nasazení do různých fází a spuštění ověření v každé fázi před přechodem na další. tímto způsobem můžete nabízet aktualizace do vašich produkčních prostředí vysoce kontrolovaným způsobem a minimalizovat neočekávané problémy s nasazením. Nasazení Blue-zelená a Kanárské verze jsou doporučenými strategiemi nasazení pro aktualizace živých produkčních prostředí. Zvažte také dobrou strategii vrácení zpět pro případ, kdy nasazení dojde k chybě. Můžete například automaticky znovu nasadit dřívější úspěšné nasazení z historie nasazení, takže parametr--rollback-On-Error v rozhraní příkazového řádku Azure je dobrým příkladem.
Izolace úloh
Dejte API Management a jakékoli jednotlivé aplikace logiky do svých vlastních samostatných šablon Správce prostředků. Pomocí samostatných šablon můžete ukládat prostředky v systémech správy zdrojového kódu. Šablony můžete nasadit společně nebo jednotlivě jako součást procesu CI/CD.
Verze
Pokaždé, když změníte konfiguraci aplikace logiky nebo nasadíte aktualizaci prostřednictvím šablony Správce prostředků, Azure uchová kopii této verze a udržuje všechny verze, které mají historii spuštění. Tyto verze můžete použít ke sledování historických změn nebo povýšení verze jako aktuální konfigurace aplikace logiky. Můžete například vrátit zpět aplikaci logiky na předchozí verzi.
API Management podporuje dvě odlišná, ale doplňkové koncepty správy verzí:
Verze umožňují spotřebitelům rozhraní API zvolit verzi rozhraní API podle svých potřeb, například V1, v2, beta nebo produkční.
Revize umožňují správcům rozhraní API vytvářet nenáročné změny v rozhraní API a nasazovat tyto změny společně s protokolem změn a informovat uživatele rozhraní API o změnách.
Můžete provést revizi ve vývojovém prostředí a nasadit tuto změnu v dalších prostředích pomocí Správce prostředků šablon. Další informace najdete v tématu publikování několika verzí vašeho rozhraní API .
Můžete také použít revize k otestování rozhraní API před provedením změn aktuálních a dostupných uživatelům. Tato metoda však není doporučena pro zátěžové testování nebo testování integrace. Místo toho použijte samostatné testovací nebo předprodukční prostředí.
Diagnostika a monitorování
Azure monitor slouží k monitorování provozu v API Management i Logic Apps. Azure Monitor poskytuje informace na základě metrik nakonfigurovaných pro každou službu a je ve výchozím nastavení povolená. Další informace naleznete v tématu:
- Monitorování publikovaných rozhraní API
- Monitorování stavu, nastavení protokolování diagnostiky a zapnutí upozornění pro Azure Logic Apps
Každá služba má také tyto možnosti:
K hlubší analýze a řídicím panelům odešlete protokoly Logic Apps do Azure Log Analytics.
pro DevOps monitorování nakonfigurujte Application Insights Azure pro API Management.
API Management podporuje šablonu řešení Power BI pro vlastní analýzu rozhraní API. Tuto šablonu řešení můžete použít k vytvoření vlastního analytického řešení. pro podnikové uživatele Power BI zpřístupňuje dostupné sestavy.
Důležité informace o zabezpečení
I když tento seznam zcela nepopisuje všechny osvědčené postupy zabezpečení, tady jsou některé bezpečnostní předpoklady, které platí konkrétně pro tuto architekturu:
Služba Azure API Management má pevnou veřejnou IP adresu. Omezte přístup pro volání koncových bodů Logic Apps jenom na IP adresu API Management. Další informace najdete v tématu omezení příchozích IP adres.
Abyste měli jistotu, že uživatelé mají odpovídající úrovně přístupu, použijte řízení přístupu na základě role v Azure (Azure RBAC).
zabezpečte veřejné koncové body rozhraní API v API Management pomocí Připojení OAuth nebo OpenID. Pro zabezpečení veřejných koncových bodů rozhraní API nakonfigurujte poskytovatele identity a přidejte zásady ověřování JSON Web Token (JWT). další informace najdete v tématu ochrana rozhraní API pomocí OAuth 2,0 s Azure Active Directory a API Management.
Připojení back-endové služby z API Management pomocí vzájemných certifikátů.
Vyvynuťte protokol HTTPS u rozhraní API Management API.
Ukládání tajných kódů
Nikdy nezapisujte hesla, přístupové klíče nebo připojovací řetězce do správy zdrojového kódu. Pokud jsou tyto hodnoty požadovány, zabezpečte a nasaďte tyto hodnoty pomocí vhodných technik.
Pokud aplikace logiky vyžaduje jakékoli citlivé hodnoty, které v rámci konektoru nemůžete vytvořit, uložte tyto hodnoty do Azure Key Vault a odkázat na ně z Správce prostředků šablony. Použijte parametry šablony nasazení a soubory parametrů pro každé prostředí. Další informace najdete v tématu zabezpečené parametry a vstupy v rámci pracovního postupu.
API Management spravuje tajné klíče pomocí objektů nazvaných pojmenované hodnoty nebo vlastnosti. Tyto objekty bezpečně ukládají hodnoty, ke kterým můžete přistupovat prostřednictvím zásad API Management. Další informace najdete v tématu použití pojmenovaných hodnot v zásadách Azure API Management.
Důležité informace o nákladech
Obecně platí, že pomocí cenové kalkulačky Azure můžete odhadnout náklady. Tady jsou některé další okolnosti.
API Management
Budou se vám účtovat všechny instance API Management, když jsou spuštěné. Pokud jste nastavili horizontální navýšení kapacity a nepotřebujete tuto úroveň výkonu po celou dobu, proveďte ruční horizontální navýšení kapacity nebo konfigurace automatického škálování.
Logic Apps
Logic Apps používá model bez serveru . Fakturace se počítá na základě akce a spuštění konektoru. Další informace najdete v tématu Logic Apps ceny.
Další informace najdete v části věnované nákladům v tématu Dobře navržená architektura Microsoft Azure.
Další kroky
Pro zajištění vyšší spolehlivosti a škálovatelnosti použijte k oddělení back-end systémů fronty zpráv a události. tento model se zobrazuje v další referenční architektuře v této sérii: Enterprise integrací pomocí front a událostí zpráv.