Overview API Gateway


本文整理 API Gateway 的基礎概念與想法,主要整理架構設計、技術規格、應用場景等探討。關於 AWS 的產品請參考 Amazon API Gateway 的整理。


Overview API Gateway

API Gateway 在 商務應用分散式系統 有不同的應用與場景需求,但是他們都具備類似的技術架構與特性。

使用情境

API Gateway 其實可以使用的情境很多,簡單整理如下:

  • 改用認證機制,像是 JWT、OAuth2
  • 重新規劃 API 介面,例如原本叫做 POST /GetMember/{id} 想改成 GET /member/{id}
  • 封裝舊的服務
    • 增強安全性
    • 原本使用 XML 做資料交換,透過 transformation 之後,改成用 JSON
    • 增加對每個 token 的追蹤、認證機制
  • 跨網域的需求 (CORS)
  • 重新處理錯誤資訊
  • 解構單體,邁向微服務化

架構的可視性

規劃上,首要考量的是整體系統架構的 可視性 (Visibility) 開始。想像是未來 API Gateway 要公開 (Public)、還是私有 (Private),還是限定特殊來源 (Protected)?

以應用場景來看,整理以下:

  • 商務應用: 從架構來看通常是對外服務的接口,但還是有例外。
    • Public: 面對 Business User,通常是開放到廣域網路,像是 Mobile APP 的 API、Web API … 等
    • Public to Protected: 面對 3rd party 的串接,像是 FB / Google SSO 的 callback、或者第三放應用程式串接的 callback.
    • Private: 這種通常是透過特殊的網路架構,像是 MPLS、Federation 等方式。
  • 分散式系統 (像是 Microservices): 使用的情境是 服務跟服務 之間的溝通,架構上的可視性組合:
    • Private to Private: 都在內部,內部網路之間的服務相互溝通
    • Private to Public: 內部跟外部對串,內部跟外部對串,像是跨雲:AWS to GCP、On-Prem to AWS …
    • Public to Public: 都在外部,直接走 Public Network

分散式系統 談的是架構性的問題,重點在於服務跟服務之間怎麼達到 可靠性 的議題,討論的是如何 Decoupling (解偶) 服務跟服務之間的同步模式 (Synchronous),他部分特性類似於 API Gateway,但這角色現在稱為 Service Mesh

Decoupling Solution 有兩種方法:

  • Synchronous: 常用的方法是透過 Load Balancing, Reverse Proxy, or API Gateway … 等實作技術,形成 Push Mode
  • Asynchronous: 常用的是透過 Queue,形成 Pull Mode

內部服務之間的通訊,技術面對的問題與 API Gateway 類似,但是實作面試有一些差異的,參閱 Service Mesh 的整理

商務應用 著重的是靈活度議題,如何透過 API Gateway 靈活調度背後的系統,滿足 商業需求 的改變與 系統架構 的異動。不管是商業需求還是系統架構,放到 現場 (Production, Go Live) 就是要能面對廣域網路,連帶的就要面對安全、效能、容錯、擴展、開發、維運 … 等議題了。

Design Pattern - Facade

API Gateway 相當於 Design Pattern 的 Facade pattern。想像把一些東西,經過重新包裝後,然後只提供需要的接口可以存取、使用。

Key Features

整理 API Gateway 各個面向應該具備的特性,分成 核心需求架構 (網路、資安、基礎)開發測試維運

  • 核心需求
    • Single Entry Point: 單一入口節點
    • Auth: 認證 (Authentication) 與授權 (Authorization)
      • 認證: 通常可以負責認證部分,可以透過簡單的 API Token, Query String, Header … 認證,也可以透過 AD / LDAP。
      • 授權: 通常交給後端應用層處理。可以整合 OAuth, OpenID, SAML, JWT … 等各式各樣
    • URL Route: 配置 URL Path 與 HTTP Method 的 Routing
    • Traffic Control / Flow Control: Rate Limit, Proxy, Response Limit, TTL
    • Transformation: 資料格式轉換,例如收到的是 JSON,轉換成 XML 給後端吃。
  • Architecture: Network / Infra / Security
    • Security: ACL, SSL, CORS, WAF, Token Management
    • Reliability: 容錯、HA、LoadBalancing
    • Scalability: 自動擴展
    • Performance: Cache (CDN), Network Throughput
  • Development and Test
    • Standard: 整合 API 標準開發工具,像是 Swagger
    • Portal: for User (Sandbox), Developer, Operation
    • Integration: 可以容易整合各種後端的服務接點, 像是 Reverse Proxy
    • Deployment Management: 部署方法,包含 B/G、Canary、A/B … etc
    • Client SDK: 支援 iOS / Android / JavaScript … 等常見的 Client App
  • Operation
    • Deployment Management: 同上
    • API Keys Management: Life cycle, Usage Planning, Quotas, Expiration
    • Logging, Monitoring, Alert
    • Documentation: API Portal

相關 Solutions

底下是常見的 Solution,分兩大類:Managed Services、Self Hosting。原則上,我會先以 Managed Service 優先考量,理由如下:

  • 跟選擇 Amazon CloudWatch 一樣:不想養機器,減少 Operation 成本。
  • 跟 Infra 整合比較好的優先
  • Leverage Cloud SLA

但是再怎麼美好,還是要有備案,所以另外要考量的是,未來如果要自己 Hosting 的必要選項。Kong 是第一選擇,因為他是 Openresty base,也是我比較熟悉的。整理 PoC 的次序如下:

  1. Amazon API Gateway
  2. Kong - Openresty (Nginx + lua) base
  3. Google: CLOUD ENDPOINTS
  4. Tyk - Golang base
  5. ENVOY
  6. Azure: API Management
  7. Akamai: API Gateway

替代方案

API Gateway 可以用類似的技術取代,像是 Reverse Proxy、Load Balancing 等方法。

實務上的實作 Nginx、Canddy、HAProxy 都是不錯的選擇。

Endpoint Planning

API Gateway 的 Endpoint 會給客戶使用,換言之,很容易覆水難收。如果 Business 是屬於多用戶的型態,也就是 API 會同時給很多人使用,通常 Migration 都會遇到一個問題:

客戶不見得願意改,或者客戶沒能力改、無法改。

所以規劃 Endpoint 時要考量這些可能的問題。規劃架構之前,要考慮實際的 Endpoint 應該怎麼配置與識別,考量的面向如下:

  • DNS Planing
  • Service Naming
  • Environment: dev, testing, sandbox, prod

舉例來說,以 Domain rick.com 做例子,Endpoint Naming 與規劃考慮如下:

  • api.rick.com: 代表都是透過 API Gateway
  • {ServiceName}.api.rick.com: 某一個服務的 API Endpoint
  • {ServiceName}.api.{Env}.rick.com: 某一個環境的 API Endpoint
    • {ServiceName}.api.sandbox.rick.com: 代表 開放 給客戶測試用的 API Endpoint
    • {ServiceName}.api.lab[1-N].rick.com: 代表某個 內部 測試環境的 API Endpoint

現在 Hybrid Cloud 很常見,所以一定會遇到 Visibility 的問題。如果要強調 Visibility,方便內外部溝通,也可以直接把關鍵字考慮進去,像是:

  • {ServiceName}.api.{Env}.internal.rick.com: 某個內部服務的 API Endpoint
    • {ServiceName}.api.lab[1-N].internal.rick.com: 某個內部 lab1 環境的 API Endpoint

上述看起來是有點道理的舉例,但是回歸到架構設計基本概念:解決複雜性問題,還有 API Gateway 的初始原則 Single Entry Point,以這兩個概念來看,上述的設計就過度複雜。

  • api.rick.com: 產品對外 API Single Entry Endpoint
    • api.rick.com/{ServiceName}: ServiceName 的路徑
  • api.{Env}.rick.com: 某一個環境的 API Endpoint
    • api.sandbox.rick.com/{ServiceName}: 代表 開放 給客戶測試用的 API Endpoint
    • api.lab[1-N].rick.com/{ServiceName}: 代表某個 內部 測試環境的 API Endpoint

相關規劃請參考 API Gateway - Custom Domain Names


Using an API Gateway

底下簡報是研讀 Designing and Deploying Microservices 這本電子書的整理,書本是由 Nginx 提供,作者則是 microservices.io 的 Chris Richardson。同樣也是談論 API Gateway,看看不同角度的談法。


系列文章

一路上斷斷續續整理的一些實際應用與功能的學習筆記。


結論

我習慣 從使用中學習,簡言之,我在用什麼軟體、或者服務,我開發的東西就會出現他們的影子。

舉例來說:不管在開發什麼應用程式,當代後端服務經常會串接 3rd API,例如 Google Map APIs,用這些 API 時,通常都會有一組 access key and secret key,除了基本的 authentication / authorization 之外,很重要的就是 traffic control,大家開發應用程式過程中應該遇過的:API 單位時間的使用限制,像是每天的使用上限、每個月的額度,更甚者,會限制一秒只能 Invoke 幾次。

反過來,當你在開發 API 時給別人用的時候,特別是這個 API 是暴露在 Internet,那上線之後,就要考慮這些問題:

  • 要怎麼保護 API?
  • 保護機制應該放在哪裡?
  • 怎麼實作 api key 跟限流的關係?
  • 怎麼統計 api key 的使用狀況?

類似概念也可以參考: SRE CH27 - Reliable Product Launches at ScaleCH22: 處理連鎖故障 (Addressing Cascading Failures)

從使用別人的服務,學習如何讓自己的服務變強壯,我從 API Gateway 中學習如何讓公司的服務更穩健。

後記補充

有朋友不了為什麼我會把 架構可視性 (Visibility) 擺在第一個,因為要強調的是:

  1. 架構一開始的考量就是能上 Production,上 Production 意味著,要能夠清楚現況架構是什麼?使用角色有哪些?從哪裡發動?安全性的控管?怎麼監控?怎麼維運? …. 等。
  2. 知道 Production 架構怎麼一回事之後,往回推:測試環境、開發環境怎麼配置?怎麼規劃

我的思維是 Ops First, Then Dev,導入新技術的時候,先思考如何放到 Production、如何 Ops。這些都想清楚了,才不會開發的很過癮,但是無法上線,很難測試、有安全問題、開發過程的協作很痛苦。特別是很多的 Ops 的事情,一開始沒想到,就再也沒機會改進了。


延伸閱讀

站內延伸

參考資料

Service Mesh

Site Reliability Engineering 相關章節

更新紀錄

  • 2018/11/24: 解構 Amazon API Gateway 的介紹,Overview API Gateway 部分解構成獨立文章,增加 Designing and Deploying Microservices 的一篇學習筆記。
  • 2019/03/23: 重新整理 Endpoint Planning 一段

Comments