一、什麼是API Gateway

一個比較普遍的定義如下：

API閘道器是一個伺服器，是系統的唯一入口。從面向物件設計的角度看，它與外觀模式類似。API閘道器封裝了系統內部架構，為每個客戶端提供一個定製的API。

API閘道器方式的核心要點是，所有的客戶端和消費端都通過統一的閘道器接入微服務，在閘道器層處理所有的非業務功能。通常，閘道器也是提供REST/HTTP的訪問API。服務端通過API-GW註冊和管理服務。

從定義中可以歸納出一下幾個核心點：

1. 服務呼叫的統一入口
2. AuthN（Authentication is establishing the your identity.）
3. AuthZ （Authorization is establishing your privileges.）
4. 監控（請求延遲、異常數、審計日誌、訪問日誌）
5. 高可用
6. 白名單、黑名單
7. 限流
8. 熔斷
9. 服務發現
10. 協議支援
11. …

二、具體實現方案

先說RC（Replication Controller）是什麼？
RC保證在同一時間能夠執行指定數量的Pod副本，保證Pod總是可用。如果實際Pod數量比指定的多就結束掉多餘的，如果實際數量比指定的少就啟動缺少的。當Pod失敗、被刪除或被終結時RC會自動建立新的Pod來保證副本數量。所以即使只有一個Pod也應該使用RC來進行管理。

三、如何開發適合自己的API Gateway？

其實，這個問題也可以拓展為如何開發適應自己業務的某系統，個人感覺應該從以下幾點考慮：

1. 自己的業務系統需要什麼樣的功能？
2. 業界中該類系統都是如何實現的？
3. 自己的基礎設施情況（主要是PaaS及中介軟體）如何？
4. 綜合1、2考慮，在滿足業務需求的前提下，往遠了考慮，往簡單了實現（既滿足目前的功能，又方便以後拓展）。

回到API Gateway這個話題，那就需要考慮一下，自己的業務系統是否需要以上列出的所有功能點？如果不是或者目前不是，那我應該先實現哪一部分？

其中，作為一個Gateway，以下幾點應該是基礎功能：

1. 服務呼叫的統一入口
2. AuthN（Authentication is establishing the your identity.）
3. AuthZ （Authorization is establishing your privileges.）
4. 監控（請求延遲、異常數、審計日誌、訪問日誌）
5. 高可用

剩下的功能實現就要看業務需要及時間了。
如果系統本身的訪問量不大，那麼限流、熔斷是否就可以先不實現？

為什麼需要關注自己的基礎設施情況（主要是PaaS及中介軟體）？

比如基礎設施中已提供Kubernetes叢集服務，那麼毫無疑問的高可用方案，應該選擇RC方案。如果沒有Kubernetes叢集服務，那麼高可用就需要考慮別的方案了。

監控部分可以參考：《ELK+Prometheus 構建實時日誌 檢索 監控 告警平臺》

個人微信公眾號：