建站
咨詢
售后
建站咨詢
新聞中心
一、寫在前面
相信不少朋友都在自己公司使用Spring Cloud框架來(lái)構(gòu)建微服務(wù)架構(gòu)，畢竟現(xiàn)在這是非?；鸬囊婚T技術(shù)。
網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)建站！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、成都小程序開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了大悟免費(fèi)建站歡迎大家使用！
如果只是用戶量很少的傳統(tǒng)IT系統(tǒng)，使用Spring Cloud可能還暴露不出什么問(wèn)題。
如果是較多用戶量，高峰每秒高達(dá)上萬(wàn)并發(fā)請(qǐng)求的互聯(lián)網(wǎng)公司的系統(tǒng)，使用Spring Cloud技術(shù)就有一些問(wèn)題需要注意了。
二、場(chǎng)景引入，問(wèn)題初現(xiàn)
先不空聊原理、理論，來(lái)講一個(gè)真實(shí)的例子，這是我的一個(gè)朋友在創(chuàng)業(yè)互聯(lián)網(wǎng)公司發(fā)生過(guò)的真實(shí)案例。
朋友A的公司做互聯(lián)網(wǎng)類的創(chuàng)業(yè)，組建了一個(gè)小型研發(fā)團(tuán)隊(duì)，上來(lái)就用了Spring Cloud技術(shù)棧來(lái)構(gòu)建微服務(wù)架構(gòu)的系統(tǒng)。
一段時(shí)間沒(méi)日沒(méi)夜的加班，好不容易核心業(yè)務(wù)系統(tǒng)給做出來(lái)了，平時(shí)正常QA測(cè)試沒(méi)發(fā)現(xiàn)什么大毛病，感覺(jué)性能還不錯(cuò)，一切都很完美。
然后系統(tǒng)就這么上線了，一開始用戶規(guī)模很小，注冊(cè)用戶量小幾十萬(wàn)，日活幾千用戶。
每天都有新的數(shù)據(jù)進(jìn)入數(shù)據(jù)庫(kù)的表中，就這么日積月累的，沒(méi)想到數(shù)據(jù)規(guī)模居然慢慢吞吞增長(zhǎng)到了單表幾百萬(wàn)。
這個(gè)時(shí)候呢，看起來(lái)也沒(méi)太大的毛病，就是有用戶反映，系統(tǒng)有些操作，會(huì)感覺(jué)卡頓幾秒鐘，會(huì)刷不出來(lái)頁(yè)面。
這是為啥呢？
- 核心原因是單表數(shù)據(jù)量大了一些，達(dá)到了幾百萬(wàn)。
- 有個(gè)別服務(wù)，跑的SQL比較復(fù)雜，一大堆的多表關(guān)聯(lián)
- 并且還沒(méi)有設(shè)計(jì)好索引，或者是設(shè)計(jì)了索引，但無(wú)奈一些小弟寫了上百行的大SQL，SQL實(shí)在太復(fù)雜了，那么一個(gè)SQL跑出來(lái)好幾秒肯定是正常的。
如果大家對(duì)微服務(wù)框架有點(diǎn)了解的話，應(yīng)該知道，比如Feign + Ribbon組成的服務(wù)調(diào)用框架，是有接口調(diào)用超時(shí)這一說(shuō)的，有一些參數(shù)可以設(shè)置接口調(diào)用的超時(shí)時(shí)間。
如果你調(diào)用一個(gè)接口，好幾秒刷不出來(lái)，人家就超時(shí)異常返回，用戶就刷不出來(lái)頁(yè)面了。
三、揚(yáng)湯止沸，飲鴆止渴
一般碰到這種事情，一大坨屎一樣的SQL擺在那兒，寫SQL的人過(guò)一個(gè)月自己都看不懂了，80%的工程師看著都不愿意去花時(shí)間重寫和優(yōu)化。
一是修改的人力成本太高，二是誰(shuí)敢負(fù)擔(dān)這責(zé)任呢？
系統(tǒng)跑的好好的，就是慢了點(diǎn)而已，結(jié)果你硬是亂改一通，重構(gòu)，把系統(tǒng)核心業(yè)務(wù)流程搞掛了怎么辦？
所以，那些兄弟第一反應(yīng)是：增加超時(shí)時(shí)間?。〗涌诼c(diǎn)可以，但是別超時(shí)不響應(yīng)?。?/p>
咱們讓接口執(zhí)行個(gè)幾秒把結(jié)果返回，用戶不就可以刷出來(lái)頁(yè)面了！不用重構(gòu)系統(tǒng)了??！輕松+愉快！
如何增加呢？很簡(jiǎn)單，看下面的參數(shù)就知道了：
大家如果看過(guò)之前的文章，應(yīng)該知道，Spring Cloud里一般會(huì)用hystrix的線程池來(lái)執(zhí)行接口調(diào)用的請(qǐng)求。
所以設(shè)置超時(shí)一般設(shè)置兩個(gè)地方，feign和ribbon那塊的超時(shí)，還有hystrix那塊的超時(shí)。其中后者那塊的超時(shí)一般必須大于前者。
Spring Cloud玩兒的好的兄弟，可千萬(wàn)別看著這些配置發(fā)笑，因?yàn)槲掖_實(shí)見過(guò)不少Spring Cloud玩兒的沒(méi)那么溜的哥們，真的就這么干了。
好了，日子在繼續(xù)。。。
優(yōu)化了參數(shù)后，看上去效果不錯(cuò)，用戶雖然覺(jué)得有的頁(yè)面慢是慢點(diǎn)，但是起碼過(guò)幾秒能刷出來(lái)。
這個(gè)時(shí)候，日活幾千的用戶量，壓根兒沒(méi)什么并發(fā)可言，高峰期每秒最多一二十并發(fā)請(qǐng)求罷了。
大家看看下面這張圖，感受一下現(xiàn)場(chǎng)氛圍：
四、問(wèn)題爆發(fā)，洪水猛獸
隨著時(shí)間的推移，公司業(yè)務(wù)高速發(fā)展……
那位兄弟的公司，在系統(tǒng)打磨成熟，幾萬(wàn)用戶試點(diǎn)都o(jì)k之后，老板立馬拿到一輪幾千萬(wàn)的融資。
公司上上下下意氣風(fēng)發(fā)??！緊接著就是組建運(yùn)營(yíng)團(tuán)隊(duì)，地推團(tuán)隊(duì)，全國(guó)大范圍的推廣。
總之就是三個(gè)字：推！推！推！
這一推不打緊！研發(fā)人員在后臺(tái)系統(tǒng)發(fā)現(xiàn)，自己的用戶量蹭蹭蹭的直線增長(zhǎng)。
注冊(cè)用戶增長(zhǎng)了幾十倍，突破了千萬(wàn)級(jí)別，日活用戶也翻了幾十倍，在活動(dòng)之類的高峰期，居然達(dá)到了上百萬(wàn)的日活用戶量！
幸福的煩惱。。。
為什么這么說(shuō)？因?yàn)橛脩袅可蟻?lái)后，悲劇的事情就發(fā)生了。
高峰期每秒的并發(fā)請(qǐng)求居然達(dá)到了近萬(wàn)的程度，研發(fā)團(tuán)隊(duì)的兄弟們哪里敢怠慢！在這個(gè)過(guò)程中，先是緊張的各種擴(kuò)容服務(wù)，一臺(tái)變兩臺(tái)，兩臺(tái)變四臺(tái)。
然后數(shù)據(jù)庫(kù)主從架構(gòu)掛上去，讀寫分離是必須的，否則單個(gè)數(shù)據(jù)庫(kù)服務(wù)器哪能承載那么大的請(qǐng)求！多搞幾個(gè)從庫(kù)，扛一下大量的讀請(qǐng)求，這樣基本就扛住了。
正準(zhǔn)備坐下來(lái)喝口茶、松口氣，更加悲劇的事情就發(fā)生了。
在這個(gè)過(guò)程中，那些兄弟經(jīng)常會(huì)發(fā)現(xiàn)高峰期，系統(tǒng)的某個(gè)功能頁(yè)面，突然就整個(gè)hang死了，就是沒(méi)法再響應(yīng)任何請(qǐng)求！所有用戶刷新這個(gè)頁(yè)面全部都是無(wú)法響應(yīng)！
這是為什么呢？原因很簡(jiǎn)單啊！一個(gè)服務(wù)A的實(shí)例里，專門調(diào)用服務(wù)B的那個(gè)線程池里的線程，總共可能就幾十個(gè)。每個(gè)線程調(diào)用服務(wù)B都會(huì)卡住5秒鐘。
那如果每秒鐘過(guò)來(lái)幾百個(gè)請(qǐng)求這個(gè)服務(wù)實(shí)例呢？一下子那個(gè)線程池里的線程就全部hang死了，沒(méi)法再響應(yīng)任何請(qǐng)求了。
大家來(lái)看看下面這張圖，再直觀的感受一下這個(gè)無(wú)助的過(guò)程！
這個(gè)時(shí)候咋辦？兄弟們只能祭出程序員最古老的法寶，重啟機(jī)器！
遇到頁(yè)面刷不出來(lái)，只能重啟機(jī)器，相當(dāng)于短暫的初始化了一下機(jī)器內(nèi)的資源。
然后接著運(yùn)行一段時(shí)間，又卡死，再次重啟！真是令人崩潰啊！用戶們的體驗(yàn)是極差的，老板的心情是憤怒的！
畫外音：
其實(shí)這個(gè)問(wèn)題本身不大，但如果對(duì)Spring Cloud沒(méi)有高并發(fā)場(chǎng)景的真實(shí)經(jīng)驗(yàn)，確實(shí)可能會(huì)跟這幫兄弟一樣，搞出些莫名其妙的問(wèn)題。
比如這個(gè)公司，明明應(yīng)該去優(yōu)化服務(wù)接口性能，結(jié)果硬是調(diào)大了超時(shí)時(shí)間。結(jié)果導(dǎo)致并發(fā)量高了，對(duì)那個(gè)服務(wù)的調(diào)用直接hang死，系統(tǒng)的核心頁(yè)面刷不出來(lái)，影響用戶體驗(yàn)了，這怪誰(shuí)呢？
五、追本溯源，治標(biāo)治本
沒(méi)法子了，那幫兄弟們只能找人求助。下面就是作者全程指導(dǎo)他們完成系統(tǒng)優(yōu)化的過(guò)程。
第一步
關(guān)鍵點(diǎn)，優(yōu)化圖中核心服務(wù)B的性能?；ヂ?lián)網(wǎng)公司，核心業(yè)務(wù)邏輯，面向C端用戶高并發(fā)的請(qǐng)求，不要用上百行的大SQL，多表關(guān)聯(lián)，那樣單表幾百萬(wàn)行數(shù)據(jù)量的話，會(huì)導(dǎo)致一下執(zhí)行好幾秒。
其實(shí)最佳的方式，就是對(duì)數(shù)據(jù)庫(kù)就執(zhí)行簡(jiǎn)單的單表查詢和更新，然后復(fù)雜的業(yè)務(wù)邏輯全部放在java系統(tǒng)中來(lái)執(zhí)行，比如一些關(guān)聯(lián)，或者是計(jì)算之類的工作。
這一步干完了之后，那個(gè)核心服務(wù)B的響應(yīng)速度就已經(jīng)優(yōu)化成幾十毫秒了，是不是很開心？從幾秒變成了幾十毫秒！
第二步
那個(gè)超時(shí)的時(shí)間，也就是上面那段ribbon和hystrix的超時(shí)時(shí)間設(shè)置。
奉勸各位同學(xué)，不要因?yàn)橄到y(tǒng)接口的性能過(guò)差而懶惰，搞成幾秒甚至幾十秒的超時(shí)，一般超時(shí)定義在1秒以內(nèi)，是比較通用以及合理的。
為什么這么說(shuō)？
因?yàn)橐粋€(gè)接口，理論的最佳響應(yīng)速度應(yīng)該在200ms以內(nèi)，或者慢點(diǎn)的接口就幾百毫秒。
如果一個(gè)接口響應(yīng)時(shí)間達(dá)到1秒+，建議考慮用緩存、索引、NoSQL等各種你能想到的技術(shù)手段，優(yōu)化一下性能。
否則你要是胡亂設(shè)置超時(shí)時(shí)間是幾秒，甚至幾十秒，萬(wàn)一下游服務(wù)偶然出了點(diǎn)問(wèn)題響應(yīng)時(shí)間長(zhǎng)了點(diǎn)呢？那你這個(gè)線程池里的線程立馬全部卡死！
這兩步解決之后，其實(shí)系統(tǒng)表現(xiàn)就正常了，核心服務(wù)B響應(yīng)速度很快，而且超時(shí)時(shí)間也在1秒以內(nèi)，不會(huì)出現(xiàn)hystrix線程池頻繁卡死的情況了。
第三步
事兒還沒(méi)完，你要真覺(jué)得兩步就搞定了，那還是經(jīng)驗(yàn)不足。
如果你要是超時(shí)時(shí)間設(shè)置成了1秒，如果就是因?yàn)榕既话l(fā)生的網(wǎng)絡(luò)抖動(dòng)，導(dǎo)致接口某次調(diào)用就是在1.5秒呢？這個(gè)是經(jīng)常發(fā)生的，因?yàn)榫W(wǎng)絡(luò)的問(wèn)題，接口調(diào)用偶然超時(shí)。
所以此時(shí)配合著超時(shí)時(shí)間，一般都會(huì)設(shè)置一個(gè)合理的重試，如下所示：
設(shè)置這段重試之后，Spring Cloud中的Feign + Ribbon的組合，在進(jìn)行服務(wù)調(diào)用的時(shí)候，如果發(fā)現(xiàn)某臺(tái)機(jī)器超時(shí)請(qǐng)求失敗，會(huì)自動(dòng)重試這臺(tái)機(jī)器，如果還是不行會(huì)換另外一臺(tái)機(jī)器重試。
這樣由于偶爾的網(wǎng)絡(luò)請(qǐng)求造成的超時(shí)，不也可以通過(guò)自動(dòng)重試避免了？
第四步
其實(shí)事兒還沒(méi)完，如果把重試參數(shù)配置了，結(jié)果你居然就放手了，那還是沒(méi)對(duì)人家負(fù)責(zé)任?。?/p>
你的系統(tǒng)架構(gòu)中，只要涉及到了重試，那么必須上接口的冪等性保障機(jī)制。
否則的話，試想一下，你要是對(duì)一個(gè)接口重試了好幾次，結(jié)果人家重復(fù)插入了多條數(shù)據(jù)，該怎么辦呢？
其實(shí)冪等性保證本身并不復(fù)雜，根據(jù)業(yè)務(wù)來(lái)，常見的方案：
- 可以在數(shù)據(jù)庫(kù)里建一個(gè)唯一索引，插入數(shù)據(jù)的時(shí)候如果唯一索引沖突了就不會(huì)插入重復(fù)數(shù)據(jù)
- 或者是通過(guò)redis里放一個(gè)唯一id值，然后每次要插入數(shù)據(jù)，都通過(guò)redis判斷一下，那個(gè)值如果已經(jīng)存在了，那么就不要插入重復(fù)數(shù)據(jù)了。
類似這樣的方案還有一些?？傊ＷC一個(gè)接口被多次調(diào)用的時(shí)候，不能插入重復(fù)的數(shù)據(jù)。
六、總結(jié)全文，回眸再看
有圖有真相！老規(guī)矩，最后給大家上一張圖，最終優(yōu)化后的系統(tǒng)表現(xiàn)大概是長(zhǎng)下面這樣子的。
文章名稱：面試官：你知道怎么把SpringCloud性能優(yōu)化提升10倍以上嗎？
瀏覽地址：http://www.5511xx.com/article/dpsceig.html
