航母哥

讀完需要

2

分鐘

速讀僅需 1 分鐘

目前就職于 58 研發(fā)中心擔(dān)任資深架構(gòu)師，負(fù)責(zé)消息中間件與全鏈路壓測的實(shí)施與落地。前阿里巴巴消息中間件資深研發(fā)，架構(gòu)師。擅長 Java 編程，對主流中間件 RocketMQ、Dubbo、ElasticJob、Netty、Sentienl、Mybatis、Mycat 等中間件有深入研究。

前幾天跟某互聯(lián)網(wǎng)主題旅游網(wǎng)架構(gòu)師聊起性能調(diào)優(yōu)的話題，那個時候正好遇到一些線上調(diào)優(yōu)的一些困惑，希望一起探討一下。

他跟我說，他們公司的系統(tǒng)從來沒有經(jīng)過性能調(diào)優(yōu)，功能測試完成后就上線了，線上也沒有出現(xiàn)過什么性能問題呀，為什么要進(jìn)行調(diào)優(yōu)呢？？

可謂底氣十足啊！！！無知者無畏啊；就不怕為公司埋雷，到時候追究他的責(zé)任？

當(dāng)時我一臉懵逼，既然不做性能優(yōu)化就直接上線，相當(dāng)于給系統(tǒng)埋了一個定時炸彈，一旦到某個臨界點(diǎn)，說炸就炸，到時候回天乏力。

因此我就回答了他一句，“我去，如果你們公司做的是淘寶，京東，12306 這樣的網(wǎng)站，不做系統(tǒng)性能優(yōu)化就上線，試試看會是什么情況”。

今天，我們就從這個話題聊起，希望能跟你一起弄明白這幾個問題：我們?yōu)槭裁匆鲂阅苷{(diào)優(yōu)？什么時候開始做？做性能調(diào)優(yōu)是不是有標(biāo)準(zhǔn)可參考？

1

? ?

為什么要做性能調(diào)優(yōu)？

在互聯(lián)網(wǎng)項(xiàng)目開發(fā)中，總是不斷針對新的需求去研發(fā)新的系統(tǒng)，而很多系統(tǒng)的設(shè)計(jì)都是可以觸類旁通的，在系統(tǒng)架構(gòu)設(shè)計(jì)中，我們必須遵循一些原則：

海恩法則：

• 事故的發(fā)生是量的積累的結(jié)果 （并發(fā)量，數(shù)據(jù)量，服務(wù)量…….）

• 再好的技術(shù)、再完美的規(guī)章， 在實(shí)際操作層面也無法取代人自身的素質(zhì)和責(zé)任心 。

墨菲定律：

• 任何事情都沒有表面看起來那么簡單 。

• 所有事情的發(fā)展都會比你預(yù)計(jì)的時間長 。

• 會出錯的事總會出錯。

• 如果你擔(dān)心某種情況發(fā)生，那么它更有可能發(fā)生。

這些原則警示我們，在互聯(lián)網(wǎng)公司里，對生產(chǎn)環(huán)境發(fā)生的任何怪異現(xiàn)象和問題 都不要輕易忽視，對于其背后的原因一定要徹查。

同樣，海恩法則也強(qiáng)調(diào)任何嚴(yán)重事故的背后 都是多次小問題的積累，積累到一定的量級后會導(dǎo)致質(zhì)變，嚴(yán)重的問題就會浮出水面 。

那么，我們需要對線上服務(wù)產(chǎn)生的任何征兆，哪怕是一個小問題，也要刨根問底。

這就需要我們有技術(shù)攻關(guān)的能力，對任何現(xiàn)象都要秉著以下原則：為什么發(fā)生？發(fā)生了怎么應(yīng)對？怎么恢復(fù)？怎么避免？對問題要徹查，不能因?yàn)閱栴}的現(xiàn)象不明顯而忽略 。

一款線上產(chǎn)品如果沒有經(jīng)過性能測試，那它就好比是一顆定時炸彈，你不知道它什么時候會出現(xiàn)問題，你也不清楚它能承受的極限在哪兒。

性能測試的目的在于驗(yàn)證軟件系統(tǒng)是否能夠達(dá)到用戶提出的性能指標(biāo)，同時發(fā)現(xiàn)軟件系統(tǒng)中存在的性能瓶頸，以優(yōu)化軟件。

有些性能問題是時間累積慢慢產(chǎn)生的，到了一定時間自然就爆炸了；而更多的性能問題是由訪問量的波動導(dǎo)致的，例如，活動或者公司產(chǎn)品用戶量上升。

當(dāng)然也有可能是一款產(chǎn)品上線后就半死不活，一直沒有大訪問量，所以還沒有引發(fā)這顆定時炸彈。

現(xiàn)在假設(shè)你的系統(tǒng)要做一次促銷活動，產(chǎn)品經(jīng)理或者老板告訴你預(yù)計(jì)有幾十萬，幾百萬，甚至更多的用戶訪問量，詢問系統(tǒng)能否承受得住這次活動的壓力。

如果你不清楚自己系統(tǒng)的性能情況，也只能戰(zhàn)戰(zhàn)兢兢地回答老板，有可能大概沒問題吧。

所以，要不要做性能調(diào)優(yōu)，這個問題其實(shí)很好回答。所有的系統(tǒng)在開發(fā)完之后，多多少少都會有性能問題，我們首先要做的就是想辦法把問題暴露出來，例如進(jìn)行壓力測試、模擬可能的操作場景等等，再通過性能調(diào)優(yōu)去解決這些問題。

好的系統(tǒng)性能調(diào)優(yōu)不僅僅可以提高系統(tǒng)的性能，還能為公司節(jié)省資源，實(shí)現(xiàn)降本增效。這也是我們做性能調(diào)優(yōu)的最直接的目的。

2

? ?

什么時候開始介入調(diào)優(yōu)？

解決了為什么要做性能優(yōu)化的問題，那么新的問題就來了：如果需要對系統(tǒng)做一次全面的性能監(jiān)測和優(yōu)化，我們從什么時候開始介入性能調(diào)優(yōu)呢？是不是越早介入越好？

其實(shí)，在項(xiàng)目開發(fā)的初期，我們沒有必要過于在意性能優(yōu)化，這樣反而會讓我們疲于性能優(yōu)化，不僅不會給系統(tǒng)性能帶來提升，還會影響到開發(fā)進(jìn)度，甚至獲得相反的效果，給系統(tǒng)帶來新的問題。

我們只需要在代碼層面保證有效的編碼，同時在架構(gòu)層面做好設(shè)計(jì)即可，具體架構(gòu)設(shè)計(jì)可以參考如下幾條行之有效的法則：

①系統(tǒng)的架構(gòu)設(shè)計(jì)，如何在架構(gòu)層面減少不必要的處理（網(wǎng)絡(luò)請求，數(shù)據(jù)庫操作等），例如：使用 Cache 來減少 IO 次數(shù)，使用異步來增加單服務(wù)吞吐量，使用無鎖數(shù)據(jù)結(jié)構(gòu)來減少響應(yīng)時間。

②網(wǎng)絡(luò)拓?fù)鋬?yōu)化減少網(wǎng)絡(luò)請求時間、如何設(shè)計(jì)拓?fù)浣Y(jié)構(gòu)，分布式如何實(shí)現(xiàn)？

③系統(tǒng)代碼級別的代碼優(yōu)化，使用什么設(shè)計(jì)模式來進(jìn)行工作？哪些類需要使用單例，哪些需要盡量減少 new 操作？

④提高代碼層面的運(yùn)行效率、如何選取合適的數(shù)據(jù)結(jié)構(gòu)進(jìn)行數(shù)據(jù)存取？如何設(shè)計(jì)合適的算法？

⑤任務(wù)執(zhí)行方式級別的同異步操作，在哪里使用同步，哪里使用異步？

⑥JVM 調(diào)優(yōu)，如何設(shè)置 Heap、Stack、Eden 的大小，如何選擇 GC 策略，控制 Full GC 的頻率？

⑦服務(wù)端調(diào)優(yōu)（線程池，等待隊(duì)列）。

⑧數(shù)據(jù)庫優(yōu)化減少查詢修改時間。數(shù)據(jù)庫的選取？數(shù)據(jù)庫引擎的選取？數(shù)據(jù)庫表結(jié)構(gòu)的設(shè)計(jì)？數(shù)據(jù)庫索引、觸發(fā)器等設(shè)計(jì)？是否使用讀寫分離？還是需要考慮使用數(shù)據(jù)倉庫？

⑨緩存數(shù)據(jù)庫的使用，如何選擇緩存數(shù)據(jù)庫？是 Redis 還是 Memcache? 如何設(shè)計(jì)緩存機(jī)制？

⑩數(shù)據(jù)通信問題，如何選擇通信方式？是使用 TCP 還是 UDP，是使用長連接還是短連接？NIO 還是 BIO？netty、mina 還是原生 socket？

?操作系統(tǒng)選取，是使用 winserver 還是 Linux？或者 Unix？

?硬件配置？是 8G 內(nèi)存還是 32G，網(wǎng)卡 10G 還是 1G？例如：增加 CPU 核數(shù)如 32 核，升級更好的網(wǎng)卡如萬兆，升級更好的硬盤如 SSD，擴(kuò)充硬盤容量如 2T，擴(kuò)充系統(tǒng)內(nèi)存如 128G。

在系統(tǒng)編碼完成之后，我們就可以對系統(tǒng)進(jìn)行性能測試了。這時候，產(chǎn)品經(jīng)理一般會提供線上預(yù)期數(shù)據(jù)，我們在提供的參考平臺上進(jìn)行壓測，通過性能分析、統(tǒng)計(jì)工具來統(tǒng)計(jì)各項(xiàng)性能指標(biāo)，看是否在預(yù)期范圍之內(nèi)。

在項(xiàng)目成功上線后，我們還需要根據(jù)線上的實(shí)際情況，依照日志監(jiān)控以及性能統(tǒng)計(jì)日志，來觀測系統(tǒng)性能問題，一旦發(fā)現(xiàn)問題，就要對日志進(jìn)行分析并及時修復(fù)問題。

在我們進(jìn)行調(diào)優(yōu)之前，必須對性能指標(biāo)有一定的認(rèn)知，否則我們調(diào)優(yōu)就是空中樓閣，沒有任何的可參考的依據(jù)，是無法實(shí)現(xiàn)調(diào)優(yōu)的。

在我們了解性能指標(biāo)之前，我們先來了解下哪些計(jì)算機(jī)資源會成為系統(tǒng)的性能瓶頸，這些東西各位應(yīng)該都非常清楚，在系統(tǒng)上線后，無外乎就是 CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等等這些問題。

CPU：有的應(yīng)用需要大量計(jì)算，他們會長時間、不間斷地占用 CPU 資源，導(dǎo)致其他資源無法爭奪到 CPU 而響應(yīng)緩慢，從而帶來系統(tǒng)性能問題。

例如，代碼遞歸導(dǎo)致的無限循環(huán)，正則表達(dá)式引起的回溯，JVM 頻繁的 FULL GC，以及多線程編程造成的大量上下文切換等，這些都有可能導(dǎo)致 CPU 資源繁忙。

大量線程搶占 CPU 資源，導(dǎo)致 CPU 占用率升高：

CPU 占用率情況排查：

內(nèi)存：Java 程序一般通過 JVM 對內(nèi)存進(jìn)行分配管理，主要是用 JVM 中的堆內(nèi)存來存儲 Java 創(chuàng)建的對象。

系統(tǒng)堆內(nèi)存的讀寫速度非常快，所以基本不存在讀寫性能瓶頸。但是由于內(nèi)存成本要比磁盤高，相比磁盤，內(nèi)存的存儲空間又非常有限。

所以當(dāng)內(nèi)存空間被占滿，對象無法回收時，就會導(dǎo)致內(nèi)存溢出、內(nèi)存泄露等問題。

磁盤 I/O：磁盤相比內(nèi)存來說，存儲空間要大很多，但磁盤 I/O 讀寫的速度要比內(nèi)存慢，雖然目前引入的 SSD 固態(tài)硬盤已經(jīng)有所優(yōu)化，但仍然無法與內(nèi)存的讀寫速度相提并論。

網(wǎng)絡(luò)：網(wǎng)絡(luò)對于系統(tǒng)性能來說，也起著至關(guān)重要的作用。如果你購買過云服務(wù)，一定經(jīng)歷過，選擇網(wǎng)絡(luò)帶寬大小這一環(huán)節(jié)。

帶寬過低的話，對于傳輸數(shù)據(jù)比較大，或者是并發(fā)量比較大的系統(tǒng)，網(wǎng)絡(luò)就很容易成為性能瓶頸。

異常：Java 應(yīng)用中，拋出異常需要構(gòu)建異常棧，對異常進(jìn)行捕獲和處理，這個過程非常消耗系統(tǒng)性能。

如果在高并發(fā)的情況下引發(fā)異常，持續(xù)地進(jìn)行異常處理，那么系統(tǒng)的性能就會明顯地受到影響。

數(shù)據(jù)庫：大部分系統(tǒng)都會用到數(shù)據(jù)庫，而數(shù)據(jù)庫的操作往往是涉及到磁盤 I/O 的讀寫。

大量的數(shù)據(jù)庫讀寫操作，會導(dǎo)致磁盤 I/O 性能瓶頸，進(jìn)而導(dǎo)致數(shù)據(jù)庫操作的延遲性。

對于有大量數(shù)據(jù)庫讀寫操作的系統(tǒng)來說，數(shù)據(jù)庫的性能優(yōu)化是整個系統(tǒng)的核心。

鎖競爭：在并發(fā)編程中，我們經(jīng)常會需要多個線程，共享讀寫操作同一個資源，這個時候?yàn)榱吮３謹(jǐn)?shù)據(jù)的原子性（即保證這個共享資源在一個線程寫的時候，不被另一個線程修改），我們就會用到鎖。

鎖的使用可能會帶來上下文切換，從而給系統(tǒng)帶來性能開銷。JDK1.6 之后，Java 為了降低鎖競爭帶來的上下文切換，對 JVM 內(nèi)部鎖已經(jīng)做了多次優(yōu)化，例如，新增了偏向鎖、自旋鎖、輕量級鎖、鎖粗化、鎖消除等。

而如何合理地使用鎖資源，優(yōu)化鎖資源，就需要你了解更多的操作系統(tǒng)知識、Java 多線程編程基礎(chǔ)，積累項(xiàng)目經(jīng)驗(yàn)，并結(jié)合實(shí)際場景去處理相關(guān)問題。

了解了上面這些基本內(nèi)容，我們可以得到下面幾個指標(biāo)，來衡量一般系統(tǒng)的性能。

2.1

? ?

響應(yīng)時間

響應(yīng)時間是衡量系統(tǒng)性能的重要指標(biāo)之一，響應(yīng)時間越短，性能越好，一般一個接口的響應(yīng)時間是在毫秒級。

在系統(tǒng)中，我們可以把響應(yīng)時間自下而上細(xì)分為以下幾種：

• 數(shù)據(jù)庫響應(yīng)時間：數(shù)據(jù)庫操作所消耗的時間，往往是整個請求鏈中最耗時的。

• 服務(wù)端響應(yīng)時間：服務(wù)端包括 Nginx 分發(fā)的請求所消耗的時間以及服務(wù)端程序執(zhí)行所消耗的時間。

• 網(wǎng)絡(luò)響應(yīng)時間：這是網(wǎng)絡(luò)傳輸時，網(wǎng)絡(luò)硬件需要對傳輸?shù)恼埱筮M(jìn)行解析等操作所消耗的時間。

• 客戶端響應(yīng)時間：對于普通的 Web、App 客戶端來說，消耗時間是可以忽略不計(jì)的，但如果你的客戶端嵌入了大量的邏輯處理，消耗的時間就有可能變長，從而成為系統(tǒng)的瓶頸。
  

2.2

? ?

吞吐量

在測試中，我們往往會比較注重系統(tǒng)接口的 TPS（每秒事務(wù)處理量），因?yàn)?TPS 體現(xiàn)了接口的性能，TPS 越大，性能越好。

在系統(tǒng)中，我們也可以把吞吐量自下而上地分為兩種：

• 磁盤吞吐量
  

• 網(wǎng)絡(luò)吞吐量

我們先來看磁盤吞吐量，磁盤性能有兩個關(guān)鍵衡量指標(biāo)：

• 一種是 IOPS（Input/Output Per Second），即每秒的輸入輸出量（或讀寫次數(shù)），這種是指單位時間內(nèi)系統(tǒng)能處理的 I/O 請求數(shù)量，I/O 請求通常為讀或?qū)憯?shù)據(jù)操作請求，關(guān)注的是隨機(jī)讀寫性能。適應(yīng)于隨機(jī)讀寫頻繁的應(yīng)用。

• 另一種是數(shù)據(jù)吞吐量，這種是指單位時間內(nèi)可以成功傳輸?shù)臄?shù)據(jù)量。對于大量順序讀寫頻繁的應(yīng)用，傳輸大量連續(xù)數(shù)據(jù)。

接下來看網(wǎng)絡(luò)吞吐量，這個是指網(wǎng)絡(luò)傳輸時沒有幀丟失的情況下，設(shè)備能夠接受的最大數(shù)據(jù)速率。

網(wǎng)絡(luò)吞吐量不僅僅跟帶寬有關(guān)系，還跟 CPU 的處理能力、網(wǎng)卡、防火墻、外部接口以及 I/O 等緊密關(guān)聯(lián)。

而吞吐量的大小主要由網(wǎng)卡的處理能力、內(nèi)部程序算法以及帶寬大小決定。

2.3

? ?

計(jì)算機(jī)資源分配使用率

通常由 CPU 占用率、內(nèi)存使用率、磁盤 I/O、網(wǎng)絡(luò) I/O 來表示資源使用率。

這幾個參數(shù)好比一個木桶，如果其中任何一塊木板出現(xiàn)短板，任何一項(xiàng)分配不合理，對整個系統(tǒng)性能的影響都是毀滅性的。

2.4

? ?

負(fù)載承受能力

當(dāng)系統(tǒng)壓力上升時，你可以觀察，系統(tǒng)響應(yīng)時間的上升曲線是否平緩。這項(xiàng)指標(biāo)能直觀地反饋給你，系統(tǒng)所能承受的負(fù)載壓力極限。

例如，當(dāng)你對系統(tǒng)進(jìn)行壓測時，系統(tǒng)的響應(yīng)時間會隨著系統(tǒng)并發(fā)數(shù)的增加而延長，直到系統(tǒng)無法處理這么多請求，拋出大量錯誤時，就到了極限。

本文首發(fā)于 51CTO 技術(shù)棧（blog51cto ）編輯：陶家龍，經(jīng)授權(quán)轉(zhuǎn)載發(fā)布

- EOF -

想要加入中生代架構(gòu)群的小伙伴，請?zhí)砑尤汉匣锶?strong>大白的微信

申請備注（姓名+公司+技術(shù)方向）才能通過哦！

螞蟻集團(tuán)技術(shù)專家山丘：性能優(yōu)化的常見模式及趨勢

Java線程池實(shí)現(xiàn)原理及其在美團(tuán)業(yè)務(wù)中的實(shí)踐

螞蟻集團(tuán)技術(shù)專家山丘：性能優(yōu)化常見壓測模型及優(yōu)缺點(diǎn)

一個思維習(xí)慣，讓你成為架構(gòu)師

美團(tuán)大咖：程序員35歲前應(yīng)做好的技術(shù)積累

阿里云MVP喬幫主：五大類型負(fù)載均衡的原理場景詳解（文末贈書）

? ?END ? ?? #架構(gòu)師必備#點(diǎn)分享點(diǎn)點(diǎn)贊點(diǎn)在看

總結(jié)

以上是生活随笔為你收集整理的没做性能优化，系统说炸就炸...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。