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)
  • 重新處理錯誤資訊
  • 解構單體，邁向微服務化
  • Backend for Frontend (BFF)、GraphQL

架構的可視性

規劃上，首要考量的是整體系統架構的 可視性 (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

Updated 2019/06/23: Which API Gateway to choose?

替代方案

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 Scale、CH22: 處理連鎖故障 (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

2018/01/24 14:35:00
Table of Content
Categories
Tags

About

  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學

    • 著作

  • 個人著作：SRE實踐與開發平台指南
  • 共同著作：軟體測試實務 (2023)
  • 譯著：分散式系統設計 (2019)

    • 演講

  • 演講錄影 @ Youtube
  • 探索職涯、複利人生 - AWS Career Exploration Day 2023
  • 個人著作 SRE 書友見面會
  • 軟體測試實務 - 新書發表會
  • 探索職涯、成就未來 - AWS Career Exploration Day 2022
  • 從理想、到現實的距離，開啟品味軟體測試之路
  • 91APP 在 AWS 上的 SRE 實踐之路
  • 在矩陣型組織裡，如何有效管理 AWS 的成本結構與系統架構
  • 災難演練 @ AWS 實戰分享
  • 導讀持續交付 2.0 - 談當代軟體交付之虛實融合
  • 聊聊軟體交付的濫觴 談產出物管理
  • 從緊急事件 談 SRE 應變能力的培養
  • 邁向 API 經濟 - API Gateway 導入之旅
  • Monitoring Tools 大亂鬥 - AWS CloudWatch
  • Ops as Code using Serverless
  • 淺談系統監控與 CloudWatch 的應用

    • Facebook

    Complete Think

    AWS Certifications

  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
    • ▲ TOP ▲