航母哥

讀完需要

2

分鐘

速讀僅需 1 分鐘

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

前幾天跟某互聯網主題旅游網架構師聊起性能調優的話題，那個時候正好遇到一些線上調優的一些困惑，希望一起探討一下。

他跟我說，他們公司的系統從來沒有經過性能調優，功能測試完成后就上線了，線上也沒有出現過什么性能問題呀，為什么要進行調優呢？？

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

當時我一臉懵逼，既然不做性能優化就直接上線，相當于給系統埋了一個定時炸彈，一旦到某個臨界點，說炸就炸，到時候回天乏力。

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

今天，我們就從這個話題聊起，希望能跟你一起弄明白這幾個問題：我們為什么要做性能調優？什么時候開始做？做性能調優是不是有標準可參考？

1

? ?

為什么要做性能調優？

在互聯網項目開發中，總是不斷針對新的需求去研發新的系統，而很多系統的設計都是可以觸類旁通的，在系統架構設計中，我們必須遵循一些原則：

海恩法則：

• 事故的發生是量的積累的結果 （并發量，數據量，服務量…….）

• 再好的技術、再完美的規章， 在實際操作層面也無法取代人自身的素質和責任心 。

墨菲定律：

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

• 所有事情的發展都會比你預計的時間長 。

• 會出錯的事總會出錯。

• 如果你擔心某種情況發生，那么它更有可能發生。

這些原則警示我們，在互聯網公司里，對生產環境發生的任何怪異現象和問題 都不要輕易忽視，對于其背后的原因一定要徹查。

同樣，海恩法則也強調任何嚴重事故的背后 都是多次小問題的積累，積累到一定的量級后會導致質變，嚴重的問題就會浮出水面 。

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

這就需要我們有技術攻關的能力，對任何現象都要秉著以下原則：為什么發生？發生了怎么應對？怎么恢復？怎么避免？對問題要徹查，不能因為問題的現象不明顯而忽略 。

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

性能測試的目的在于驗證軟件系統是否能夠達到用戶提出的性能指標，同時發現軟件系統中存在的性能瓶頸，以優化軟件。

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

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

現在假設你的系統要做一次促銷活動，產品經理或者老板告訴你預計有幾十萬，幾百萬，甚至更多的用戶訪問量，詢問系統能否承受得住這次活動的壓力。

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

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

好的系統性能調優不僅僅可以提高系統的性能，還能為公司節省資源，實現降本增效。這也是我們做性能調優的最直接的目的。

2

? ?

什么時候開始介入調優？

解決了為什么要做性能優化的問題，那么新的問題就來了：如果需要對系統做一次全面的性能監測和優化，我們從什么時候開始介入性能調優呢？是不是越早介入越好？

其實，在項目開發的初期，我們沒有必要過于在意性能優化，這樣反而會讓我們疲于性能優化，不僅不會給系統性能帶來提升，還會影響到開發進度，甚至獲得相反的效果，給系統帶來新的問題。

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

①系統的架構設計，如何在架構層面減少不必要的處理（網絡請求，數據庫操作等），例如：使用 Cache 來減少 IO 次數，使用異步來增加單服務吞吐量，使用無鎖數據結構來減少響應時間。

②網絡拓撲優化減少網絡請求時間、如何設計拓撲結構，分布式如何實現？

③系統代碼級別的代碼優化，使用什么設計模式來進行工作？哪些類需要使用單例，哪些需要盡量減少 new 操作？

④提高代碼層面的運行效率、如何選取合適的數據結構進行數據存取？如何設計合適的算法？

⑤任務執行方式級別的同異步操作，在哪里使用同步，哪里使用異步？

⑥JVM 調優，如何設置 Heap、Stack、Eden 的大小，如何選擇 GC 策略，控制 Full GC 的頻率？

⑦服務端調優（線程池，等待隊列）。

⑧數據庫優化減少查詢修改時間。數據庫的選取？數據庫引擎的選取？數據庫表結構的設計？數據庫索引、觸發器等設計？是否使用讀寫分離？還是需要考慮使用數據倉庫？

⑨緩存數據庫的使用，如何選擇緩存數據庫？是 Redis 還是 Memcache? 如何設計緩存機制？

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

?操作系統選取，是使用 winserver 還是 Linux？或者 Unix？

?硬件配置？是 8G 內存還是 32G，網卡 10G 還是 1G？例如：增加 CPU 核數如 32 核，升級更好的網卡如萬兆，升級更好的硬盤如 SSD，擴充硬盤容量如 2T，擴充系統內存如 128G。

在系統編碼完成之后，我們就可以對系統進行性能測試了。這時候，產品經理一般會提供線上預期數據，我們在提供的參考平臺上進行壓測，通過性能分析、統計工具來統計各項性能指標，看是否在預期范圍之內。

在項目成功上線后，我們還需要根據線上的實際情況，依照日志監控以及性能統計日志，來觀測系統性能問題，一旦發現問題，就要對日志進行分析并及時修復問題。

在我們進行調優之前，必須對性能指標有一定的認知，否則我們調優就是空中樓閣，沒有任何的可參考的依據，是無法實現調優的。

在我們了解性能指標之前，我們先來了解下哪些計算機資源會成為系統的性能瓶頸，這些東西各位應該都非常清楚，在系統上線后，無外乎就是 CPU、內存、磁盤、網絡等等這些問題。

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

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

大量線程搶占 CPU 資源，導致 CPU 占用率升高：

CPU 占用率情況排查：

內存：Java 程序一般通過 JVM 對內存進行分配管理，主要是用 JVM 中的堆內存來存儲 Java 創建的對象。

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

所以當內存空間被占滿，對象無法回收時，就會導致內存溢出、內存泄露等問題。

磁盤 I/O：磁盤相比內存來說，存儲空間要大很多，但磁盤 I/O 讀寫的速度要比內存慢，雖然目前引入的 SSD 固態硬盤已經有所優化，但仍然無法與內存的讀寫速度相提并論。

網絡：網絡對于系統性能來說，也起著至關重要的作用。如果你購買過云服務，一定經歷過，選擇網絡帶寬大小這一環節。

帶寬過低的話，對于傳輸數據比較大，或者是并發量比較大的系統，網絡就很容易成為性能瓶頸。

異常：Java 應用中，拋出異常需要構建異常棧，對異常進行捕獲和處理，這個過程非常消耗系統性能。

如果在高并發的情況下引發異常，持續地進行異常處理，那么系統的性能就會明顯地受到影響。

數據庫：大部分系統都會用到數據庫，而數據庫的操作往往是涉及到磁盤 I/O 的讀寫。

大量的數據庫讀寫操作，會導致磁盤 I/O 性能瓶頸，進而導致數據庫操作的延遲性。

對于有大量數據庫讀寫操作的系統來說，數據庫的性能優化是整個系統的核心。

鎖競爭：在并發編程中，我們經常會需要多個線程，共享讀寫操作同一個資源，這個時候為了保持數據的原子性（即保證這個共享資源在一個線程寫的時候，不被另一個線程修改），我們就會用到鎖。

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

而如何合理地使用鎖資源，優化鎖資源，就需要你了解更多的操作系統知識、Java 多線程編程基礎，積累項目經驗，并結合實際場景去處理相關問題。

了解了上面這些基本內容，我們可以得到下面幾個指標，來衡量一般系統的性能。

2.1

? ?

響應時間

響應時間是衡量系統性能的重要指標之一，響應時間越短，性能越好，一般一個接口的響應時間是在毫秒級。

在系統中，我們可以把響應時間自下而上細分為以下幾種：

• 數據庫響應時間：數據庫操作所消耗的時間，往往是整個請求鏈中最耗時的。

• 服務端響應時間：服務端包括 Nginx 分發的請求所消耗的時間以及服務端程序執行所消耗的時間。

• 網絡響應時間：這是網絡傳輸時，網絡硬件需要對傳輸的請求進行解析等操作所消耗的時間。

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

2.2

? ?

吞吐量

在測試中，我們往往會比較注重系統接口的 TPS（每秒事務處理量），因為 TPS 體現了接口的性能，TPS 越大，性能越好。

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

• 磁盤吞吐量
  

• 網絡吞吐量

我們先來看磁盤吞吐量，磁盤性能有兩個關鍵衡量指標：

• 一種是 IOPS（Input/Output Per Second），即每秒的輸入輸出量（或讀寫次數），這種是指單位時間內系統能處理的 I/O 請求數量，I/O 請求通常為讀或寫數據操作請求，關注的是隨機讀寫性能。適應于隨機讀寫頻繁的應用。

• 另一種是數據吞吐量，這種是指單位時間內可以成功傳輸的數據量。對于大量順序讀寫頻繁的應用，傳輸大量連續數據。

接下來看網絡吞吐量，這個是指網絡傳輸時沒有幀丟失的情況下，設備能夠接受的最大數據速率。

網絡吞吐量不僅僅跟帶寬有關系，還跟 CPU 的處理能力、網卡、防火墻、外部接口以及 I/O 等緊密關聯。

而吞吐量的大小主要由網卡的處理能力、內部程序算法以及帶寬大小決定。

2.3

? ?

計算機資源分配使用率

通常由 CPU 占用率、內存使用率、磁盤 I/O、網絡 I/O 來表示資源使用率。

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

2.4

? ?

負載承受能力

當系統壓力上升時，你可以觀察，系統響應時間的上升曲線是否平緩。這項指標能直觀地反饋給你，系統所能承受的負載壓力極限。

例如，當你對系統進行壓測時，系統的響應時間會隨著系統并發數的增加而延長，直到系統無法處理這么多請求，拋出大量錯誤時，就到了極限。

本文首發于 51CTO 技術棧（blog51cto ）編輯：陶家龍，經授權轉載發布

- EOF -

想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信

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

螞蟻集團技術專家山丘：性能優化的常見模式及趨勢

Java線程池實現原理及其在美團業務中的實踐

螞蟻集團技術專家山丘：性能優化常見壓測模型及優缺點

一個思維習慣，讓你成為架構師

美團大咖：程序員35歲前應做好的技術積累

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

? ?END ? ?? #架構師必備#點分享點點贊點在看

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。