618大促， 我們的閘道承載了幾十億的流量和調用， 在這種情況下， 閘道系統必須保證整個系統的穩定性和高可用， 保證高性能和可靠， 以支撐業務。 我們面臨的是一個非常複雜的問題， 基於這種複雜問題， 怎樣做到很好地提高它的性能和穩定性、複雜技術之間怎麼整合保證整體閘道的高可用， 是本文的重點。
1閘道涵蓋技術
1.1 閘道系統
閘道系統主要有兩種：
第一種叫用戶端閘道主要用來接收一些用戶端的請求， 也就是APP的服務端；
第二種叫開放閘道， 主要是公司（比如京東）對於協力廠商合作夥伴提供介面。
這兩種不同閘道所使用的技術非常類似。
流量比較大的閘道面臨的難點包括：
第一， 閘道系統需要扛幾十億的流量調用， 介面的平穩運行、每一個介面在後端服務之後的性能耗損都非常重要。 比如我們使用了一個Redis集群， 然後構建了兩個機房， 每一個機房都搭建了一個Redis集群， 這樣的話就能夠很好地保證高可用。 在面對一個瞬間流量的時候， 我們採用了一些緩存技術， 或者更前置的Nginx+lua+Redis技術， 讓這種大流量應用能夠脫離開JVM的依賴。 還有我們需要梳理各個介面， 通過降級的策略把一些弱依賴的介面進行降級， 從而保證核心應用的可用。
第二， 閘道系統其實就是一個把Http請求拓展到後端服務的過程。 我們的閘道承接了一千以上的後端服務介面，
一千個以上的介面， 每個介面性能都不一致， 而且每個介面所依賴的外部資源、資料庫緩存等都不一樣， 幾乎每天都會出現各種各樣的問題， 我們怎樣通過一些隔離技術、治理技術等， 保證當這些介面出現問題的時候， 不會影響到全域？
第三， 我們對外暴露了一千個服務介面， 所有介面的後面意味著幾十個甚至上百個團隊每天在不停地開發， 每天都可能上線新的需求。 面對這麼複雜的情況，
我們採用了一個動態接入的技術， 讓後端的閘道能夠通過一種接入的協議進行無縫接入， 之後通過一些動態代理的方式， 直接讓後端的介面， 不管做任何修改或上線， 都可以通過後端管理平臺從閘道上對外進行透傳發佈， 很好地解決了我們閘道所面臨的依賴於後端介面服務的上線問題。
1.2 閘道涵蓋技術
閘道的四個技術方向：
第一， 統一接入。 就是前端（包括APP或其他來源）的流量， 能夠都在統一網路層進行接入。 這一層所面臨的問題是：高性能透傳、高併發接入、高可效性， 以及當前端流量來了之後， 怎樣能夠進行一個負載的往後端的轉發。
第二， 流量管控， 主要指流量治理部分。 面對海量流量， 我們怎樣通過一些防刷技術， 保障閘道不被大流量衝垮；以及怎樣通過一些像限流、降級、熔斷等技術， 對閘道進行全方位保護。
第三， 協議適配。 就是前文提到的，
第四， 安全防護。 這一部分對於網路來說非常重要， 因為閘道是整個公司對外的一個出口， 在這一層我們要做一些防刷， 比如防清洗一些惡意流量、做一些黑名單， 當有一些惡意流量的話， 通過限制IP等限制手段把它拒絕在整個閘道之外， 防止這些惡意流量把閘道衝垮。
2自研閘道架構
2.1 自研閘道架構
我們的自研閘道架構主要分為三層。
第一層：接入層。主要負責一些長短連結的接入、限流、黑白名單、路由、負載均衡、容災切換等。這一層所採用的技術是Nginx+lua的方式。
第二層：分發層（或者叫：閘道的業務層）。它更多的是NIO+Serviet3非同步的技術。在這一層中又分為幾個部分。
● 最上層部分是資料校驗，在這一層會做一些簽名的校驗、時間的校驗、和版本、方法等。
● 下面一層叫泛化調用層，主要是把閘道對外暴露的restful請求轉換成京東內部的協定，進行一個動態適配調用的過程。這一塊我們更多使用的是一些緩存的技術，執行緒隔離、熔斷等技術也都是在這一層實現的。因為有大量資料和協定的轉換，所以這一層用了多使用緩存的技術，我們閘道層所有的資料都不會直接穿透到DB，而是採用一個叫異構資料的方式直接用緩存去做的。
泛化層中間有兩塊：一個叫主動通知，另一個是沙箱測試。主動通知很好理解，就是我們會通過這種TCP的下行通道及時通知到用戶端，發一些像京東帳戶優惠券或提醒等；沙箱測試主要是說我們在一些介面發佈上線之前，進行一個外部的測試。
如圖，最右側部分是服務降級、日誌記錄、監控告警，這三個都是我們整個閘道的支撐系統。服務降級是說當有些服務出現問題，第一時間把它降調；日誌是給我們排查問題用的；監控告警在下文會重點介紹，因為一個閘道的可用性很大方面是通過監控系統來完善的，沒有監控系統、沒有告警，就像沒有眼睛一樣，沒辦法知道任何事。
第三層：後端各種各樣的業務API（業務介面）。這些介面通過閘道對外進行暴露。
整個閘道大體上分為以上三層，最上面的接入層、中間是閘道的分發層，以及業務校驗、業務邏輯層，然後通過閘道透傳請求到後端服務。
除了這三層之外，我們再看兩邊的系統，都是我們整個閘道比較核心和重要的支撐。
● 閘道註冊中心。後端各種各樣的介面可以通過閘道註冊中心對外進行發佈，這個系統有一個類似管理介面，只要後端的API服務按照固有的協定進行一個編寫，如果格式OK的話上傳到管理後臺，一鍵就可以發佈到線上。當然介面發佈之前會有一個測試。
● OA鑒權中心。這一塊主要是做鑒權用的，像資料校驗層的很多簽名的校驗等安全校驗都是在這一層統一做的。
2.2 技術棧
我們的閘道系統所涉及到的一些技術棧：第一是接入層Nginx+lua技術；第二是NIO+Serviet3非同步的技術；第三是分離技術；第四是降級限流；第五是熔斷技術；第六是緩存，哪些地方該加緩存，哪些地方可以直接讀庫；第七是異構數據；第八是快速失敗；最後是監控統計，這是整個高可用閘道系統裡非常重要的一部分。
下文會針對這些技術所適用的場景進行深入探討和分析，包括我們用這些技術解決什麼問題。
3基本思路及過程改進點
實踐 1 Nginx層統一接入
先看閘道整個線上的部署架構，先通過一個軟負載LVS進入到整個京東的閘道，第一層是核心Nginx，經過核心Nginx之後就是後面的業務Nginx，然後通過業務Nginx把我們的請求透傳到後端的伺服器。
核心Nginx主要是前端流量的分配，比如限流、防刷都是在這層去做。下層是業務Nginx，主要的Nginx+lua的邏輯在這一層實現。這一層還有能減輕核心Nginx壓力、CPU壓力的作用，而且一些lua的應用邏輯，比如限流、防刷、鑒權、降級都是在這一層做的。
為什麼要加上Nginx+lua這一層？相較於Tomcat等，Nginx其實是一個能扛特別大併發流量的伺服器。基於這種狀況我們之前出現過問題，當這種併發流量特別大的時候，一旦後面出現單個機有問題，哪怕你針對這個介面做了降級，但其實真正流量還是到了Tomcat層的JVM裡，當流量很大的時候，很難通過JVM去消化掉這塊東西，這樣導致的結果是：當你的Tomcat出現問題了，你很難通過重啟去解決這個問題，因為流量會一直存在，這台Tomcat出問題了， 重啟完之後是把所有行動都釋放了，但是它們就像病毒一樣，會來回傳染，你重啟了一批，這批馬上又被傳染到。Nginx天然就是這種NIO非同步的方式，能夠非常好地支持大併發的業務需求。所以我們把一些核心的，比如降級、流控等，都放在這一層，讓它替我們在最前端把流量防住。
實踐 2 引入NIO、利用Servlet3非同步化
第二個實踐是在Tomcat層引入了NIO，用了一個JDK7+TOMCAT7+Servlet3的配置，讓同步請求變得非同步化，然後利用NIO的多工處理技術，讓我們能夠同時處理更高的併發數。
利用Servlet3非同步化之後可以提升輸送量，但單個請求的回應時間會略微變長，不過這種損耗是可以忍受的，因為這會帶來整個應用輸送量的增加和靈活性的增強。還是非常值得我們使用的。
具體採用策略：業務方法開啟非同步化上下文AsynContext;釋放tomcat當前處理執行緒；tomcat該執行緒被釋放，然後用於下次請求的處理，提高其輸送量；在AsynContext環境中完成業務方法的處理，調用其complete方法，將回應寫迴響應流。這樣可以提高tomcat業務邏輯的可能性，讓我們在這一層非常少的執行緒數就能處理更多的請求，而不至於當流量非常大的時候會被壓垮。
實踐 3 分離之術
本節將在所有分離技術中挑兩個比較重點的進行分享。
請求解析和業務處理分離
第一個是通過NIO的方式，把請求解析的執行緒和後面處理的業務執行緒進行分離。
請求由tomcat單執行緒，在NIO模式下可以用非常少量執行緒大量連結情況。業務邏輯處理和生成回應都是由另外的tomcat執行緒池處理，從而跟請求執行緒隔離。這裡的業務執行緒池還可以進一步隔離，不同業務設置不同的執行緒池。
業務執行緒池分離
第二個是業務執行緒池分離，就是通過一個執行緒的隔離技術，把不同的介面或不同類型的介面進行隔離。比如訂單相關的介面，拿20個單獨執行緒去處理；商品相關的介面，拿10個單獨的執行緒去處理，這樣的話就可以讓不同的介面之間互不影響，如果訂單這塊有一個出了問題，最多消耗它自己，不會影響到其他介面的執行緒的調用。
具體的執行緒隔離可以根據業務來指定一組執行緒的數量，這幾個執行緒是為固定介面準備的，當這個介面出現問題，它就把自己的執行緒數用掉了，不會去佔用其他介面的執行緒，這樣起到了執行緒隔離的作用，讓單個API出問題的時候不會影響到其他。
實踐 4 降級
降級主要是說當有某個介面出現問題，我們能夠把這個介面直接降調，讓它調用直接返回，不會用到其他應用。還有就是如果某一塊弱一點的業務邏輯出現問題，我們直接把這塊邏輯降調，不至於影響到其他的黃金邏輯。
降級怎麼做？
首先，降級開關要集中化管理，比如通過zookeeper推送到各個應用服務。這樣才能在出現問題的第一時間找到對應開關做降級處理。
一個基於開發降級的統一配置本身這個系統要是高可用的、支援多維度的緩存，比如我們如果用zookeeper實現，首先zookeeper會有資料庫存儲，再上面會有一個本地緩存。再就是我們會有一個快照，如果zookeeper讀不到緩存，會通過快照去載入進來一些托底的資料，以保證開發一旦觸發之後能夠在第一時間回應。而我們的開關也不至於會成為其他系統的問題，它是非常弱化、非常薄的一層。
精細化流量控制
說完開關、流量控制和降級之後，我們來看通過多維度的流量控制和降級的策略，比如按照單個API或API+地域、運營商等維度進行控制。一旦出問題了，我們會把多種組合方式進行降級，還可以根據秒/分鐘級等不同維度進行流量控制，從而達到精細化流量管理。
優雅降級
說到降級，前面說的更多的是技術層面的，在業務層面的話，我們也要講究優雅降級。我們不能說這個邏輯一旦建立之後就直接返回前端502，這肯定是不友好的。我們肯定會跟前端進行溝通，比如降級之後回饋給前端一個對應的錯誤碼，或者給使用者回饋一個提示等操作指令，這樣能夠讓使用者體驗更好一些。
實踐 5 限流
惡意請求、惡意攻擊，惡意的請求流量可以只訪問cache，惡意的IP可以使用nginx層的 deny進行屛蔽；
防止流程超出系統的承載能力，雖然會預估但總有意外，如果沒有限流，當超過系統承載峰值的時候，整個系統就會打垮。
1、具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加群。
2、在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加群。
3、如果沒有工作經驗，但基礎非常扎實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的，可以加群。
4、覺得自己很牛B，一般需求都能搞定。但是所學的知識點沒有系統化，很難在技術領域繼續突破的可以加群。
5.群號：521479582 高級開發
6.阿裡Java高級大牛直播講解知識點，分享知識，多年工作經驗的梳理和總結，帶著大家全面、科學地建立自己的技術體系和技術認知。
實踐 6 熔斷
當我們的後端機構出現問題了，達到某個閥值了，系統就能夠自動進行關閉降級，這是熔斷的大體思路。我們會有更靈活的配置：比如當某個介面接連三次訪問超時或返回錯誤的話就自動熔斷；也可以是配置一些超時間，比如連續三次這種方法調用的性能都超過了50毫秒，就會自動對這個方法進行熔斷，熔斷之後就相當於降級了，再次調用的話會返回失敗，就是直接拒絕返回了。
熔斷之後還可以有一個設置：比如5秒或一分鐘之後出來一個半打開狀態，再次醒來之後，它會去試探一下當天這個服務是否已經OK了，如果沒有問題了，它就會去把你之前熔斷的API業務再次打開，能夠正常對外提供服務。現在有一些開源的實踐，通過這些實踐可以很好的做熔斷，當然根據這裡邊的思路，自己也可以實現，這不是特別複雜的事情。
實踐 7 快速失敗-鏈路中的超時
快速失敗是非常重要的一個實踐，不光是做閘道系統，做其他系統也要記住，特別是調用量大的系統，比如注意到整個鏈條中的超時設置。這是我們每年在做雙11和618備戰的時候，都需要重點去review的一塊東西，包括我們平時在做開發的時候、每一次新模組上線之前，我們都要重點去監控這一塊。我們會梳理所有系統對外的依賴，比如閘道依賴於我們自己的一些業務的緩存、資料庫，更多的是依賴於後端數千個不同的服務。
這種涉及到網路的，我們必須要設置超時間，因為像閘道這種調用量比較大的系統，如果不設超時間，有可能它默認時間就是幾分鐘，這麼長時間，一旦有一個機構出問題了，有可能瞬間整個閘道系統會全部雪崩掉，任何一個介面都不能對外使用，因為資料量很大，有可能你都來不及降級就已經被衝垮了。
實踐 8 監控統計-應用層
監控統計是閘道系統裡非常核心的一部分，只有有了監控，有了報警，才能讓我們即時瞭解所有的運營情況、每一個API調用的情況。
監控目標
第一：保證7*24小時守護系統；
第二：能夠即時監控系統的運營狀況，比如哪個API是不是調用時間過長了？哪個API已經熔斷了？等等；
第三：統計資料，分析指標。比如一天過去了，每一個API調用情況有沒有超時？有沒有訪問的性能降低等；
第四：即時報警。因為監控是一部分，發現問題之後能夠第一時間通知到我們，讓我們能夠馬上處理也是讓系統更加健康的一個方面。
監控範圍
監控的維度
第一層：硬體監控。比如系統的CPU記憶體、網卡等。
第二層：自訂監控。比如直接報警。
第三層：性能監控。比如每個介面的TP指標，TP999 TP99 TP90 TP50四種性能指標作為SLA的參考標準，還有可用率等，這個對於閘道來說至關重要。
第四層：心跳監控。閘道系統線上有很多機器，每個機器現在的情況怎樣？有沒有存貨等。
第五層：業務層監控。比如我們會有一些JVM監控，監控Nginx連接數等。
在京東內部有一個很完善的監控體系，叫UMP系統，能夠説明我們做各個層級的監控。它主要是提供給我們一些類似於配置的檔，我們配置好之後就可以進行系統的監控，我們在做的時候會通過一些AOP代理的方式，對所有的方法進行監控。因為我們是閘道，需要大量的後端透傳，閘道因為是動態地生成這些介面，根本不知道有哪些介面，所以在動態生成介面的時候自動地AOP給它注入一個個監控，這樣的話就是每一個介面都能夠有一個監控。
說到監控不得不提的是，我們做閘道系統就是做透傳的，後面有各種各樣不同的介面、業務邏輯，每個業務邏輯和介面的性能都需要去監控，然後告知對方讓對方去整改的，所以我們除了把這些監控加完之後，有了問題要能夠通知到對應的負責人，包括我們自己。所以我們每一天每一周都會有郵件以報表形式發出，讓所有系統負責人都知道對應的機構的情況，比如性能是否有問題、是否需要整改等。
1、具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加群。
2、在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加群。
3、如果沒有工作經驗，但基礎非常扎實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的，可以加群。
4、覺得自己很牛B，一般需求都能搞定。但是所學的知識點沒有系統化，很難在技術領域繼續突破的可以加群。
5.群號：521479582 高級開發
6.阿裡Java高級大牛直播講解知識點，分享知識，多年工作經驗的梳理和總結，帶著大家全面、科學地建立自己的技術體系和技術認知。
防止這些惡意流量把閘道衝垮。2自研閘道架構
2.1 自研閘道架構
我們的自研閘道架構主要分為三層。
第一層：接入層。主要負責一些長短連結的接入、限流、黑白名單、路由、負載均衡、容災切換等。這一層所採用的技術是Nginx+lua的方式。
第二層：分發層（或者叫：閘道的業務層）。它更多的是NIO+Serviet3非同步的技術。在這一層中又分為幾個部分。
● 最上層部分是資料校驗，在這一層會做一些簽名的校驗、時間的校驗、和版本、方法等。
● 下面一層叫泛化調用層，主要是把閘道對外暴露的restful請求轉換成京東內部的協定，進行一個動態適配調用的過程。這一塊我們更多使用的是一些緩存的技術，執行緒隔離、熔斷等技術也都是在這一層實現的。因為有大量資料和協定的轉換，所以這一層用了多使用緩存的技術，我們閘道層所有的資料都不會直接穿透到DB，而是採用一個叫異構資料的方式直接用緩存去做的。
泛化層中間有兩塊：一個叫主動通知，另一個是沙箱測試。主動通知很好理解，就是我們會通過這種TCP的下行通道及時通知到用戶端，發一些像京東帳戶優惠券或提醒等；沙箱測試主要是說我們在一些介面發佈上線之前，進行一個外部的測試。
如圖，最右側部分是服務降級、日誌記錄、監控告警，這三個都是我們整個閘道的支撐系統。服務降級是說當有些服務出現問題，第一時間把它降調；日誌是給我們排查問題用的；監控告警在下文會重點介紹，因為一個閘道的可用性很大方面是通過監控系統來完善的，沒有監控系統、沒有告警，就像沒有眼睛一樣，沒辦法知道任何事。
第三層：後端各種各樣的業務API（業務介面）。這些介面通過閘道對外進行暴露。
整個閘道大體上分為以上三層，最上面的接入層、中間是閘道的分發層，以及業務校驗、業務邏輯層，然後通過閘道透傳請求到後端服務。
除了這三層之外，我們再看兩邊的系統，都是我們整個閘道比較核心和重要的支撐。
● 閘道註冊中心。後端各種各樣的介面可以通過閘道註冊中心對外進行發佈，這個系統有一個類似管理介面，只要後端的API服務按照固有的協定進行一個編寫，如果格式OK的話上傳到管理後臺，一鍵就可以發佈到線上。當然介面發佈之前會有一個測試。
● OA鑒權中心。這一塊主要是做鑒權用的，像資料校驗層的很多簽名的校驗等安全校驗都是在這一層統一做的。
2.2 技術棧
我們的閘道系統所涉及到的一些技術棧：第一是接入層Nginx+lua技術；第二是NIO+Serviet3非同步的技術；第三是分離技術；第四是降級限流；第五是熔斷技術；第六是緩存，哪些地方該加緩存，哪些地方可以直接讀庫；第七是異構數據；第八是快速失敗；最後是監控統計，這是整個高可用閘道系統裡非常重要的一部分。
下文會針對這些技術所適用的場景進行深入探討和分析，包括我們用這些技術解決什麼問題。
3基本思路及過程改進點
實踐 1 Nginx層統一接入
先看閘道整個線上的部署架構，先通過一個軟負載LVS進入到整個京東的閘道，第一層是核心Nginx，經過核心Nginx之後就是後面的業務Nginx，然後通過業務Nginx把我們的請求透傳到後端的伺服器。
核心Nginx主要是前端流量的分配，比如限流、防刷都是在這層去做。下層是業務Nginx，主要的Nginx+lua的邏輯在這一層實現。這一層還有能減輕核心Nginx壓力、CPU壓力的作用，而且一些lua的應用邏輯，比如限流、防刷、鑒權、降級都是在這一層做的。
為什麼要加上Nginx+lua這一層？相較於Tomcat等，Nginx其實是一個能扛特別大併發流量的伺服器。基於這種狀況我們之前出現過問題，當這種併發流量特別大的時候，一旦後面出現單個機有問題，哪怕你針對這個介面做了降級，但其實真正流量還是到了Tomcat層的JVM裡，當流量很大的時候，很難通過JVM去消化掉這塊東西，這樣導致的結果是：當你的Tomcat出現問題了，你很難通過重啟去解決這個問題，因為流量會一直存在，這台Tomcat出問題了， 重啟完之後是把所有行動都釋放了，但是它們就像病毒一樣，會來回傳染，你重啟了一批，這批馬上又被傳染到。Nginx天然就是這種NIO非同步的方式，能夠非常好地支持大併發的業務需求。所以我們把一些核心的，比如降級、流控等，都放在這一層，讓它替我們在最前端把流量防住。
實踐 2 引入NIO、利用Servlet3非同步化
第二個實踐是在Tomcat層引入了NIO，用了一個JDK7+TOMCAT7+Servlet3的配置，讓同步請求變得非同步化，然後利用NIO的多工處理技術，讓我們能夠同時處理更高的併發數。
利用Servlet3非同步化之後可以提升輸送量，但單個請求的回應時間會略微變長，不過這種損耗是可以忍受的，因為這會帶來整個應用輸送量的增加和靈活性的增強。還是非常值得我們使用的。
具體採用策略：業務方法開啟非同步化上下文AsynContext;釋放tomcat當前處理執行緒；tomcat該執行緒被釋放，然後用於下次請求的處理，提高其輸送量；在AsynContext環境中完成業務方法的處理，調用其complete方法，將回應寫迴響應流。這樣可以提高tomcat業務邏輯的可能性，讓我們在這一層非常少的執行緒數就能處理更多的請求，而不至於當流量非常大的時候會被壓垮。
實踐 3 分離之術
本節將在所有分離技術中挑兩個比較重點的進行分享。
請求解析和業務處理分離
第一個是通過NIO的方式，把請求解析的執行緒和後面處理的業務執行緒進行分離。
請求由tomcat單執行緒，在NIO模式下可以用非常少量執行緒大量連結情況。業務邏輯處理和生成回應都是由另外的tomcat執行緒池處理，從而跟請求執行緒隔離。這裡的業務執行緒池還可以進一步隔離，不同業務設置不同的執行緒池。
業務執行緒池分離
第二個是業務執行緒池分離，就是通過一個執行緒的隔離技術，把不同的介面或不同類型的介面進行隔離。比如訂單相關的介面，拿20個單獨執行緒去處理；商品相關的介面，拿10個單獨的執行緒去處理，這樣的話就可以讓不同的介面之間互不影響，如果訂單這塊有一個出了問題，最多消耗它自己，不會影響到其他介面的執行緒的調用。
具體的執行緒隔離可以根據業務來指定一組執行緒的數量，這幾個執行緒是為固定介面準備的，當這個介面出現問題，它就把自己的執行緒數用掉了，不會去佔用其他介面的執行緒，這樣起到了執行緒隔離的作用，讓單個API出問題的時候不會影響到其他。
實踐 4 降級
降級主要是說當有某個介面出現問題，我們能夠把這個介面直接降調，讓它調用直接返回，不會用到其他應用。還有就是如果某一塊弱一點的業務邏輯出現問題，我們直接把這塊邏輯降調，不至於影響到其他的黃金邏輯。
降級怎麼做？
首先，降級開關要集中化管理，比如通過zookeeper推送到各個應用服務。這樣才能在出現問題的第一時間找到對應開關做降級處理。
一個基於開發降級的統一配置本身這個系統要是高可用的、支援多維度的緩存，比如我們如果用zookeeper實現，首先zookeeper會有資料庫存儲，再上面會有一個本地緩存。再就是我們會有一個快照，如果zookeeper讀不到緩存，會通過快照去載入進來一些托底的資料，以保證開發一旦觸發之後能夠在第一時間回應。而我們的開關也不至於會成為其他系統的問題，它是非常弱化、非常薄的一層。
精細化流量控制
說完開關、流量控制和降級之後，我們來看通過多維度的流量控制和降級的策略，比如按照單個API或API+地域、運營商等維度進行控制。一旦出問題了，我們會把多種組合方式進行降級，還可以根據秒/分鐘級等不同維度進行流量控制，從而達到精細化流量管理。
優雅降級
說到降級，前面說的更多的是技術層面的，在業務層面的話，我們也要講究優雅降級。我們不能說這個邏輯一旦建立之後就直接返回前端502，這肯定是不友好的。我們肯定會跟前端進行溝通，比如降級之後回饋給前端一個對應的錯誤碼，或者給使用者回饋一個提示等操作指令，這樣能夠讓使用者體驗更好一些。
實踐 5 限流
惡意請求、惡意攻擊，惡意的請求流量可以只訪問cache，惡意的IP可以使用nginx層的 deny進行屛蔽；
防止流程超出系統的承載能力，雖然會預估但總有意外，如果沒有限流，當超過系統承載峰值的時候，整個系統就會打垮。
1、具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加群。
2、在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加群。
3、如果沒有工作經驗，但基礎非常扎實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的，可以加群。
4、覺得自己很牛B，一般需求都能搞定。但是所學的知識點沒有系統化，很難在技術領域繼續突破的可以加群。
5.群號：521479582 高級開發
6.阿裡Java高級大牛直播講解知識點，分享知識，多年工作經驗的梳理和總結，帶著大家全面、科學地建立自己的技術體系和技術認知。
實踐 6 熔斷
當我們的後端機構出現問題了，達到某個閥值了，系統就能夠自動進行關閉降級，這是熔斷的大體思路。我們會有更靈活的配置：比如當某個介面接連三次訪問超時或返回錯誤的話就自動熔斷；也可以是配置一些超時間，比如連續三次這種方法調用的性能都超過了50毫秒，就會自動對這個方法進行熔斷，熔斷之後就相當於降級了，再次調用的話會返回失敗，就是直接拒絕返回了。
熔斷之後還可以有一個設置：比如5秒或一分鐘之後出來一個半打開狀態，再次醒來之後，它會去試探一下當天這個服務是否已經OK了，如果沒有問題了，它就會去把你之前熔斷的API業務再次打開，能夠正常對外提供服務。現在有一些開源的實踐，通過這些實踐可以很好的做熔斷，當然根據這裡邊的思路，自己也可以實現，這不是特別複雜的事情。
實踐 7 快速失敗-鏈路中的超時
快速失敗是非常重要的一個實踐，不光是做閘道系統，做其他系統也要記住，特別是調用量大的系統，比如注意到整個鏈條中的超時設置。這是我們每年在做雙11和618備戰的時候，都需要重點去review的一塊東西，包括我們平時在做開發的時候、每一次新模組上線之前，我們都要重點去監控這一塊。我們會梳理所有系統對外的依賴，比如閘道依賴於我們自己的一些業務的緩存、資料庫，更多的是依賴於後端數千個不同的服務。
這種涉及到網路的，我們必須要設置超時間，因為像閘道這種調用量比較大的系統，如果不設超時間，有可能它默認時間就是幾分鐘，這麼長時間，一旦有一個機構出問題了，有可能瞬間整個閘道系統會全部雪崩掉，任何一個介面都不能對外使用，因為資料量很大，有可能你都來不及降級就已經被衝垮了。
實踐 8 監控統計-應用層
監控統計是閘道系統裡非常核心的一部分，只有有了監控，有了報警，才能讓我們即時瞭解所有的運營情況、每一個API調用的情況。
監控目標
第一：保證7*24小時守護系統；
第二：能夠即時監控系統的運營狀況，比如哪個API是不是調用時間過長了？哪個API已經熔斷了？等等；
第三：統計資料，分析指標。比如一天過去了，每一個API調用情況有沒有超時？有沒有訪問的性能降低等；
第四：即時報警。因為監控是一部分，發現問題之後能夠第一時間通知到我們，讓我們能夠馬上處理也是讓系統更加健康的一個方面。
監控範圍
監控的維度
第一層：硬體監控。比如系統的CPU記憶體、網卡等。
第二層：自訂監控。比如直接報警。
第三層：性能監控。比如每個介面的TP指標，TP999 TP99 TP90 TP50四種性能指標作為SLA的參考標準，還有可用率等，這個對於閘道來說至關重要。
第四層：心跳監控。閘道系統線上有很多機器，每個機器現在的情況怎樣？有沒有存貨等。
第五層：業務層監控。比如我們會有一些JVM監控，監控Nginx連接數等。
在京東內部有一個很完善的監控體系，叫UMP系統，能夠説明我們做各個層級的監控。它主要是提供給我們一些類似於配置的檔，我們配置好之後就可以進行系統的監控，我們在做的時候會通過一些AOP代理的方式，對所有的方法進行監控。因為我們是閘道，需要大量的後端透傳，閘道因為是動態地生成這些介面，根本不知道有哪些介面，所以在動態生成介面的時候自動地AOP給它注入一個個監控，這樣的話就是每一個介面都能夠有一個監控。
說到監控不得不提的是，我們做閘道系統就是做透傳的，後面有各種各樣不同的介面、業務邏輯，每個業務邏輯和介面的性能都需要去監控，然後告知對方讓對方去整改的，所以我們除了把這些監控加完之後，有了問題要能夠通知到對應的負責人，包括我們自己。所以我們每一天每一周都會有郵件以報表形式發出，讓所有系統負責人都知道對應的機構的情況，比如性能是否有問題、是否需要整改等。
1、具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加群。
2、在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加群。
3、如果沒有工作經驗，但基礎非常扎實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的，可以加群。
4、覺得自己很牛B，一般需求都能搞定。但是所學的知識點沒有系統化，很難在技術領域繼續突破的可以加群。
5.群號：521479582 高級開發
6.阿裡Java高級大牛直播講解知識點，分享知識，多年工作經驗的梳理和總結，帶著大家全面、科學地建立自己的技術體系和技術認知。