京東API網(wǎng)關實踐之路！

京東作為電商平臺，近幾年用戶、業(yè)務持續(xù)增長，訪問量持續(xù)上升，隨著這些業(yè)務的發(fā)展，API網(wǎng)關應運而生。

API網(wǎng)關，就是為了解放客戶端與服務端而存在的。對于客戶端，使開放給客戶端的接口標準統(tǒng)一，以降低客戶端的接入成本；對于服務端，使服務端無需關注接口暴露在公網(wǎng)面臨的問題而著眼于業(yè)務的實現(xiàn)，來提升開發(fā)效率。

在剛剛過去的全民狂歡購物節(jié)，API網(wǎng)關如何做才能高效的處理近千萬的并發(fā)請求是本文的重點。

API網(wǎng)關，作為客戶端與服務端的紐帶，核心任務是將客戶端請求轉(zhuǎn)發(fā)到后端服務。但是，作為所有流量請求的入口 , 面臨的很重要的一個問題就是高并發(fā)，因為高并發(fā)的需要，要求網(wǎng)關處理請求必須高效；其次是安全防護，安全主要是指對網(wǎng)關對后端服務的一個保護；再者就是完善的數(shù)據(jù)統(tǒng)計及監(jiān)控報警機制；當然，為了方便我們內(nèi)部用戶接入，多協(xié)議適配的支持、灰度發(fā)布上線也是必備功能。

API網(wǎng)關特征：

1）高性能：在高吞吐量下保證低延遲。

2）安全穩(wěn)定：身份認證、精細化流量控制、大數(shù)據(jù)實時分析等多種手段保障服務質(zhì)量。

3）平臺化：進行各項數(shù)據(jù)監(jiān)控，提供數(shù)據(jù)分析、監(jiān)控告警、故障定位等服務。

4）灰度：灰度發(fā)布，支持按設備、PIN、自定義比例方式在不影響正常用戶的情況下，保障后端服務平穩(wěn)過渡。

5）方便快捷：支持http、jsf服務快捷接入，mock功能加快協(xié)同開發(fā)。

API網(wǎng)關服務于原生客戶端、Web、小程序，不限于具體的業(yè)務。其主要架構圖如下所示：

主要分3層：

• 第1是VIP層，主要是接收客戶端http、https請求，并將請求轉(zhuǎn)發(fā)到網(wǎng)關；
• 第2是網(wǎng)關層，對請求進行合法性校驗并轉(zhuǎn)發(fā)；
• 第3層就是后端業(yè)務API，這些業(yè)務方，就是我們服務的主要對象。

網(wǎng)關高并發(fā)實踐主要利用異步化處理技術，將請求由同步變?yōu)楫惒?，利用NIO多路復用，達到請求接收最大化。

首先看下圖同步處理過程：

采用同步處理，線程的釋放就受限于后端服務響應的快慢。當響應過慢時，線程池就容易出現(xiàn)耗盡現(xiàn)象，并且資源利用率上不去，吞吐量很低，或者說此時的大量請求都會被服務器拒絕。

由此可以看出，同步處理使資源利用率得不到充分的利用，大量請求被拒絕同時又影響了用戶體驗。如果想提高并發(fā)只能通過橫向加機器，這樣造成機器資源大量浪費的現(xiàn)象。如果是網(wǎng)關這么處理，那么這種現(xiàn)象體現(xiàn)的將更明顯。

為了解決同步引起的問題，采用異步，如下圖所示：

通過實現(xiàn)異步化處理，線程可以在開啟異步后直接釋放，當前請求的響應會被延后，當后端服務有響應后，再將響應寫回給客戶端。這樣就算是有后端服務響應很慢，因為線程已被釋放了，可以繼續(xù)接收新的請求，達到服務資源使用的最大化。

精細化流控：

作為所有業(yè)務方的第一道防線，網(wǎng)關承載著海量流量的訪問，以及隨時可能爆發(fā)的惡意流量攻擊的壓力。

很典型的，每年雙十一或是618都會有刷子惡意刷后端服務接口，如果網(wǎng)關不做處理直接將流量透傳到后端服務，后端服務很大可能會被瞬時流量沖垮，至少會增大后端服務響應延時及浪費公司大量資源來處理攻擊。

那么，進行流量控制就是必不可少的。網(wǎng)關提供秒級的流量控制，可以對單個接口按地域、風控等級等維度進行流控配置。這樣流量只到了網(wǎng)關層面，就不會透傳到后端服務了。

流控主要是采用令牌桶算法實現(xiàn)，策略主要有排隊或熔斷，具體的策略根據(jù)不同的端，選擇合適的流控動作。

授權及簽名認證：

API暴露在公網(wǎng)，肯定會存在被刷的風險，網(wǎng)關要做的就是盡可能降低這種風險。就像通過制定法律來盡可能減少犯罪一樣，通過訪問權限控制、簽名認證、跨域校驗等來盡可能的降低API接口被刷的風險。

授權：只有通過API負責人授權的接口，客戶端才有權限訪問 。如果未授權，在網(wǎng)關處攔截，響應給客戶端沒有訪問權限；

簽名認證：按規(guī)則將請求參數(shù)通過HMAC-SHA256算法運算生成簽名值，對客戶端計算的簽名值與網(wǎng)關計算的簽名值進行匹配，匹配的請求繼續(xù)向下流轉(zhuǎn)，否則直接被攔截。

跨域效驗：

對于WEB端應用，調(diào)用網(wǎng)關屬于跨域請求。這類請求，如果不進行校驗，會產(chǎn)生跨域攻擊。所以需要獲取到客戶端請求來源，對客戶端請求來源進行認證，只有合法的請求來源才被允許訪問后端服務。對于小程序應用，也會校驗小程序真實性。

設想這樣一個場景：有一個核心業(yè)務，做了比較大的改動，又或者是項目重構，開發(fā)完成，同時測試完成，要上線了。但是，問題也來了：因為改動很大，業(yè)務很重要，測試所拿機型設備有限，擔心直接全部上線會影響測試未覆蓋的線上用戶。那么，能不能先有10%的流量請求到新服務，看下用戶使用情況，再決定是否全部上線呢。

為了滿足這種需求，網(wǎng)關提供按設備號、用戶標識的定點灰度測試，同時支持按比例進行的灰度上線。

用戶請求到網(wǎng)關，如果開啟灰度模式，就獲取到灰度地址，將請求轉(zhuǎn)發(fā)到特定的服務。

在高舉可持續(xù)發(fā)展旗幟的時代下，如果一個產(chǎn)品僅僅做到功能齊全是遠遠不夠的。只有做到可持續(xù)發(fā)展，實現(xiàn)自動化運營的產(chǎn)品才真正是個好產(chǎn)品。API網(wǎng)關平臺化意味著N條產(chǎn)品線，一個網(wǎng)關，通過實現(xiàn)自動化運營，解放生產(chǎn)力，打造統(tǒng)一化平臺，提供可持續(xù)化產(chǎn)品，擁抱API經(jīng)濟，實現(xiàn)API變現(xiàn)。

API網(wǎng)關控制臺首頁

  API網(wǎng)關統(tǒng)一管理著發(fā)布方對外暴露的API服務，各個服務可以獨立開發(fā)部署。針對后端服務的發(fā)布與下線，發(fā)布方可通過API網(wǎng)關提供界面化管理控制平臺，實現(xiàn)流程化管理，線上審批通過后，實時生效，無需手動控制，實現(xiàn)自動化運營。

同時對于后端服務的各項配置，如API權限管理、流量控制等，API網(wǎng)關進行自動化管理，動態(tài)配置，動態(tài)加載，保證在無需重啟服務的情況下即可進行配置更改操作。

要實現(xiàn)自動化運營，除了對API服務管理做到獨立部署、快速擴展外，對于API的調(diào)用方也實現(xiàn)自助API開通，授權訪問API服務。

由于API網(wǎng)關處在一個內(nèi)部系統(tǒng)與外部環(huán)境的分界點處，所有外部請求都經(jīng)過API網(wǎng)關進行調(diào)度和過濾，每時每刻都有大量請求通過API網(wǎng)關進入內(nèi)部服務。因此可以在API網(wǎng)關層進行請求接入監(jiān)控，監(jiān)控各個接口的訪問請求并進行收集，以便相應指標的統(tǒng)計分析。

在API網(wǎng)關界面化管理控制平臺中，對收集統(tǒng)計到的監(jiān)控數(shù)據(jù)，如API接口調(diào)用量、響應時間等信息，提供了可視化的API實時智能數(shù)據(jù)分析與監(jiān)控告警功能，訂閱API異常報警信息，以便實時監(jiān)控后端服務運行情況。

后端接口監(jiān)控數(shù)據(jù)圖

當發(fā)生線上故障時，API網(wǎng)關提供一系列的故障現(xiàn)場還原措施進行故障的定位與排查，通過日志實時分析、異常流量實時探測、監(jiān)控告警等技術，快速拿到故障快照、還原故障現(xiàn)場以及迅速定位問題原因。

作為系統(tǒng)的唯一入口，API網(wǎng)關的地位是至關重要的。API網(wǎng)關位于技術中臺的核心要塞，符合技術中臺戰(zhàn)略發(fā)展方向，做到了產(chǎn)品組件化、需求結構化、數(shù)據(jù)配置化、業(yè)務可視化：

對于基于微服務架構實現(xiàn)的后端服務而言，接入一個性能高效、安全穩(wěn)定的API網(wǎng)關，享受其帶來的身份認證、路由請求、協(xié)議轉(zhuǎn)換等便利，更加專注于自身業(yè)務邏輯的開發(fā)，是有必要的。利用API網(wǎng)關對各個服務API進行統(tǒng)一的管理和監(jiān)控，解決客戶端與后端服務交互不便的問題，具有十分重要的意義。

特別推薦一個分享架構+算法的優(yōu)質(zhì)內(nèi)容，還沒關注的小伙伴，可以長按關注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝