點(diǎn)擊關(guān)注公眾號(hào)，Java干貨及時(shí)送達(dá)??
來(lái)源：https://www.jianshu.com/p/165b1941cdfa
網(wǎng)關(guān)是一個(gè)比較成熟的產(chǎn)品，基本上各大互聯(lián)網(wǎng)公司都會(huì)有網(wǎng)關(guān)這個(gè)中間件，來(lái)解決一些公有業(yè)務(wù)的上浮，而且能快速的更新迭代，如果沒(méi)有網(wǎng)關(guān)，要更新一個(gè)公有特性，就要推動(dòng)所有業(yè)務(wù)方都更新和發(fā)布，那是效率極低的事，有網(wǎng)關(guān)后，這一切都變得不是問(wèn)題。喜馬拉雅也是一樣，用戶數(shù)增長(zhǎng)達(dá)到 6 億多的級(jí)別，Web 服務(wù)個(gè)數(shù)達(dá)到500+，目前我們網(wǎng)關(guān)日處理 200億+ 次調(diào)用，單機(jī) QPS 高峰達(dá)到 4w+。
網(wǎng)關(guān)除了要實(shí)現(xiàn)最基本的功能反向代理外，還有公有特性，比如黑白名單，流控，鑒權(quán)，熔斷，API 發(fā)布，監(jiān)控和報(bào)警等，我們還根據(jù)業(yè)務(wù)方的需求實(shí)現(xiàn)了流量調(diào)度，流量 Copy，預(yù)發(fā)布，智能化升降級(jí)，流量預(yù)熱等相關(guān)功能，下面就我們網(wǎng)關(guān)在這些方便的一些實(shí)踐經(jīng)驗(yàn)以及發(fā)展歷程，下面是喜馬拉雅網(wǎng)關(guān)的演化過(guò)程：
第一版 Tomcat nio + AsyncServlet
網(wǎng)關(guān)在架構(gòu)設(shè)計(jì)時(shí)最為關(guān)鍵點(diǎn)，就是網(wǎng)關(guān)在接收到請(qǐng)求，調(diào)用后端服務(wù)時(shí)不能阻塞 Block，否則網(wǎng)關(guān)的吞吐量很難上去，因?yàn)樽詈臅r(shí)的就是調(diào)用后端服務(wù)這個(gè)遠(yuǎn)程調(diào)用過(guò)程，如果這里是阻塞的，Tomcat 的工作線程都 block 主了，在等待后端服務(wù)響應(yīng)的過(guò)程中，不能去處理其他的請(qǐng)求，這個(gè)地方一定要異步。這版我們實(shí)現(xiàn)單獨(dú)的 Push 層，作為網(wǎng)關(guān)收到響應(yīng)后，響應(yīng)客戶端時(shí)，通過(guò)這層實(shí)現(xiàn)，和后端服務(wù)的通信是 HttpNioClient，對(duì)業(yè)務(wù)的支持黑白名單，流控，鑒權(quán)，API發(fā)布等功能。但是這版只是功能上達(dá)到網(wǎng)關(guān)的要求，處理能力很快就成了瓶頸，單機(jī) qps 到 5k 的時(shí)候，就會(huì)不停的 full gc，后面通過(guò) dump 線上的堆分析，發(fā)現(xiàn)全是 Tomcat 緩存了很多 HTTP 的請(qǐng)求，因?yàn)?Tomcat 默認(rèn)會(huì)緩存 200 個(gè) requestProcessor，每個(gè) prcessor 都關(guān)聯(lián)了一個(gè)request，還有就是 Servlet 3.0 Tomcat 的異步實(shí)現(xiàn)會(huì)出現(xiàn)內(nèi)存泄漏，后面通過(guò)減少這個(gè)配置，效果明顯。但性能肯定就下降了，總結(jié)了下，基于 Tomcat 做為接入端，有如下幾個(gè)問(wèn)題：- 緩存太多，Tomcat 用了很多對(duì)象池技術(shù)，內(nèi)存有限的情況下，流量一高很容易觸發(fā)gc。
- 內(nèi)存 copy，Tomcat 的默認(rèn)是用堆內(nèi)存，所以數(shù)據(jù)需要讀到堆內(nèi)，而我們后端服務(wù)是 Netty，有堆外內(nèi)存，需要通過(guò)數(shù)次 copy。
- Tomcat 還有個(gè)問(wèn)題是讀 body 是阻塞的, Tomcat 的 NIO 模型和 reactor 模型不一樣，讀 body 是 block 的。
這里再分享一張 Tomcat buffer 的關(guān)系圖：通過(guò)上面的圖，我們可以看出，Tomcat 對(duì)外封裝的很好，內(nèi)部默認(rèn)的情況下會(huì)有三次 copy。- 獲取和釋放連接都需要加鎖，對(duì)應(yīng)網(wǎng)關(guān)這樣的代理服務(wù)場(chǎng)景，會(huì)頻繁的建連和關(guān)閉連接，勢(shì)必會(huì)影響性能。
基于 Tomcat 的存在的這些問(wèn)題，我們后面對(duì)接入端做改造，用 Netty 做接入層和服務(wù)調(diào)用層，也就是我們的第二版，能徹底解決上面的問(wèn)題，達(dá)到理想的性能。
基于 Netty 的優(yōu)勢(shì)，我們實(shí)現(xiàn)了全異步，無(wú)鎖，分層的架構(gòu)。
先看下我們基于 Netty 做接入端的架構(gòu)圖：Netty 的 IO 線程，負(fù)責(zé) HTTP 協(xié)議的編解碼工作，同時(shí)對(duì)協(xié)議層面的異常做監(jiān)控報(bào)警。對(duì) HTTP 協(xié)議的編解碼做了優(yōu)化，對(duì)異常，攻擊性請(qǐng)求監(jiān)控可視化。比如我們對(duì) HTTP 的請(qǐng)求行和請(qǐng)求頭大小是有限制的，Tomcat 是請(qǐng)求行和請(qǐng)求加在一起，不超過(guò) 8k，Netty 是分別有大小限制。假如客戶端發(fā)送了超過(guò)閥值的請(qǐng)求，帶 cookie 的請(qǐng)求很容易超過(guò)，正常情況下，Netty 就直接響應(yīng) 400 給客戶端。經(jīng)過(guò)改造后，我們只取正常大小的部分，同時(shí)標(biāo)記協(xié)議解析失敗，到業(yè)務(wù)層后，就可以判斷出是那個(gè)服務(wù)出現(xiàn)這類問(wèn)題，其他的一些攻擊性的請(qǐng)求，比如只發(fā)請(qǐng)求頭，不發(fā) body 或者發(fā)部分這些都需要監(jiān)控和報(bào)警。負(fù)責(zé)對(duì)API路由，流量調(diào)度等一序列的支持業(yè)務(wù)的公有邏輯，都在這層實(shí)現(xiàn)，采樣責(zé)任鏈模式，這層不會(huì)有 IO 操作。
在業(yè)界和一些大廠的網(wǎng)關(guān)設(shè)計(jì)中，業(yè)務(wù)邏輯層基本都是設(shè)計(jì)成責(zé)任鏈模式，公有的業(yè)務(wù)邏輯也在這層實(shí)現(xiàn)，我們?cè)谶@層也是相同的套路，支持了：- 用戶鑒權(quán)和登陸校驗(yàn)，支持接口級(jí)別配置。
- 黑白名單，分全局和應(yīng)用，以及 ip 維度，參數(shù)級(jí)別。
- 流量控制，支持自動(dòng)和手動(dòng)，自動(dòng)是對(duì)超大流量自動(dòng)攔截，通過(guò)令牌桶算法實(shí)現(xiàn)。
- 智能熔斷，在 histrix 的基礎(chǔ)上做了改進(jìn)，支持自動(dòng)升降級(jí)，我們是全部自動(dòng)的，也支持手動(dòng)配置立即熔斷，就是發(fā)現(xiàn)服務(wù)異常比例達(dá)到閥值，就自動(dòng)觸發(fā)熔斷。
- 灰度發(fā)布，我對(duì)新啟動(dòng)的機(jī)器的流量支持類似 tcp 的慢啟動(dòng)機(jī)制，給機(jī)器一個(gè)預(yù)熱的時(shí)間窗口。
- 統(tǒng)一降級(jí)，我們對(duì)所有轉(zhuǎn)發(fā)失敗的請(qǐng)求都會(huì)找統(tǒng)一降級(jí)的邏輯，只要業(yè)務(wù)方配了降級(jí)規(guī)則，都會(huì)降級(jí)，我們對(duì)降級(jí)規(guī)則是支持到參數(shù)級(jí)別的，包含請(qǐng)求頭里的值，是非常細(xì)粒度的，另外我們還會(huì)和 varnish 打通，支持 varnish 的優(yōu)雅降級(jí)。
- 流量調(diào)度，支持業(yè)務(wù)根據(jù)篩選規(guī)則，對(duì)流量篩選到對(duì)應(yīng)的機(jī)器，也支持只讓篩選的流量訪問(wèn)這臺(tái)機(jī)器，這在查問(wèn)題/新功能發(fā)布驗(yàn)證時(shí)非常用，可以先通過(guò)小部分流量驗(yàn)證再大面積發(fā)布上線。
- 流量copy，我們支持對(duì)線上的原始請(qǐng)求根據(jù)規(guī)則 copy 一份，寫入到 mq 或者其他的 upstream，來(lái)做線上跨機(jī)房驗(yàn)證和壓力測(cè)試。
- 請(qǐng)求日志采樣，我們對(duì)所有的失敗的請(qǐng)求都會(huì)采樣落盤，提供業(yè)務(wù)方排查問(wèn)題支持，也支持業(yè)務(wù)方根據(jù)規(guī)則進(jìn)行個(gè)性化采樣，我們采樣了整個(gè)生命周期的數(shù)據(jù)，包含請(qǐng)求和響應(yīng)相關(guān)的所有數(shù)據(jù)。
上面提到的這么多都是對(duì)流量的治理，我們每個(gè)功能都是一個(gè) filter，處理失敗都不影響轉(zhuǎn)發(fā)流程，而且所有的這些規(guī)則的元數(shù)據(jù)在網(wǎng)關(guān)啟動(dòng)時(shí)就會(huì)全部初始化好。在執(zhí)行的過(guò)程中，不會(huì)有 IO 操作，目前有些設(shè)計(jì)會(huì)對(duì)多個(gè) filter 做并發(fā)執(zhí)行，由于我們的都是內(nèi)存操作，開(kāi)銷并不大，所以我們目前并沒(méi)有支持并發(fā)執(zhí)行。還有個(gè)就是規(guī)則會(huì)修改，我們修改規(guī)則時(shí)，會(huì)通知網(wǎng)關(guān)服務(wù)，做實(shí)時(shí)刷新，我們對(duì)內(nèi)部自己的這種元數(shù)據(jù)更新的請(qǐng)求，通過(guò)獨(dú)立的線程處理，防止 IO 在操作時(shí)影響業(yè)務(wù)線程。服務(wù)調(diào)用對(duì)于代理網(wǎng)關(guān)服務(wù)是關(guān)鍵的地方，一定需要異步，我們通過(guò) Netty 實(shí)現(xiàn),同時(shí)也很好的利用了 Netty 提供的連接池，做到了獲取和釋放都是無(wú)鎖操作。網(wǎng)關(guān)在發(fā)起服務(wù)調(diào)用后，讓工作線程繼續(xù)處理其他的請(qǐng)求，而不需要等待服務(wù)端返回，這里的設(shè)計(jì)是我們?yōu)槊總€(gè)請(qǐng)求都會(huì)創(chuàng)建一個(gè)上下文，我們?cè)诎l(fā)完請(qǐng)求后，把該請(qǐng)求的 context 綁定到對(duì)應(yīng)的連接上，等 Netty 收到服務(wù)端響應(yīng)時(shí)，就會(huì)在給連接上執(zhí)行 read 操作。解碼完后，再?gòu)慕o連接上獲取對(duì)應(yīng)的 context，通過(guò) context 可以獲取到接入端的 session，這樣 push 就通過(guò) session 把響應(yīng)寫回客戶端了，這樣設(shè)計(jì)也是基于 HTTP 的連接是獨(dú)占的，即連接和請(qǐng)求上下文綁定。服務(wù)調(diào)用層除了異步發(fā)起遠(yuǎn)程調(diào)用外，還需要對(duì)后端服務(wù)的連接進(jìn)行管理，HTTP 不同于 RPC，HTTP 的連接是獨(dú)占的，所以在釋放的時(shí)候要特別小心，一定要等服務(wù)端響應(yīng)完了才能釋放，還有就是連接關(guān)閉的處理也要小心，總結(jié)如下幾點(diǎn)：上面幾種需要關(guān)閉連接的場(chǎng)景，下面主要說(shuō)下 Connection:close 和空閑寫超時(shí)兩種，其他的應(yīng)該是比較常見(jiàn)的比如讀超時(shí)，連接空閑超時(shí)，收到 fin，reset 碼這幾個(gè)。后端服務(wù)是 Tomcat，Tomcat 對(duì)連接重用的次數(shù)是有限制的，默認(rèn)是100次，當(dāng)達(dá)到 100 次后，Tomcat 會(huì)通過(guò)在響應(yīng)頭里添加 Connection:close，讓客戶端關(guān)閉該連接，否則如果再用該連接發(fā)送的話，會(huì)出現(xiàn) 400。還有就是如果端上的請(qǐng)求帶了 connection:close,那 Tomcat 就不等這個(gè)連接重用到 100 次，即一次就關(guān)閉，通過(guò)在響應(yīng)頭里添加 Connection:close，即成了短連接，這個(gè)在和 Tomcat 保持長(zhǎng)連接時(shí)，需要注意的，如果要利用，就要主動(dòng) remove 掉這個(gè) close 頭。首先網(wǎng)關(guān)什么時(shí)候開(kāi)始計(jì)算服務(wù)的超時(shí)時(shí)間，如果從調(diào)用 writeAndFlush 開(kāi)始就計(jì)算，這其實(shí)是包含了 Netty 對(duì) HTTP 的 encode 時(shí)間和從隊(duì)列里把請(qǐng)求發(fā)出去即 flush 的時(shí)間，這樣是對(duì)后端服務(wù)不公平的，所以需要在真正 flush 成功后開(kāi)始計(jì)時(shí)，這樣是和服務(wù)端最接近的，當(dāng)然還包含了網(wǎng)絡(luò)往返時(shí)間和內(nèi)核協(xié)議棧處理的時(shí)間，這個(gè)不可避免，但基本不變。所以我們是 flush 成功回調(diào)后開(kāi)始啟動(dòng)超時(shí)任務(wù)，這里就有個(gè)注意的地方，如果 flush 不能快速回調(diào)，比如來(lái)了一個(gè)大的 post 請(qǐng)求，body 部分比較大，而 Netty 發(fā)送的時(shí)候第一次默認(rèn)是發(fā)1k的大小，如果還沒(méi)有發(fā)完，則增大發(fā)送的大小繼續(xù)發(fā)，如果在 Netty 在 16 次后還沒(méi)有發(fā)送完成，則不會(huì)再繼續(xù)發(fā)送，而是提交一個(gè) flushTask 到任務(wù)隊(duì)列，待下次執(zhí)行到后再發(fā)送。這時(shí) flush 回調(diào)的時(shí)間就比較大，導(dǎo)致這樣的請(qǐng)求不能及時(shí)關(guān)閉，而且后端服務(wù) Tomcat 會(huì)一直阻塞在讀 body 的地方，基于上面的分析，所以我們需要一個(gè)寫超時(shí)，對(duì)大的 body 請(qǐng)求，通過(guò)寫超時(shí)來(lái)及時(shí)關(guān)閉。下面是我們?cè)谡麄€(gè)鏈路超時(shí)處理的機(jī)制。網(wǎng)關(guān)業(yè)務(wù)方能看到的是監(jiān)控和報(bào)警，我們是實(shí)現(xiàn)秒級(jí)別報(bào)警和秒級(jí)別的監(jiān)控，監(jiān)控?cái)?shù)據(jù)定時(shí)上報(bào)給我們的管理系統(tǒng)，由管理系統(tǒng)負(fù)責(zé)聚合統(tǒng)計(jì)，落盤到influxdb。我們對(duì) HTTP 協(xié)議做了全面的監(jiān)控和報(bào)警，無(wú)論是協(xié)議層的還是服務(wù)層的。- 攻擊性請(qǐng)求，只發(fā)頭，不發(fā)/發(fā)部分 body，采樣落盤，還原現(xiàn)場(chǎng)，并報(bào)警
- Line or Head or Body 過(guò)大的請(qǐng)求，采樣落盤，還原現(xiàn)場(chǎng)，并報(bào)警
- 耗時(shí)監(jiān)控，有慢請(qǐng)求，超時(shí)請(qǐng)求，以及 tp99，tp999 等
- 帶寬監(jiān)控和報(bào)警，支持對(duì)請(qǐng)求和響應(yīng)的行，頭，body單獨(dú)監(jiān)控。
- 響應(yīng)碼監(jiān)控，特別是 400，和 404
- 連接監(jiān)控，我們對(duì)接入端的連接，以及和后端服務(wù)的連接，后端服務(wù)連接上待發(fā)送字節(jié)大小也都做了監(jiān)控
- 流量抖動(dòng)報(bào)警，這是非常有必要的，流量抖動(dòng)要么是出了問(wèn)題，要么就是出問(wèn)題的前兆。
對(duì)于高并發(fā)系統(tǒng)，頻繁的創(chuàng)建對(duì)象不僅有分配內(nèi)存的開(kāi)銷外，還有對(duì) GC 會(huì)造成壓力，我們?cè)趯?shí)現(xiàn)時(shí)會(huì)對(duì)頻繁使用的比如線程池的任務(wù) task，StringBuffer等會(huì)做寫重用，減少頻繁的申請(qǐng)內(nèi)存的開(kāi)銷。高并發(fā)系統(tǒng)，通常都采用異步設(shè)計(jì)，異步化后，不得不考慮線程上下文切換的問(wèn)題，我們的線程模型如下：我們整個(gè)網(wǎng)關(guān)沒(méi)有涉及到 IO 操作，但我們?cè)跇I(yè)務(wù)邏輯這塊還是和 Netty 的 IO 編解碼線程異步，是有兩個(gè)原因，1）是防止開(kāi)發(fā)寫的代碼有阻塞，2）是業(yè)務(wù)邏輯打日志可能會(huì)比較多，在突發(fā)的情況下，在 push 線程時(shí)，支持用 Netty 的 IO 線程替代，這里做的工作比較少，這里有異步修改為同步后(通過(guò)修改配置調(diào)整)，CPU 的上下文切換減少 20%，進(jìn)而提高了整體的吞吐量，就是不能為了異步而異步，zull2 的設(shè)計(jì)和我們的類似。在高并發(fā)系統(tǒng)，GC 的優(yōu)化不可避免，我們?cè)谟昧藢?duì)象池技術(shù)和堆外內(nèi)存時(shí)，對(duì)象很少進(jìn)入老年代，另外我們年輕代會(huì)設(shè)置的比較大，而且 SurvivorRatio=2，晉升年齡設(shè)置最大 15，盡量對(duì)象在年輕代就回收掉， 但監(jiān)控發(fā)現(xiàn)老年代的內(nèi)存還是會(huì)緩慢增長(zhǎng)。通過(guò) dump 分析，我們每個(gè)后端服務(wù)創(chuàng)建一個(gè)連接，都時(shí)有一個(gè) socket，socket 的 AbstractPlainSocketImpl，而 AbstractPlainSocketImpl 就重寫了 Object 類的 finalize 方法，實(shí)現(xiàn)如下：/** * Cleans up if the user forgets to close it. */ protected void finalize() throws IOException { close(); }
是為了我們沒(méi)有主動(dòng)關(guān)閉連接，做的一個(gè)兜底，在 GC 回收的時(shí)候，先把對(duì)應(yīng)的連接資源給釋放了，由于 finalize 的機(jī)制是通過(guò) JVM 的 Finalizer線程來(lái)處理的，而且 Finalizer 線程的優(yōu)先級(jí)不高，默認(rèn)是 8，需要等到 Finalizer 線程把 ReferenceQueue 的對(duì)象對(duì)于的 finalize 方法執(zhí)行完，還要等到下次 GC 時(shí)，才能把該對(duì)象回收，導(dǎo)致創(chuàng)建連接的這些對(duì)象在年輕代不能立即回收，從而進(jìn)入了老年代，這也是為啥老年代會(huì)一直緩慢增長(zhǎng)的問(wèn)題。高并發(fā)下，特別是 Netty 的 IO 線程除了要執(zhí)行該線程上的 IO 讀寫操作，還有執(zhí)行異步任務(wù)和定時(shí)任務(wù)，如果 IO 線程處理不過(guò)來(lái)隊(duì)列里的任務(wù)，很有可能導(dǎo)致新進(jìn)來(lái)異步任務(wù)出現(xiàn)被拒絕的情況。那什么情況下可能呢，IO 是異步讀寫的問(wèn)題不大，就是多耗點(diǎn) CPU，最有可能 block 住 IO 線程的是我們打的日志，目前 Log4j 的 ConsoleAppender 日志 immediateFlush 屬性默認(rèn)為 true，即每次打 log 都是同步寫 flush 到磁盤的，這個(gè)對(duì)于內(nèi)存操作來(lái)說(shuō)，慢了很多。同時(shí) AsyncAppender 的日志隊(duì)列滿了也會(huì) block 住線程,log4j 默認(rèn)的 buffer 大小是 128，而且是 block 的，即如果 buffer 的大小達(dá)到 128，就阻塞了寫日志的線程，在并發(fā)寫日志量大的的情況下，特別是堆棧很多時(shí)，log4j 的 Dispatcher 線程會(huì)出現(xiàn)變慢要刷盤，這樣 buffer 就不能快速消費(fèi)，很容易寫滿日志事件，導(dǎo)致 Netty IO 線程 block 住，所以我們?cè)诖蛉罩緯r(shí)，也要注意精簡(jiǎn)。現(xiàn)在我們都是基于 HTTP/1，現(xiàn)在 HTTP/2 相對(duì)于 HTTP/1 關(guān)鍵實(shí)現(xiàn)了在連接層面的服務(wù)，即一個(gè)連接上可以發(fā)送多個(gè) HTTP 請(qǐng)求，即 HTTP 連接也能和 rpc 連接一樣，建幾個(gè)連接就可以了，徹底解決了 HTTP/1 連接不能復(fù)用導(dǎo)致每次都建連和慢啟動(dòng)的開(kāi)銷。我們也在基于 Netty 升級(jí)到 HTTP/2, 除了技術(shù)升級(jí)外，我們對(duì)監(jiān)控報(bào)警也一直在持續(xù)優(yōu)化，怎么提供給業(yè)務(wù)方準(zhǔn)確無(wú)誤的報(bào)警，也是一直在努力，還有一個(gè)就是降級(jí)，作為統(tǒng)一接入網(wǎng)關(guān)，和業(yè)務(wù)方做好全方位的降級(jí)措施，也是一直在完善的點(diǎn)，保證全站任何故障都能通過(guò)網(wǎng)關(guān)第一時(shí)間降級(jí)，也是我們的重點(diǎn)。
網(wǎng)關(guān)已經(jīng)是一個(gè)互聯(lián)網(wǎng)公司的標(biāo)配，這里總結(jié)實(shí)踐過(guò)程中的一些心得和體會(huì)，希望給大家一些參考以及一些問(wèn)題的解決思路，歡迎交流，我們也還在不斷完善中，同時(shí)我們也在做多活，云原生，穩(wěn)定性平臺(tái)等項(xiàng)目，喜馬拉雅平臺(tái)架構(gòu)有機(jī)會(huì)有挑戰(zhàn)，目前正在大力招攬人才，感興趣的同學(xué)可以加入我們。最近面試BAT，整理一份面試資料《Java面試BATJ通關(guān)手冊(cè)》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫(kù)、數(shù)據(jù)結(jié)構(gòu)等等。
獲取方式：點(diǎn)“在看”，關(guān)注公眾號(hào)并回復(fù) Java 領(lǐng)取，更多內(nèi)容陸續(xù)奉上。
文章有幫助的話，在看，轉(zhuǎn)發(fā)吧。
謝謝支持喲 (*^__^*)
