微服務基礎——厲害了！API網關

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

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

一、客戶端須要知道每一個服務的地址

二、每一個後端服務都須要實現認證、限流、日誌、監控、緩存等功能，重複造輪子大大下降了開發效率，而這些公共業務邏輯徹底能夠拆分出來

三、假如後端某些服務由以前的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網關接管了身份認證的功能，識別調用者信息，而且將其傳遞給後端服務。常見身份認證的方式有不少，這些方式關注的點是如何攜帶身份信息，以及如何對信息作加密，選擇這些認證方式的考量就是安全性和性能。下面分析幾種常見的身份驗證的方式：

一、HTTP基本認證(Basic Authentication)

就是將用戶名、密碼信息進行base64編碼，放在Authorization header中發送給網關，網關驗證用戶名密碼是否正確。

好處：調用簡單

不足：不夠安全，爲了防止密碼被泄露，通常使用https傳輸；須要調用遠端的用戶中心服務，查詢用戶信息，驗證用戶名密碼的正確性。

二、HMAC Authentication

客戶端將請求信息（包含用戶名，不包含密碼）與密碼作HMAC，生成一串散列值（簽名信息），傳給網關。網關經過用戶名獲取密碼，再和收到的請求信息作HMAC，生成簽名信息，並與客戶端的簽名信息進行比對，一致則驗證經過。

好處：安全，客戶端無需傳密碼至網關，同時經過簽名的方式防止了請求信息被篡改。

不足：須要調用遠端的用戶中心服務，查詢用戶密碼等信息；客戶端每次調用前還須要生成簽名信息，致使調用不太方便。

基於HMAC Authentication的簽名認證算法有不少，如AWS、京東雲、阿里雲API網關的基於AK,SK的簽名算法，就是在HMAC Authentication上改進的。

三、JWT Authentication

JSON Web Token（JWT）也是一種經常使用的身份驗證和簽名算法，客戶端請求登陸的時候攜帶用戶名密碼請求用戶中心服務器，獲取token（不包含密碼）保存到客戶端，客戶端攜帶token調用網關時，網關解析token，經過公鑰驗證token的正確性，獲取用戶信息。

好處：安全性高，調用簡單，網關無需訪問用戶中心服務

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

訪問控制（受權）

不少狀況下，咱們並不但願全部的用戶都能訪問咱們的接口，或者只但願某些用戶訪問到部份內容，那麼使用訪問受權就能實現。網關在API或API分組級別上對用戶的調用作控制，限制用戶訪問某些分組或者API，經常使用的訪問控制組件有ACL。更爲高級的訪問控制功能能夠參考各大雲廠商的訪問控制組件，好比AWS的IAM以及阿里雲的RAM。

一、訪問控制列表(ACL)

ACL是將一組白名單用戶或一組黑名單用戶關聯到具體的API分組或者API，當請求通過網關時，網關會驗證調用者是否爲白名單或者黑名單用戶，以此判斷是否容許或拒絕請求。

二、IAM

訪問控制（Identity and Access Management， IAM）是針對子用戶進行的權限管理，能夠提供更精細化的權限控制。IAM的特色是使用一組策略來定義權限，策略包含接口名稱，資源（參數），權限類型，這樣就將權限控制在資源（參數）層級。

限流

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

一、限流算法

簡單計數法、令牌桶、漏桶等是常見的限流算法，簡單計數法的特色是統計某一段時間內的請求個數，以此判斷是否拒絕請求，這種簡單粗暴的限流方式沒法應對突發流量；令牌桶算法的特色是，以固定速率往桶裏添加令牌，經過桶裏是否有令牌判斷是否拒絕請求，桶的大小決定了突發流量的大小。漏桶的思想和令牌桶相反，以固定的速率分發請求，實現流量的平滑處理。所以，當咱們徹底不關心流量突發的狀況，選擇簡單計數法便可，當咱們沒法容忍流量突發，則選擇漏桶算法，當咱們容許必定程度的流量突發，選擇令牌桶算法。

二、單機限流

單擊限流，調用數存儲在本地，無需頻繁的和遠端節點交互，性能比較高。

三、分佈式限流

分佈式限流，調用數存儲在遠端節點，如redis。每次須要和遠端節點交互，性能較低。那爲啥還要使用分佈式限流呢？由於有些場景下（特別是API網關），限流值是用戶配置的，須要保證限流的準確性。咱們有個折中的方案，先在本機存儲少許的調用數，而後同步到遠端節點，這樣就成倍的減小了調用遠端的次數，雖然準確性有所下降，可是在可接受的範圍。

安全

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

一、IP限制

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

二、WAF

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

日誌

API網關接管了全部的入口流量，包含豐富的調用日誌，因此利用好網關的日誌，可以爲後端服務作不少事情。API網關的日誌一般包括access日誌，error日誌，審計日誌等。access日誌經過會記錄Trace_id標識一個請求的完整鏈路、請求總耗時、網關耗時、請求方式、請求體大小、響應體大小、響應狀態碼、用戶標識、API分組標識、API標識、請求是否到後端等。審計日誌更完整，除了記錄access日誌包含的內容，還記錄請求參數，響應參數，用戶信息等具體內容。下面簡單羅列API網關日誌能夠作什麼？

一、簡單的日誌查詢。 二、將指定API分組的日誌輸入到指定文件、http/https後端、TCP後端、UDP後端、kafka等多個位置，供API提供者作進一步處理。 三、將指定API分組的日誌輸入到DataDog、Prometheus、ZipKin等服務，提供日誌統計、分析、監控的功能。 四、接入計費功能，按調用次數、輸入輸出流量統一計費。

監控

監控平臺是API網關針對API和API分組作統一監控告警，API提供者經過平臺配置告警規則，查看實時的監控數據，包括QPS、成功失敗次數分佈、響應狀態分佈、響應時間分佈、用戶調用次數分佈、流量分佈等。正如日誌部分介紹的，若是API提供者須要定製更多的監控功能，能夠將日誌輸入到Prometheus，而後作進一步處理。

API市場

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

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

點擊【閱讀】可瞭解京東雲API網關服務

歡迎點擊「京東雲」瞭解更多精彩內容