本篇文章內容來自2016年TOP100summit華為架構部資深架構師王啟軍的案例分享。

編輯：Cynthia

王啟軍:華為架構部資深架構師。負責華為的云化、微服務架構推進落地，前后參與了華為手機祥云4.0、物聯網IoT2.0的架構設計。曾任當當網架構師，主導電商平臺架構設計，包括訂單、支付、價格、庫存、物流等。曾就職于搜狐負責手機微博的研發。“奔跑中的蝸牛”公眾號博主。

導讀：隨著云時代的來臨，軟件架構日新月異，各種新技術層出不窮。“微服務”這個詞更是如火如荼，得到了業界的廣泛認可。但是，微服務并不是銀彈，微服務架構下的性能問題在交付項目型的公司尤為重要。

本文主要圍繞微服務下的性能問題展開，目的是通過實際問題的解決過程，分析在服務拆分到一定粒度后，服務調用鏈變長，如何評估、提升整體性能。

一、問題的提出

在架構設計階段，大家比較關心的幾個基本要素包括：性能、可用性、一致性、擴展性、安全性。其中性能問題在起步階段往往容易被忽略，但隨著架構的逐步演進，規模越來越大，性能問題會變得越來越重要，很可能一個小小的改動，就可以節省一半的服務器資源。

那性能到底表現在哪些方面？

●一個是響應時間，也就是發送請求和返回結果的耗時；

●另一個是吞吐量，也就是單位時間內響應次數。

當然這兩個指標是在一定資源限制下才有意義。例如要占用多大磁盤、多少CPU、多大內存等。吞吐量和響應時間之間也互為影響，雖然這不是絕對的。

平時比較常見的性能問題包括：

●內存泄露——導致內存耗盡

●過載——突發流量，大量超時重試

●網絡瓶頸——需要加載的內容太多

●阻塞——無盡的等待

●鎖——通過限制

●IO繁忙——大量的讀寫，分布式

●CPU繁忙——計算型常見問題

●長請求擁塞——連接耗盡

當吞吐量有問題的時候，我們期望通過線程或者進程的方式來擴展，線程的方式比進程的方式要復雜得多，因為線程方式需要考慮共享數據變化的問題。

微服務就是一種進程擴展的模式。我們可以嘗試給微服務下一個定義：

一種架構風格。

●單個服務盡量專注一件事情，高內聚、低耦合；

●進程隔離；

●每個服務可以獨立的開發、測試、構建、部署；

●小且靈活；

微服務架構帶來的優勢包括：

●交付周期。每個服務可以獨立開發、測試和交付，降低周期；

●快速溝通。小團隊開發，降低代碼耦合度導致的溝通成本； 業務按服務拆分，新人不需要了解整體架構，上手快；

●定制化。可以根據市場需求，靈活多變地組合出新的業務場景；

●隔離性。進程隔離方式，故障范圍有效控制；

●技術棧。可以根據需求，按服務選擇不同技術棧；

●演進優化。可以按照服務粒度進行演進優化；

同時帶來的問題包括：

●架構復雜度。由于服務數量暴增引起的各種復雜的架構問題。例如一致性問題、大量遠程接口調用的復雜度；

●管理成本。服務數量爆炸導致管理、運維成本升高。我們希望交付周期短，周期短必然引起變更快，變更是可用性的天敵。需要通過自動化、可視化的手段解決問題；

●故障定位。例如一個涉及幾十個服務的請求，如何在故障發生的時候快速定位問題；

●性能損失。原本一次調用可以返回結果，現在需要流經幾個或幾十個服務才能返回結果，如何提升響應時間的問題； 由于拆分導致的吞吐量降低，如何補償？云化就意味著可以橫向擴展。架構如何實現擴展？提升整體的系統吞吐量。

二、實踐過程

第一步，樹立目標。

通常你得到的需求是這樣的：“速度要快！”“跟以前比，性能不能降低”。很明顯，這并不是一個有效的指標。

如何設立目標呢？先列出幾種常見卻無效的目標。

●平均響應時間1s

可以看這組數據，[2, 5, 3, 4, 301, 4, 2, 8, 7, 3, 3, 1, 1, 8, 2] AVG(f)=23.6平均響應時間因為一次非常嚴重的超時導致偏離。無法正確描述響應時間。

●99%請求要在1S內完成

首先，不同的業務，響應時間不應該相同；

其次，單純的設定響應時間毫無意義，要在吞吐量之下進行設定；

●支持100萬并發用戶？

首先，這并不等于系統吞吐量的設定；

其次，系統目前有多大數據量，增長速度是前提；

●錯誤率

指標再高，有錯誤也沒用。

我們可以嘗試這樣來設定：

例如下單操作，

響應時間95%<1s

吞吐量>10萬tps

系統數據量：10億>訂單表>1億……

增長速度：1億/年

資源限制：服務器資源……

其他影響因素……

同時，其他目標也要同步設定，例如系統整體可用性、一致性等。

第二步，尋找瓶頸點。

首先進行壓力測試。可以從生產環境引流進行測試，測試環境測出來的結果毫無意義。另外，要基于場景測試，單測某個功能無意義。

其次，要進行全面的監控，包括調用鏈分析，快速定位性能瓶頸點。

第三步，優化。

優化的手段有很多，包括：同步轉異步、阻塞轉非阻塞、數據冗余、數據拆分、數據合并、壓縮、簡化業務環節等等。關鍵取決于應用場景和成本。

服務化框架

如圖1所示，一個電商里的詳情頁面會調用價格、庫存、商品等服務，綜合展示信息，如果是串行調用，總耗時等于每個服務耗時之和；如果是并行調用，總耗時等于三個服務耗時的最大值，性能提升顯著。

還有很多其他的優化點，例如：

●使用高效的序列化協議，protobuf、thrift等協議要比http+json的方式好很多，可以在服務內部使用；

●采用長連接，避免重復建立連接導致的性能損失；

●業務線程和IO線程隔離等。

消息中間件

通過消息中間件可以削峰填谷，提升吞吐量。如圖2，下單操作直接發送到MQ即返回，由MQ保障最終一致性，還能夠降低響應時間。把依賴關系從強依賴變成弱依賴。也就是說，訂單系統的暫時不可用，對下單操作無影響。另外，MQ的吞吐量遠遠大于關系型數據庫，MQ擴展相對要方便很多。

當然，使用MQ也有一定的問題，有一個一致性的時間窗口，對于要求強一致的業務來說，是比較致命的。

分布式緩存

緩存是被用來提升性能的利器。本地緩存不能共享，會導致比較大的內存浪費，另一方面，垃圾回收也會影響業務服務。在微服務架構中，我們普遍要求把狀態外置到緩存、數據庫中，大型應用多采用分布式緩存。

由于數據庫擴展起來比較復雜，帶來的后遺癥較多，用緩存來平衡數據庫的壓力是非常好的做法。

分布式緩存，例如redis、memcache，吞吐量大概在10萬qps這個級別，相對數據庫幾千qps來說是一個非常大的提升。

當然，分布式緩存帶來的問題就是一致性的問題，什么時候去更新緩存？如果緩存更新失敗、數據庫更新成功怎么辦？

數據庫

數據庫的優化是非常直接有效的。

以優先級來排序，優化的方式如下：

●索引、冗余、批量寫入

●減小鎖粒度

●減小復雜查詢

●適當轉移事務處理

●提升硬件性能

●讀寫分離

●分庫

●垂直分表

●水平分表

●根據業務情況選擇NoSql

三、案例分析

如圖3，在電商中，一個價格服務，為了提升寫的效率，可以采用消息中間件，為了解決重復提交的問題，（特別是當某個系統不可用的時候，用戶會頻繁提交，導致人為的風暴）可以通過緩存去做排重。

如果一個用戶提交了一百萬價格變動信息，另一個用戶提交了一個價格修改請求，這個請求會被那一百萬請求阻塞很長時間，這時候就需要消息中間件有優先級的概念，如果不能做優先級，可以通過建立多個隊列分類來解決問題。

如果一個用戶提交了一百萬條價格修改，發現其中有一個錯了，改了其中一條再提交，按照上述方式會導致新版本被老版本覆蓋，我們需要通過建立版本號的方式解決這個問題。

四、總結

●并不是所有的地方都需要高性能，需要權衡代碼可讀性維護性，架構復雜度 ；

●優化之前，找到驅動力；

●正確對待優化帶來的其他問題。

11月9-12日，北京國家會議中心，第六屆TOP100全球軟件案例研究峰會，華為精益敏捷專家陳軍將分享《華為百人團隊精益看板演進變革之路》；華為云計算測試經理李超峰將分享《華為云虛擬化質量平臺建設實踐》。

TOP100全球軟件案例研究峰會已舉辦六屆，甄選全球軟件研發優秀案例，每年參會者達2000人次。包含產品、團隊、架構、運維、大數據、人工智能等多個技術專場，現場學習谷歌、微軟、騰訊、阿里、百度等一線互聯網企業的最新研發實踐。

TOP100大會將于11月9日-12日在北京國家會議中心舉辦，在現場通過對案例的復盤總結，分享成功者背后的經驗和方法。大會開幕式單天體驗票免費入口。