京東10億級呼叫量背後的高可用網關係統架構實踐！
作者介紹：
王棟
京東商城開放平臺高階架構師
擁有 10 多年的架構和團隊管理經驗，涉及資訊保安、網際網路、電商等領域。 2011 年底至今一直在京東商城就職，期間負責過商城、POP、京東開放生態、京東移動 APP、京東商戶 APP 等業務，熟悉電商核心的流程和移動網際網路。在這 4 年當中見證了京東一步步成長成為行業巨頭，也見證了京東的技術部從 300 人到 7000 人，從跟不上業務發展到驅動業務發展的過程。 現任京東商城開放平臺高階架構師，京東商家移動端負責人，京東創新聯盟平臺創新評委，新晉架構師評委等。
京東開放服務平臺是京東對外開發的視窗，每年的 618 大促，京東的閘道器都要承載十億級的呼叫量來保障幾十萬商家穩定使用的使命。
在保證近千個不同型別服務介面的海量呼叫的同時，我們還要確保服務介面之間的互不干擾，並且能夠快速響應任何複雜情況，因此穩定、快速是我們一直追求的目標。
今年的 618 大促，京東的閘道器承載了幾十億的流量和呼叫，在這種情況下，網關係統必須保證整個系統的穩定性和高可用，保證高效能和可靠性，以支撐業務。
閘道器涵蓋技術
網關係統
網關係統主要有兩種：
- 客戶端閘道器，主要用來接收一些客戶端的請求，也就是 APP 的服務端。
- 開放閘道器，主要是公司（比如京東）對於第三方合作伙伴提供介面。
這兩種不同閘道器所使用的技術非常類似。
流量比較大的閘道器面臨的難點包括：
- 網關係統需要扛幾十億的流量呼叫，介面的平穩執行、每一個介面在後端服務之後的效能耗損都非常重要。
比如我們使用了一個 Redis 叢集，然後構建了兩個機房，每一個機房都搭建了一個 Redis 叢集，這樣的話就能夠很好地保證高可用。在面對一個瞬間流量的時候，我們採用了一些快取技術，或者更前置的 Nginx+lua+Redis 技術，讓這種大流量應用能夠脫離開 JVM 的依賴。
還有我們需要梳理各個介面，通過降級的策略把一些弱依賴的介面進行降級，從而保證核心應用的可用。
- 網關係統其實就是一個把 HTTP 請求拓展到後端服務的過程。
我們的閘道器承接了一千以上的後端服務介面，面對這種情況，怎樣做到服務與服務之間相互不影響？架構層面怎樣能夠杜絕蝴蝶效應、防止雪崩？就是說當一個接口出現問題的時候，不至於影響到其他介面的健康執行。這個說起來簡單，但實際卻不然。
一千個以上的介面，每個介面效能都不一致，而且每個介面所依賴的外部資源、資料庫快取等都不一樣，幾乎每天都會出現各種各樣的問題，我們怎樣通過一些隔離技術、治理技術等，保證當這些接口出現問題的時候，不會影響到全域性？
- 我們對外暴露了一千個服務介面，所有介面的後面意味著幾十個甚至上百個團隊每天在不停地開發，每天都可能上線新的需求。
面對這麼複雜的情況，我們不可能每次後端伺服器有任何修改，都需要有閘道器的修改或上線，這樣閘道器會變得非常脆弱，穩定性極低。我們採用了一個動態接入的技術，讓後端的閘道器能夠通過一種接入的協議進行無縫接入，之後通過一些動態代理的方式，直接讓後端的介面，不管做任何修改或上線，都可以通過後端管理平臺從閘道器上對外進行透傳發布。
這樣就很好地解決了閘道器所面臨的依賴於後端介面服務的上線問題。
閘道器涵蓋技術
閘道器的四個技術方向：
- 統一接入，就是前端（包括 APP 或其他來源）的流量，都能在統一網路層進行接入。
這一層所面臨的問題是：高效能透傳、高併發接入、高可效性，以及當前端流量來了之後，怎樣能夠進行一個負載的服務往後端的轉發。
- 流量管控，主要指流量治理部分。面對海量流量，我們怎樣通過一些防刷技術，保障閘道器不被大流量沖垮；以及怎樣通過一些像限流、降級、熔斷等技術，對閘道器進行全方位保護。
- 協議適配，就是前文提到的，閘道器會透傳後端上千個服務，而這些服務一定不是每一個都需要閘道器去開發配置的。
我們通過一個協議適配的轉換，讓後端的各種服務通過我們指定的協議、通過 HTTP 的方式從閘道器開放出去，當然閘道器不單單是 HTTP 協議，還有一些 TCP 的。
京東內部的協議相對比較統一，有 HTTP 的 restful 的協議，也有 JSF 的介面，JSF 是京東內部自研的一個框架，一個 RPC 呼叫框架，和 Double 是類似的，然後基於註冊發現的一個 RPC 框架。
- 安全防護，這一部分對於網路來說非常重要，因為閘道器是整個公司對外的一個出口，在這一層我們要做一些防刷。
比如防清洗一些惡意流量、做一些黑名單，當有一些惡意流量的話，通過限制 IP 等限制手段把它拒絕在整個閘道器之外，防止這些惡意流量把閘道器沖垮。
自研閘道器架構
自研閘道器架構
我們的自研閘道器架構主要分為三層：
接入層
主要負責一些長短連結的接入、限流、黑白名單、路由、負載均衡、容災切換等。這一層所採用的技術是 Nginx+lua 的方式。
分發層
這一層是分發層或者叫閘道器的業務層，它更多的是 NIO+Serviet3 非同步的技術。
在這一層中又分為幾個部分：
- 最上層部分是資料校驗，在這一層會做一些簽名的校驗、時間的校驗、版本、方法等。
- 下面一層叫泛化呼叫層，主要是把閘道器對外暴露的 restful 請求轉換成京東內部的協議，進行一個動態適配呼叫的過程。
這一塊我們更多使用的是一些快取的技術，執行緒隔離、熔斷等技術也都是在這一層實現的。
因為有大量資料和協議的轉換，所以這一層用了多使用快取的技術，我們閘道器層所有的資料都不會直接穿透到 DB，而是採用一個叫異構資料的方式直接用快取去做的。
泛化層中間有兩塊：
- 主動通知，就是我們會通過這種 TCP 的下行通道及時通知到客戶端，發一些像京東賬戶優惠券或提醒等。
- 沙箱測試，主要是在一些介面釋出上線之前，進行一個外部的測試。
如上圖，最右側部分是服務降級、日誌記錄、監控告警，這三個都是我們整個閘道器的支撐系統。
服務降級是說當有些服務出現問題，第一時間把它降調；日誌是給我們排查問題用的。
監控告警在下文會重點介紹，因為一個閘道器的可用性很大方面是通過監控系統來完善的，沒有監控系統、沒有告警，就像沒有眼睛一樣，沒辦法知道任何事。
後端各種各樣的業務 API
這些業務 API（業務介面）通過閘道器對外進行暴露。整個閘道器大體上分為如上圖的三層，最上面是接入層、中間是閘道器的分發層，以及業務校驗、業務邏輯層，然後通過閘道器透傳請求到後端服務。
除了這三層之外，我們再看兩邊的系統，都是我們整個閘道器比較核心和重要的支撐：
- 網關注冊中心，後端各種各樣的介面可以通過網關注冊中心對外進行釋出，這個系統有一個類似的管理介面，只要後端的 API 服務按照固有的協議進行一個編寫。
- 如果格式 OK 的話上傳到管理後臺，一鍵就可以釋出到線上。當然介面釋出之前會有一個測試。
- OA 鑑權中心，這一塊主要是做鑑權用的，像資料校驗層的很多簽名的校驗等安全校驗都是在這一層統一做的。
技術棧
我們的網關係統所涉及到的一些技術棧：
- 接入層 Nginx+lua 技術。
- NIO+Serviet3 非同步技術。
- 分離技術。
- 降級限流。
- 熔斷技術。
- 快取，哪些地方該加快取，哪些地方可以直接讀庫。
- 異構資料。
- 快速失敗。
- 監控統計，這是整個高可用網關係統裡非常重要的一部分。
下文會針對這些技術所適用的場景進行深入探討和分析，包括我們用這些技術解決什麼問題。
基本思路及過程改進點
Nginx 層統一接入
先看閘道器整個線上的部署架構，通過一個軟負載 LVS 進入到整個京東的閘道器，第一層是核心 Nginx，經過核心 Nginx 之後就是後面的業務 Nginx，然後通過業務 Nginx 把我們的請求透傳到後端的伺服器。
核心 Nginx 主要是前端流量的分配，比如限流、防刷都是在這層去做。下層是業務 Nginx，主要的 Nginx+lua 的邏輯在這一層實現。
這一層還有能減輕核心 Nginx 壓力、CPU 壓力的作用，而且一些 lua 的應用邏輯，比如限流、防刷、鑑權、降級都是在這一層做的。
為什麼要加上 Nginx+lua 這一層？相較於 Tomcat 等，Nginx 是一個能扛特別大併發流量的伺服器。
基於這種狀況，我們之前出現過問題，當這種併發流量特別大的時候，一旦後面出現單機有問題，哪怕你針對這個介面做了降級，但真正流量還是到了 Tomcat 層的 JVM 裡。
當流量很大的時候，很難通過 JVM 能夠消化掉，這樣導致的結果是：當你的 Tomcat 出現問題了，你很難通過重啟去解決這個問題。
因為流量會一直存在，這臺 Tomcat 出問題了， 重啟完之後是把所有行動都釋放了，但是它們就像病毒一樣，會來回傳染，你重啟了一批，這批馬上又被傳染到。
Nginx 天然就是這種 NIO 非同步的方式，能夠非常好地支援大併發的業務需求。所以我們把一些核心的，比如降級、流控等，都放在這一層，讓它替我們在最前端把流量防住。
引入 NIO、利用 Servlet3 非同步化
第二個實踐是在 Tomcat 層引入了 NIO，用了一個 JDK7+TOMCAT7+Servlet3 的配置，讓同步請求變得非同步化，然後利用 NIO 的多路複用處理技術，讓我們能夠同時處理更高的併發數。
利用 Servlet3 非同步化之後可以提升吞吐量，但單個請求的響應時間會略微變長，不過這種損耗是可以忍受的，因為這會帶來整個應用吞吐量的增加和靈活性的增強，還是非常值得我們使用的。
具體採用策略：
- 業務方法開啟非同步化上下文 AsynContext。
- 釋放 Tomcat 當前處理執行緒。
- Tomcat 該執行緒被釋放，然後用於下次請求的處理，提高其吞吐量。
- 在 AsynContext 環境中完成業務方法的處理，呼叫其 complete 方法，將響應寫回響應流。
這樣可以提高 Tomcat 業務邏輯的可能性，讓我們在這一層非常少的執行緒數就能處理更多的請求，而不至於當流量非常大的時候被壓垮。
分離之術
在所有分離技術中，我挑兩個比較重要的點進行分享。
請求解析和業務處理分離
第一個是通過 NIO 的方式，把請求解析的執行緒和後面處理的業務執行緒進行分離。
請求由 Tomcat 單執行緒處理，在 NIO 模式下可以用非常少量的執行緒處理大量的連結情況。
業務邏輯處理和生成響應都是由另外的 Tomcat 執行緒池處理，從而跟請求執行緒隔離。這裡的業務執行緒池還可以進一步隔離，不同業務設定不同的執行緒池。
業務執行緒池分離
第二個是業務執行緒池分離，就是通過一個執行緒的隔離技術，把不同的介面或不同型別的介面進行隔離。
比如訂單相關的介面，拿 20 個單獨執行緒去處理；商品相關的介面，拿 10 個單獨的執行緒去處理，這樣的話就可以讓不同的介面之間互不影響，如果訂單這塊有一個出了問題，最多消耗它自己，不會影響到其他介面的執行緒的呼叫。
具體的執行緒隔離可以根據業務來指定一組執行緒的數量，這幾個執行緒是為固定介面準備的。
當這個接口出現問題，它就把自己的執行緒數用掉了，不會去佔用其他介面的執行緒，這樣起到了執行緒隔離的作用，讓單個 API 出問題的時候不會影響到其他。
降級
降級主要是說當有某個接口出現問題，我們能夠把這個介面直接降調，讓它呼叫直接返回，不會用到其他應用。
還有就是如果某一塊弱一點的業務邏輯出現問題，我們直接把這塊邏輯降調，不至於影響到其他的黃金邏輯。
降級怎麼做？
首先，降級開關要集中化管理，比如通過 Zookeeper 推送到各個應用服務。這樣才能在出現問題的第一時間找到對應開關做降級處理。
一個基於開發降級的統一配置本身這個系統要是高可用的、支援多維度的快取，比如我們如果用 Zookeeper 實現，首先 Zookeeper 會有資料庫儲存，再上面會有一個本地快取。
再就是我們會有一個快照，如果 Zookeeper 讀不到快取，會通過快照去載入進來一些託底的資料，以保證開發一旦觸發之後能夠在第一時間響應。而我們的開關也不至於會成為其他系統的問題，它是非常弱化、非常薄的一層。
精細化流量控制
說完開關、流量控制和降級之後，我們來看通過多維度的流量控制和降級的策略，比如按照單個 API 或 API+ 地域、運營商等維度進行控制。
一旦出問題了，我們會把多種組合方式進行降級，還可以根據秒/分鐘級等不同維度進行流量控制，從而達到精細化流量管理。
優雅降級
說到降級，前面說的更多的是技術層面的，在業務層面的話，我們也要講究優雅降級。我們不能說這個邏輯一旦建立之後就直接返回前端 502，這肯定是不友好的。
我們肯定會跟前端進行溝通，比如降級之後反饋給前端一個對應的錯誤碼，或者給使用者反饋一個提示等操作指令，這樣能夠讓使用者體驗更好一些。
限流
惡意請求、惡意攻擊，惡意的請求流量可設定為只訪問 Cache，惡意的IP可以使用 Nginx 層的 Deny 進行屛蔽，防止流程超出系統的承載能力，雖然會預估但總有意外，如果沒有限流，當超過系統承載峰值的時候，整個系統就會被打垮。
熔斷
當我們的後端機構出現問題了，達到某個閥值了，系統就能夠自動進行關閉降級，這是熔斷的大體思路。
我們會有更靈活的配置：比如當某個介面接連三次訪問超時或返回錯誤的話就自動熔斷。
也可以是配置一些超時間，比如連續三次這種方法呼叫的效能都超過了 50 毫秒，就會自動對這個方法進行熔斷，熔斷之後就相當於降級了，再次呼叫的話會返回失敗，就是直接拒絕返回了。
熔斷之後還可以有一個設定：比如 5 秒或一分鐘之後出來一個半開啟狀態，再次醒來之後，它會去試探一下當天這個服務是否已經 OK 了，如果沒有問題了，它就會去把你之前熔斷的 API 業務再次開啟，能夠正常對外提供服務。
現在有一些開源的實踐，通過這些實踐可以很好的做熔斷，當然根據這裡邊的思路，自己也可以實現，這不是特別複雜的事情。
快速失敗-鏈路中的超時
快速失敗是非常重要的一個實踐，不光是做網關係統，做其他系統也要記住，特別是呼叫量大的系統，比如注意到整個鏈條中的超時設定。
這是我們每年在做雙 11 和 618 備戰的時候，都需要重點去 review 的一塊功能，包括我們平時在做開發的時候、每一次新模組上線之前，我們都要重點去監控這一塊。
我們會梳理所有系統對外的依賴，比如閘道器依賴於我們自己的一些業務的快取、資料庫，更多的是依賴於後端數千個不同的服務。
這種涉及到網路的，我們必須要設定超時間，因為像閘道器這種呼叫量比較大的系統，如果不設超時間，有可能它預設時間就是幾分鐘。
這麼長時間，一旦有一個機構出問題了，有可能瞬間整個網關係統會全部雪崩掉，任何一個介面都不能對外使用，因為資料量很大，有可能你都來不及降級就已經被沖垮了。
監控統計-應用層
監控統計是網關係統裡非常核心的一部分，只有有了監控，有了報警，才能讓我們實時瞭解所有的運營情況、每一個 API 呼叫的情況。
監控目標
- 保證 7*24 小時守護系統。
- 能夠實時監控系統的運營狀況，比如哪個 API 是不是呼叫時間過長了？哪個 API 已經熔斷了？等等。
- 統計資料，分析指標。比如一天過去了，每一個 API 呼叫情況有沒有超時？有沒有訪問的效能降低等。
- 實時報警。因為監控是一部分，發現問題之後能夠第一時間通知到我們，讓我們能夠馬上處理也是讓系統更加健康的一個方面。
監控的維度
- 硬體監控。比如系統的 CPU 記憶體、網絡卡等。
- 自定義監控。比如直接報警。
- 效能監控。比如每個介面的 TP 指標，TP999、TP99、TP90、TP50 四種性能指標作為 SLA 的參考標準，還有可用率等，這個對於閘道器來說至關重要。
- 心跳監控。網關係統線上有很多機器，每個機器現在的情況怎樣？有沒有存貨等。
- 業務層監控。比如我們會有一些 JVM 監控，監控 Nginx 連線數等。
在京東內部有一個很完善的監控體系，叫 UMP 系統，能夠幫助我們做各個層級的監控。
它主要是提供給我們一些類似於配置的檔案，我們配置好之後就可以進行系統的監控，我們在做的時候會通過一些 AOP 代理的方式，對所有的方法進行監控。
因為我們是閘道器，需要大量的後端透傳，閘道器因為是動態地生成這些介面，根本不知道有哪些介面，所以在動態生成介面的時候自動地 AOP 給它注入一個個監控，這樣的話就是每一個介面都能夠有一個監控。
說到監控不得不提的是，我們做網關係統就是做透傳的，後面有各種各樣不同的介面、業務邏輯，每個業務邏輯和介面的效能都需要去監控，然後告知對方讓對方去整改的。
所以我們除了把這些監控加完之後，有了問題要能夠通知到對應的負責人，包括我們自己。
我們每一天每一週都會有郵件以報表形式發出，讓所有系統負責人都知道對應的機構的情況，比如效能是否有問題、是否需要整改等。