本文由喜馬拉雅技術團隊原創分享，原題《喜馬拉雅自研網關架構實踐》，有改動。

1、引言

網關是一個比較成熟的產品，基本上各大互聯網公司都會有網關這個中間件，來解決一些公有業務的上浮，而且能快速的更新迭代。如果沒有網關，要更新一個公有特性，就要推動所有業務方都更新和發布，那是效率極低的事，有網關后，這一切都變得不是問題。

喜馬拉雅也是一樣，用戶數增長達到 6 億多的級別，Web 服務個數達到500+，目前我們網關日處理 200 億+次調用，單機 QPS 高峰達到 4w+。

網關除了要實現最基本的功能反向代理外，還有公有特性，比如黑白名單，流控，鑒權，熔斷，API 發布，監控和報警等。我們還根據業務方的需求實現了流量調度，流量 Copy，預發布，智能化升降級，流量預熱等相關功能。

從技術上來說，喜馬拉雅API網關的技術演進路線圖大致如下：

本文將分享在喜馬拉雅API網關在億級流量前提下，進行的技術演進發展歷程和實踐經驗總結。

（本文同步發布于：http://www.52im.net/thread-3564-1-1.html）

2、專題目錄

本文是系列文章的第5篇，總目錄如下：

《長連接網關技術專題(一)：京東京麥的生產級TCP網關技術實踐總結》

《長連接網關技術專題(二)：知乎千萬級并發的高性能長連接網關技術實踐》

《長連接網關技術專題(三)：手淘億級移動端接入層網關的技術演進之路》

《長連接網關技術專題(四)：愛奇藝WebSocket實時推送網關技術實踐》

《長連接網關技術專題(五)：喜馬拉雅自研億級API網關技術實踐》（* 本文）

3、第1版：Tomcat NIO+Async Servlet

網關在架構設計時最為關鍵點，就是網關在接收到請求，調用后端服務時不能阻塞 Block，否則網關的吞吐量很難上去，因為最耗時的就是調用后端服務這個遠程調用過程。

如果這里是阻塞的，Tomcat 的工作線程都 block 住了，在等待后端服務響應的過程中，不能去處理其他的請求，這個地方一定要異步。

架構圖如下：

這版我們實現單獨的 Push 層，作為網關收到響應后，響應客戶端時，通過這層實現，和后端服務的通信是 HttpNioClient，對業務的支持黑白名單，流控，鑒權，API 發布等功能。

但是這版只是功能上達到網關的要求，處理能力很快就成了瓶頸，單機 QPS 到 5K 的時候，就會不停的 Full GC。

后面通過 Dump 線上的堆分析，發現全是 Tomcat 緩存了很多 HTTP 的請求，因為 Tomcat 默認會緩存 200 個 requestProcessor，每個 prcessor 都關聯了一個 request。

還有就是 Servlet 3.0 Tomcat 的異步實現會出現內存泄漏，后面通過減少這個配置，效果明顯。

但性能肯定就下降了，總結了下，基于 Tomcat 做為接入端，有如下幾個問題。

Tomcat 自身的問題：

• 1）緩存太多，Tomcat 用了很多對象池技術，內存有限的情況下，流量一高很容易觸發 GC；
• 2）內存 Copy，Tomcat 的默認是用堆內存，所以數據需要讀到堆內，而我們后端服務是 Netty，有堆外內存，需要通過數次 Copy；
• 3）Tomcat 還有個問題是讀 body 是阻塞的, Tomcat 的 NIO 模型和 reactor 模型不一樣，讀 body 是 block 的。

這里再分享一張 Tomcat buffer 的關系圖：

通過上面的圖，我們可以看出，Tomcat 對外封裝的很好，內部默認的情況下會有三次 copy。

HttpNioClient 的問題：獲取和釋放連接都需要加鎖，對應網關這樣的代理服務場景，會頻繁的建連和關閉連接，勢必會影響性能。

基于 Tomcat 的存在的這些問題，我們后面對接入端做改造，用 Netty 做接入層和服務調用層，也就是我們的第二版，能徹底解決上面的問題，達到理想的性能。

4、第2版：Netty+全異步

基于 Netty 的優勢，我們實現了全異步，無鎖，分層的架構。

先看下我們基于 Netty 做接入端的架構圖：

PS：如果你對Netty和Java NIO了解太少，下面幾篇資料請務必閱讀：

《少啰嗦！一分鐘帶你讀懂Java的NIO和經典IO的區別》

《Java的BIO和NIO很難懂？用代碼實踐給你看，再不懂我轉行！》

《史上最強Java NIO入門：擔心從入門到放棄的，請讀這篇！》

《寫給初學者：Java高性能NIO框架Netty的學習方法和進階策略》

《新手入門：目前為止最透徹的的Netty高性能原理和框架架構解析》

《史上最通俗Netty框架入門長文：基本介紹、環境搭建、動手實戰》

4.1 接入層

Netty 的 IO 線程，負責 HTTP 協議的編解碼工作，同時對協議層面的異常做監控報警。

對 HTTP 協議的編解碼做了優化，對異常，攻擊性請求監控可視化。比如我們對 HTTP 的請求行和請求頭大小是有限制的，Tomcat 是請求行和請求加在一起，不超過 8K，Netty 是分別有大小限制。

假如客戶端發送了超過閥值的請求，帶 cookie 的請求很容易超過，正常情況下，Netty 就直接響應 400 給客戶端。

經過改造后，我們只取正常大小的部分，同時標記協議解析失敗，到業務層后，就可以判斷出是那個服務出現這類問題，其他的一些攻擊性的請求，比如只發請求頭，不發 body 或者發部分這些都需要監控和報警。

4.2 業務邏輯層

負責對 API 路由，流量調度等一序列的支持業務的公有邏輯，都在這層實現，采樣責任鏈模式，這層不會有 IO 操作。

在業界和一些大廠的網關設計中，業務邏輯層基本都是設計成責任鏈模式，公有的業務邏輯也在這層實現。

我們在這層也是相同的套路，支持了：

• 1）用戶鑒權和登陸校驗，支持接口級別配置；
• 2）黑白名單：分全局和應用，以及 IP 維度，參數級別；
• 3）流量控制：支持自動和手動，自動是對超大流量自動攔截，通過令牌桶算法實現；
• 4）智能熔斷：在 Histrix 的基礎上做了改進，支持自動升降級，我們是全部自動的，也支持手動配置立即熔斷，就是發現服務異常比例達到閥值，就自動觸發熔斷；
• 5）灰度發布：我對新啟動的機器的流量支持類似 TCP 的慢啟動機制，給機器一個預熱的時間窗口；
• 6）統一降級：我們對所有轉發失敗的請求都會找統一降級的邏輯，只要業務方配了降級規則，都會降級，我們對降級規則是支持到參數級別的，包含請求頭里的值，是非常細粒度的，另外我們還會和 varnish 打通，支持 varnish 的優雅降級；
• 7）流量調度：支持業務根據篩選規則，對流量篩選到對應的機器，也支持只讓篩選的流量訪問這臺機器，這在查問題/新功能發布驗證時非常用，可以先通過小部分流量驗證再大面積發布上線；
• 8）流量 copy：我們支持對線上的原始請求根據規則 copy 一份，寫入到 MQ 或者其他的 upstream，來做線上跨機房驗證和壓力測試；
• 9）請求日志采樣：我們對所有的失敗的請求都會采樣落盤，提供業務方排查問題支持，也支持業務方根據規則進行個性化采樣，我們采樣了整個生命周期的數據，包含請求和響應相關的所有數據。

上面提到的這么多都是對流量的治理，我們每個功能都是一個 filter，處理失敗都不影響轉發流程，而且所有的這些規則的元數據在網關啟動時就會全部初始化好。

在執行的過程中，不會有 IO 操作，目前有些設計會對多個 filter 做并發執行，由于我們的都是內存操作，開銷并不大，所以我們目前并沒有支持并發執行。

還有個就是規則會修改，我們修改規則時，會通知網關服務，做實時刷新，我們對內部自己的這種元數據更新的請求，通過獨立的線程處理，防止 IO 在操作時影響業務線程。

4.3 服務調用層

服務調用對于代理網關服務是關鍵的地方，一定需要異步，我們通過 Netty 實現，同時也很好的利用了 Netty 提供的連接池，做到了獲取和釋放都是無鎖操作。

4.3.1）異步 Push：

網關在發起服務調用后，讓工作線程繼續處理其他的請求，而不需要等待服務端返回。

這里的設計是我們為每個請求都會創建一個上下文，我們在發完請求后，把該請求的 context 綁定到對應的連接上，等 Netty 收到服務端響應時，就會在給連接上執行 read 操作。

解碼完后，再從給連接上獲取對應的 context，通過 context 可以獲取到接入端的 session。

這樣 push 就通過 session 把響應寫回客戶端了，這樣設計也是基于 HTTP 的連接是獨占的，即連接和請求上下文綁定。

4.3.2）連接池：

連接池的原理如下圖：

服務調用層除了異步發起遠程調用外，還需要對后端服務的連接進行管理。

HTTP 不同于 RPC，HTTP 的連接是獨占的，所以在釋放的時候要特別小心，一定要等服務端響應完了才能釋放，還有就是連接關閉的處理也要小心。

總結如下幾點：

• 1）Connection:close；
• 2）空閑超時，關閉連接；
• 3）讀超時關閉連接；
• 4）寫超時，關閉連接；
• 5）Fin、Reset。

上面幾種需要關閉連接的場景，下面主要說下 Connection:close 和空閑寫超時兩種，其他的應該是比較常見的比如讀超時，連接空閑超時，收到 fin，reset 碼這幾個。

4.3.3）Connection:close：

后端服務是 Tomcat，Tomcat 對連接重用的次數是有限制的，默認是 100 次。

當達到 100 次后，Tomcat 會通過在響應頭里添加 Connection:close，讓客戶端關閉該連接，否則如果再用該連接發送的話，會出現 400。

還有就是如果端上的請求帶了 connection:close，那 Tomcat 就不等這個連接重用到 100 次，即一次就關閉。

通過在響應頭里添加 Connection:close，即成了短連接，這個在和 Tomcat 保持長連接時，需要注意的，如果要利用，就要主動 remove 掉這個 close 頭。

4.3.4）寫超時：

首先網關什么時候開始計算服務的超時時間，如果從調用 writeAndFlush 開始就計算，這其實是包含了 Netty 對 HTTP 的 encode 時間和從隊列里把請求發出去即 flush 的時間，這樣是對后端服務不公平的。

所以需要在真正 flush 成功后開始計時，這樣是和服務端最接近的，當然還包含了網絡往返時間和內核協議棧處理的時間，這個不可避免，但基本不變。

所以我們是 flush 成功回調后開始啟動超時任務。

這里就有個注意的地方：如果 flush 不能快速回調，比如來了一個大的 post 請求，body 部分比較大，而 Netty 發送的時候第一次默認是發 1k 的大小。

如果還沒有發完，則增大發送的大小繼續發，如果在 Netty 在 16 次后還沒有發送完成，則不會再繼續發送，而是提交一個 flushTask 到任務隊列，待下次執行到后再發送。

這時 flush 回調的時間就比較大，導致這樣的請求不能及時關閉，而且后端服務 Tomcat 會一直阻塞在讀 body 的地方，基于上面的分析，所以我們需要一個寫超時，對大的 body 請求，通過寫超時來及時關閉。

5、全鏈路超時機制

上圖是我們在整個鏈路超時處理的機制：

• 1）協議解析超時；
• 2）等待隊列超時；
• 3）建連超時；
• 4）等待連接超時；
• 5）寫前檢查是否超時；
• 6）寫超時；
• 7）響應超時。

6、監控報警

網關業務方能看到的是監控和報警，我們是實現秒級別報警和秒級別的監控，監控數據定時上報給我們的管理系統，由管理系統負責聚合統計，落盤到 influxdb。

我們對 HTTP 協議做了全面的監控和報警，無論是協議層的還是服務層的。

協議層：

• 1）攻擊性請求，只發頭，不發/發部分 body，采樣落盤，還原現場，并報警；
• 2）Line or Head or Body 過大的請求，采樣落盤，還原現場，并報警。

應用層：

• 1）耗時監控：有慢請求，超時請求，以及 tp99，tp999 等；
• 2）OPS 監控和報警；
• 3）帶寬監控和報警：支持對請求和響應的行，頭，body 單獨監控；
• 4）響應碼監控：特別是 400，和 404；
• 5）連接監控：我們對接入端的連接，以及和后端服務的連接，后端服務連接上待發送字節大小也都做了監控；
• 6）失敗請求監控；
• 7）流量抖動報警：這是非常有必要的，流量抖動要么是出了問題，要么就是出問題的前兆。

總體架構：

7、性能優化實踐

7.1 對象池技術

對于高并發系統，頻繁的創建對象不僅有分配內存的開銷外，還有對gc會造成壓力，我們在實現時會對頻繁使用的比如線程池的任務task，StringBuffer等會做寫重用，減少頻繁的申請內存的開銷。

7.2 上下文切換

高并發系統，通常都采用異步設計，異步化后，不得不考慮線程上下文切換的問題。

我們的線程模型如下：

我們整個網關沒有涉及到io操作，但我們在業務邏輯這塊還是和netty的io編解碼線程異步。

是有兩個原因：

• 1）是防止開發寫的代碼有阻塞；
• 2）是業務邏輯打日志可能會比較多，在突發的情況下，但是我們在push線程時，支持用netty的io線程替代，這里做的工作比較少，這里有異步修改為同步后(通過修改配置調整)，cpu的上下文切換減少20%，進而提高了整體的吞吐量，就是不能為了異步而異步，zull2的設計和我們的類似。

7.3 GC優化

在高并發系統，gc的優化不可避免，我們在用了對象池技術和堆外內存時，對象很少進入老年代，另外我們年輕代會設置的比較大，而且SurvivorRatio=2，晉升年齡設置最大15，盡量對象在年輕代就回收掉， 但監控發現老年代的內存還是會緩慢增長，通過dump分析，我們每個后端服務創建一個鏈接，都時有一個socket，socket的AbstractPlainSocketImpl，而AbstractPlainSocketImpl就重寫了Object類的finalize方法。

實現如下：

/**

 * Cleans up if the user forgets to close it.

 */

protected void finalize() throws IOException {

    close();

}

是為了我們沒有主動關閉鏈接，做的一個兜底，在gc回收的時候，先把對應的鏈接資源給釋放了。

由于finalize的機制是通過jvm的Finalizer線程來處理的，而且Finalizer線程的優先級不高，默認是8，需要等到Finalizer線程把ReferenceQueue的對象對于的finalize方法執行完，還要等到下次gc時，才能把該對象回收，導致創建鏈接的這些對象在年輕代不能立即回收，從而進入了老年代，這也是為啥老年代會一直緩慢增長的問題。

7.4 日志

高并發下，特別是 Netty 的 IO 線程除了要執行該線程上的 IO 讀寫操作，還有執行異步任務和定時任務，如果 IO 線程處理不過來隊列里的任務，很有可能導致新進來異步任務出現被拒絕的情況。

那什么情況下可能呢？IO 是異步讀寫的問題不大，就是多耗點 CPU，最有可能 block 住 IO 線程的是我們打的日志。

目前 Log4j 的 ConsoleAppender 日志 immediateFlush 屬性默認為 true，即每次打 log 都是同步寫 flush 到磁盤的，這個對于內存操作來說，慢了很多。

同時 AsyncAppender 的日志隊列滿了也會 block 住線程，log4j 默認的 buffer 大小是 128，而且是 block 的。

即如果 buffer 的大小達到 128，就阻塞了寫日志的線程，在并發寫日志量大的的情況下，特別是堆棧很多時，log4j 的 Dispatcher 線程會出現變慢要刷盤。

這樣 buffer 就不能快速消費，很容易寫滿日志事件，導致 Netty IO 線程 block 住，所以我們在打日志時，也要注意精簡。

8、未來規劃

現在我們都是基于 HTTP/1，現在 HTTP/2 相對于 HTTP/1 關鍵實現了在連接層面的服務，即一個連接上可以發送多個 HTTP 請求。

即 HTTP 連接也能和 RPC 連接一樣，建幾個連接就可以了，徹底解決了 HTTP/1 連接不能復用導致每次都建連和慢啟動的開銷。

我們也在基于 Netty 升級到 HTTP/2，除了技術升級外，我們對監控報警也一直在持續優化，怎么提供給業務方準確無誤的報警，也是一直在努力。

還有一個就是降級，作為統一接入網關，和業務方做好全方位的降級措施，也是一直在完善的點，保證全站任何故障都能通過網關第一時間降級，也是我們的重點。

9、寫在最后

網關已經是一個互聯網公司的標配，這里總結實踐過程中的一些心得和體會，希望給大家一些參考以及一些問題的解決思路，我們也還在不斷完善中，同時我們也在做多活的項目，歡迎交流。

附錄：更多相關資料

[1] NIO異步網絡編程資料：

《Java新一代網絡編程模型AIO原理及Linux系統AIO介紹》

《有關“為何選擇Netty”的11個疑問及解答》

《MINA、Netty的源代碼（在線閱讀版）已整理發布》

《詳解Netty的安全性：原理介紹、代碼演示（上篇）》

《詳解Netty的安全性：原理介紹、代碼演示（下篇）》

《詳解Netty的優雅退出機制和原理》

《NIO框架詳解：Netty的高性能之道》

《Twitter：如何使用Netty 4來減少JVM的GC開銷（譯文）》

《絕對干貨：基于Netty實現海量接入的推送服務技術要點》

《新手入門：目前為止最透徹的的Netty高性能原理和框架架構解析》

《寫給初學者：Java高性能NIO框架Netty的學習方法和進階策略》

《少啰嗦！一分鐘帶你讀懂Java的NIO和經典IO的區別》

《史上最強Java NIO入門：擔心從入門到放棄的，請讀這篇！》

《手把手教你用Netty實現網絡通信程序的心跳機制、斷線重連機制》

《Java的BIO和NIO很難懂？用代碼實踐給你看，再不懂我轉行！》

《史上最通俗Netty框架入門長文：基本介紹、環境搭建、動手實戰》

《長連接網關技術專題(一)：京東京麥的生產級TCP網關技術實踐總結》

《長連接網關技術專題(五)：喜馬拉雅自研億級API網關技術實踐》

>> 更多同類文章 ……

[2] 有關IM架構設計的文章：

《淺談IM系統的架構設計》

《簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端》

《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》

《一套原創分布式即時通訊(IM)系統理論架構方案》

《從零到卓越：京東客服即時通訊系統的技術架構演進歷程》

《蘑菇街即時通訊/IM服務器開發之架構選擇》

《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》

《如何解讀《微信技術總監談架構：微信之道——大道至簡》》

《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》

《移動端IM中大規模群消息的推送如何保證效率、實時性？》

《現代IM系統中聊天消息的同步和存儲方案探討》

《微信朋友圈千億訪問量背后的技術挑戰和實踐總結》

《騰訊資深架構師干貨總結：一文讀懂大型分布式系統設計的方方面面》

《以微博類應用場景為例，總結海量社交系統的架構設計步驟》

《子彈短信光鮮的背后：網易云信首席架構師分享億級IM平臺的技術實踐》

《一套高可用、易伸縮、高并發的IM群聊、單聊架構方案設計實踐》

《社交軟件紅包技術解密(一)：全面解密QQ紅包技術方案——架構、技術實現等》

《即時通訊新手入門：一文讀懂什么是Nginx？它能否實現IM的負載均衡？》

《從游擊隊到正規軍(一)：馬蜂窩旅游網的IM系統架構演進之路》

《從游擊隊到正規軍(二)：馬蜂窩旅游網的IM客戶端架構演進和實踐總結》

《從游擊隊到正規軍(三)：基于Go的馬蜂窩旅游網分布式IM系統技術實踐》

《瓜子IM智能客服系統的數據架構設計（整理自現場演講，有配套PPT）》

《阿里釘釘技術分享：企業級IM王者——釘釘在后端架構上的過人之處》

《微信后臺基于時間序的新一代海量數據存儲架構的設計實踐》

《IM開發基礎知識補課(九)：想開發IM集群？先搞懂什么是RPC！》

《阿里技術分享：電商IM消息平臺，在群聊、直播場景下的技術實踐》

《一套億級用戶的IM架構技術干貨(上篇)：整體架構、服務拆分等》

《一套億級用戶的IM架構技術干貨(下篇)：可靠性、有序性、弱網優化等》

《從新手到專家：如何設計一套億級消息量的分布式IM系統》

>> 更多同類文章 ……

[3] 更多其它架構設計相關文章：

《騰訊資深架構師干貨總結：一文讀懂大型分布式系統設計的方方面面》

《快速理解高性能HTTP服務端的負載均衡技術原理》

《子彈短信光鮮的背后：網易云信首席架構師分享億級IM平臺的技術實踐》

《知乎技術分享：從單機到2000萬QPS并發的Redis高性能緩存實踐之路》

《新手入門：零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐》

《阿里技術分享：深度揭秘阿里數據庫技術方案的10年變遷史》

《阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路》

《達達O2O后臺架構演進實踐：從0到4000高并發請求背后的努力》

《優秀后端架構師必會知識：史上最全MySQL大表優化方案總結》

《小米技術分享：解密小米搶購系統千萬高并發架構的演進和實踐》

《一篇讀懂分布式架構下的負載均衡技術：分類、原理、算法、常見方案等》

《通俗易懂：如何設計能支撐百萬并發的數據庫架構？》

《多維度對比5款主流分布式MQ消息隊列，媽媽再也不擔心我的技術選型了》

《從新手到架構師，一篇就夠：從100到1000萬高并發的架構演進之路》

《美團技術分享：深度解密美團的分布式ID生成算法》

《12306搶票帶來的啟示：看我如何用Go實現百萬QPS的秒殺系統(含源碼)》

>> 更多同類文章 ……

本文已同步發布于“即時通訊技術圈”公眾號。

▲ 本文在公眾號上的鏈接是：點此進入。同步發布鏈接是：http://www.52im.net/thread-3564-1-1.html