Egy mikroszolgáltatás-architektúrában az ügyfél több előtérbeli szolgáltatással is kommunikálhat. Ebből a tényből adódóan hogyan tudja egy ügyfél, hogy milyen végpontokat kell meghívni? Mi történik az új szolgáltatások bevezetésekor, vagy a meglévő szolgáltatások újrabontásakor? Hogyan kezelik a szolgáltatások az SSL-leállítást, a kölcsönös TLS-t, a hitelesítést és egyéb problémákat? Az API-átjárók segíthetnek ezeknek a kihívásoknak a megoldásában.
diagramja
Az architektúra Visio-fájl letöltése.
Mi az az API-átjáró?
Az API-átjárók központi belépési pontot biztosítanak az ügyfelek és az alkalmazásszolgáltatások közötti interakciók kezeléséhez. Fordított proxyként működik, és átirányítja az ügyfelek kéréseit a megfelelő szolgáltatásokhoz. Emellett különböző horizontális feladatokat is el tud végezni, például hitelesítést, SSL-lezárást, kölcsönös TLS-t és sebességkorlátozást.
Miért érdemes API-átjárót használni?
Az API-átjáró leegyszerűsíti a kommunikációt, javítja az ügyfél-interakciókat, és központosítja a gyakori szolgáltatási szintű feladatok kezelését. Közvetítőként működik, és megakadályozza az alkalmazásszolgáltatások ügyfeleknek való közvetlen kitettségét. API-átjáró nélkül az ügyfeleknek közvetlenül kell kommunikálniuk az egyes alkalmazásszolgáltatásokkal, ami a következő kihívásokat jelentheti:
összetett ügyfélkód: Összetett ügyfélkódot eredményezhet. Az ügyfeleknek több végpontot kell nyomon követnie, és rugalmasan kell kezelnie a hibákat.
Szoros csatolási: Összekapcsolást hoz létre az ügyfél és a háttérrendszer között. Az ügyfeleknek meg kell érteniük az egyes szolgáltatások felbontását, ami megnehezíti a szolgáltatás karbantartását és újrabontását.
Megnövekedett késés: Egyetlen művelet több szolgáltatás hívását igényelheti. Az eredmény lehet több hálózati körút az ügyfél és a kiszolgáló között, ami jelentős késést eredményez.
aggodalmak redundáns kezelése: Minden nyilvános szolgáltatásnak kezelnie kell az olyan problémákat, mint a hitelesítés, az SSL és az ügyfélsebesség-korlátozás.
protokollkorlátozások: A szolgáltatásoknak ügyfélbarát protokollt, például HTTP-t vagy WebSocketet kell elérhetővé tennie. Ez az expozíció korlátozza kommunikációs protokollokat lehetőségeket.
Bővített támadási felület: A nyilvános végpontok növelik a lehetséges támadási felületet, és megkeményedést igényelnek.
API-átjáró használata
Az API-átjárók meghatározott tervezési minták használatával testre szabhatók az alkalmazás követelményeinek megfelelően. Ezek a tervezési minták olyan kulcsfontosságú funkciókkal foglalkoznak, mint az útválasztás, a kérelmek összesítése és a horizontális szempontok:
átjáró útválasztási. Az API-átjáró fordított proxyként is használható az ügyfélkérések különböző alkalmazásszolgáltatásokhoz való átirányításához. Az API-átjáró a 7. rétegbeli útválasztást használja, és egyetlen végpontot biztosít az ügyfelek számára. Az API-átjáró útválasztását akkor használja, ha le szeretné választani az ügyfeleket az alkalmazásszolgáltatásoktól.
átjáróösszesítési. Az API-átjáróval több ügyfélkérést összesíthet egyetlen kérelemben. Ezt a mintát akkor használja, ha egyetlen művelethez több alkalmazásszolgáltatás hívására van szükség. Az API-összesítésben az ügyfél egy kérést küld az API-átjárónak. Ezután az API-átjáró átirányítja a kéréseket a műveletekhez szükséges különböző szolgáltatásokhoz. Végül az API-átjáró összesíti az eredményeket, és visszaküldi őket az ügyfélnek. Az összesítés segít csökkenteni az ügyfél és az alkalmazásszolgáltatások közötti csevegést.
átjáró kiszervezése. Az API-átjárókkal többirányú funkciókat biztosíthat, így az egyes szolgáltatásoknak nem kell azt biztosítaniuk. Hasznos lehet a keresztvágási funkciókat egy helyre egyesíteni ahelyett, hogy minden szolgáltatást felelőssé tennék. Íme néhány példa olyan funkciókra, amelyeket ki lehet kapcsolni egy API-átjáróra:
- SSL-leállítás
- Kölcsönös TLS
- Hitelesítés
- IP-engedélyezési lista vagy tiltólista
- Ügyfélsebesség-korlátozás (szabályozás)
- Naplózás és figyelés
- Válasz gyorsítótárazása
- Webalkalmazási tűzfal
- GZIP-tömörítés
- Statikus tartalom karbantartása
API-átjáró beállításai
Íme néhány lehetőség az API-átjáró alkalmazásbeli implementálására.
Fordított proxykiszolgáló. Az Nginx és a HAProxy nyílt forráskódú fordított proxyajánlatok. Támogatják az olyan funkciókat, mint a terheléselosztás, az SSL leállítása és a 7. rétegbeli útválasztás. Ingyenes verziókkal és fizetős kiadásokkal rendelkeznek, amelyek további funkciókat és támogatási lehetőségeket biztosítanak. Ezek a termékek fejlettek, gazdag funkciókészletekkel, nagy teljesítménnyel és bővíthetőséggel.
Service Mesh bejövőforgalom-vezérlő. Ha szolgáltatáshálót használ, értékelje ki az adott szolgáltatáshálóra jellemző bejövőforgalom-vezérlő funkcióit. Ellenőrizze az AKS által támogatott bővítményeket, például az Istio-t és az Open Service Mesh-t. Keressen külső nyílt forráskódú projekteket, például a Linkerdet vagy a Consul Connectet. Az Istio bejövőforgalom-vezérlő például támogatja a 7. rétegbeli útválasztást, a HTTP-átirányításokat, az újrapróbálkozásokat és más funkciókat.
Azure Application Gateway. Az Application Gateway egy felügyelt terheléselosztási szolgáltatás. 7. rétegbeli útválasztást, SSL-lezárást és webalkalmazási tűzfalat (WAF) biztosít.
Azure Front Door. Az Azure Front Door egy tartalomkézbesítési hálózat (CDN). Globális és helyi jelenléti pontokat (PoP-k) használ, hogy gyors, megbízható és biztonságos hozzáférést biztosítson az alkalmazások statikus és dinamikus webes tartalmaihoz globálisan.
Azure API Management. Az API Management egy felügyelt megoldás az API-k külső és belső ügyfelek számára történő közzétételéhez. Olyan funkciókat biztosít, amelyekkel kezelhetők a nyilvános API-k, beleértve a sebességkorlátozást, az IP-korlátozásokat és a Microsoft Entra-azonosítóval vagy más identitásszolgáltatókkal végzett hitelesítést. Az API Management nem végez terheléselosztást, ezért terheléselosztóval, például Azure Application Gatewayrel vagy fordított proxyval kell használnia. További információ: API Management az Azure Application Gateway.
API Gateway-technológia kiválasztása
API-átjáró kiválasztásakor vegye figyelembe a következő tényezőket:
Minden követelmény támogatása. Válasszon egy API-átjárót, amely támogatja a szükséges funkciókat. Az összes korábbi API Gateway-beállítás támogatja a 7. rétegbeli útválasztást. Más funkciók, például a hitelesítés, a sebességkorlátozás és az SSL-leállítás támogatása azonban eltérő lehet. Felmérheti, hogy egy átjáró megfelel-e az igényeinek, vagy több átjáróra van-e szükség.
A beépített ajánlatok előnyben részesítve. Használjon beépített API-átjárót és a platform által biztosított bejövő megoldásokat, például az Azure Container Appst és az AKS-t, amikor megfelelnek a biztonsági és vezérlési követelményeknek. Csak akkor használjon egyéni átjárót, ha a beépített lehetőségek nem rendelkeznek a szükséges rugalmassággal. Az egyéni megoldásokhoz olyan szabályozási modellre van szükség, mint például a GitOps, az életciklus hatékony kezeléséhez.
Válassza ki a megfelelő üzemi modellt. Használjon olyan felügyelt szolgáltatásokat, mint az Azure Application Gateway és az Azure API Management, a működési többletterhelés csökkentése érdekében. Ha általános célú fordított proxykat vagy terheléselosztókat használ, helyezze üzembe őket az architektúrához igazodó módon. Az általános célú API-átjárókat dedikált virtuális gépeken vagy egy AKS-fürtön belül helyezheti üzembe a bejövőforgalom-vezérlő ajánlataiban. Ha el szeretné különíteni az API-átjárót a számítási feladattól, üzembe helyezheti őket a fürtön kívül, de ez az üzembe helyezés növeli a felügyelet összetettségét.
Módosítások kezelése. Amikor szolgáltatásokat frissít vagy újakat ad hozzá, előfordulhat, hogy frissítenie kell az átjáró útválasztási szabályait. Folyamatok vagy munkafolyamatok implementálása az útválasztási szabályok kezeléséhez szolgáltatások, SSL-tanúsítványok, IP-engedélyezési listák és biztonsági konfigurációk hozzáadásakor vagy módosításakor. Az API-átjárók felügyeletének egyszerűsítéséhez használja az infrastruktúra kódként és automatizálási eszközeit.
Következő lépések
A korábbi cikkek az mikroszolgáltatások, valamint a mikroszolgáltatások és az ügyfélalkalmazások közötti felületeket ismertették. Ezek az interfészek minden szolgáltatást önálló, átlátszatlan egységként kezelnek. A mikroszolgáltatás-architektúra kritikus elve, hogy a szolgáltatások soha ne tegyenek közzé belső adatokat az adatok kezelésével kapcsolatban. Ez a megközelítés jelentős hatással van az adatok integritásának és konzisztenciájának fenntartására, amely a következő cikk tárgya.