喜馬拉雅自研網關架構實踐

1-     背景     -
2

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

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

網關除了要實現最基本的功能反向代理外，還有公有特性，比如黑白名單，流控，鑑權，熔斷，API 發佈，監控和報警等，我們還根據業務方的需求實現了流量調度，流量 Copy，預發佈，智能化升降級，流量預熱等相關功能，下面就我們網關在這些方便的一些實踐經驗以及發展歷程，下面是喜馬拉雅網關的演化過程：

1-     第一版 Tomcat nio + AsyncServlet     -
2

網關在架構設計時最爲關鍵點，就是網關在接收到請求，調用後端服務時不能阻塞 Block，否則網關的吞吐量很難上去，因爲最耗時的就是調用後端服務這個遠程調用過程，如果這裏是阻塞的，Tomcat 的工作線程都 block 主了，在等待後端服務響應的過程中，不能去處理其他的請求，這個地方一定要異步。

架構圖如下：

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

但是這版只是功能上達到網關的要求，處理能力很快就成了瓶頸，單機 qps 到 5k 的時候，就會不停的 full gc，後面通過 dump 線上的堆分析，發現全是 Tomcat 緩存了很多 HTTP 的請求，因爲 Tomcat 默認會緩存 200 個 requestProcessor，每個 prcessor 都關聯了一個 request，還有就是 Servlet 3.0 Tomcat 的異步實現會出現內存泄漏，後面通過減少這個配置，效果明顯。但性能肯定就下降了，總結了下，基於 Tomcat 做爲接入端，有如下幾個問題：

Tomcat 自身的問題：

• 緩存太多，Tomcat 用了很多對象池技術，內存有限的情況下，流量一高很容易觸發 gc。

• 內存 copy，Tomcat 的默認是用堆內存，所以數據需要讀到堆內，而我們後端服務是 Netty，有堆外內存，需要通過數次 copy。

• Tomcat 還有個問題是讀 body 是阻塞的, Tomcat 的 NIO 模型和 reactor 模型不一樣，讀 body 是 block 的。

這裏再分享一張 Tomcat buffer 的關係圖：

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

HttpNioClient 的問題：

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

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

1-     第二版 Netty + 全異步     -
2

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

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

接入層

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

對 HTTP 協議的編解碼做了優化，對異常，攻擊性請求監控可視化。比如我們對 HTTP 的請求行和請求頭大小是有限制的，Tomcat 是請求行和請求加在一起，不超過 8k，Netty 是分別有大小限制。假如客戶端發送了超過閥值的請求，帶 cookie 的請求很容易超過，正常情況下，Netty 就直接響應 400 給客戶端。

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

業務邏輯層

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

在業界和一些大廠的網關設計中，業務邏輯層基本都是設計成責任鏈模式，公有的業務邏輯也在這層實現，我們在這層也是相同的套路，支持了：

• 用戶鑑權和登陸校驗，支持接口級別配置。

• 黑白名單，分全局和應用，以及 ip 維度，參數級別。

• 流量控制，支持自動和手動，自動是對超大流量自動攔截，通過令牌桶算法實現。

• 智能熔斷，在 histrix 的基礎上做了改進，支持自動升降級，我們是全部自動的，也支持手動配置立即熔斷，就是發現服務異常比例達到閥值，就自動觸發熔斷。

• 灰度發佈，我對新啓動的機器的流量支持類似 tcp 的慢啓動機制，給機器一個預熱的時間窗口。

• 統一降級，我們對所有轉發失敗的請求都會找統一降級的邏輯，只要業務方配了降級規則，都會降級，我們對降級規則是支持到參數級別的，包含請求頭裏的值，是非常細粒度的，另外我們還會和 varnish 打通，支持 varnish 的優雅降級。

• 流量調度，支持業務根據篩選規則，對流量篩選到對應的機器，也支持只讓篩選的流量訪問這臺機器，這在查問題 / 新功能發佈驗證時非常用，可以先通過小部分流量驗證再大面積發佈上線。

• 流量 copy，我們支持對線上的原始請求根據規則 copy 一份，寫入到 mq 或者其他的 upstream，來做線上跨機房驗證和壓力測試。

• 請求日誌採樣，我們對所有的失敗的請求都會採樣落盤，提供業務方排查問題支持，也支持業務方根據規則進行個性化採樣，我們採樣了整個生命週期的數據，包含請求和響應相關的所有數據。

上面提到的這麼多都是對流量的治理，我們每個功能都是一個 filter，處理失敗都不影響轉發流程，而且所有的這些規則的元數據在網關啓動時就會全部初始化好。在執行的過程中，不會有 IO 操作，目前有些設計會對多個 filter 做併發執行，由於我們的都是內存操作，開銷並不大，所以我們目前並沒有支持併發執行。

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

服務調用層

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

異步 Push

網關在發起服務調用後，讓工作線程繼續處理其他的請求，而不需要等待服務端返回，這裏的設計是我們爲每個請求都會創建一個上下文，我們在發完請求後，把該請求的 context 綁定到對應的連接上，等 Netty 收到服務端響應時，就會在給連接上執行 read 操作。

解碼完後，再從給連接上獲取對應的 context，通過 context 可以獲取到接入端的 session，這樣 push 就通過 session 把響應寫回客戶端了，這樣設計也是基於 HTTP 的連接是獨佔的，即連接和請求上下文綁定。

連接池

連接池的原理如下圖：

• Connection:close

• 空閒超時，關閉連接

• 讀超時關閉連接

• 寫超時，關閉連接

• Fin,Reset

Connection:close

後端服務是 Tomcat，Tomcat 對連接重用的次數是有限制的，默認是 100 次，當達到 100 次後，Tomcat 會通過在響應頭裏添加 Connection:close，讓客戶端關閉該連接，否則如果再用該連接發送的話，會出現 400。

還有就是如果端上的請求帶了 connection:close, 那 Tomcat 就不等這個連接重用到 100 次，即一次就關閉，通過在響應頭裏添加 Connection:close，即成了短連接，這個在和 Tomcat 保持長連接時，需要注意的，如果要利用，就要主動 remove 掉這個 close 頭。

寫超時

首先網關什麼時候開始計算服務的超時時間，如果從調用 writeAndFlush 開始就計算，這其實是包含了 Netty 對 HTTP 的 encode 時間和從隊列裏把請求發出去即 flush 的時間，這樣是對後端服務不公平的，所以需要在真正 flush 成功後開始計時，這樣是和服務端最接近的，當然還包含了網絡往返時間和內核協議棧處理的時間，這個不可避免，但基本不變。

所以我們是 flush 成功回調後開始啓動超時任務，這裏就有個注意的地方，如果 flush 不能快速回調，比如來了一個大的 post 請求，body 部分比較大，而 Netty 發送的時候第一次默認是發 1k 的大小，如果還沒有發完，則增大發送的大小繼續發，如果在 Netty 在 16 次後還沒有發送完成，則不會再繼續發送，而是提交一個 flushTask 到任務隊列，待下次執行到後再發送。

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

全鏈路超時機制

下面是我們在整個鏈路超時處理的機制。

• 協議解析超時

• 等待隊列超時

• 建連超時

• 等待連接超時

• 寫前檢查是否超時

• 寫超時

• 響應超時

監控報警

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

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

協議層

• 攻擊性請求，只發頭，不發 / 發部分 body，採樣落盤，還原現場，並報警

• Line or Head or Body 過大的請求，採樣落盤，還原現場，並報警

應用層

• 耗時監控，有慢請求，超時請求，以及 tp99，tp999 等

• qps 監控和報警

• 帶寬監控和報警，支持對請求和響應的行，頭，body 單獨監控。

• 響應碼監控，特別是 400，和 404

• 連接監控，我們對接入端的連接，以及和後端服務的連接，後端服務連接上待發送字節大小也都做了監控

• 失敗請求監控

• 流量抖動報警，這是非常有必要的，流量抖動要麼是出了問題，要麼就是出問題的前兆。

1-     性能優化實踐     -
2

對象池技術

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

上下文切換

高併發系統，通常都採用異步設計，異步化後，不得不考慮線程上下文切換的問題，我們的線程模型如下：

我們整個網關沒有涉及到 IO 操作，但我們在業務邏輯這塊還是和 Netty 的 IO 編解碼線程異步，是有兩個原因，1）是防止開發寫的代碼有阻塞，2）是業務邏輯打日誌可能會比較多，在突發的情況下，在 push 線程時，支持用 Netty 的 IO 線程替代，這裏做的工作比較少，這裏有異步修改爲同步後 (通過修改配置調整)，CPU 的上下文切換減少 20%，進而提高了整體的吞吐量，就是不能爲了異步而異步，zull2 的設計和我們的類似。

GC 優化

在高併發系統，GC 的優化不可避免，我們在用了對象池技術和堆外內存時，對象很少進入老年代，另外我們年輕代會設置的比較大，而且  SurvivorRatio=2，晉升年齡設置最大 15，儘量對象在年輕代就回收掉， 但監控發現老年代的內存還是會緩慢增長。

通過 dump 分析，我們每個後端服務創建一個連接，都時有一個 socket，socket 的 AbstractPlainSocketImpl，而 AbstractPlainSocketImpl 就重寫了 Object 類的 finalize 方法，實現如下：

1/**
2     * Cleans up if the user forgets to close it.
3     */
4    protected void finalize() throws IOException {
5        close();
6    }
7

是爲了我們沒有主動關閉連接，做的一個兜底，在 GC 回收的時候，先把對應的連接資源給釋放了，由於 finalize 的機制是通過 JVM 的 Finalizer 線程來處理的，而且 Finalizer 線程的優先級不高，默認是 8，需要等到 Finalizer 線程把 ReferenceQueue 的對象對於的 finalize 方法執行完，還要等到下次 GC 時，才能把該對象回收，導致創建連接的這些對象在年輕代不能立即回收，從而進入了老年代，這也是爲啥老年代會一直緩慢增長的問題。

日誌

高併發下，特別是 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 住，所以我們在打日誌時，也要注意精簡。

未來規劃

現在我們都是基於 HTTP/1，現在 HTTP/2 相對於 HTTP/1 關鍵實現了在連接層面的服務，即一個連接上可以發送多個 HTTP 請求，即 HTTP 連接也能和 rpc 連接一樣，建幾個連接就可以了，徹底解決了 HTTP/1 連接不能複用導致每次都建連和慢啓動的開銷。

我們也在基於 Netty 升級到 HTTP/2, 除了技術升級外，我們對監控報警也一直在持續優化，怎麼提供給業務方準確無誤的報警，也是一直在努力，還有一個就是降級，作爲統一接入網關，和業務方做好全方位的降級措施，也是一直在完善的點，保證全站任何故障都能通過網關第一時間降級，也是我們的重點。

1-     總結     -
2

網關已經是一個互聯網公司的標配，這裏總結實踐過程中的一些心得和體會，希望給大家一些參考以及一些問題的解決思路，歡迎交流，我們也還在不斷完善中，同時我們也在做多活，雲原生，穩定性平臺等項目，喜馬拉雅平臺架構有機會有挑戰，目前正在大力招攬人才，感興趣的同學可以加入我們。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/XS1_dSDqebUL85gtJn-DeA