11.11大促，我們的網關承載了幾十億的流量和調用，在這種情況下，網關系統(tǒng)必須保證整個系統(tǒng)的穩(wěn)定性和高可用，保證高性能和可靠，以支撐業(yè)務。我們面臨的是一個非常復雜的問題，基于這種復雜問題，怎樣做到很好地提高它的性能和穩(wěn)定性、復雜技術之間怎么整合保證整體網關的高可用，是本文的重點。
1.1 網關系統(tǒng)
網關系統(tǒng)主要有兩種：
第一種叫客戶端網關主要用來接收一些客戶端的請求，也就是APP的服務端；
第二種叫開放網關，主要是公司（比如京東）對于第三方合作伙伴提供接口。
這兩種不同網關所使用的技術非常類似。
流量比較大的網關面臨的難點包括：
第一，網關系統(tǒng)需要扛幾十億的流量調用，接口的平穩(wěn)運行、每一個接口在后端服務之后的性能耗損都非常重要。比如我們使用了一個Redis集群，然后構建了兩個機房，每一個機房都搭建了一個Redis集群，這樣的話就能夠很好地保證高可用。在面對一個瞬間流量的時候，我們采用了一些緩存技術，或者更前置的Nginx+lua+Redis技術，讓這種大流量應用能夠脫離開JVM的依賴。還有我們需要梳理各個接口，通過降級的策略把一些弱依賴的接口進行降級，從而保證核心應用的可用。
第二，網關系統(tǒng)其實就是一個把Http請求拓展到后端服務的過程。我們的網關承接了一千以上的后端服務接口，面對這種情況，怎樣做到服務與服務之間相互不影響？架構層面怎樣能夠杜絕蝴蝶效應、防止雪崩？就是說當一個接口出現問題的時候，不至于影響到其他接口的健康運行。這個說起來簡單，但實際卻不然。
一千個以上的接口，每個接口性能都不一致，而且每個接口所依賴的外部資源、數據庫緩存等都不一樣，幾乎每天都會出現各種各樣的問題，我們怎樣通過一些隔離技術、治理技術等，保證當這些接口出現問題的時候，不會影響到全局？
第三，我們對外暴露了一千個服務接口，所有接口的后面意味著幾十個甚至上百個團隊每天在不停地開發(fā)，每天都可能上線新的需求。面對這么復雜的情況，我們不可能每次后端服務器有任何修改，都需要有網關的修改或上線，這樣網關會變得非常脆弱，穩(wěn)定性極低。
我們采用了一個動態(tài)接入的技術，讓后端的網關能夠通過一種接入的協(xié)議進行無縫接入，之后通過一些動態(tài)代理的方式，直接讓后端的接口，不管做任何修改或上線，都可以通過后端管理平臺從網關上對外進行透傳發(fā)布，很好地解決了我們網關所面臨的依賴于后端接口服務的上線問題。
1.2 網關涵蓋技術
網關的四個技術方向：
第一，統(tǒng)一接入。就是前端（包括APP或其他來源）的流量，能夠都在統(tǒng)一網絡層進行接入。這一層所面臨的問題是：高性能透傳、高并發(fā)接入、高可效性，以及當前端流量來了之后，怎樣能夠進行一個負載的往后端的轉發(fā)。
第二，流量管控，主要指流量治理部分。面對海量流量，我們怎樣通過一些防刷技術，保障網關不被大流量沖垮；以及怎樣通過一些像限流、降級、熔斷等技術，對網關進行全方位保護。
第三，協(xié)議適配。就是前文提到的，網關會透傳后端上千個服務，而這些服務一定不是每一個都需要網關去開發(fā)配置的。我們通過一個協(xié)議適配的轉換，讓后端的各種服務通過我們指定的協(xié)議、通過http的方式從網關開放出去，當然網關不單單是http協(xié)議，還有一些TCP的。京東內部的協(xié)議相對比較統(tǒng)一，有Http的restful的協(xié)議，也有JSF的接口，JSF是京東內部自研的一個框架，一個RPC調用框架，和double是類似的，然后基于注冊發(fā)現的一個rpc框架。
第四，安全防護。這一部分對于網絡來說非常重要，因為網關是整個公司對外的一個出口，在這一層我們要做一些防刷，比如防清洗一些惡意流量、做一些黑名單，當有一些惡意流量的話，通過限制IP等限制手段把它拒絕在整個網關之外，防止這些惡意流量把網關沖垮。
2.1 自研網關架構
我們的自研網關架構主要分為三層。
第一層：接入層。主要負責一些長短鏈接的接入、限流、黑白名單、路由、負載均衡、容災切換等。這一層所采用的技術是Nginx+lua的方式。
第二層：分發(fā)層（或者叫：網關的業(yè)務層）。它更多的是NIO+Serviet3異步的技術。在這一層中又分為幾個部分。
● 最上層部分是數據校驗，在這一層會做一些簽名的校驗、時間的校驗、和版本、方法等。
● 下面一層叫泛化調用層，主要是把網關對外暴露的restful請求轉換成京東內部的協(xié)議，進行一個動態(tài)適配調用的過程。這一塊我們更多使用的是一些緩存的技術，線程隔離、熔斷等技術也都是在這一層實現的。因為有大量數據和協(xié)議的轉換，所以這一層用了多使用緩存的技術，我們網關層所有的數據都不會直接穿透到DB，而是采用一個叫異構數據的方式直接用緩存去做的。
泛化層中間有兩塊：一個叫主動通知，另一個是沙箱測試。主動通知很好理解，就是我們會通過這種TCP的下行通道及時通知到客戶端，發(fā)一些像京東賬戶優(yōu)惠券或提醒等；沙箱測試主要是說我們在一些接口發(fā)布上線之前，進行一個外部的測試。
如圖，最右側部分是服務降級、日志記錄、監(jiān)控告警，這三個都是我們整個網關的支撐系統(tǒng)。服務降級是說當有些服務出現問題，第一時間把它降調；日志是給我們排查問題用的；監(jiān)控告警在下文會重點介紹，因為一個網關的可用性很大方面是通過監(jiān)控系統(tǒng)來完善的，沒有監(jiān)控系統(tǒng)、沒有告警，就像沒有眼睛一樣，沒辦法知道任何事。
第三層：后端各種各樣的業(yè)務API（業(yè)務接口）。這些接口通過網關對外進行暴露。
整個網關大體上分為以上三層，最上面的接入層、中間是網關的分發(fā)層，以及業(yè)務校驗、業(yè)務邏輯層，然后通過網關透傳請求到后端服務。
除了這三層之外，我們再看兩邊的系統(tǒng)，都是我們整個網關比較核心和重要的支撐。
● 網關注冊中心。后端各種各樣的接口可以通過網關注冊中心對外進行發(fā)布，這個系統(tǒng)有一個類似管理界面，只要后端的API服務按照固有的協(xié)議進行一個編寫，如果格式OK的話上傳到管理后臺，一鍵就可以發(fā)布到線上。當然接口發(fā)布之前會有一個測試。
● OA鑒權中心。這一塊主要是做鑒權用的，像數據校驗層的很多簽名的校驗等安全校驗都是在這一層統(tǒng)一做的。
2.2 技術棧
我們的網關系統(tǒng)所涉及到的一些技術棧：第一是接入層Nginx+lua技術；第二是NIO+Serviet3異步的技術；第三是分離技術；第四是降級限流；第五是熔斷技術；第六是緩存，哪些地方該加緩存，哪些地方可以直接讀庫；第七是異構數據；第八是快速失敗；最后是監(jiān)控統(tǒng)計，這是整個高可用網關系統(tǒng)里非常重要的一部分。
下文會針對這些技術所適用的場景進行深入探討和分析，包括我們用這些技術解決什么問題。
實踐 1 Nginx層統(tǒng)一接入
先看網關整個線上的部署架構，先通過一個軟負載LVS進入到整個京東的網關，第一層是核心Nginx，經過核心Nginx之后就是后面的業(yè)務Nginx，然后通過業(yè)務Nginx把我們的請求透傳到后端的服務器。
核心Nginx主要是前端流量的分配，比如限流、防刷都是在這層去做。下層是業(yè)務Nginx，主要的Nginx+lua的邏輯在這一層實現。這一層還有能減輕核心Nginx壓力、CPU壓力的作用，而且一些lua的應用邏輯，比如限流、防刷、鑒權、降級都是在這一層做的。
為什么要加上Nginx+lua這一層？相較于Tomcat等，Nginx其實是一個能扛特別大并發(fā)流量的服務器。基于這種狀況我們之前出現過問題，當這種并發(fā)流量特別大的時候，一旦后面出現單個機有問題，哪怕你針對這個接口做了降級，但其實真正流量還是到了Tomcat層的JVM里，當流量很大的時候，很難通過JVM去消化掉這塊東西，這樣導致的結果是：當你的Tomcat出現問題了，你很難通過重啟去解決這個問題，因為流量會一直存在，這臺Tomcat出問題了， 重啟完之后是把所有行動都釋放了，但是它們就像病毒一樣，會來回傳染，你重啟了一批，這批馬上又被傳染到。Nginx天然就是這種NIO異步的方式，能夠非常好地支持大并發(fā)的業(yè)務需求。所以我們把一些核心的，比如降級、流控等，都放在這一層，讓它替我們在最前端把流量防住。
實踐 2 引入NIO、利用Servlet3異步化
第二個實踐是在Tomcat層引入了NIO，用了一個JDK7+TOMCAT7+Servlet3的配置，讓同步請求變得異步化，然后利用NIO的多路復用處理技術，讓我們能夠同時處理更高的并發(fā)數。
利用Servlet3異步化之后可以提升吞吐量，但單個請求的響應時間會略微變長，不過這種損耗是可以忍受的，因為這會帶來整個應用吞吐量的增加和靈活性的增強。還是非常值得我們使用的。
具體采用策略：業(yè)務方法開啟異步化上下文AsynContext;釋放tomcat當前處理線程；tomcat該線程被釋放，然后用于下次請求的處理，提高其吞吐量；在AsynContext環(huán)境中完成業(yè)務方法的處理，調用其complete方法，將響應寫回響應流。這樣可以提高tomcat業(yè)務邏輯的可能性，讓我們在這一層非常少的線程數就能處理更多的請求，而不至于當流量非常大的時候會被壓垮。
實踐 3 分離之術
本節(jié)將在所有分離技術中挑兩個比較重點的進行分享。
請求解析和業(yè)務處理分離
第一個是通過NIO的方式，把請求解析的線程和后面處理的業(yè)務線程進行分離。
請求由tomcat單線程處理，在NIO模式下可以用非常少量線程處理大量鏈接情況。業(yè)務邏輯處理和生成響應都是由另外的tomcat線程池處理，從而跟請求線程隔離。這里的業(yè)務線程池還可以進一步隔離，不同業(yè)務設置不同的線程池。
業(yè)務線程池分離
第二個是業(yè)務線程池分離，就是通過一個線程的隔離技術，把不同的接口或不同類型的接口進行隔離。比如訂單相關的接口，拿20個單獨線程去處理；商品相關的接口，拿10個單獨的線程去處理，這樣的話就可以讓不同的接口之間互不影響，如果訂單這塊有一個出了問題，最多消耗它自己，不會影響到其他接口的線程的調用。
具體的線程隔離可以根據業(yè)務來指定一組線程的數量，這幾個線程是為固定接口準備的，當這個接口出現問題，它就把自己的線程數用掉了，不會去占用其他接口的線程，這樣起到了線程隔離的作用，讓單個API出問題的時候不會影響到其他。
實踐 4 降級
降級主要是說當有某個接口出現問題，我們能夠把這個接口直接降調，讓它調用直接返回，不會用到其他應用。還有就是如果某一塊弱一點的業(yè)務邏輯出現問題，我們直接把這塊邏輯降調，不至于影響到其他的黃金邏輯。
降級怎么做？
首先，降級開關要集中化管理，比如通過zookeeper推送到各個應用服務。這樣才能在出現問題的第一時間找到對應開關做降級處理。
一個基于開發(fā)降級的統(tǒng)一配置本身這個系統(tǒng)要是高可用的、支持多維度的緩存，比如我們如果用zookeeper實現，首先zookeeper會有數據庫存儲，再上面會有一個本地緩存。再就是我們會有一個快照，如果zookeeper讀不到緩存，會通過快照去加載進來一些托底的數據，以保證開發(fā)一旦觸發(fā)之后能夠在第一時間響應。而我們的開關也不至于會成為其他系統(tǒng)的問題，它是非常弱化、非常薄的一層。
精細化流量控制
說完開關、流量控制和降級之后，我們來看通過多維度的流量控制和降級的策略，比如按照單個API或API+地域、運營商等維度進行控制。一旦出問題了，我們會把多種組合方式進行降級，還可以根據秒/分鐘級等不同維度進行流量控制，從而達到精細化流量管理。
優(yōu)雅降級
說到降級，前面說的更多的是技術層面的，在業(yè)務層面的話，我們也要講究優(yōu)雅降級。我們不能說這個邏輯一旦建立之后就直接返回前端502，這肯定是不友好的。我們肯定會跟前端進行溝通，比如降級之后反饋給前端一個對應的錯誤碼，或者給用戶反饋一個提示等操作指令，這樣能夠讓用戶體驗更好一些。
實踐 5 限流
惡意請求、惡意攻擊，惡意的請求流量可以只訪問cache，惡意的IP可以使用nginx層的 deny進行屛蔽；
防止流程超出系統(tǒng)的承載能力，雖然會預估但總有意外，如果沒有限流，當超過系統(tǒng)承載峰值的時候，整個系統(tǒng)就會打垮。
實踐 6 熔斷
實踐 7 快速失敗-鏈路中的超時
實踐 8 監(jiān)控統(tǒng)計-應用層
監(jiān)控統(tǒng)計是網關系統(tǒng)里非常核心的一部分，只有有了監(jiān)控，有了報警，才能讓我們實時了解所有的運營情況、每一個API調用的情況。
監(jiān)控目標
監(jiān)控范圍
監(jiān)控的維度
看完本文有收獲？請轉發(fā)分享給更多人
