微服務基礎——厲害了！API閘道器

微服務剛剛誕生的時候，人們將服務進行拆分，實現服務之間的松耦合，並且每個服務有專門的團隊維護，然後客戶端直接和各個子服務進行互動。比如，訂單，商品，會員服務。

那麼這種客戶端直接和後端服務互動的方式會有什麼問題呢？

1、客戶端需要知道每個服務的地址

2、每個後端服務都需要實現認證、限流、日誌、監控、快取等功能，重複造輪子大大降低了開發效率，而這些公共業務邏輯完全可以拆分出來

3、假如後端某些服務由之前的http/https呼叫變成rpc呼叫，或者某些引數發生改變，則客戶端需要做很大調整。

後來人們為了解決這些問題，引入 API閘道器。

當引入API閘道器後，API閘道器接管了所有的入口流量，就像nginx，將請求路由到對應的後端服務。這樣客戶端無需關心後端服務地址，只需呼叫閘道器即可。不僅如此，閘道器還針對這些流量做了功能的擴充套件，包括鑑權、限流、日誌監控、告警、訪問控制、協議轉換等功能，這樣後端服務只需關注自身的業務邏輯。

我們可以將API閘道器的部分功能做一個簡單的梳理。

註冊API

API閘道器要給後端服務賦能，就需要後端服務（API提供者）將API資訊註冊到閘道器，並且為每個API配置後端服務的地址。但是，這樣遇到的問題是，API之間是獨立的，無法將服務於同一功能的API組織起來，統一管理。為了適應真實的服務場景，API閘道器使用API分組來管理一組API，並配置同一後端，使用者（API提供者）不僅可以管理API也可以管理API分組。

下圖參考了京東雲的API閘道器

當呼叫者（API呼叫者）發起呼叫時，閘道器先判斷請求來自哪個分組，最後判斷請求來自哪個API，如果API提供者對分組新增能力，比如限流，那麼這個限流功能只針對分組生效。

身份認證

基本上每個元件都關聯了使用者資訊，需要識別使用者身份。因此API閘道器接管了身份認證的功能，識別呼叫者資訊，並且將其傳遞給後端服務。常見身份認證的方式有很多，這些方式關注的點是如何攜帶身份資訊，以及如何對資訊做加密，選擇這些認證方式的考量就是安全性和效能。下面分析幾種常見的身份驗證的方式：

1、 HTTP基本認證(Basic Authentication)

就是將使用者名稱、密碼資訊進行base64編碼，放在Authorization header中傳送給閘道器，閘道器驗證使用者名稱密碼是否正確。

好處 ：呼叫簡單

不足 ：不夠安全，為了防止密碼被洩露，一般使用https傳輸；需要呼叫遠端的使用者中心服務，查詢使用者資訊，驗證使用者名稱密碼的正確性。

2、 HMAC Authentication

客戶端將請求資訊（包含使用者名稱，不包含密碼）與密碼做HMAC，生成一串雜湊值（簽名資訊），傳給閘道器。閘道器透過使用者名稱獲取密碼，再和收到的請求資訊做HMAC，生成簽名資訊，並與客戶端的簽名資訊進行比對，一致則驗證透過。

好處 ：安全，客戶端無需傳密碼至閘道器，同時透過簽名的方式防止了請求資訊被篡改。

不足 ：需要呼叫遠端的使用者中心服務，查詢使用者密碼等資訊；客戶端每次呼叫前還需要生成簽名資訊，導致呼叫不太方便。

基於HMAC Authentication的簽名認證演算法有很多，如AWS、京東雲、阿里雲API閘道器的基於AK,SK的簽名演算法，就是在HMAC Authentication上改進的。

3、 JWT Authentication

JSON Web Token（JWT）也是一種常用的身份驗證和簽名演算法，客戶端請求登入的時候攜帶使用者名稱密碼請求使用者中心伺服器，獲取token（不包含密碼）儲存到客戶端，客戶端攜帶token呼叫閘道器時，閘道器解析token，透過公鑰驗證token的正確性，獲取使用者資訊。

好處 ：安全性高，呼叫簡單，閘道器無需訪問使用者中心服務

不足 ：非對稱加密，消耗計算資源

訪問控制（授權）

很多情況下，我們並不希望所有的使用者都能訪問我們的介面，或者只希望某些使用者訪問到部分內容，那麼使用訪問授權就能實現。閘道器在API或API分組級別上對使用者的呼叫做控制，限制使用者訪問某些分組或者API，常用的訪問控制元件有ACL。更為高階的訪問控制功能可以參考各大雲廠商的訪問控制元件，比如AWS的IAM以及阿里雲的RAM。

1、 訪問控制列表(ACL)

ACL是將一組白名單使用者或一組黑名單使用者關聯到具體的API分組或者API，當請求經過閘道器時，閘道器會驗證呼叫者是否為白名單或者黑名單使用者，以此判斷是否允許或拒絕請求。

2、 IAM

訪問控制（Identity and Access Management， IAM）是針對子使用者進行的許可權管理，可以提供更精細化的許可權控制。IAM的特點是使用一組策略來定義許可權，策略包含介面名稱，資源（引數），許可權型別，這樣就將許可權控制在資源（引數）層級。

限流

對於經常出現流量突增的系統，比如618，雙11大促、微博出現重大新聞事件等，我們很難及時的評估流量，做好應對預案，最終導致服務整個不可用。因此做好限流就十分有必要了，當流量突增超過限流閾值時，透過限流降級策略保護核心業務的正常運轉。選擇限流方案，主要考慮使用什麼樣的限流演算法，單擊限流還是分散式限流。

1、 限流演算法

簡單計數法、令牌桶、漏桶等是常見的限流演算法，簡單計數法的特點是統計某一段時間內的請求個數，以此判斷是否拒絕請求，這種簡單粗暴的限流方式無法應對突發流量；令牌桶演算法的特點是，以固定速率往桶裡新增令牌，透過桶裡是否有令牌判斷是否拒絕請求，桶的大小決定了突發流量的大小。漏桶的思想和令牌桶相反，以固定的速率分發請求，實現流量的平滑處理。因此，當我們完全不關心流量突發的情況，選擇簡單計數法即可，當我們無法容忍流量突發，則選擇漏桶演算法，當我們允許一定程度的流量突發，選擇令牌桶演算法。

2、 單機限流

單擊限流，呼叫數儲存在本地，無需頻繁的和遠端節點互動，效能比較高。

3、 分散式限流

分散式限流，呼叫數儲存在遠端節點，如redis。每次需要和遠端節點互動，效能較低。那為啥還要使用分散式限流呢？因為有些場景下（特別是API閘道器），限流值是使用者配置的，需要保證限流的準確性。我們有個折中的方案，先在本機儲存少量的呼叫數，然後同步到遠端節點，這樣就成倍的減少了呼叫遠端的次數，雖然準確性有所降低，但是在可接受的範圍。

安全

安全是API閘道器不可或缺的功能，身份驗證、訪問授權，限流等一定程度上也算是保障後端服務的安全穩定，但是這些遠遠不夠用。API閘道器的安全防範功能還包括IP限制、waf等。

1、IP限制

主要是透過IP白名單和黑名單列表，允許和拒絕某些IP訪問後端服務

2、WAF

網站應用級入侵防禦系統（Web Application Firewal， WAF），是透過安全策略，更細粒度的驗證請求的合法性，從而為後端服務應用級安全性提供保障。

日誌

API閘道器接管了所有的入口流量，包含豐富的呼叫日誌，所以利用好閘道器的日誌，能夠為後端服務做很多事情。API閘道器的日誌通常包括access日誌，error日誌，審計日誌等。access日誌透過會記錄Trace_id標識一個請求的完整鏈路、請求總耗時、閘道器耗時、請求方式、請求體大小、響應體大小、響應狀態碼、使用者標識、API分組標識、API標識、請求是否到後端等。審計日誌更完整，除了記錄access日誌包含的內容，還記錄請求引數，響應引數，使用者資訊等具體內容。下面簡單羅列API閘道器日誌可以做什麼？

1、簡單的日誌查詢。
2、將指定API分組的日誌輸入到指定檔案、http/https後端、TCP後端、UDP後端、kafka等多個位置，供API提供者做進一步處理。
3、將指定API分組的日誌輸入到DataDog、Prometheus、ZipKin等服務，提供日誌統計、分析、監控的功能。
4、接入計費功能，按呼叫次數、輸入輸出流量統一計費。

監控

監控平臺是API閘道器針對API和API分組做統一監控告警，API提供者透過平臺配置告警規則，檢視實時的監控資料，包括QPS、成功失敗次數分佈、響應狀態分佈、響應時間分佈、使用者呼叫次數分佈、流量分佈等。正如日誌部分介紹的，如果API提供者需要定製更多的監控功能，可以將日誌輸入到Prometheus，然後做進一步處理。

API市場

API市場是實現API商業化的有效途徑，API閘道器將API上架到API市場供其他使用者購買使用，並根據呼叫次數或者流量計算費用，最終幫助API提供者獲利。

當然，API閘道器的功能遠遠不止這些，還包括引數校驗、引數轉換、協議轉換、請求體響應體大小限制、請求跨域訪問限制、mock服務、serverless、後端路由、服務發現、快取、容錯降級、金絲雀釋出、藍綠部署等。總之， API閘道器為後端服務提供更好的體驗和保障的同時，也大大縮短了API的上線週期，方便API的運營維護，最終還能實現API的商業化，價值非常之大，意義非常之深遠。