“京東開放服務平臺是京東對外開發(fā)的窗口，每年的 618 大促，京東的網(wǎng)關都要承載十億級的調(diào)用量來保障幾十萬商家穩(wěn)定使用的使命。

在保證近千個不同類型服務接口的海量調(diào)用的同時，我們還要確保服務接口之間的互不干擾，并且能夠快速響應任何復雜情況，因此穩(wěn)定、快速是我們一直追求的目標。

[[209075]]

今年的 618 大促，京東的網(wǎng)關承載了幾十億的流量和調(diào)用，在這種情況下，網(wǎng)關系統(tǒng)必須保證整個系統(tǒng)的穩(wěn)定性和高可用，保證高性能和可靠性，以支撐業(yè)務。

我們面臨的是一個非常復雜的問題，基于這種復雜問題，怎樣做到很好地提高它的性能和穩(wěn)定性，復雜技術之間怎么整合保證整體網(wǎng)關的高可用，是本文的重點。

網(wǎng)關涵蓋技術

網(wǎng)關系統(tǒng)

網(wǎng)關系統(tǒng)主要有兩種：

• 客戶端網(wǎng)關，主要用來接收一些客戶端的請求，也就是 APP 的服務端。
• 開放網(wǎng)關，主要是公司(比如京東)對于第三方合作伙伴提供接口。

這兩種不同網(wǎng)關所使用的技術非常類似。

流量比較大的網(wǎng)關面臨的難點包括：

• 網(wǎng)關系統(tǒng)需要扛幾十億的流量調(diào)用，接口的平穩(wěn)運行、每一個接口在后端服務之后的性能耗損都非常重要。

比如我們使用了一個 Redis 集群，然后構建了兩個機房，每一個機房都搭建了一個 Redis 集群，這樣的話就能夠很好地保證高可用。

在面對一個瞬間流量的時候，我們采用了一些緩存技術，或者更前置的 Nginx+lua+Redis 技術，讓這種大流量應用能夠脫離開 JVM 的依賴。

還有我們需要梳理各個接口，通過降級的策略把一些弱依賴的接口進行降級，從而保證核心應用的可用。

網(wǎng)關系統(tǒng)其實就是一個把 HTTP 請求拓展到后端服務的過程。

我們的網(wǎng)關承接了一千以上的后端服務接口，面對這種情況，怎樣做到服務與服務之間相互不影響?架構層面怎樣能夠杜絕蝴蝶效應、防止雪崩?

就是說當一個接口出現(xiàn)問題的時候，不至于影響到其他接口的健康運行。這個說起來簡單，但實際卻不然。

一千個以上的接口，每個接口性能都不一致，而且每個接口所依賴的外部資源、數(shù)據(jù)庫緩存等都不一樣，幾乎每天都會出現(xiàn)各種各樣的問題，我們怎樣通過一些隔離技術、治理技術等，保證當這些接口出現(xiàn)問題的時候，不會影響到全局?

• 我們對外暴露了一千個服務接口，所有接口的后面意味著幾十個甚至上百個團隊每天在不停地開發(fā)，每天都可能上線新的需求。

面對這么復雜的情況，我們不可能每次后端服務器有任何修改，都需要有網(wǎng)關的修改或上線，這樣網(wǎng)關會變得非常脆弱，穩(wěn)定性極低。

我們采用了一個動態(tài)接入的技術，讓后端的網(wǎng)關能夠通過一種接入的協(xié)議進行無縫接入，之后通過一些動態(tài)代理的方式，直接讓后端的接口，不管做任何修改或上線，都可以通過后端管理平臺從網(wǎng)關上對外進行透傳發(fā)布。

這樣就很好地解決了網(wǎng)關所面臨的依賴于后端接口服務的上線問題。

網(wǎng)關涵蓋技術

網(wǎng)關的四個技術方向：

• 統(tǒng)一接入，就是前端(包括 APP 或其他來源)的流量，都能在統(tǒng)一網(wǎng)絡層進行接入。

這一層所面臨的問題是：高性能透傳、高并發(fā)接入、高可效性，以及當前端流量來了之后，怎樣能夠進行一個負載的服務往后端的轉發(fā)。

• 流量管控，主要指流量治理部分。面對海量流量，我們怎樣通過一些防刷技術，保障網(wǎng)關不被大流量沖垮;以及怎樣通過一些像限流、降級、熔斷等技術，對網(wǎng)關進行全方位保護。
• 協(xié)議適配，就是前文提到的，網(wǎng)關會透傳后端上千個服務，而這些服務一定不是每一個都需要網(wǎng)關去開發(fā)配置的。

我們通過一個協(xié)議適配的轉換，讓后端的各種服務通過我們指定的協(xié)議、通過 HTTP 的方式從網(wǎng)關開放出去，當然網(wǎng)關不單單是 HTTP 協(xié)議，還有一些 TCP 的。

京東內(nèi)部的協(xié)議相對比較統(tǒng)一，有 HTTP 的 restful 的協(xié)議，也有 JSF 的接口，JSF 是京東內(nèi)部自研的一個框架，一個 RPC 調(diào)用框架，和 Double 是類似的，然后基于注冊發(fā)現(xiàn)的一個 RPC 框架。

• 安全防護，這一部分對于網(wǎng)絡來說非常重要，因為網(wǎng)關是整個公司對外的一個出口，在這一層我們要做一些防刷。

比如防清洗一些惡意流量、做一些黑名單，當有一些惡意流量的話，通過限制 IP 等限制手段把它拒絕在整個網(wǎng)關之外，防止這些惡意流量把網(wǎng)關沖垮。

自研網(wǎng)關架構

自研網(wǎng)關架構

我們的自研網(wǎng)關架構主要分為三層：

接入層

主要負責一些長短鏈接的接入、限流、黑白名單、路由、負載均衡、容災切換等。這一層所采用的技術是 Nginx+lua 的方式。

分發(fā)層

這一層是分發(fā)層或者叫網(wǎng)關的業(yè)務層，它更多的是 NIO+Serviet3 異步的技術。

在這一層中又分為幾個部分：

• 最上層部分是數(shù)據(jù)校驗，在這一層會做一些簽名的校驗、時間的校驗、版本、方法等。
• 下面一層叫泛化調(diào)用層，主要是把網(wǎng)關對外暴露的 restful 請求轉換成京東內(nèi)部的協(xié)議，進行一個動態(tài)適配調(diào)用的過程。

這一塊我們更多使用的是一些緩存的技術，線程隔離、熔斷等技術也都是在這一層實現(xiàn)的。

因為有大量數(shù)據(jù)和協(xié)議的轉換，所以這一層用了多使用緩存的技術，我們網(wǎng)關層所有的數(shù)據(jù)都不會直接穿透到 DB，而是采用一個叫異構數(shù)據(jù)的方式直接用緩存去做的。

泛化層中間有兩塊：

• 主動通知，就是我們會通過這種 TCP 的下行通道及時通知到客戶端，發(fā)一些像京東賬戶優(yōu)惠券或提醒等。
• 沙箱測試，主要是在一些接口發(fā)布上線之前，進行一個外部的測試。

如上圖，最右側部分是服務降級、日志記錄、監(jiān)控告警，這三個都是我們整個網(wǎng)關的支撐系統(tǒng)。

服務降級是說當有些服務出現(xiàn)問題，第一時間把它降調(diào);日志是給我們排查問題用的。

監(jiān)控告警在下文會重點介紹，因為一個網(wǎng)關的可用性很大方面是通過監(jiān)控系統(tǒng)來完善的，沒有監(jiān)控系統(tǒng)、沒有告警，就像沒有眼睛一樣，沒辦法知道任何事。

后端各種各樣的業(yè)務 API

這些業(yè)務 API(業(yè)務接口)通過網(wǎng)關對外進行暴露。整個網(wǎng)關大體上分為如上圖的三層，最上面是接入層、中間是網(wǎng)關的分發(fā)層，以及業(yè)務校驗、業(yè)務邏輯層，然后通過網(wǎng)關透傳請求到后端服務。

除了這三層之外，我們再看兩邊的系統(tǒng)，都是我們整個網(wǎng)關比較核心和重要的支撐：

• 網(wǎng)關注冊中心，后端各種各樣的接口可以通過網(wǎng)關注冊中心對外進行發(fā)布，這個系統(tǒng)有一個類似的管理界面，只要后端的 API 服務按照固有的協(xié)議進行一個編寫。
• 如果格式 OK 的話上傳到管理后臺，一鍵就可以發(fā)布到線上。當然接口發(fā)布之前會有一個測試。
• OA 鑒權中心，這一塊主要是做鑒權用的，像數(shù)據(jù)校驗層的很多簽名的校驗等安全校驗都是在這一層統(tǒng)一做的。

技術棧

我們的網(wǎng)關系統(tǒng)所涉及到的一些技術棧：

• 接入層 Nginx+lua 技術。
• NIO+Serviet3 異步技術。
• 分離技術。
• 降級限流。
• 熔斷技術。
• 緩存，哪些地方該加緩存，哪些地方可以直接讀庫。
• 異構數(shù)據(jù)。
• 快速失敗。
• 監(jiān)控統(tǒng)計，這是整個高可用網(wǎng)關系統(tǒng)里非常重要的一部分。

下文會針對這些技術所適用的場景進行深入探討和分析，包括我們用這些技術解決什么問題。

基本思路及過程改進點

Nginx 層統(tǒng)一接入

先看網(wǎng)關整個線上的部署架構，通過一個軟負載 LVS 進入到整個京東的網(wǎng)關，第一層是核心 Nginx，經(jīng)過核心 Nginx 之后就是后面的業(yè)務 Nginx，然后通過業(yè)務 Nginx 把我們的請求透傳到后端的服務器。

核心 Nginx 主要是前端流量的分配，比如限流、防刷都是在這層去做。下層是業(yè)務 Nginx，主要的 Nginx+lua 的邏輯在這一層實現(xiàn)。

這一層還有能減輕核心 Nginx 壓力、CPU 壓力的作用，而且一些 lua 的應用邏輯，比如限流、防刷、鑒權、降級都是在這一層做的。

為什么要加上 Nginx+lua 這一層?相較于 Tomcat 等，Nginx 是一個能扛特別大并發(fā)流量的服務器。

基于這種狀況，我們之前出現(xiàn)過問題，當這種并發(fā)流量特別大的時候，一旦后面出現(xiàn)單機有問題，哪怕你針對這個接口做了降級，但真正流量還是到了 Tomcat 層的 JVM 里。

當流量很大的時候，很難通過 JVM 能夠消化掉，這樣導致的結果是：當你的 Tomcat 出現(xiàn)問題了，你很難通過重啟去解決這個問題。

因為流量會一直存在，這臺 Tomcat 出問題了， 重啟完之后是把所有行動都釋放了，但是它們就像病毒一樣，會來回傳染，你重啟了一批，這批馬上又被傳染到。

Nginx 天然就是這種 NIO 異步的方式，能夠非常好地支持大并發(fā)的業(yè)務需求。所以我們把一些核心的，比如降級、流控等，都放在這一層，讓它替我們在最前端把流量防住。

引入 NIO、利用 Servlet3 異步化

第二個實踐是在 Tomcat 層引入了 NIO，用了一個 JDK7+TOMCAT7+Servlet3 的配置，讓同步請求變得異步化，然后利用 NIO 的多路復用處理技術，讓我們能夠同時處理更高的并發(fā)數(shù)。

利用 Servlet3 異步化之后可以提升吞吐量，但單個請求的響應時間會略微變長，不過這種損耗是可以忍受的，因為這會帶來整個應用吞吐量的增加和靈活性的增強，還是非常值得我們使用的。

具體采用策略：

• 業(yè)務方法開啟異步化上下文 AsynContext。
• 釋放 Tomcat 當前處理線程。
• Tomcat 該線程被釋放，然后用于下次請求的處理，提高其吞吐量。
• 在 AsynContext 環(huán)境中完成業(yè)務方法的處理，調(diào)用其 complete 方法，將響應寫回響應流。

這樣可以提高 Tomcat 業(yè)務邏輯的可能性，讓我們在這一層非常少的線程數(shù)就能處理更多的請求，而不至于當流量非常大的時候被壓垮。

分離之術

在所有分離技術中，我挑兩個比較重要的點進行分享。

請求解析和業(yè)務處理分離

第一個是通過 NIO 的方式，把請求解析的線程和后面處理的業(yè)務線程進行分離。

請求由 Tomcat 單線程處理，在 NIO 模式下可以用非常少量的線程處理大量的鏈接情況。

業(yè)務邏輯處理和生成響應都是由另外的 Tomcat 線程池處理，從而跟請求線程隔離。這里的業(yè)務線程池還可以進一步隔離，不同業(yè)務設置不同的線程池。

業(yè)務線程池分離

第二個是業(yè)務線程池分離，就是通過一個線程的隔離技術，把不同的接口或不同類型的接口進行隔離。

比如訂單相關的接口，拿 20 個單獨線程去處理;商品相關的接口，拿 10 個單獨的線程去處理，這樣的話就可以讓不同的接口之間互不影響，如果訂單這塊有一個出了問題，最多消耗它自己，不會影響到其他接口的線程的調(diào)用。

具體的線程隔離可以根據(jù)業(yè)務來指定一組線程的數(shù)量，這幾個線程是為固定接口準備的。

當這個接口出現(xiàn)問題，它就把自己的線程數(shù)用掉了，不會去占用其他接口的線程，這樣起到了線程隔離的作用，讓單個 API 出問題的時候不會影響到其他。

降級

降級主要是說當有某個接口出現(xiàn)問題，我們能夠把這個接口直接降調(diào)，讓它調(diào)用直接返回，不會用到其他應用。

還有就是如果某一塊弱一點的業(yè)務邏輯出現(xiàn)問題，我們直接把這塊邏輯降調(diào)，不至于影響到其他的黃金邏輯。

降級怎么做?

首先，降級開關要集中化管理，比如通過 Zookeeper 推送到各個應用服務。這樣才能在出現(xiàn)問題的第一時間找到對應開關做降級處理。

一個基于開發(fā)降級的統(tǒng)一配置本身這個系統(tǒng)要是高可用的、支持多維度的緩存，比如我們?nèi)绻?Zookeeper 實現(xiàn)，首先 Zookeeper 會有數(shù)據(jù)庫存儲，再上面會有一個本地緩存。

再就是我們會有一個快照，如果 Zookeeper 讀不到緩存，會通過快照去加載進來一些托底的數(shù)據(jù)，以保證開發(fā)一旦觸發(fā)之后能夠在第一時間響應。而我們的開關也不至于會成為其他系統(tǒng)的問題，它是非常弱化、非常薄的一層。

精細化流量控制

說完開關、流量控制和降級之后，我們來看通過多維度的流量控制和降級的策略，比如按照單個 API 或 API+ 地域、運營商等維度進行控制。

一旦出問題了，我們會把多種組合方式進行降級，還可以根據(jù)秒/分鐘級等不同維度進行流量控制，從而達到精細化流量管理。

優(yōu)雅降級

說到降級，前面說的更多的是技術層面的，在業(yè)務層面的話，我們也要講究優(yōu)雅降級。我們不能說這個邏輯一旦建立之后就直接返回前端 502，這肯定是不友好的。

我們肯定會跟前端進行溝通，比如降級之后反饋給前端一個對應的錯誤碼，或者給用戶反饋一個提示等操作指令，這樣能夠讓用戶體驗更好一些。

限流

惡意請求、惡意攻擊，惡意的請求流量可設置為只訪問 Cache，惡意的IP可以使用 Nginx 層的 Deny 進行屛蔽，防止流程超出系統(tǒng)的承載能力，雖然會預估但總有意外，如果沒有限流，當超過系統(tǒng)承載峰值的時候，整個系統(tǒng)就會被打垮。

熔斷

當我們的后端機構出現(xiàn)問題了，達到某個閥值了，系統(tǒng)就能夠自動進行關閉降級，這是熔斷的大體思路。

我們會有更靈活的配置：比如當某個接口接連三次訪問超時或返回錯誤的話就自動熔斷。

也可以是配置一些超時間，比如連續(xù)三次這種方法調(diào)用的性能都超過了 50 毫秒，就會自動對這個方法進行熔斷，熔斷之后就相當于降級了，再次調(diào)用的話會返回失敗，就是直接拒絕返回了。

熔斷之后還可以有一個設置：比如 5 秒或一分鐘之后出來一個半打開狀態(tài)，再次醒來之后，它會去試探一下當天這個服務是否已經(jīng) OK 了，如果沒有問題了，它就會去把你之前熔斷的 API 業(yè)務再次打開，能夠正常對外提供服務。

現(xiàn)在有一些開源的實踐，通過這些實踐可以很好的做熔斷，當然根據(jù)這里邊的思路，自己也可以實現(xiàn)，這不是特別復雜的事情。

快速失敗-鏈路中的超時

快速失敗是非常重要的一個實踐，不光是做網(wǎng)關系統(tǒng)，做其他系統(tǒng)也要記住，特別是調(diào)用量大的系統(tǒng)，比如注意到整個鏈條中的超時設置。

這是我們每年在做雙 11 和 618 備戰(zhàn)的時候，都需要重點去 review 的一塊功能，包括我們平時在做開發(fā)的時候、每一次新模塊上線之前，我們都要重點去監(jiān)控這一塊。

我們會梳理所有系統(tǒng)對外的依賴，比如網(wǎng)關依賴于我們自己的一些業(yè)務的緩存、數(shù)據(jù)庫，更多的是依賴于后端數(shù)千個不同的服務。

這種涉及到網(wǎng)絡的，我們必須要設置超時間，因為像網(wǎng)關這種調(diào)用量比較大的系統(tǒng)，如果不設超時間，有可能它默認時間就是幾分鐘。

這么長時間，一旦有一個機構出問題了，有可能瞬間整個網(wǎng)關系統(tǒng)會全部雪崩掉，任何一個接口都不能對外使用，因為數(shù)據(jù)量很大，有可能你都來不及降級就已經(jīng)被沖垮了。

監(jiān)控統(tǒng)計-應用層

監(jiān)控統(tǒng)計是網(wǎng)關系統(tǒng)里非常核心的一部分，只有有了監(jiān)控，有了報警，才能讓我們實時了解所有的運營情況、每一個 API 調(diào)用的情況。

監(jiān)控目標

• 保證 7*24 小時守護系統(tǒng)。
• 能夠實時監(jiān)控系統(tǒng)的運營狀況，比如哪個 API 是不是調(diào)用時間過長了?哪個 API 已經(jīng)熔斷了?等等。
• 統(tǒng)計數(shù)據(jù)，分析指標。比如一天過去了，每一個 API 調(diào)用情況有沒有超時?有沒有訪問的性能降低等。
• 實時報警。因為監(jiān)控是一部分，發(fā)現(xiàn)問題之后能夠第一時間通知到我們，讓我們能夠馬上處理也是讓系統(tǒng)更加健康的一個方面。

監(jiān)控范圍

監(jiān)控的維度

• 硬件監(jiān)控。比如系統(tǒng)的 CPU 內(nèi)存、網(wǎng)卡等。
• 自定義監(jiān)控。比如直接報警。
• 性能監(jiān)控。比如每個接口的 TP 指標，TP999、TP99、TP90、TP50 四種性能指標作為 SLA 的參考標準，還有可用率等，這個對于網(wǎng)關來說至關重要。
• 心跳監(jiān)控。網(wǎng)關系統(tǒng)線上有很多機器，每個機器現(xiàn)在的情況怎樣?有沒有存貨等。
• 業(yè)務層監(jiān)控。比如我們會有一些 JVM 監(jiān)控，監(jiān)控 Nginx 連接數(shù)等。

在京東內(nèi)部有一個很完善的監(jiān)控體系，叫 UMP 系統(tǒng)，能夠幫助我們做各個層級的監(jiān)控。

它主要是提供給我們一些類似于配置的文件，我們配置好之后就可以進行系統(tǒng)的監(jiān)控，我們在做的時候會通過一些 AOP 代理的方式，對所有的方法進行監(jiān)控。

因為我們是網(wǎng)關，需要大量的后端透傳，網(wǎng)關因為是動態(tài)地生成這些接口，根本不知道有哪些接口，所以在動態(tài)生成接口的時候自動地 AOP 給它注入一個個監(jiān)控，這樣的話就是每一個接口都能夠有一個監(jiān)控。

說到監(jiān)控不得不提的是，我們做網(wǎng)關系統(tǒng)就是做透傳的，后面有各種各樣不同的接口、業(yè)務邏輯，每個業(yè)務邏輯和接口的性能都需要去監(jiān)控，然后告知對方讓對方去整改的。

所以我們除了把這些監(jiān)控加完之后，有了問題要能夠通知到對應的負責人，包括我們自己。

我們每一天每一周都會有郵件以報表形式發(fā)出，讓所有系統(tǒng)負責人都知道對應的機構的情況，比如性能是否有問題、是否需要整改等。

[[209076]]

王棟

京東商城開放平臺高級架構師

擁有 10 多年的架構和團隊管理經(jīng)驗，涉及信息安全、互聯(lián)網(wǎng)、電商等領域。 2011 年底至今一直在京東商城就職，期間負責過商城、POP、京東開放生態(tài)、京東移動 APP、京東商戶 APP 等業(yè)務，熟悉電商核心的流程和移動互聯(lián)網(wǎng)。在這 4 年當中見證了京東一步步成長成為行業(yè)巨頭，也見證了京東的技術部從 300 人到 7000 人，從跟不上業(yè)務發(fā)展到驅動業(yè)務發(fā)展的過程。 現(xiàn)任京東商城開放平臺高級架構師，京東商家移動端負責人，京東創(chuàng)新聯(lián)盟平臺創(chuàng)新評委，新晉架構師評委等。